#Grounded Architecture and Selected-Structure Adequacy

C.30 · Cluster C.IV - Composite & Macro-Scale · Stable · Architectural pattern · Normative unless explicitly marked informative · Part C - Kernel Extension Specifications

#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 architecture talk is doing more than naming modules, diagrams, documents, tool outputs, or a general engineering topic. Apply C.30 when the question under repair is what architecture claim is being described, what selected structures carry it, what artifact role the text or model being inspected has, and what the next admissible architecture move is.

#Keywords

• grounded architecture
• ArchitectureOf@Context
• selected structure
• architecture claim
• architecture question card
• architecture-description boundary
• artifact-as-architecture guard.

#Relations

#Content

#Problem frame

Use this pattern when architecture talk is doing more than naming modules, diagrams, documents, tool outputs, or a general engineering topic. Apply C.30 when the question under repair is what architecture claim is being described, what selected structures carry it, what artifact role the text or model being inspected has, and what the next admissible architecture move is.

The ordinary first output is intentionally small:

ArchitectureQuestionCard@Project:
  describedHolonRef:
  boundedContextRef:
  architectureConcernCue:
  claimReadinessClass:
    preClaimCue | problemCardReady | architectureClaimReady | nonArchitectureClaimReady
  plainPromptLabel?:
  selectedStructureKindRefs: FinSet(ArchitectureStructureKindRef)
  collapseCue:
  firstArchitectureMove:
  ordinaryNotThisPatternBoundary:
  governingPatternApplicationRefs:

Use ArchitectureConcernCue only to recognize the architecture problem family that chooses the first structure kind and architecture move:

ArchitectureConcernCue:
  changeLocalization | substitutionOrReplacement | flowBottleneck |
  controlOrRateMismatch | dataCustodyOrStateResidence |
  physicalSeparationOrPlacement | evidenceReuseOrAssuranceReuse |
  scaleWindowOrCoarseningLoss | runtimeFailureMode |
  crossScopeResidual | descriptionViewLoss | otherDeclared

Typical architecture problem cues:

changeLocalizationFailure
substitutionFailure
crossViewMismatch
flowBottleneckOrHiddenCrossing
controlRateOrRecoveredControlLayerMismatch
dataCustodyOrStateResidenceUnclear
placementOrJurisdictionMismatch
evidenceReuseFailure
sourceReturnNeeded
crossScopeResidual
generatedViewLoss

Use the cue only to choose the first architecture move: described holon, bounded context, one candidate structure kind, artifact role, and one admissible next move. If those fields cannot yet be named, keep the material as a concern cue or ProblemCard@Context-style issue rather than promoting it to ArchitectureOf@Context by wording alone. ISO 42010-style concern language may remain as lineage or project wording, but C.30 recovers the FPF representation fields as architectureConcernCue, governingArchitectureConcernRefs?, or architectureConcernNotes?.

ArchitectureQuestionCard@Project is a project-side triage aid for choosing one architecture move. Quality scores, risk ratings, proof, evidence, assurance, gate, decision, release, or publication-authority claims are governed by their FPF patterns when they are being made.

Use this when:

• a practitioner says "architecture" and needs to know whether the claim being made is about a holon, selected structure, architecture description, view, carrier, decision, work, evidence, assurance, or mathematical lens;
• downgrade an artifact to publication, diagram, carrier, source relation, or generated relation graph when it is not a Description or view;
• name the selected architecture-relevant structure and the next architecture move before writing a full architecture-description record;
• state a minimal architecture structural view only when it changes the next move;
• keep architecture-description machinery conditional instead of making every architecture discussion a multi-view description exercise;
• state NoMathLensUseNeeded when no mathematical lens changes the next architecture move;
• apply C.29 when a formal substrate, preserved and lost structure, or mathematical-lens use is being claimed.

Use a conditional ArchitectureDescription@Context bridge only when durable architecture-description use is being made: cross-team reuse, regulated or safety use, reusable design, comparison, source or lens reuse, or another named full-mode architecture-description use. Ordinary use stops at ArchitectureQuestionCard@Project when it makes one next architecture move clear. If the architecture description itself becomes the EntityOfConcern under repair, use [C.30.AD](/generated/patterns/C.30.AD).

What goes wrong if C.30 is missed: architecture collapses into a document, a module diagram, a workflow graph, a mathematical lens, a benchmark, a maturity score, or a decision record. Then the practitioner cannot see which holon is described, which structures matter, what the first architecture move is, which source or lens relation is being relied on, and which non-architecture claim must be governed elsewhere.

