A.22:4 - 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 satisfy its defining predicate and retain identity under that predicate’s occurrence rule. A 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. A usable frame states the question, admissible action, and stop or return condition. A generic phrase such as “current use” or “appropriate structure” is not a use frame. Any optional explanatory overread follows F.19:4’s plausible-reader test and remains outside structure identity.

A system may perform dated structure-selection work by an exact method and may create a result episteme about the selected structure. Recover that basis when a load-bearing selection claim is current. The method, work, A.6.1 binding or direct participation relation, decision, and C.2.1 result episteme are neighboring objects outside structure identity.

A diagram, graph, table, model, description, view, or publication may designate, represent, or describe the selected organization and its already identified constituents. Use C.29, C.2.1, E.17.0, and the exact publication or source-use patterns for those neighboring claims; the direct participant and relation predicates remain the obtaining basis.

A.22:4.1 - 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, admissible action, and stop or return condition.

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. A change to an explanatory guard alone does not change identity. If its content changes an applied constraint or a frame value, compare that existing discriminator.

If no current predicate definition, applicability condition, or occurrence rule can identify the required constituent or test the obtaining-relation claim for this use, stop at the exact description or representation and return missing-governor. If the governor exists and the available case basis is sufficient to apply its positive test but that test fails, return factually unsupported; if a fact needed to decide the test is unavailable, return missing-information. State a negative only when an applicable non-obtaining criterion or complete closure basis and satisfying facts establish it. If the constraints or named use frame are absent, name that exact gap: 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: exact stop or return condition
  groundedNonAdmissibleUse?:

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. stopOrReturnCondition is another name for stopOrNonAdmissibleUse, not an independently filled value.

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.

A.22:4.1a - 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; use each neighboring pattern only for the definition or test it contributes. 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.

A.22:4.1b - Constraint-governed unfolding structure

Use A.22.CGUS when the current A.22 structure has several locally declared loci whose bindings identify the independently selected constituents for the unfolding question, and when the selected obtaining relation occurrences together with the applied constraint claims define at least two potential continuations across allowed cases. The loci are not free-standing A.6.5 slots. A separate case- and time-indexed result may enable zero, one, or several candidates. This specialization remains U.Structure; it is not a route, workflow, method, work plan, performed work, decision, evidence relation, gate, architecture description, or publication.

Use 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.

A.22:4.1c - 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 defined and tested 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 obtaining crossing occurrences that satisfy independently defined predicates, 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 crossing predicate and current facts establish 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
  SubjectPatternLocator: A.22
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseRef: conditional selected organization of independently defined 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 independently defined crossing relation obtains and one positive A.22 membership witness is available; 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 defines the intended mapping plan. For each exact dated mapping Work individual, use A.13 to identify the actual performer and let A.15.1 independently admit the Work from its history, enacted Method, extent, and containing-System relation. If the mapping account must also identify the assignment under which the Work was performed, check that relation separately through F.6; F.6 identifies neither assignment nor performer. C.2.1 independently identifies the candidate episteme called a Context Map. While exact independently defined 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 the E.17.0 test establishes EpistemeViewpointConformanceRelation(E, P). Use C.29 for any representation relation and E.17/E.24.PUB for rendering or publication; form and carrier remain separate. Thus Method, plan, Work, performer, optional assignment check, proposal, selected structure, candidate episteme, dependent view membership, representation, and publication stay distinct while the external source terms remain retrievable.

A.22:4.1d - 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 satisfy their defining predicates and identity rules; 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, admissible action, and stop or return condition. Any optional explanatory overread follows F.19:4 and remains outside structure identity. The return condition 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 defines the network’s detailed identity, reference, recursion, local-state, and conformance rules; A.22 does not copy those fields.

Use the first discriminator to record structure constituents. Introduce a separately re-identifiable world-side membership relation only when a receiving use needs it and can supply its participants, obtaining predicate, and identity rule.

A.22:4.2 - Structure claim reliance relation selection

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 definition or test used for that relation. Use that definition for the relation’s required fields and use limits.

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 resolved.

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.

