#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 structure as an 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 structure as an 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 substrate, what relation or constraint matters, what is preserved, what is lost, and what use or stop condition follows. Diagrams, graphs, documents, source items, mathematical-lens outputs, project records, and architecture descriptions may help expose that structure; they do not replace the selected structure. The first useful move is small:

StructureQuestionCard@Project:
declared structure substrate:
bounded context:
candidate structure:
relation, operation, constraint, invariant, or variation class:
what is preserved:
what is lost, hidden, or excluded:
reliance relation, if being claimed: source-description, base-dependence, grounding, evidence, lens, simulation, extraction, or representation
admissible use:
non-admissible use:
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; evidence, gate, decision, work, release, publication, source-use, or description-use claims are governed by their FPF patterns when they are being made.

Ordinary minimum: name the bounded context, the candidate structure, one relation, constraint, invariant, or variation class that changes action, one non-admissible overread, and the FPF pattern application or stop. Fill preserved or lost structure, reliance-relation, and source-return fields only when extraction, coarsening, source-description, base-dependence, grounding, evidence, lens, simulation, representation, or action reliance is being claimed. All other fields are conditional and may be not used.

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

What goes wrong if A.22 is missed: architecture becomes a document, a module diagram, a TGA graph, a mathematical-lens output, or a project record; a source, lens output, or view becomes the structure; a coarsened or extracted representation becomes loss-free. Those collapses damage first-principles reasoning because the practitioner cannot see what is organized, what carries the claim, which reliance relation is being claimed, and where the use stops.

What A.22 buys in practice: a practitioner can name selected structure, state preserved and lost structure, name source or lens reliance when it is being claimed, return to source when the 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: if the issue under repair is still whether wording such as architecture, structure, diagram, module, model, view, functional architecture, or a source label such as layer, level, tier, stack, block, expert, cache, router, or gate names a structure, a structure description, an architecture description, a view, a carrier, or another governed claim or relation named by value, use [C.30.P](/generated/patterns/C.30.P) and [C.30.STRAT](/generated/patterns/C.30.STRAT) as triggered before applying A.22. Do not copy either trigger table here; A.22 resumes 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 carrier;
• 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 a dependent, non-agentive EntityOfConcern:

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 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, and carriers are used only as 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. Generic description and publication-use guards belong in the boundary section below, not in the selected-structure definition.

EntityOfConcern bridge. In A.22, "EntityOfConcern" names the mode in which selected structure is treated: dependent, non-agentive, claim-bearing through descriptions or views when those description or view uses are being made, and not reducible to one physical part or one publication. It is not a second EntityOfConcern head beside EntityOfConcern. 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 faces, forms, units, carriers, and renderings only make the episteme or view available.

A.22 governs U.Structure as a dependent, non-agentive EntityOfConcern. 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.

#Auxiliary description and publication-use boundary

This subsection is the A.22 auxiliary description and publication-use boundary. It protects the selected structure from description, publication, and source overread without turning A.22 into a general pattern about descriptions.

U.Structure is not the grounding holon, source, evidence path, lens output, simulation, generated representation, declared substrate itself, U.Holon by default, U.Work, evidence record, gate decision, project decision, architecture claim, or mathematical lens. It does not act, optimize, prove, warrant, authorize, promise, prescribe, decide, or release. When one of those publication-use or project-side claims is being made, the governing pattern is named for the evidence, assurance, causal, gate, decision, publication, work, base-declaration, source-description, lens, architecture-description, or mathematical-lens-use claim being made. A.22 keeps only the structure portion and the source-return condition that protects the structure use.

Descriptions and views of structure are Description epistemes and specification-use cases under the EntityOfConcern and Description-episteme boundary and specification-use and refinement discipline, not the structure itself. A publication, diagram, graph, table, dashboard, file, carrier, model card, or generated representation can make a structural description or view available, but it does not become the selected structure or supply evidence, assurance, gate, decision, work, release, or authority claim by appearance.

#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 | flowTransduction |
    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.

#Structure claim reliance relation selection

A.22 does not mint a local support-headed or basis-headed relation 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 support-headed or basis-headed record to make the claim look governed.

U.Structure does not carry description, representation, extraction, mathematical-lens, simulation, support, or basis-headed 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, carriers, 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, ArchitectureFlowStructureRelation@TGA, 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: TransductionGraphRef under E.18
candidate structure: selected flow structure or selected transduction structure
structure-claim reliance relation: selected reliance relation named by value(
  sourceDescriptionOrPatternApplicationRef = SourceViewRef or E.18 graph, path, or crossing record,
  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.TGA-FLOW-REL when this selected structure is used in an architecture-flow description
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, and F.18.

Coordinates with: C.30.P, C.30.STRAT, C.30, C.30.ASV, C.30.TGA-FLOW-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)