#Structure and Structural Views (STRUCT-CAL)

A.22 · Stable · Architectural pattern · Normative unless explicitly marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when a practitioner needs to select U.Structure as the EntityOfConcern: an organization among exact constituents and obtaining relations, selected to expose a relation class, applied constraint, invariant, variation class, preserved arrangement, or lost arrangement that changes the next engineering or reasoning action.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner needs to select U.Structure as the EntityOfConcern: an organization among exact constituents and obtaining relations, selected to expose a relation class, applied constraint, invariant, variation class, preserved arrangement, or lost arrangement that changes the next engineering or reasoning action.

The first A.22 question is not “which diagram or record shows the structure?” It is “which organization is selected for this named use?” Recover that organization in this order:

1. identify every constituent independently under its direct governing pattern;
2. recover the exact relation occurrences among those constituents that actually obtain under their direct predicates;
3. state the exact constraints applied to those constituents and relations, plus the named selection-use frame that says what question or action this organization serves;
4. name the resulting selected organization and the admissible action or stop that follows.

When the use makes a load-bearing claim that a structure was selected, also recover the selecting system, its method-governed dated selection work, and the exact direct participant relations or A.6.1 bindings used by that work. Those neighboring facts support the selection judgment; they do not enter U.Structure identity. If the judgment must persist, identify a separate C.2.1 result episteme whose claim content designates the selected structure.

The first useful move is small:

StructureQuestionCard@Project:
  named selection use:
  independently identified constituents:
  exact obtaining relation occurrences selected:
  constraints applied:
  selected structure:
  preserved structure:
  lost, hidden, or excluded structure:
  admissible action:
  stop or non-admissible overread:
  selecting system, method, and dated work, when selection is claimed:
  selection-result episteme, when a durable result is needed:
  claim scope or effective reference scheme of that claim, if current:
  reliance relation, if a neighboring reliance claim is being made:

StructureQuestionCard@Project is a project-side triage aid for this selected-structure use. It is not a new structure kind. Fill the reliance row only when extraction, coarsening, source-description, base-dependence, grounding, evidence, lens, simulation, representation, or action reliance is being claimed; otherwise leave it unused and keep the move on selected structure.

Here @Project is a compatibility and retrieval cue, not a type or relation assertion. It identifies neither a project entity nor a composite project U.Work, and it establishes no context, authority, viewpoint, or parthood. When this card is used in relation to one actual project, name that exact composite U.Work and the direct relation by which the current structure-selection work, decision, description, or other governed object concerns it. Otherwise no project-work reference is implied. The same rule applies to ArchitectureStructureKindTriage@Project below.

Stop at this card when it makes the next structure use clear. Open heavier records only when a named description, view, publication, extraction, coarsening, comparison, mathematical-lens, architecture-description, or other neighboring claim is being made.

What goes wrong if A.22 is missed: the practitioner reasons from the visible diagram, source publication, source-use record, lens output, generated representation, project record, or architecture description instead of asking which organization is selected and what loss or reliance boundary matters for action.

What A.22 buys in practice: a practitioner can name selected structure, state preserved and lost structure, name source-basis or lens reliance only when it is being claimed, add a StructureUseReturnCondition when loss matters, and apply the FPF pattern that governs any non-structure claim being made.

Not this pattern when the question under repair is grounded architecture adequacy, architecture structural-view adequacy, or mathematical-lens use. Use [C.30](/generated/patterns/C.30), [C.30.ASV](/generated/patterns/C.30.ASV), or [C.29](/generated/patterns/C.29) respectively. For any other claim being made, use the governing FPF pattern and keep A.22 only to the selected-structure portion.

Thin precision-restoration pointer: when the wording still may name a structure, a structure description, an architecture description, a view, a publication form, or another governed claim, use [C.30.P](/generated/patterns/C.30.P) or [C.30.STRAT](/generated/patterns/C.30.STRAT) first as triggered. Apply A.22 only after the selected-structure claim or structure-view portion is recoverable.

