#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: the organization, relation class, constraint, invariant, variation class, preserved arrangement, or lost arrangement that changes a next engineering or reasoning move.

#Keywords

• structure
• structural view
• selected structure
• preserved and lost structure
• source return
• architecture-description boundary
• structural description.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner needs to select U.Structure as the EntityOfConcern: the organization, relation class, constraint, invariant, variation class, preserved arrangement, or lost arrangement that changes a next engineering or reasoning move.

The first A.22 question is positive: what is organized, over which bounded context and declared substrate, which relation, constraint, invariant, or variation matters, what is preserved, what is lost or hidden, and which admissible use or stop condition follows.

The first useful move is small:

StructureQuestionCard@Project:
  declared structure substrate:
  bounded context:
  selected structure:
  relation, operation, constraint, invariant, or variation class:
  preserved structure:
  lost, hidden, or excluded structure:
  reliance relation, if being claimed:
  admissible use:
  non-admissible overread:
  governingPatternApplicationRefs, if another claim is being made:

StructureQuestionCard@Project is a project-side triage aid for this selected-structure move. 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.

Stop at this card when it makes the next structure move 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, 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 or lens reliance only when it is being claimed, add a SourceReturnCondition 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, evidence path, 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 EntityOfConcern used when selected organization changes a next engineering or reasoning move.

U.Structure is the organization of typed relations, constraints, invariants, variation classes, and admissible references to operation or dynamics descriptions over a declared substrate, or declared A.6.6 base declaration when base-dependence is being claimed, inside a bounded context and admissible-use frame.

The A.22 ontic head is intentionally narrow. U.Structure is the selected organization under concern: typed relations, constraints, invariants, variation classes, operation or dynamics references, preserved organization, and lost organization over a declared substrate in a bounded context. The grounding object may be a U.Holon, U.System, U.Episteme, declared substrate, or another governed value named by the current use; the selected structure remains the structure of or over that object.

The first useful A.22 move is about the selected structure itself: name the bounded context, selected structure, relation, constraint, invariant, variation class, operation or dynamics reference that matters, preserved or lost organization, and the source-return condition or governing-pattern application needed for work. Description records, views, publications, diagrams, publication forms, and renderings are aids that make that structure move inspectable, reusable, comparable, or safe to rely on; they do not share the center of the Solution.

U.Structure may fill EntityOfConcern for a structure description, view, or structure-claim relation. When a structure description or view is being used, DescriptionContext.EntityOfConcernRef names the selected structure, structure claim, or relation governed by the governing pattern for that use; publication forms, publication units, and renderings only make the episteme or view available.

A.22 governs U.Structure as a dependent, non-agentive ontic head. It works first over selected-structure EntityOfConcern records and structure-claim reliance relations. Structural descriptions, structural views, extracted structural views, structural-aspect descriptions, structural-coarsening descriptions, and structure-general source-return conditions are subordinate record forms used only when they preserve the selected-structure move, expose loss, enable comparison, or state a reliance boundary. A.22 does not govern architecture descriptions directly; C.30 and its subpatterns govern architecture as a use of selected structure over a described holon.

#Selected Structure Object

U.Structure ::= {
  structureId,
  declaredStructureSubstrateRef:
    U.EntityRef | U.HolonRef | U.EpistemeRef | DeclaredSubstrateRef,
  boundedContextRef,
  relationSignatureRefs?,
  operationOrDynamicsDescriptionRefs?,
  constraintRefs?,
  invariantRefs?,
  symmetryRefs?,
  topologyOrGeometryRefs?,
  stateSpaceRefs?,
  causalOrPredictiveDescriptionRefs?,
  informationRegularityRefs?,
  coarseGrainingRefs?,
  generalStructureAspectKindRefs:
    functional | mereological | modular | transformationFlow |
    control | workMethod | roleEnactor | evidenceAssurance |
    semantic | informational | causalPredictive | dynamical |
    algebraic | topological | geometric | scaleCoarseGrained |
    otherDeclared,
  granularityOrScaleRef?,
  equivalenceOrIsomorphismCriterion?,
  variationClassRefs?,
  preservedUnder?,
  brokenBy?,
  admissibleUse,
  nonAdmissibleUse
}