A.22:4.3 - 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 designates an existing U.Episteme: C.2.1 supplies its identity and E.10.D2 constrains its describing use. Every record whose name ends in View@Context remains that same episteme and has U.View membership only when the E.17.0 conformance test to an exact viewpoint episteme passes. A.6.3 supplies only an optional source-to-receiving construction. The @Context suffix is a local retrieval convention; it does not add a context object or identity field.

In the description and view forms below, admissibleUse states the actual use and its limits. nonAdmissibleUse?, also named groundedNonAdmissibleUse?, carries one optional explanatory guard under F.19:4’s plausible-reader test; the two names do not introduce separate fields.

StructuralDescription@Context ::= {
  descriptionId,
  entityOfConcernRef,
  effectiveReferenceScheme,
  selectedViewpointRef?,
  selectedModelUseStructureRef?,
  structureRefs: FinSet(U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidenceRelationRef | EvidenceProvenanceRelationRef | MathLensUseOutputRef | StructureUseReturnConditionRef | U.EpistemeRef),
  describingEpistemeRef,
  admissibleUse,
  nonAdmissibleUse?
}

StructuralView@Context ::= {
  viewId,
  entityOfConcernRef,
  effectiveReferenceScheme,
  selectedViewpointRef?,
  selectedModelUseStructureRef?,
  structureRefs: FinSet(U.StructureRef),
  structuralAspectDescriptionRefs?,
  selectedRelationsOrOperations,
  hiddenOrLostStructure,
  admissibleUse,
  nonAdmissibleUse?
}

The exact EntityOfConcern and effective scheme identify the episteme with its claim content under C.2.1. selectedViewpointRef, when present, records that this named describing use selects exact viewpoint P; it does not establish conformance or U.View membership. selectedModelUseStructureRef, when present, resolves one independently selected BoundedModelUseStructure used by the receiving assertion or calculation; it is neither episteme identity nor another viewpoint field. When reliance is on a named claim, U.EpistemeRef resolves the exact C.2.1 claim-bearing episteme; a PatternID normally locates the definition, constraint, or test it uses, and an exact ClaimGraph is added only when that identity changes the use.

A.22:4.3a - Orientation belongs to a representation of a named structure

Use vertical, horizontal, above, below, or at the same level as structural shorthand only when the reader can recover which object’s structure is represented, which relation is shown, and how the drawing or ordering convention represents it. These words can make an explanation easier to follow. Their useful content comes from the named structure and convention.

For example, a diagram of a Method’s composition may place encompassing Methods above their constituents and draw each established methodPartOf connection upward. A diagram of result use may place a supplying Method to the left of a receiving Method. The second diagram needs to state what result is used and under what conditions; its horizontal arrow supplies no parthood claim. Rotating either diagram changes its orientation, not those relations. Conversely, two boxes at the same height need not denote peers, independent participants, objects of one kind, or simultaneous work.

Recover the relation before choosing an axis:

A holon can participate in several structures, each with its own relevant relations and constraints. A family of holons drawn as a hierarchy need not be one tree. Calling a representation a lattice requires the mathematical claim actually used: a specified order, the requisite meets and joins, and a justified correspondence to the represented subject under C.29. A branching picture or the presence of several encompassing wholes establishes none of these properties.

For a first explanation, a sentence such as “in this diagram of Method composition, upward arrows connect a constituent to its encompassing Method” is sufficient when the relations are already clear. Add a separate structure, view, or mathematical account only when the intended use needs it. C.30.ASV:4.5a develops the selection of structures for Methods; C.30.STRAT recovers an unresolved architecture label.

A.22:4.4 - Extracted and transformed structural views

Use extracted or transformed structure records when a view of structure is obtained from a corpus, trace, model, simulation, or generated representation, through a mathematical lens or coarsening pass, or within an observer or budget boundary, and may hide distinctions.