#Problem

FPF needs a selected-structure EntityOfConcern that is useful before any one domain ontology, mathematical formalism, architecture notation, or publication form takes over. Working projects often notice that "the structure" is doing real work:

• dependencies repeat across cases;
• a method or work description hides an invariant relation;
• a model compresses a trace by preserving one relation class and losing others;
• a diagram shows an arrangement but is mistaken for the arrangement itself;
• a mathematical lens exposes preserved structure but is then overread as ontology;
• an architecture discussion needs selected structure over a holon before it can describe architecture.

How can FPF let a practitioner name structure as an EntityOfConcern while preserving the distinction between:

• selected structure and the source-description relation, source-use relation, evidence relation, lens output, simulation, generated representation, or declared substrate from which it was inferred or declared;
• structure and a Description episteme or view of that structure;
• structure and a publication face, diagram, table, graph, or publication form;
• structure and mathematical-lens application;
• structure and another FPF claim kind governed by its governing pattern;
• structure in general and architecture-specific structure selected by C.30.

#Forces

#Solution

Select U.Structure as the A.22 ontic head: a dependent, non-agentive organization selected from independently identified constituents and exact obtaining relation occurrences under applied constraints for one named use frame.

The constituents keep their own identities and kinds. Every selected relation occurrence must already obtain and retain identity under its direct governing pattern. A.22 neither creates those participants nor makes their relations obtain. An exact system or practitioner selects their organization; A.22 supplies the identity and boundary rule for that selected organization.

The applied constraints are the exact constraint claims used in the selection judgment, not the identity of the document, table, rule card, or constraint episteme that carries them. The named use frame states the question being answered, the admissible action, and the non-admissible overread. A generic phrase such as “current use” or “appropriate structure” is not a use frame.

A system may perform dated structure-selection work by an exact method and may create a result episteme about the selected structure. The system acts; the pattern, constraints, graph, result, and structure do not. The method, work, A.6.1 binding or direct participation relation, decision, and C.2.1 result episteme are neighboring objects. None constitutes or reidentifies the structure.

A diagram, graph, table, model, description, view, or publication may designate, represent, or describe the selected organization and its already identified constituents. Its form does not establish a constituent's identity, make a relation obtain, or select a structure. Use C.29, C.2.1, E.17.0, and the exact publication or source-use patterns for those neighboring claims.

#Base U.Structure Identity and Selection

For a selected structure S, recover four identity discriminators:

StructureIdentity(S) = <
  exact independently identified constituents,
  exact selected obtaining relation occurrences,
  exact constraints as applied,
  one named selection-use frame
>

Base U.Structure identity has no ambient context field. A bounded-context label, U.ContextSlice, U.ClaimScope, project record, description, view, graph, table, or publication is not automatically an additional discriminator. If an exact scope is referenced by an applied constraint, that constraint contributes through the third discriminator. If a model-use structure is independently selected as a constituent of another structure, it contributes through the first discriminator.

The first discriminator is an exact plurality, not a graph node set created by notation. A separately useful C.13 collection may designate the same constituents, but collection membership neither proves parthood nor replaces their direct identities. The second discriminator contains the exact relation occurrences chosen for this organization; a relation name, edge label, tuple position, or adjacency row is insufficient. The third contains the semantic constraints actually applied; changing only the rationale, formatting, or publication of an unchanged constraint claim does not change this discriminator. The fourth names the use question and its admissible action or stop.

Two references resolve to the same U.Structure when all four discriminators resolve to the same values. A changed designator, selecting system, method, work occurrence, result episteme, description, graph, representation scheme, view, or publication leaves the structure unchanged when the four discriminators remain unchanged. Replacing a constituent, a selected relation occurrence, an applied constraint, or the named use frame can identify another structure. If a relation occurrence itself may have been reidentified, apply its direct relation pattern before reapplying A.22.

If the constituents or obtaining relations cannot be recovered, stop at the exact description or representation and return the missing-governor or missing-grounding question. If the constraints or named use frame are absent, the material may show an arrangement, but it does not yet support the claimed selected U.Structure.