What C.30 buys in practice: a practitioner can separate architecture claim, selected structure, architecture description, view, publication, source relation, and non-architecture claim kind, then choose one small next architecture move.

Not this pattern when the EntityOfConcern under repair is only a general selected structure, a full architecture description, an architecture structural view, a TGA flow relation, an LCA/control view, a mathematical-lens use, measurement, evidence, assurance, gate, work, decision, or publication. Use [A.22](/generated/patterns/A.22), [C.30.AD](/generated/patterns/C.30.AD), [C.30.ASV](/generated/patterns/C.30.ASV), C.30.TGA-FLOW-REL, [C.30.LCA](/generated/patterns/C.30.LCA), [C.29](/generated/patterns/C.29), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [G.6](/generated/patterns/G.6), [B.3](/generated/patterns/B.3), [A.20](/generated/patterns/A.20), [A.21](/generated/patterns/A.21), [A.15](/generated/patterns/A.15), [C.11](/generated/patterns/C.11), or [E.17](/generated/patterns/E.17) respectively, and keep C.30 only for the architecture-claim portion if that portion is being claimed.

Thin precision-restoration pointer: if the issue under repair is still whether architecture, architecture description, structural view, module diagram, model, artifact, functional architecture, or a source label such as layer, level, tier, stack, block, expert, cache, router, or gate names an architecture claim, description, view, carrier, source, structure, or non-architecture governing-pattern application, use [C.30.P](/generated/patterns/C.30.P) and [C.30.STRAT](/generated/patterns/C.30.STRAT) as triggered before applying C.30 to the recovered architecture portion. Keep the trigger tables in those patterns; C.30 is applied only after ArchitectureOf@Context, selected architecture-relevant structure, conditional ArchitectureDescription@Context bridge use, [C.30.AD](/generated/patterns/C.30.AD) application, or the non-architecture application named by value is recoverable.

#Problem

Engineering teams use "architecture" for several different things:

• the selected structure of a holon;
• a diagram, model, table, dashboard, generated relation graph, or document;
• a module layout;
• a TGA graph or flow description;
• a functional, control, information, deployment, logical, or physical structure view;
• an ADR-like publication;
• a project-side claim carried by another governing FPF pattern.

These uses are all useful in ordinary engineering speech, but they cannot carry the same FPF claim. The core distinction is the one already used across FPF: the architecture-relevant selected structure, the architecture claim over that structure, the Description episteme or view of that claim, the publication of that description or view, and the project decision about changing architecture are different records.

The first-minute practitioner can ask: Are we choosing an architecture, or just naming a module layout? Which structure is being described: function, flow, control, module structure, interface relation, work, role relation, enactor structure, evidence relation, assurance relation, information structure, data structure, placement structure, deployment structure, scale structure, or declared logical structure? What artifact are we looking at: architecture claim, description, view, carrier, publication, decision, source relation, or mathematical lens?

How can FPF describe architecture without:

• creating U.Architecture as a new root kind;
• treating a description, view, diagram, graph, ADR, dashboard, or generated relation graph as the architecture;
• reducing architecture to module structure or interface relation;
• letting TGA, LCA, C.29 lenses, quality language, evidence, assurance, gates, work, or decisions silently become architecture ontology;
• making architecture descriptions so heavy that ordinary practitioners cannot get a first useful move.

#Forces

#Solution

C.30 starts from one architecture move over one described holon in one bounded context: recover the ArchitectureOf@Context claim record when it is being claimed, selected structures, structure kind refs, artifact role, and first admissible architecture move. Use a conditional architecture-description bridge when durable, reusable, multi-view, regulated, comparison, or reliance-bearing description is being made. If ArchitectureQuestionCard@Project gives one usable next move, stop there.

In C.30, the EntityOfConcern for this use is the architecture claim, one of its selected structures, or the relation record or claim record named by value for the architecture use being made. The description is not the architecture itself, and description hygiene is not the center of C.30.