The field list is a recovery aid, not a demand to fill every field. The ordinary record names only the fields that carry the next admissible move. When state, dynamics, causality, measurement, bridge, evidence, assurance, gate, work, decision, or mathematical-lens claims are being made, the record names the governing pattern instead of absorbing that claim kind into A.22.

A.22 generalStructureAspectKindRefs are general structure-aspect cues. C.30.ASV ArchitectureStructureKindRef values are architecture-local structure-kind classifiers for structures selected by ArchitectureOf@Context. A matching label does not imply identity. Use a declared mapping when an A.22 aspect is used as an architecture structure kind.

#Compact auxiliary boundary

Use description, publication, source, evidence, work, gate, decision, release, architecture-description, and mathematical-lens patterns when those claims are being made. A.22 keeps only the selected-structure portion and the source-return condition that protects that structure use. 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.

#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 named by value kind and governing pattern:

If no reliance relation kind can be selected, keep the material as source-finding, recognition, 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, 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 path, 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 a specialization of existing U.Episteme governed by C.2.1 and E.10.D2. Every record whose name ends in View@Context here is a specialization of existing U.View or U.EpistemicViewing governed by A.6.3 and E.17.0. DescriptionContext is imported, not locally redefined.

StructuralDescription@Context ::= {
  descriptionId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, BoundedContextRef, ViewpointRef),
  structureRefs: FinSet(U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidencePathRef | MathLensUseOutputRef | SourceReturnConditionRef | NamedClaimGoverningPatternRef),
  describingEpistemeRef,
  admissibleUse,
  nonAdmissibleUse
}

StructuralView@Context ::= {
  viewId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, BoundedContextRef, ViewpointRef),
  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, BoundedContextRef, ViewpointRef),
  sourceCorpusOrTraceRefs,
  structureRefs: FinSet(U.StructureRef),
  extractionDescriptionRef,
  preservedStructure,
  lostStructure,
  validationBoundary,
  sourceReturnCondition,
  admissibleUse,
  nonAdmissibleUse
}

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

StructuralAspectDescription@Context ::= {
  aspectDescriptionId,
  descriptionContext: DescriptionContext(EntityOfConcernRef, BoundedContextRef, ViewpointRef),
  aspectKindRef,
  structureRefs: FinSet(U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidencePathRef | MathLensUseOutputRef | SourceReturnConditionRef | NamedClaimGoverningPatternRef),
  admissibleUse,
  nonAdmissibleUse
}

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

#Source return

SourceReturnCondition 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 source 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 the source-side 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

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 reliance relation 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 = 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 move 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, extraction method, preserved structure, lost structure, validation boundary, and source-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 edition
  sourceReturnCondition: 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 move; it is not a required project control form and not a substitute for the card, note, view, relation, or repair move above.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

FPF needs one general selected-structure EntityOfConcern because many useful project claims depend on organization before they depend on a specific architecture, mathematical, measurement, or publication pattern. The selected-structure entity has to be dependent, non-agentive, and claim-bearing through descriptions or views: it can be described, sourced, compared, coarsened, extracted, or used by architecture, but it does not act 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 source-return records are used only when the next use would otherwise hide loss, source dependence, or non-structure claim kind.

The reason to keep C.30 separate is architectural clarity. Architecture is selected structure for a described holon under context and 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: C.2.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: 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, A.10, G.6, B.3, A.20, A.21, C.28, A.15, C.11, C.16, C.25, G.5, and governing patterns named for structure-information, equivalence, and synthesis claim kinds when those claim kinds are being made.

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-05-31 — this section last modified in upstream FPF commit 16cd3138 (github.com/ailev/FPF)