The following two compact records are recovery aids, not new ontic kinds. In SelectedStructureBasis, the selected structure, constituents, selected obtaining relations, applied constraints, and use frame state identity; the preserved/lost and action/stop rows state the use-return boundary rather than adding identity fields.

SelectedStructureBasis:
  selectedStructureRef:
  constituentRefs:
  selectedObtainingRelationOccurrenceRefs:
  appliedConstraintClaimRefs:
  namedSelectionUseFrame:
  preservedStructure:
  lostHiddenOrExcludedStructure:
  admissibleAction:
  stopOrNonAdmissibleUse:

StructureSelectionUse:
  selectingSystemRef:
  selectionMethodRef:
  selectionWorkRef:
  directParticipationOrOperationBindingRefs:
  selectedStructureRef:
  selectionResultEpistemeRef?, when the judgment must persist:
  selectionDecisionRef?, when an accountable choice is current:

StructureSelectionUse records how a system performed the selection and reached the judgment. SelectedStructureBasis records the four identity discriminators plus the use-return boundary. Do not copy the system, work, method, result episteme, or decision into the structure basis. A U.ClaimScope, effective U.ReferenceScheme, or model-use structure that merely qualifies a claim about either record does not enter base identity. A scope referenced by an applied constraint or a model-use structure selected as a constituent enters only through that already declared discriminator.

A.22 structure-aspect names such as functional, mereological, modular, transformation-flow, control, semantic, causal, dynamical, algebraic, topological, geometric, or coarse-grained remain cues for which relations and constraints to recover. They do not identify a structure without the four discriminators. C.30.ASV ArchitectureStructureKindRef values remain architecture-local classifiers; a matching label does not imply identity.

#Compact auxiliary boundary

Use description, publication, source-use, evidence, work, gate, decision, release, architecture-description, and mathematical-lens patterns when those claims are being made. The A.22 application contains the selected-structure portion and the structure-use return condition that protects that structure use; neighboring claims remain with their governing patterns. A publication, diagram, graph, table, dashboard, file, model card, generated representation, or lens output may make a structural description or view available; it does not become the selected structure or supply neighboring claim authority by appearance.

#Constraint-governed unfolding structure

Use A.22.CGUS when the current A.22 structure is an organization among several governed loci and constraints: admitted starting records, already-current starting structures, relation signatures, constraints, invariants, guarded transitions, preserved and lost structure, admissible next forms, and conditions for stop, return, split, or currentness refresh. This structure specialization is still U.Structure; it is not a route, workflow, method, work plan, performed work, decision, evidence relation, gate, architecture description, or publication.

Open A.22.CGUS only when the candidate has several loci and cross-locus constraints. A route card, table, graph, README entry, narrative, slide, or happy-path example may describe or demonstrate the unfolding structure, but it is not the structure itself.

#Bounded And Cross-Context Model-Use Structure Specializations

BoundedModelUseStructure is a U.Structure selected over one exact model episteme, exact admitted model-use holons, the obtaining model-applicability, actual model-use, and model-expression-coherence occurrences governed by A.1.1, exact applied constraint claims used by the selection judgment, and one named bounded-model-use frame. Its A.22 identity uses exactly those constituents, selected occurrences, exact constraint claims, and frame. A claim scope, membership outcome, boundary display, or carrier is not an applied constraint by itself; a constraint claim may instead state a proposition about that scope or its A.2.6 membership predicate. No boundary crossing participates in that identity. Continuity across model editions additionally requires the exact C.2.1 episteme-edition relation and declared A.1.1 continuity rule. It is not a holon, description, view, or endpoint manufactured by a later crossing.

CrossContextRelationStructure is a conditional specialization of a different already identified U.Structure. Membership requires exact independently governed obtaining crossing occurrences selected among several bounded model-use structures, applied constraints, and one named crossing-analysis use, with all four A.22 base discriminators established. Until a compatible direct crossing governor supplies those occurrences, a Context Map can describe only a proposed crossing organization and no positive CrossContextRelationStructure member is asserted. The selecting system and its work remain separate. Sharing a participant does not merge structures, and overlap does not prove parthood.