Architecture-description material in C.30 is deliberately minimal. C.30 itself is not the full architecture-description mechanism. It binds ArchitectureDescription@Context to ArchitectureOf@Context, selected structures, structural views, correspondence, source return, and admissible use only when durable description use is being made. C.30.AD carries the full architecture-description EntityOfConcern: multi-view description sets, viewpoint-based views, correspondences, source return, freshness, specification use, and publication boundary over ArchitectureOf@Context. Generic Description, view, viewpoint, publication-face, and carrier machinery still remains in A.7, E.17.0, E.17.1, E.17.2, and E.17. C.30.ASV carries the selected-structure-kind-to-view relation; C.30.TGA-FLOW-REL, C.30.LCA, and other named subpatterns carry named structure relations.

C.30 does not mint U.Architecture and does not redefine U.Viewpoint. It specializes A.22 structure records and U.MultiViewDescribing only for architecture descriptions whose DescriptionContext EntityOfConcernRef is the ArchitectureOf@Context claim record for a holon, while preserving the EntityOfConcern and Description-episteme and specification-use distinction between architecture and its descriptions.

C.30 governs grounded architecture adequacy for one ArchitectureOf@Context claim record over selected U.Structure references for one described holon in one bounded context. It governs ArchitectureOf@Context, ArchitectureQuestionCard@Project, selected architecture-relevant structures, architecture structure-kind recovery, artifact-role recovery, first architecture-question assignment, characteristic assignment, small boundary notes, and the thin ArchitectureDescription@Context bridge when durable description use is being made. It does not mint U.Architecture and does not govern all architecture structure-kind views; C.30.ASV governs architecture structural views, and C.30.AD governs the full architecture-description mechanism. Generic guards about publication, permission, promise, evidence sufficiency, gate passage, work authority, decision authority, or release authority stay in the publication-use boundary or in governing patterns.

#Architecture claim record

ArchitectureOf@Context ::= {
  describedHolonRef: U.HolonRef,
  boundedContextRef: U.BoundedContextRef,
  structureRefs: FinSet(U.StructureRef),
  structureKindRefs: FinSet(ArchitectureStructureKindRef),
  architectureConcernCue?,
  governingArchitectureConcernRefs?,
  architectureConcernNotes?,
  structuralRelationRecordRefs?,
  admissibleUse,
  nonAdmissibleUse
}

ArchitectureOf@Context is a project-side architecture claim record over selected structures. It is not the selected structure itself, not a Description episteme, not a view, not a diagram, not a publication face, not a decision, and not a new root U.* kind.

ArchitectureOf@ContextRef is admissible as a DescriptionContext.EntityOfConcernRef for architecture Description epistemes and views. The holon whose architecture is claimed remains ArchitectureOf@Context.describedHolonRef; it is not the DescriptionContext EntityOfConcernRef for those architecture descriptions unless a separate direct holon description is opened.

EntityOfConcern bridge. In C.30, the primary EntityOfConcern is the ArchitectureOf@Context claim record, one of its selected structures, or an neighboring relation record or claim record selected by the use under repair. Selected architecture structure is dependent, non-agentive, and claim-bearing through episteme or view records, but it is not a second EntityOfConcern family beside EntityOfConcern. Publication faces, forms, units, carriers, and renderings publish descriptions or views; they do not become the architecture claim or the selected structure.

#Conditional architecture-description bridge

C.30 does not define a second local ArchitectureDescription@Context record shape. The canonical ArchitectureDescription@Context record is governed by C.30.AD:4.1. C.30 admits only a thin bridge to that record when durable architecture-description use changes the first architecture move.

The minimum bridge recoverable in C.30 is:

C30ArchitectureDescriptionBridge minimum:
  architectureClaimRef: ArchitectureOf@ContextRef
  selectedStructureRefs or structureKindRefs:
  architectureStructuralViewRefs? only when a structural view is being used
  admissibleUse:
  nonAdmissibleUse:
  correspondenceRefs or sourceReturnCondition? when reuse, cross-view use, or source return is needed
  freshnessCueRefs? when currentness bounds the admissible use

This bridge does not mint another ArchitectureDescription@Context definition, does not add local fields to the canonical record, and does not collect non-architecture claim kinds as architecture-description ontology. It lets the C.30 reader say why a description matters for the next architecture move, then applies [C.30.AD](/generated/patterns/C.30.AD) whenever the architecture description itself becomes the EntityOfConcern under repair or the full mechanism is needed: multi-view composition, correspondence, source return, freshness, specification-use boundary, publication-use boundary, or reusable architecture-description use.

An architecture-description freshness cue is also canonical in C.30.AD:4.4. C.30 may point to that cue only to bound the admissible use of the first architecture move; the cue is not evidence sufficiency and not assurance.

#Publication-use boundary

