#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 say what organization, relation class, constraint, invariant, variation class, or preserved/lost arrangement is being discussed, without turning a diagram, graph, table, document, mathematical lens, source item, base, evidence path, mathematical-lens output, decision, or architecture description into the structure itself.

#Keywords

• structure
• structural view
• selected structure
• preserved/lost structure
• source return
• architecture-description claim
• structural description.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner needs to say what organization, relation class, constraint, invariant, variation class, or preserved/lost arrangement is being discussed, without turning a diagram, graph, table, document, mathematical lens, source item, base, evidence path, mathematical-lens output, decision, or architecture description into the structure itself.

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:
source/base/evidence/lens reading, if reliance is live:
admissible use:
non-admissible use:
governingPatternApplicationRefs, if another claim kind is live:

StructureQuestionCard@Project is a project-side triage aid, not a new structure kind, not a D/S publication, not evidence, and not a decision.

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 exact FPF pattern application or stop. Fill preserved or lost structure, source/base/evidence/lens reading and source-return fields only when extraction, coarsening, source/base/evidence/lens reliance, or action reliance is live. All other fields are conditional and may be not live.

Stop at this card when it makes the next move clear. Open the heavier records below only when publication, reuse, extraction, coarsening, comparison, evidence, assurance, C.29 lens use, architecture description, or cross-case source/lens reuse is live.

What goes wrong if A.22 is missed: architecture becomes a document, a module diagram, a TGA graph, a mathematical-lens output, or a decision record; a source, lens output, or evidence item becomes the structure; a view becomes the described object; 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 source/base/evidence/lens reading is live, and where the use stops.

What A.22 buys in practice: a practitioner can name selected structure, name the exact source, base, evidence, or lens reading, publish a structural view, state preserved and lost structure, return to source when the loss matters, or name the exact FPF pattern application that carries evidence, assurance, gate, decision, work, release, architecture-description, or mathematical-lens claim kind.

Not this pattern when the live question is architecture-description adequacy. Use [C.30](/generated/patterns/C.30). If the live question is an architecture structural view, use [C.30.ASV](/generated/patterns/C.30.ASV). If it is mathematical-lens adequacy, use [C.29](/generated/patterns/C.29). If it is evidence, assurance, gate, decision, work, release, or project authority, use the exact governing FPF pattern and keep A.22 only to the structure carrier or structure-view portion.

Thin precision-restoration pointer: if the live issue is still whether wording such as architecture, structure, diagram, module, model, view, layer, stack, or functional architecture is naming a structure, a structure description, an architecture description, a view, a carrier, or another receiving object, use [C.30.P](/generated/patterns/C.30.P) before applying A.22. Do not copy the [C.30.P](/generated/patterns/C.30.P) trigger table here; A.22 resumes only after the selected-structure object or structure-view portion is recoverable.

#Problem

FPF needs a carrier for structure 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 intensional object 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 D/S description or view of that structure;
• structure and a publication face, diagram, table, graph, or carrier;
• structure and mathematical-lens application;
• structure and evidence, assurance, gate, decision, work, or release;
• structure in general and architecture-specific structure selected by C.30.

#Forces

#Solution

Select candidate:U.Structure as a dependent, non-agentive intensional object:

candidate: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 live, inside a bounded context and admissible-use frame.

candidate:U.Structure is not the described entity, grounding holon, source, evidence path, lens output, simulation, generated representation, or declared substrate itself, not a U.Holon by default, not Work, not Evidence, not Gate, not Decision, not Architecture, and not a mathematical lens. It does not act, optimize, prove, warrant, or decide. Claims about a structure are carried by U.Episteme, U.View, evidence, publication, decision, or exact evidence, assurance, causal, gate, decision, publication, base-declaration, source-description, or lens records. Descriptions and views of structure are D/S epistemes under I/D/S, not the structure itself.

A.22 governs candidate:U.Structure as a dependent, non-agentive intensional object and the D/S descriptions and views that describe selected structure in one bounded context. It governs structure carriers, structure-claim reliance readings, structural descriptions, structural views, extracted structural views, structural-aspect descriptions, structural-coarsening descriptions, and structure-general source-return conditions. It does not govern architecture descriptions directly; C.30 and its subpatterns govern architecture as a use of selected structure over a described holon.

#Structure carrier

candidate: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 live, the record names the exact 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 readings

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 exact reliance reading and governing pattern:

If no reading 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.

candidate:U.Structure does not carry description, representation, extraction, mathematical-lens, simulation, support, or basis postures as internal structure postures. 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.

#D/S 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(DescribedEntityRef, BoundedContextRef, ViewpointRef),
  structureRefs: FinSet(candidate:U.StructureRef),
  structureClaimRelianceRefs?: FinSet(U.ScopedWitnessedBaseDeclarationRef | EvidencePathRef | C29LensOutputRef | SourceReturnConditionRef | NamedClaimGoverningPatternRef),
  describingEpistemeRef,
  admissibleUse,
  nonAdmissibleUse
}

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

descriptionContext.ViewpointRef is the viewpoint field. Do not duplicate it locally under another name unless the exact 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, or observer/budget boundary produces a view of structure that may hide distinctions.

ExtractedStructuralView@Context ::= {
  extractedViewId,
  descriptionContext: DescriptionContext(DescribedEntityRef, BoundedContextRef, ViewpointRef),
  sourceCorpusOrTraceRefs,
  structureRefs: FinSet(candidate:U.StructureRef),
  extractionDescriptionRef,
  preservedStructure,
  lostStructure,
  validationBoundary,
  sourceReturnCondition,
  admissibleUse,
  nonAdmissibleUse
}

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

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

StructuralCoarseningDescription@Context ::= {
  coarseningDescriptionId,
  descriptionContext: DescriptionContext(DescribedEntityRef, BoundedContextRef, ViewpointRef),
  sourceStructureRefs: FinSet(candidate:U.StructureRef),
  targetStructureRefs: FinSet(candidate: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 live 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 exact 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/transduction structure
structure-claim reliance reading: exact governing ontology as live(
  sourceDescriptionOrPatternApplicationRef = SourceViewRef or E18 graph/path/crossing record,
  governingPatternRef = E.18 or A.6.6/A.10/C.29 as live,
  relationReading = source-description | base-dependence | evidence | lens, as live,
  validationBoundary = path/slice/crossing currentness boundary
)
next exact 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 reading 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 live 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 structure carrier because many useful project claims depend on organization before they depend on a specific architecture, mathematical, measurement, or publication pattern. The carrier has to be intensional, dependent, and non-agentive: 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 D/S, A.6.6 base-dependence, extraction, lens, evidence, and source-return records open 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 D/S publications over that claim. 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, 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 named receiving patterns for structure-information, equivalence, and synthesis claims when those claim kinds are live.

Does not replace: C.30 for architecture description, C.29 for mathematical-lens adequacy, C.16 for measurement and characterization, C.28 for causal-use support, 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)