Pending local name settlement. The following F.18 NameCard is local to A.22 while the positive crossing-occurrence basis is unavailable. It does not create the structures, crossing relations, mapping method, or view.

NameCard:
  NameCardId: NC-CROSS-CONTEXT-RELATION-STRUCTURE
  GovernedValueRef: U.Structure selected over several BoundedModelUseStructure values and their exact crossing relations
  GoverningPatternRef: A.22
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseRef: conditional selected organization of independently governed obtaining crossings among several bounded model-use structures under all four A.22 base discriminators; a Context Map may describe only a proposed organization until that exact positive basis exists
  TechLabel: CrossContextRelationStructure
  PlainLabel: relations among bounded contexts
  CandidateSet: CrossContextRelationStructure; BoundedContextRelationStructure; ContextRelationStructure; ContextMapStructure
  RejectedCandidates: BoundedContextRelationStructure hides plurality; ContextRelationStructure leaves the endpoint kind unresolved; ContextMapStructure confuses the structure with the DDD view and FPF Map
  SelectionRationale: reserve one local retrieval label for the conditional cross-structure rule without retyping its proposed description, view, diagram, or publication as an admitted structure
  PublicRowStatus: pending
  LineageEntries: replaces broad context-map and bounded-context-relation wording
  RefreshCondition: reopen when an independent direct governor supplies an exact obtaining crossing and one positive A.22 membership witness; only then rerun F.18/F.17 for public reuse

This pending card has no UnifiedTermRowRef. Until its refresh condition is met, CrossContextRelationStructure is an A.22-local provisional designator only; other Core hosts must cite the descriptive A.22 conditional cross-structure rule rather than consume that label as public vocabulary.

DDD Context Mapping names a repeatable U.Method. A.15.2 governs intended mapping work; A.15.1 identifies each exact dated mapping Work individual admitted under U.Work, the performer system and obtaining role assignment, and the exact enactsMethod relation. C.2.1 independently identifies the candidate episteme called a Context Map. While exact independently governed crossing occurrences or the four A.22 base discriminators are missing, its EntityOfConcern is the proposed or described crossing organization, not an exact CrossContextRelationStructure. Only after both conditions are met may a corresponding C.2.1 episteme designate the exact structure. Either episteme is additionally a U.View only when exact EpistemeViewpointConformanceRelation(E, P) obtains under E.17.0. Any C.29 representation, rendering, publication occurrence, form, and carrier remain separate under their direct patterns. Thus method, work, proposal, selected structure, candidate episteme, dependent view membership, representation, and publication stay distinct while the external source terms remain retrievable.

#Transformation-flow structure network profile

Use E.18.NET when one engineering use selects two or more independently identified transformation-flow structures, or nested networks of them, together with exact obtaining relations across their boundaries. Apply the four A.22 discriminators directly: the exact TFS or nested-network members are the constituents; the exact cross-member relation occurrences retain their direct governors; the exact applied endpoint, boundary-exposure, and acyclic direct-member constraints are selected under E.18.NET; and the named network-use frame states the practical question or action and the forbidden overread. Record the return condition separately; it reopens selection when a member, relation, constraint, or use-frame value changes and is not a fifth identity discriminator. The result is one dependent, non-agentive U.Structure specialization. E.18.NET owns the network's detailed identity, reference, recursion, local-state, and conformance rules; A.22 does not copy those fields.

Selecting a constituent in the first discriminator does not create a separately re-identifiable membership occurrence. A member row, graph edge, containment picture, or shared label proves neither membership nor another relation. If a receiving use genuinely needs a world-side membership relation, recover its participants, obtaining and identity under a direct relation governor; otherwise use the exact constituent discriminator and do not mint a generic membership edge.

#Structure claim reliance relation selection