This subsection is the C.30 publication-use boundary. It says what an architecture description or its publication does not carry by itself, while the subject Solution stays about architecture claim, described holon, selected structures, structural views, and the next architecture move. If a guard concerns permission, promise, prescription, evidence sufficiency, assurance, decision, gate passage, work authority, release, or authority-source claim, keep it here, in C.30.AD, or in the description or publication pattern governing that claim rather than expanding C.30's thin bridge.

ArchitectureDescriptionPublication@Project ::= {
  sourceEpistemeRef | sourceViewRef,
  publicationViewpointRef?,
  publicationScopeId,
  boundedContextRef,
  mvpkFaceRef,
  carrierRef,
  sourcePinSetRef,
  audience,
  admissiblePublicationUse,
  nonAdmissiblePublicationUse
}

ArchitectureDescriptionPublication@Project is subordinate to E.17 and MVPK machinery. It publishes one source episteme or episteme-lane view reference. publicationViewpointRef? names the publication-side viewpoint only when MVPK needs one; it is not an architecture viewpoint and not a TEVB viewpoint. mvpkFaceRef is a publication-lane face reference, not an alternative source episteme, source view, or source relation. Publication does not add architecture claims, evidence sufficiency, gate decision state, work authority, assurance, decision authority, or release permission.

Model cards, system cards, and evaluation harness reports enter C.30 through the same publication boundary or source-relation boundary. They may describe a model, deployed AI system, architecture claim, evaluation harness, or policy, but they do not by themselves establish architecture adequacy, safety proof, release authority, or gate passage.

ModelCardOrSystemCardBoundaryNote@Project ::= {
  sourcePublicationRef,
  entityOfConcernRef,
  entityOfConcernKind:
    model | deployedAISystem | architectureClaim |
    evaluationHarness | policy | otherDeclared,
  architectureStructureKindRefs?,
  intendedUseScope,
  evaluationScopeAndKnownLoss?,
  deploymentContextMismatch?,
  evidenceOrAssuranceGoverningPatternRef?,
  nonAdmissibleUse:
    notArchitectureAdequacy | notSafetyProof |
    notReleaseAuthorityByPublicationAlone
}

If the card or harness is used beyond transparency, recover the architecture structure kind being used first and then apply [A.10](/generated/patterns/A.10), [G.6](/generated/patterns/G.6), [B.3](/generated/patterns/B.3), [A.20](/generated/patterns/A.20), [A.21](/generated/patterns/A.21), [C.16](/generated/patterns/C.16), [C.28](/generated/patterns/C.28), or [C.11](/generated/patterns/C.11) for the non-architecture claim kind.

#Architecture name formation

The word architecture is shorthand only after the described holon, bounded context, selected structures, structure kind, and artifact role are recoverable. Without those qualifiers, it is a recovery trigger, not a stable FPF term.

ArchitectureNameFormationRule:

If a text says "<X> architecture", then the FPF-governed use is conforming only with:
  describedHolonRef,
  boundedContextRef,
  structureKindRef = <X>StructureKind or declared local relation,
  structureRefs,
  ArchitectureStructuralViewRefs if this is a description or view claim,
  admissibleUse,
  nonAdmissibleUse.

If <X> is not a declared structure kind, the phrase is plain recognition wording only.

#Architecture characteristic assignment

C.30 uses three bearers before any quality, fitness, measure, metric, score, modularity, or ility wording carries an architecture-adequacy claim. Those words are triggers for bearer recovery, not stable architecture adequacy by themselves.

ArchitectureCharacteristicAssignment:

A. SystemQualityAffectedByArchitecture
   Bearer: described U.Holon, named product holon, or named system holon
   Governing pattern: C.25 Q-Bundle or C.16
   Examples: maintainability, evolvability, resilience, availability, safety, observability

B. ArchitectureStructuralCharacteristic
   Bearer: `ArchitectureOf@Context` claim, architecture structural view, declared structural relation or constraint, module relation, or interface relation
      Governing pattern: selected from C.16, A.17-A.19, C.25, or the characteristic-space or Q-bundle pattern governing the characteristic claim
   Examples: coupling, cohesion, interface alphabet, substitutability, hidden coupling, reusable-structure share