ExtractedStructuralView@Context ::= {
  extractedViewId,
  entityOfConcernRef,
  effectiveReferenceScheme,
  selectedViewpointRef?,
  selectedModelUseStructureRef?,
  sourceCorpusOrTraceRefs,
  structureRefs: FinSet(U.StructureRef),
  extractionDescriptionRef,
  preservedStructure,
  lostStructure,
  validationBoundary,
  structureUseReturnCondition,
  admissibleUse,
  nonAdmissibleUse?
}

StructureExtractionDescription@Context ::= {
  extractionDescriptionId,
  entityOfConcernRef,
  effectiveReferenceScheme,
  selectedViewpointRef?,
  selectedModelUseStructureRef?,
  sourceInputKind,
  lensOrMethodRef,
  budgetOrObserverBoundary?,
  preservedStructureKinds,
  lostStructureKinds,
  validationBoundary,
  structureUseReturnCondition,
  admissibleUse,
  nonAdmissibleUse?
}

StructuralAspectDescription@Context ::= {
  aspectDescriptionId,
  entityOfConcernRef,
  effectiveReferenceScheme,
  selectedViewpointRef?,
  selectedModelUseStructureRef?,
  aspectKindRef,
  structureRefs: FinSet(U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidenceRelationRef | EvidenceProvenanceRelationRef | MathLensUseOutputRef | StructureUseReturnConditionRef | U.EpistemeRef),
  admissibleUse,
  nonAdmissibleUse?
}

StructuralCoarseningDescription@Context ::= {
  coarseningDescriptionId,
  entityOfConcernRef,
  effectiveReferenceScheme,
  selectedViewpointRef?,
  selectedModelUseStructureRef?,
  sourceStructureRefs: FinSet(U.StructureRef),
  resultStructureRefs: FinSet(U.StructureRef),
  preservedUnder,
  brokenBy,
  lostStructure,
  structureUseReturnCondition,
  admissibleUse,
  nonAdmissibleUse?
}

A.22:4.5 - 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.

A.22:4.6 - 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 the architecture claim or selected architecture-relevant structures. An asserted actual architecture relation is an independently obtaining C.30 ArchitectureRelation between an exact holon and an exact selected structure.

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

C.30 uses A.22 to identify one selected architecture-relevant structure, then tests the direct ArchitectureRelation between that structure and one exact holon. C.30.ASV separately defines and tests an architecture structural view. A reference from an architecture description establishes neither the direct relation nor view conformance.

Architecture-related terms governed by C.30 or its subpatterns include ArchitectureRelation, 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.

A.22:4.7 - Boundary and repair table

A.22:4.8 - 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 satisfy their defining predicates
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 C.29 graph may represent the same organization, while the direct predicates of the selected relation occurrences remain its obtaining basis. A visually identical graph with an unestablished connection remains a representation candidate.

Architecture kernel slice. A team says, “the architecture is the graph.” Recover the selected structure and the graph’s exact reliance relation:

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, structure or crossing record selected under E.18, or E.18.2 mathematical graph description,
  relationContribution = E.18 selected-structure or crossing definition | A.6.6 base-dependence test | independently established support relation recovered through A.10 provenance and bounded-use account | C.29 mathematical-lens result, chosen for the claim 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
stop or return condition: stop at the selected reliance relation's result; for a Work, evidence, gate, or decision claim, apply its specific test in A.22:4.7
non-admissible use: the graph as the whole architecture

The practitioner can now use the graph through the selected source-description, base-dependence, evidence, or lens relation and route the architecture claim to C.30.TFS-REL.

Extracted code structure slice. A code-agent relation graph or probe JSON reports imports, calls, registry wiring and data-flow links. Recover the source codebase or publication, extraction method, preserved and lost structure, validation boundary and structure-use return condition. That establishes the declared extraction result only. For an A.6.3 epistemic-viewing claim, identify source episteme X and receiving episteme Y, their same EntityOfConcern, and the projected or re-expressed ClaimGraph and ReferenceScheme. Qualify Y as a U.View only when the applicable E.17.0 viewpoint conformance independently obtains. A claim about the codebase architecture, internal agent belief, assurance or release readiness still needs its own evidence and governing predicate.

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