A.22 does not mint a local generic reliance record. When a structure claim relies on something beyond the selected structure itself, choose the reliance relation kind, name the relation record by value, and name the governing pattern:

If no reliance relation kind can be selected, keep the wording as a source-finding note, recognition cue, ordinary help, quote-only wording, or reduced-use cue. Do not create a generic reliance record to make the claim look governed.

U.Structure does not carry description, representation, extraction, mathematical-lens, simulation, or generic reliance state as an internal structure field. Those are source-description, source-use, base-dependence, evidence, lens, extraction, simulation, or publication relations about a structure. PublicationRef is not an admissible substitute for the source episteme, source view, evidence relation, SWBD, or lens output.

#Structural descriptions and views

Structural descriptions and views reuse existing episteme and view machinery. Architecture does not define a second ontology of descriptions, views, viewpoint bundles, multi-view descriptions, publications, publication forms, or source-pin sets. Every record whose name ends in Description@Context here is an existing U.Episteme governed by C.2.1 and qualified for describing use under E.10.D2. Every record whose name ends in View@Context here remains that same episteme and has U.View membership only when E.17.0 conformance to an exact viewpoint episteme obtains. A.6.3 governs only an optional source-to-receiving construction. DescriptionContext is imported, not locally redefined.

StructuralDescription@Context ::= {
  descriptionId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, EffectiveReferenceScheme, ViewpointRef?, ModelUseStructureRef?),
  structureRefs: FinSet(U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidenceRelationRef | EvidenceProvenanceRelationRef | MathLensUseOutputRef | StructureUseReturnConditionRef | NamedClaimGoverningPatternRef),
  describingEpistemeRef,
  admissibleUse,
  nonAdmissibleUse
}

StructuralView@Context ::= {
  viewId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, EffectiveReferenceScheme, ViewpointRef?, ModelUseStructureRef?),
  structureRefs: FinSet(U.StructureRef),
  structuralAspectDescriptionRefs?,
  selectedRelationsOrOperations,
  hiddenOrLostStructure,
  admissibleUse,
  nonAdmissibleUse
}

descriptionContext.ViewpointRef is the viewpoint field. Do not duplicate it locally under another name unless the governing pattern supplies a more specific view record.

#Extracted and transformed structural views

Use extracted or transformed structure records when a corpus, trace, model, lens, simulation, generated representation, coarsening pass, observer boundary, or budget boundary produces a view of structure that may hide distinctions.

ExtractedStructuralView@Context ::= {
  extractedViewId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, EffectiveReferenceScheme, ViewpointRef?, ModelUseStructureRef?),
  sourceCorpusOrTraceRefs,
  structureRefs: FinSet(U.StructureRef),
  extractionDescriptionRef,
  preservedStructure,
  lostStructure,
  validationBoundary,
  structureUseReturnCondition,
  admissibleUse,
  nonAdmissibleUse
}

StructureExtractionDescription@Context ::= {
  extractionDescriptionId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, EffectiveReferenceScheme, ViewpointRef?, ModelUseStructureRef?),
  sourceInputKind,
  lensOrMethodRef,
  budgetOrObserverBoundary?,
  preservedStructureKinds,
  lostStructureKinds,
  validationBoundary,
  structureUseReturnCondition,
  admissibleUse,
  nonAdmissibleUse
}

StructuralAspectDescription@Context ::= {
  aspectDescriptionId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, EffectiveReferenceScheme, ViewpointRef?, ModelUseStructureRef?),
  aspectKindRef,
  structureRefs: FinSet(U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidenceRelationRef | EvidenceProvenanceRelationRef | MathLensUseOutputRef | StructureUseReturnConditionRef | NamedClaimGoverningPatternRef),
  admissibleUse,
  nonAdmissibleUse
}

StructuralCoarseningDescription@Context ::= {
  coarseningDescriptionId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, EffectiveReferenceScheme, ViewpointRef?, ModelUseStructureRef?),
  sourceStructureRefs: FinSet(U.StructureRef),
  resultStructureRefs: FinSet(U.StructureRef),
  preservedUnder,
  brokenBy,
  lostStructure,
  structureUseReturnCondition,
  admissibleUse,
  nonAdmissibleUse
}