C. ArchitectureAdequacyBearer
   Bearer: one selected architecture adequacy bearer: `ArchitectureOf@Context`, selected architecture-relevant structure, `ArchitectureDescription@Context` when durable description use is being made, architecture structural view, or correspondence model
   Governing pattern: selected from C.30 for grounded architecture and selected-structure adequacy, E.17 for publication-face and view discipline, C.16.Q for quality-term precision, or C.16 for measurement and characterization
   Examples: viewpoint coverage, correspondence adequacy, source-return adequacy, description modularity

C.30 keeps only a thin bridge from structural characteristics to Q-Bundle relevance. If the claim says architecture causes an outcome improvement, assign the causal-use claim to [C.28](/generated/patterns/C.28) before causal use. If a structural characteristic is used as a mechanism, constraint, predictor, proxy, evidence relation, or causal hypothesis for a Q-Bundle slot, start with ArchitectureStructuralCharacteristicQBundleRelationLine rather than a formula such as low coupling = maintainability; assign measurement, modularity scoring, reusable-structure share or accounting, bespoke-residue accounting, evidence sufficiency, assurance, gate, causal proof, and scale audit to their governing patterns.

ArchitectureStructuralCharacteristicQBundleRelationLine is the only ordinary first-contact relation shape C.30 introduces for this case. Do not add a second generic characteristic relation record in C.30. Use the line when the useful move is to show why one structural characteristic may matter without opening the full relation record. Do not use this line as a measurement record, modularity score, evidence sufficiency statement, assurance verdict, or causal proof:

ArchitectureStructuralCharacteristicQBundleRelationLine ::= {
  architectureClaimRef: ArchitectureOf@ContextRef,
  architectureStructuralViewRef?: ArchitectureStructuralView@ContextRef,
  structuralCharacteristicCueOrRef,
  affectedQBundleSlotRef,
  qBundleRelationKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidencePathForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | causalModelBased | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | reportOnly,
  evidenceOrCausalGoverningPatternRef?,
  nonAdmissibleUse
}

Minimal structural-characteristic relation-line examples:

ArchitectureCharacteristicQBundleRelationRecord is a triggered full-mode record, not the ordinary first-contact shape. Use the full record only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case relation reliance is being claimed and the thin line cannot keep the relation inspectable, reusable, or bounded. This preserves the protection against causal or quality overread without turning C.30 into a measurement-first pattern.

Relation kinds in this record are C.30-local relation tokens. They must remain recoverable as A.6.P-style relation specifications: polarity, participant slots, qualifiers, witness expectations, admissible semantic change classes, and bridge or loss boundary where those boundary conditions are being claimed. ISO/IEC 25010-like quality models may be used as quality vocabulary or comparison lineage for product qualities such as reliability, security, maintainability, usability, efficiency, compatibility, or portability. C.30 does not inherit them as architecture theory. Architecture relates to qualities through Q-Bundle slots, mechanism slots, relation class or admissible-use value, evidence or causal governing patterns, or report-only use.

ArchitectureCharacteristicQBundleRelationRecord ::= {
  architectureClaimRef: ArchitectureOf@Context,
  architectureStructuralViewRef?,
  architectureDescriptionRef?,
  structuralCHRRefs,
  affectedQBundleRefs,
  relationKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidencePathForQBundleSlot,
  participantSlots:
    structuralCharacteristicRef,
    qBundleSlotRef,
    architectureClaimRef,
    scopeOrScaleWindow?,
    viewpointRef?,
  qualifiers?,
  witnessExpectations?,
  relationGroundingKind:
    modelBased | empirical | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | causalModelBased | reportOnly,
  bridgeOrLossBoundary?,
  admissibleUse,
  nonAdmissibleUse,
  evidenceOrCausalGoverningPatternRef?
}

#Relation to structural views

C.30.ASV governs ArchitectureStructuralView@Context. C.30 governs the ArchitectureOf@Context claim and, only when durable description use is being made, how its thin ArchitectureDescription@Context bridge uses structural views, with hidden or lost structure, correspondence, source or reliance relation, and source-return boundaries recoverable when those boundaries affect action. C.30.AD governs the full architecture-description mechanism.

A diagram, model, table, TGA graph, LCA diagram, C.29 lens output, ADR, dashboard, generated explanation, or other publication face may carry an architecture description or an architecture structural view. It does not become the architecture, and it does not become a conforming view only because it looks like a view.

Use AffectedArchitectureStructureNote when the next architecture move needs to name affected structures or view losses without using an architecture decision, ADR, gate, evidence, assurance, or release record:

AffectedArchitectureStructureNote:
  architectureClaimRef:
  affectedStructureKindRefs:
  affectedStructureRefs?:
  affectedArchitectureStructuralViewRefs?:
  acceptedOrSuspectedViewLoss?:
  sourceReturnCondition?:
  nextAdmissibleMove:

This note only names affected architecture structure for the next move. Decision, ADR, gate-passage, evidence-sufficiency, and release-authority claims apply the patterns governing those claims.

#Minimal boundary notes

Use these notes when a common architecture phrase is close to a governing pattern but the full governing-pattern application is not yet needed for an asserted claim.

Use the thinnest relation form that preserves the next architecture move. Use fuller relation governing the asserted use records only when the relation being used cannot be inspected, used, compared, refreshed, or bounded without it. Typical thin forms are ArchitectureMathLensUseBoundary before C.29 Mini or Full, AffectedArchitectureStructureNote before an architecture decision record, and ArchitectureStructuralCharacteristicQBundleRelationLine before full measurement records, causal records, or evidence records.

InterfaceSignatureBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    interface | signature | port | endpoint | connector | link |
    API | protocol | E.18 transduction relation | TGA path | mechanism reference,
  recoveredKind,
  governingPatternApplicationRefs,
  admissibleUse,
  nonAdmissibleUse
}

ModuleRelationBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    module | component | package | platform | open architecture |
    recoveredModuleInterfaceSourceLabel |
    typed control-structure relation,
  moduleInterfaceRepairClaimLive?: yes | no,
  openOrPlatformClaimLive?: yes | no,
  exactModuleInterfaceRelationRefs?,
  variationPointRef?,
  substitutabilityPolicyRef?,
  interfaceConformanceEvidencePatternRef?,
  changePathRef?,
  consumerMigrationBoundary?,
  versionOrUpdateChannelRef?,
  secureDefaultOrHardeningBoundary?,
  governingPatternApplicationRefs,
  admissibleUse,
  nonAdmissibleUse
}

These notes are not substitutes for the module named by value-and-interface repair pattern, interface specifications, signature records, conformance evidence, or module-and-interface repair. An open or platform label is not substitutability proof, security proof, scale proof, assurance, or universal maturity evidence. A source label such as layer, stack, block, expert, cache, router, or gate enters this note only after [C.30.STRAT](/generated/patterns/C.30.STRAT) recovers a module-interface or adjacent architecture-relevant item. It becomes architecture-relevant only through local structure, interface, variation, substitution, migration, update, and hardening boundaries. Relation-heavy wording inside these notes remains a Plain cue until an module relation reference named by value, interface relation ref, relation governing the asserted use record, or governing FPF pattern application is named. The note keeps first use honest until the non-architecture claim kind named by value is being made.

#Architecture mathematical-lens boundary

Architecture descriptions may use C.29 lenses, but the lens does not become architecture ontology.

ArchitectureMathLensUseBoundary:
  noMLUNeeded?: yes | no
  lensOneLine?:
    lensRef,
    structureClaimRef,
    preservedStructure,
    lostStructure,
    lensRelationKind,
    stopCondition,
    governingPatternApplicationRefs?

Use the one-line boundary only when it is enough to keep the lens from being overread. Use a C.29 Mini or Full card when the lens choice, preserved structure, lost structure, relation class or admissible-use value, or stop condition changes the architecture move.

Lens use by architecture problem:

This table is not a C.29 replacement and does not make mathematics mandatory. It helps the practitioner see when a lens may add a useful architecture move; C.29 still carries lens-use result, preserved structure, lost structure, relation class or admissible-use value, and stop condition when those description or view uses are being made.

Epiplexity-like use remains a C.29 bounded-observer structural-information lens. It may help recover learnable structure from traces, but it is not an architecture quality, task relevance proof, causal proof, assurance, or selector authority.

#Boundary and repair table

#Worked slices

"We have the architecture in this diagram." The diagram is a carrier or publication face unless it explicitly carries an ArchitectureDescription@Context or ArchitectureStructuralView@Context.

ArchitectureQuestionCard@Project:
describedHolonRef: payment system
boundedContextRef: checkout platform context
architectureConcernCue: unclear dependency between payment orchestration and fraud scoring
plainPromptLabel: "architecture in this diagram"
selectedStructureKindRefs: FunctionalStructure, ModuleInterfaceStructure, FlowTransductionStructure
collapseCue: diagram is being treated as architecture itself
firstArchitectureMove: downgrade the diagram to a publication face and create a minimal architecture structural-view note
ordinaryNotThisPatternBoundary: no evidence, assurance, gate, or decision claim yet
governingPatternApplicationRefs: C.30.ASV

