#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 the current question is an ArchitectureOf@Context claim: which selected U.Structure refs matter for one described U.Holon in one U.BoundedContext, and what next architecture move follows.

#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 the current question is an ArchitectureOf@Context claim: which selected U.Structure refs matter for one described U.Holon in one U.BoundedContext, and what next architecture move follows.

The first useful move is small:

ArchitectureQuestionCard@Project:
  describedHolonRef:
  boundedContextRef:
  architectureConcernCue:
  sourcePhrase?, if useful:
  questionDisposition:
    concernCueOnly | problemCardReady | architectureClaimReady | nonArchitectureClaimReady
  selectedStructureRefs or selectedStructureKindRefs:
  inspectedMaterialRole, if current:
  firstArchitectureMove:
  architectureDescriptionBridge, if durable description use is current:
  governingPatternApplicationRefs, if another claim is being made:
  non-admissible overread:

architectureConcernCue is recognition wording only until it helps choose one selected structure kind and one architecture move. When a controlled cue is useful, use changeLocalization, substitutionOrReplacement, flowBottleneck, controlOrRateMismatch, dataCustodyOrStateResidence, physicalSeparationOrPlacement, evidenceReuseOrAssuranceReuse, scaleWindowOrCoarseningLoss, runtimeFailureMode, crossScopeResidual, descriptionViewLoss, or otherDeclared. Local phrases such as change localization failure, hidden crossing, source return, generated-view loss, or state-residence uncertainty may remain in sourcePhrase? or Plain prose. If the described holon, bounded context, selected structure, and first move cannot yet be named, set questionDisposition to concernCueOnly or problemCardReady rather than promoting it to ArchitectureOf@Context by wording alone.

ArchitectureQuestionCard@Project is a project-side triage aid for choosing one architecture move. questionDisposition records the card's current result: keep it as a concern cue, prepare a ProblemCard@Context, open an ArchitectureOf@Context claim, or name the non-architecture governing pattern. The card is not an evidence record, gate, decision, release record, quality score, risk rating, or publication-authority claim. When those claims are being made, name the governing FPF pattern and keep C.30 to the architecture-claim portion; later sections cite this boundary rather than repeating the full non-use catalogue.

Use a conditional ArchitectureDescription@Context bridge only when durable architecture-description use is current: 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: the practitioner reasons from a document, module diagram, workflow graph, mathematical lens, benchmark, maturity score, or decision record instead of recovering the described holon, selected structures, first architecture move, and neighboring claim kind.

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

Not this pattern when the EntityOfConcern under repair is not an architecture claim, selected architecture-relevant structure, source relation, description relation, view relation, publication-role recovery for an architecture claim, or the thin architecture-description bridge needed for one architecture move. Use the direct governing pattern named by the recovered relation, and keep C.30 only for the architecture-claim portion if that portion is being claimed. Common neighboring claim boundaries are summarized in [C.30:12](/generated/patterns/C.30#relations).

Thin precision-restoration pointer: if the issue under repair is still whether architecture, architecture description, structural view, module diagram, model, source material, functional architecture, or a source label such as layer, level, tier, stack, block, expert, cache, router, or gate names an architecture claim, description, view, publication form, source relation, structure, or non-architecture governing-pattern application, use [C.30.P](/generated/patterns/C.30.P) or [C.30.STRAT](/generated/patterns/C.30.STRAT) as triggered before applying C.30 to the recovered architecture portion. If the recovered issue is mathematical-lens use, apply [C.29](/generated/patterns/C.29); when no mathematical-lens move changes the architecture work, keep ordinary prose or use NoMathLensUseNeededNote under C.29 rather than creating a C.30-local lens result. 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 selected transformation-flow structure, flow description, or mathematical graph 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 is the inspected material being used as: architecture claim, description, view, publication form, 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 E.18 transformation-flow structures, LCA structures, control structures, 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 U.Holon in one U.BoundedContext: recover the ArchitectureOf@Context claim record when it is being claimed, selected U.Structure references, structure kind refs, the source, description, view, or publication role of the inspected material, 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 publication-form 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.TFS-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. Use A.1 for U.Holon, A.22 for selected U.Structure, and E.24.PUB when the problem is a confusion among ontic, ontic-description episteme, and publication form.

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, source, description, view, or publication-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 a related 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, 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,
  publicationFormRef,
  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 neighboring claim authority; apply C.30:4.3 and the governing pattern when evidence, gate, work, assurance, decision, or release claims are current.

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 the architecture move still needs ArchitectureOf@Context, selected structures, and any neighboring proof, release, or gate claim assigned to its governing pattern.

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 source, description, view, or publication 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 accounting, bespoke-residue accounting, evidence, assurance, gate, causal, and scale-audit claims 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 |
    structuralCharacteristicEvidenceRelationForQBundleSlot(A.10-governed evidence relation only when evidence provenance is the claim being made),
  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 |
    structuralCharacteristicEvidenceRelationForQBundleSlot(A.10-governed evidence relation only when evidence provenance is the claim being made),
  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, selected transformation-flow diagram, mathematical graph description, 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 transformation-flow relation | E.18 path | mechanism reference,
  recoveredKind,
  governingPatternApplicationRefs,
  admissibleUse,
  nonAdmissibleUse
}

ModuleRelationBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    module | component | package | platform | open architecture |
    recoveredModuleInterfaceSourceLabel |
    typed control-structure relation,
  moduleInterfaceRepairClaimCurrent?: yes | no,
  openOrPlatformClaimCurrent?: yes | no,
  selectedModuleInterfaceRelationRefs?,
  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 publication face unless it explicitly publishes an ArchitectureDescription@Context or ArchitectureStructuralView@Context.

ArchitectureQuestionCard@Project:
  describedHolonRef: payment system
  boundedContextRef: checkout platform context
  architectureConcernCue: descriptionViewLoss or flowBottleneck
  sourcePhrase?: "architecture in this diagram"; unclear dependency between payment orchestration and fraud scoring
  questionDisposition: architectureClaimReady
  inspectedMaterialRole: diagram as publication face carrying possible architecture structural-view material
  selectedStructureKindRefs: FunctionalStructure, ModuleInterfaceStructure, TransformationFlowStructure
  firstArchitectureMove: recover the diagram as a publication face and create a minimal architecture structural-view note
  governingPatternApplicationRefs: C.30.ASV
  non-admissible overread: treating the diagram as architecture itself, evidence, assurance, gate passage, or decision

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

"The backup-pump architecture is safe because the loop is redundant." C.30 starts with the plant holon, bounded operating context, and selected structures: control loop, material-flow structure, placement structure, module-interface relation, and maintenance-work relation. The redundancy phrase may motivate an architecture move, but safety proof, causal proof, evidence sufficiency, gate passage, and work authorization move to their governing patterns. The C.30 output is the selected structure and next architecture move, not a safety case by slogan.

"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 value is already recovered. The phrase is admissible architecture recognition only after the changed structure kind, transformation-flow 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, recover a source, description, view, or publication role, 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 publication form into the architecture.

#SoTA-Echoing

#Relations

Builds on: A.1, A.22, E.24.PUB, 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.TFS-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.1 for the described holon, A.22 for selected-structure EntityOfConcern, E.24.PUB for ontic-description and publication-form boundary, C.30.STRAT for stratification-wording and source-label repair, C.30.ASV for structural-view adequacy, E.18 for selected transformation-flow structure, path, and crossing discipline, E.18.2 and C.29 for mathematical graph descriptions and 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)