#Structure-use return

StructureUseReturnCondition is present when compression, extraction, coarsening, evidence reuse, mathematical-lens use, simulation, ML evaluation, bounded exception, many-to-many allocation, or decision reliance hides a distinction needed for action, assurance, causal use, legal review, regulatory review, comparison, or subsequent decision reopening.

Do not make structure-use return mandatory for ordinary local recognition when no hidden distinction is being used for action. The condition is needed only when the repaired text still relies on a hidden selected-structure, source-basis, source-description, evidence, lens, simulation, extraction, or representation distinction.

#Relation to architecture

StructuralAspectDescription@Context describes one selected structural aspect under A.22. It is not an ArchitectureStructureKindRef by itself. ArchitectureStructuralView@Context is a C.30.ASV view over structures selected by ArchitectureOf@Context and typed by ArchitectureStructureKindRef.

A.22 is intentionally upstream of C.30. Architecture uses structure; structure does not import architecture as a parent.

C.30 uses A.22 by selecting architecture-relevant structures for one described holon through ArchitectureOf@Context. C.30.ASV then governs architecture structural views over those selected structures. A structure can be used by architecture, but a structure is not an architecture merely because an architecture description refers to it.

Architecture-related records that belong to C.30 or its subpatterns include ArchitectureOf@Context, ArchitectureDescription@Context, ArchitectureStructuralView@Context, ArchitectureStructureKindRef, ArchitectureStructureKindTriage@Project, FunctionalStructureView@Context, ArchitectureTransformationFlowStructureRelation@Context, ControlStructureView@Context, and CrossScopeArchitectureResidualTriage@Context. A.22 may name them as FPF pattern applications. It does not define their architecture-specific conformance.

#Boundary and repair table

#Worked slices

Maintenance-isolation structure selection. A planner needs to choose which relations matter when isolating a pump skid for maintenance.

named selection use: choose isolation points before Pump_37 maintenance
constituents: independently identified Pump_37, Motor_12, Valve_In_4, Valve_Out_4, and Bus_7
selected obtaining relations: exact installed-with, connected-to, supplied-by, and upstream-of occurrences that currently obtain under their direct patterns
applied constraints: isolate every live energy and material path to Pump_37; retain only relations relevant to this isolation use
selecting system: MaintenancePlanner_A
method and work: IsolationStructureSelectionMethod enacted in SelectionWork_2026-07-25
selected structure: Pump37_MaintenanceIsolationStructure
admissible action: prepare the isolation sequence from the selected paths
stop: reopen selection when a constituent, selected occurrence, or isolation constraint changes

Pump37_MaintenanceIsolationStructure is identified by the exact constituents, exact selected obtaining occurrences, applied isolation constraints, and maintenance-isolation use frame. SelectionWork_2026-07-25, the enacted method, and any C.2.1 episteme that records the judgment remain separate. A graph can represent the same organization under C.29; an edge in that graph neither makes its relation obtain nor replaces the exact relation occurrence. A near miss is a visually identical graph assembled from labels when one connection has not been established: it is a representation candidate, not the selected structure claimed above.

Architecture kernel slice. A team says, "the architecture is the graph." A.22 does not accept that sentence as a root-kind claim. The repair is:

declaredStructureSubstrateRef: TransformationFlowStructureRef under E.18, with mathematical graph description under E.18.2 when that expression is the current claim
candidate structure: selected transformation-flow structure
structure-claim reliance relation: selected relation record named by value(
  sourceDescriptionOrPatternApplicationRef = SourceViewRef, E.18 selected structure or crossing record, or E.18.2 mathematical graph description,
  governingPatternRef = E.18, A.6.6, A.10, or C.29 when that reliance claim is being made,
  relationKind = source-description | base-dependence | evidence | lens, selected for this reliance,
  validationBoundary = graph-path currentness boundary, slice currentness boundary, or crossing currentness boundary
)
next FPF pattern application: C.30.TFS-REL when this selected structure is used in an architecture-to-transformation-flow relation
non-admissible use: graph as whole architecture, work, evidence, gate, or decision