"Low coupling gives maintainability." C.30 does not allow that formula to carry the claim by itself. The ordinary repair starts with the thin relation line:

ArchitectureStructuralCharacteristicQBundleRelationLine:
  architectureClaimRef: ArchitectureOf@ContextRef
  structuralCharacteristicCueOrRef: coupling under module relation or interface relation
  affectedQBundleSlotRef: maintainability Q-Bundle slot
  qBundleRelationKind: structuralCharacteristicRelevantToQBundleSlot
  relationGroundingKind: sourceLineageOnly | SoTAActionLineage | modelBased, as actually grounded
  evidenceOrCausalGoverningPatternRef?: one selected governing pattern reference: C.28, B.3, A.10, or G.6 when evidence sufficiency, causal-use, assurance, or safety-case claim is being made
  nonAdmissibleUse: causal proof or assurance by slogan

Use ArchitectureCharacteristicQBundleRelationRecord only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case relation reliance needs the fuller record. The useful move is to decide whether a structural characteristic has a bounded relation to a maintainability slot, not to accept the slogan as architecture truth.

"We replaced the neural-network block, so the architecture improved." Treat block first as a source label and apply [C.30.STRAT](/generated/patterns/C.30.STRAT) unless the changed item is already recovered. The phrase is admissible architecture recognition only after the changed structure kind, flow or transduction relation, module or interface claim kind, preserved and lost structure, changed characteristic, source relation, and decision or evidence governing patterns are named. A block label, benchmark result, ablation, pruning mask, or distillation result is not an architecture decision, evidence sufficiency, gate passage, assurance, or architecture adequacy by itself.

#Archetypal Grounding

#Bias-Annotation

Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: FPF architecture-description use over holons.

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

Architecture is most useful in FPF when it stays close to selected structure over a holon and far away from document-as-architecture, graph-as-architecture, model-as-architecture, and decision-as-architecture collapses. The ArchitectureOf@Context record gives the selected structure a project-side claim handle without minting U.Architecture.

C.30 and C.30.ASV establish an FPF architecture kernel: architecture as selected EntityOfConcern structure for a described holon, with Description epistemes and structural views, structure-kind discipline, correspondence and source-return boundaries, and characteristic-relation applications. They do not by themselves provide full measurement, synthesis, decision, causal proof, safety proof, or assurance.

The small first card is deliberate. Architecture discussions often need one immediate move: name the holon, choose the structure kind under consideration, downgrade an artifact, assign an evidence or assurance claim to its governing pattern, or stop. A full architecture description is useful only when durable publication, cross-team use, comparison, regulated use, source reuse, or reliance-relation reuse is being made.

The DescriptionContext structure also preserves plurality. The same architecture claim may have several descriptions and views; several publications may render one description; several source records may be source relations for a view with different validation boundaries. C.30 keeps those variants usable without turning any one carrier into the architecture.

#SoTA-Echoing

#Relations

Builds on: A.22, C.30.P, C.2.1, A.6.3, A.7, E.10.D2, E.17.0, E.17.1, E.17, E.17.2, A.6.P, F.18, E.10, and C.2.P.

Coordinates with: C.30.STRAT, C.30.ASV, A.6.F, C.30.TGA-FLOW-REL, C.30.LCA, C.30.ILC, E.18, C.29, C.16, C.25, C.28, A.10, G.6, B.3, A.20, A.21, A.15, C.11, E.17, and named governing patterns for architecture decision and candidate-set claims when those claim kinds are being made.

Neighboring claims stay with their governing patterns: A.22 for selected-structure EntityOfConcern, C.30.STRAT for stratification-wording and source-label repair, C.30.ASV for structural-view adequacy, E.TGA for graph, path, and crossing discipline, C.29 for mathematical-lens use, C.16 for characterization, C.25 for Q-Bundles, C.28 for causal use, A.10 and G.6 for evidence, B.3 for assurance, A.20 and A.21 for gate or release records, A.15 for work, C.11 for decisions, and E.17 for publication. C.30 governs the grounded architecture claim, selected structures, and the next admissible architecture move.

#C.30:End

Last Updated: 2026-06-03 — this section last modified in upstream FPF commit a0c90e3b (github.com/ailev/FPF)