The useful structure use survives: the practitioner can use the graph as a governed reliance relation for selected flow structure without turning it into architecture ontology.

Extracted code structure slice. A code-agent relation graph or probe JSON reports imports, calls, registry wiring, and data-flow links. A.22 treats it as an extracted structural view only when the source codebase or publication, extraction method, preserved structure, lost structure, validation boundary, and structure-use return condition are named. The relation graph or probe output is not the codebase architecture itself and is not proof of internal agent belief, assurance, or release readiness.

ExtractedStructuralView@Context:
  sourceCorpusOrTraceRefs: repo snapshot, probe outputs, traces
  preservedStructure: selected typed relation families
  lostStructure: unexplored regions, dynamic calls, hidden generated code, ambiguous relation kinds
  validationBoundary: probe coverage and source codebase or publication edition
  structureUseReturnCondition: when an architecture decision, assurance use, or repair depends on a relation not observed by the extraction

#Archetypal Grounding

#Bias-Annotation

Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: universal within FPF structure claims.

This checklist verifies the preceding guidance after the practitioner has chosen the selected repair action; it is not a required project control form and not a substitute for the card, note, view, relation, or repair guidance above.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

FPF needs one general selected-structure ontic because many useful claims depend on organization before they depend on a specific architecture, mathematical, measurement, or publication pattern. The selected structure is dependent and non-agentive. Claims about it are carried by separate epistemes and views: it can be described, sourced, compared, coarsened, extracted, or used by architecture, but it does not act, select, carry claim content, or certify.

The selected design keeps A.22 small enough for first use. A practitioner can write one StructureQuestionCard@Project and stop. Heavier DescriptionContext, A.6.6 base-dependence, extraction, lens, evidence, and structure-use return records are used only when the next use would otherwise hide loss, source-basis dependence, or non-structure claim kind.

The reason to keep C.30 separate is architectural clarity. Architecture is selected structure for an exact described holon and architecture concern; architecture descriptions are Description epistemes and specification-use cases or views over that claim, while publications only make those epistemes or views available. A.22 supplies the structure substrate, not the architecture ontology.

#SoTA-Echoing

#Relations

Builds on: A.1, C.13, C.2.1, A.6.REL, A.6.0, A.6.5, A.3.1, A.6.1, A.15.1, A.6.P, A.7, A.6.2, A.6.3, A.14, C.16, C.29, E.10.D2, E.10, C.2.P, E.17.0, E.17.1, E.24, E.24.PUB, and F.18.

Coordinates with: A.1.1, A.2.6, A.22.CGUS, C.30.P, C.30.STRAT, C.30, C.30.ASV, C.30.TFS-REL, C.30.LCA, C.30.ILC, A.6.F, E.18, E.18.NET, E.18.3, A.10, G.6, B.3, A.20, A.21, C.28, A.15, C.11, C.16, C.25, G.5, C.33, C.34, and C.35 when architecture-specific structure-capture, preservation, or discovery adequacy claim kinds are being made.

Queue 7b relation note: C.33, C.34, and C.35 govern architecture-specific capture, preservation, and discovery adequacy over selected structures. A.22 keeps the general selected-structure portion; it does not decide architecture use, candidate admission, measurement, evidence, assurance, or decision authority for those adequacy claims.

Does not replace: C.30.P or C.30.STRAT wording-use precision restoration, C.30 for grounded architecture adequacy and conditional architecture-description use, C.29 for mathematical-lens use, C.16 for measurement and characterization, C.28 for causal-use relation, B.3 for assurance, A.10 and G.6 for evidence, A.20 and A.21 for gates and release, A.15 for work, C.11 for decisions, or E.17 for publication.

#A.22:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)