#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 concerns the architecture of one exact U.Holon: which actual subject relations obtain, which exact U.Structure is selected from them, whether the direct ArchitectureRelation obtains, what one C.2.1 claim says about that holon, relation, or structure, under which concern and admissible-use frame, and what next architecture move follows.

#Keywords

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

#Relations

#Content

#Problem frame

Use this pattern when the current question concerns the architecture of one exact U.Holon: which actual subject relations obtain, which exact U.Structure is selected from them, whether the direct ArchitectureRelation obtains, what one C.2.1 claim says about that holon, relation, or structure, under which concern and admissible-use frame, and what next architecture move follows.

The first useful architecture move is small:

ArchitectureQuestionCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureQuestionProjectUseRelationRef?: U.RelationRef
  architectureClaimRef?: ArchitectureClaimRef
  describedHolonRef:
  architectureRelationDisposition:
    actualRelationNamed | actualRelationStillToRecover |
    candidateOrExpectedOnly | nonArchitectureQuestion
  architectureRelationRefs?: FinSet(U.RelationRef)
  claimScope?:
  effectiveReferenceScheme?:
  modelUseStructureRef?: only when one selected bounded model-use structure changes this architecture use
  architectureConcernCue:
  architectureConcernClaimRefs?: FinSet(U.EpistemeRef)
  sourcePhrase?, if useful:
  questionDisposition:
    concernCueOnly | problemCardReady | architectureClaimReady | nonArchitectureClaimReady
  selectedStructureRefs?: FinSet(U.StructureRef)
  candidateOrExpectedStructureRefs?: FinSet(U.StructureRef)
  selectedStructureKindRefs or candidateStructureKindRefs:
  inspectedMaterialRole, if current:
  firstArchitectureMove:
  architectureDescriptionBridge, if durable description use is current:
  governingPatternApplicationRefs, if another claim is being made:
  non-admissible overread:

The card can stop before a durable claim. An actualRelationNamed result requires exact obtaining ArchitectureRelation occurrences and their A.22 structure participants. A candidate, planned, required, desired, expected, modeled, or diagrammed structure remains in candidateOrExpectedStructureRefs and makes no subject relation obtain. 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, actual/candidate structure distinction, architecture concern, and first move cannot yet be named, set questionDisposition to concernCueOnly or problemCardReady; wording alone promotes neither a claim nor an obtaining relation.

ArchitectureQuestionCard@Project is a triage aid for choosing one architecture move. questionDisposition records whether to keep a concern cue, prepare a separately governed ProblemCard, constitute an ArchitectureClaim, or name a non-architecture owner. architectureRelationDisposition separately records whether an actual direct relation has been recovered or the content is candidate/expected only. The card is not an evidence record, gate, decision, release record, quality score, risk rating, or publication-use authority claim.

Across C.30, @Project in a record name is a compatibility and retrieval cue only. It identifies neither a project entity nor a composite project U.Work, and it establishes no context, authority, viewpoint, or parthood. When the card is genuinely local to one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work recovered under A.15.6 and architectureQuestionProjectUseRelationRef identifies the exact obtaining relation by which this card use concerns that Work. Description publication and other project-local uses likewise name their own exact Work and project-use relation. A described holon, architecture claim, or architecture relation does not become project Work by retrieval suffix.

Use a conditional ArchitectureDescription 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 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, transformation-flow graph description, mathematical lens, benchmark, maturity score, or decision record instead of recovering the described holon, selected structures, first architecture move, and non-architecture claim kind.

What C.30 buys in practice: a practitioner can separate actual subject relations, selected structure, direct architecture relation, claim episteme, description, view, representation, publication occurrence/form/carrier, 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 non-architecture 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, representation, 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 use changes the architecture work, keep ordinary prose or use NoMathLensUseNeededNote under C.29 rather than creating a C.30-local lens result. Keep trigger tables in those patterns; C.30 is applied only after ArchitectureClaim, exact selected architecture-relevant structure, conditional ArchitectureDescription 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: actual subject-relation occurrences; the exact A.22 structure selected from them; the direct ArchitectureRelation that may obtain between that structure and one holon; a C.2.1 claim about the holon, relation, or structure; the Description episteme or view; the representation and publication objects; and any project decision about changing architecture are different objects.

The first-minute practitioner can ask: Are we recovering an actual architecture relation, considering a candidate structure, or only reading a representation? Which subject relations actually obtain, and which exact A.22 structure is selected from them? Which structure kind is in view: 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: claim content, description, view, representation, 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 architecture move.

#Forces

#Solution

C.30 starts from one architecture move over one exact U.Holon. Recover separately: any actual subject-relation occurrences; the exact A.22 structures selected from them; any obtaining ArchitectureRelation; the claim episteme that states an affirmative, negative, unresolved, candidate, or expected architecture claim; the concern and admissible-use frame; and the source, description, view, representation, or publication role of the inspected material. 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 architecture candidate use, stop there.

In C.30, the EntityOfConcern is one exact described holon, one exact ArchitectureRelation occurrence, one exact selected structure, or another exact subject object selected by the current claim. A claim episteme, description, diagram, or publication is not a proxy EntityOfConcern for a world-side relation or structure. Description hygiene supports this boundary but 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 gives a thin bridge from the exact holon, architecture relation, or selected structure to a separately constituted architecture-description episteme only when durable description use changes the architecture move. C.30.AD carries the full general architecture-description EntityOfConcern: multi-view description sets, viewpoint-based views, correspondences, source return, freshness, specification use, and publication boundary. C.30.AD.BA carries built-asset architecture-description, asset-information, digital-twin, and reference-designation specialization. Generic episteme, view, viewpoint, publication, form, representation, and carrier machinery remains with C.2.1, E.17.0, E.17.1, E.17.2, E.17, E.24.PUB, and C.29. C.30.ASV carries the selected-structure-to-view branch; C.30.TFS-REL, C.30.LCA, and other named subpatterns carry their direct structure relations and claims.

C.30 does not mint U.Architecture and does not redefine U.Viewpoint. It directly governs ArchitectureRelation, the architecture claim form, ArchitectureQuestionCard@Project, selected architecture-relevant structures, structure-kind recovery, architecture concern and admissible-use framing, source/description/view/publication-role recovery, first architecture-question assignment, characteristic-claim assignment, small boundary notes, and the thin description bridge. It does not make descriptions or views conform merely by form and does not govern all architecture structure-kind views. Generic guards about publication, deontic permission, promise, evidence sufficiency, assurance, decision, gate passage, work authorization, or release authorization stay in their direct patterns.

#Direct architecture relation and architecture claim

C.30 keeps one subject-side relation and one claim-bearing episteme distinct.

Direct relation kind. ArchitectureRelation is a C.30-governed direct dependent U.Relation between exactly two actual participants:

1. architectureBearingHolonRef — the exact U.Holon whose realized organization is at issue; and
2. selectedArchitectureStructureRef — one exact U.Structure selected under A.22 from declared constituents, obtaining subject-relation occurrences, applied constraints and invariants, and an admissible-use frame.

The relation is applicable only when the structure's exact constituents and selected subject-relation occurrences are recoverable for that holon or its admitted constituents and the structure is being used as architecture-relevant organization of that holon. Its obtaining predicate is satisfied only when the selected structure is actually constituted under A.22, every selected subject relation required by that structure obtains under its direct owner, and those constituents and relations organize the exact holon in the declared way. A planned, required, desired, expected, modeled, diagrammed, listed, or merely published structure does not satisfy this predicate.

Occurrence identity is the exact participant pair over one maximal continuous interval during which that predicate remains satisfied. A different holon, a differently identified A.22 structure, or cessation followed by later renewed obtaining yields another occurrence. A changed concern, claim scope, effective reference scheme, description, viewpoint, view, representation, publication, or carrier does not by itself reidentify or create the relation. Ordinary prose may state the readable relation and stop; use A.6.REL only when a later receiver must distinguish this occurrence from another one.

Architecture claim episteme. ArchitectureClaim is an ordinary C.2.1 U.Episteme, not the direct relation and not a new architecture kind:

ArchitectureClaim ::= {
  claimEpistemeRef: U.EpistemeRef,
  entityOfConcernRef:
    describedHolonRef | architectureRelationRef | selectedStructureRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  content: {
    describedHolonRef: U.HolonRef,
    architectureRelationAssertion:
      obtains | doesNotObtain | unresolved | candidateOrExpectedOnly,
    architectureRelationRefs?: FinSet(U.RelationRef),
    selectedStructureRefs?: FinSet(U.StructureRef),
    candidateOrExpectedStructureRefs?: FinSet(U.StructureRef),
    structureKindRefs: FinSet(ArchitectureStructureKindRef),
    architectureConcernClaimRefs?: FinSet(U.EpistemeRef),
    architectureConcernCue?: Plain recognition wording,
    admissibleUse,
    nonAdmissibleUse
  },
  modelUseStructureRef?: U.StructureRef,
  empiricalGroundingRelationRef?: U.RelationRef
}

The C.2.1 identity basis is the exact content, one exact entityOfConcernRef, and effective U.ReferenceScheme. claimScope qualifies what the claim covers. modelUseStructureRef appears only when one independently selected bounded-model-use structure changes structure interpretation or selection for this receiving use. empiricalGroundingRelationRef names a separately obtaining grounding relation; neither grounding nor the optional model-use structure is an ArchitectureRelation participant.

For an affirmative actual claim, every architectureRelationRef resolves to an obtaining occurrence governed by the direct settlement above and every selectedStructureRef is the exact structure participant of one of those occurrences. A negative, unresolved, candidate, required, desired, or expected claim can remain truthful claim content without an obtaining occurrence; it uses no invented positive reference. A description, diagram, graph, file, list, architecture decision, authoring act, or publication may state or carry the claim, but creates neither its truth nor the subject-side relation or structure.

Earlier consumers may still say “open the ArchitectureOf@Context form in the current C.30 edition.” In this edition that legacy retrieval instruction resolves to the ArchitectureClaim form plus the separate ArchitectureRelation settlement above. The suffix supplies no field, participant, scope, scheme, grounding, project identity, or relation fact, and new records use the current names.

EntityOfConcern bridge. C.30 may make the described holon, one exact ArchitectureRelation occurrence, or one exact selected structure the EntityOfConcern of a claim. A later architecture description independently chooses the exact holon, relation occurrence, or structure it describes under C.2.1; it does not use a claim record as a world-side proxy. Publication occurrences, forms, representations, and carriers remain separate.

#Holonic architecture modes

Recover which holonic architecture mode is current before applying MHT, structure, description, or mathematical-lens language:

#Evolutionary-engineering architecture candidate bridge

Use this bridge when an open-ended search, quality-diversity archive, current pool, front, or selected set contains possible architecture moves. The archive or front is not yet an actual architecture relation. It becomes C.30 material only when the current claim names the described holon, the existing or candidate structure and structure kind, the affected architecture characteristic, and the next architecture move.

ArchitectureCandidateMove:
  candidateMoveClaimEpistemeRef: U.EpistemeRef
  architectureClaimRef?: ArchitectureClaimRef
  describedHolonRef:
  currentArchitectureRelationRefs?: FinSet(U.RelationRef)
  currentSelectedStructureRefs?: FinSet(U.StructureRef)
  candidateStructureRefs: FinSet(U.StructureRef)
  candidateStructureKindRefs:
  affectedArchitectureCharacteristicRef:
  candidateMoveClaim:
  candidateSetOrArchiveRef:
  selectedSetPublicationRef?:
  localChoiceRef?:
  patternUseRecommendationRef?:
  workPlanRef?:
  workEntryReadinessRef?:
  gateDecisionRef?:
  performedWorkRef?:
  stopCondition:

ArchitectureCandidateMove is a thin claim note about a possible structural change. It records why a generated, retained, front-member, or selected-set variant can be considered as architecture material; it is not an obtaining ArchitectureRelation, work plan, local choice result, selected-set publication, decision, performed Work, or new kind. Candidate structure content remains modal until the exact structure is constituted and the direct architecture predicate obtains.

If the current work is archive generation, front maintenance, current-pool treatment, selected-set publication, or local choice, use [C.18](/generated/patterns/C.18), [C.19](/generated/patterns/C.19), [G.5](/generated/patterns/G.5), or [C.11](/generated/patterns/C.11) before C.30 relies on it. If the selected architecture move is a recommended FPF pattern use, cite [E.11.PUR](/generated/patterns/E.11.PUR). If it is ready to enter planning, work-entry readiness, gate decision, or performed work, use [A.15.2](/generated/patterns/A.15.2), [A.15.5](/generated/patterns/A.15.5), [A.21](/generated/patterns/A.21), or [A.15.1](/generated/patterns/A.15.1) respectively. C.30 keeps only the architecture claim: which exact holon and current relation are at issue, which candidate structure matters, which characteristic may change, and which next use is admissible.

Architecture-move wording creates no root U.Move, structure, relation, WorkPlan, readiness relation, gate decision, performed work, decision, or source-use claim by itself. When source wording uses “move” outside this architecture-candidate use, restore the concern through [E.10.MOVE](/generated/patterns/E.10.MOVE) and name the direct governing pattern.

When the useful next work is synthesizing candidate architecture variants rather than judging or repairing one grounded actual relation, stop the C.30 question card after the described holon, current/candidate structure distinction, structure kind, concern, admissible-use frame, and admissible next use are named. Apply [C.32](/generated/patterns/C.32) only to build the candidate architecture palette. If the next claim is comparison, selector-policy use, selected-set publication, final local choice, project architecture decision, evidence, assurance, gate, release, or performed work, send the palette or candidate reference to [A.19.CPM](/generated/patterns/A.19.CPM), [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism), [G.5](/generated/patterns/G.5), [C.11](/generated/patterns/C.11), [C.32.PAD](/generated/patterns/C.32.PAD), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [A.20](/generated/patterns/A.20), [A.21](/generated/patterns/A.21), or [A.15](/generated/patterns/A.15) when that claim is current.

#Conditional architecture-description bridge

C.30 does not define a second local ArchitectureDescription record shape. The canonical C.2.1 episteme and its architecture-use specialization are governed by C.30.AD:4.1. C.30 admits only a thin bridge when durable description use changes the first architecture move.

The minimum bridge recoverable in C.30 is:

C30ArchitectureDescriptionBridge minimum:
  architectureDescriptionRef: exact U.EpistemeRef
  entityOfConcernRef: exactly one described holon,
    obtaining ArchitectureRelation occurrence, or selected U.Structure
  effectiveReferenceScheme: U.ReferenceScheme, byValue
  architectureClaimRefs?: bounded claim content or trace
  selectedStructureRefs or structureKindRefs:
  architectureStructuralViewRefs?: only for exact description epistemes
    with independently obtaining E.17.0 viewpoint conformance
  viewpointConformanceRelationRefs?:
  admissibleUse:
  nonAdmissibleUse:
  correspondenceClaimOrRelationRefs or sourceReturnCondition?:
    only when reuse, cross-view use, or source return is needed
  freshnessClaimRefs?: only when currentness bounds admissible use

This bridge does not mint another description definition, local view-membership relation, subject-side architecture relation, selected structure, or truth fact. It lets the C.30 reader say why an exact description episteme matters for the next architecture move, then applies [C.30.AD](/generated/patterns/C.30.AD) whenever the description itself becomes the EntityOfConcern under repair or the full mechanism is needed: multi-view description-set use, exact viewpoint conformance, correspondence, source return, freshness, specification-use boundary, representation/publication boundary, or reusable architecture-description use.

An architecture-description freshness claim is canonical in C.30.AD:4.4. C.30 may point to it only to bound admissible use of the first architecture move; it is not empirical grounding, publication currentness, evidence sufficiency, or 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 deontic permission, promise, prescription, evidence sufficiency, assurance, decision, gate passage, work authorization, release authorization, source authority, or publication-use authority, 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,
  claimScope?,
  effectiveReferenceScheme?,
  modelUseStructureRef?,
  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 establish non-publication claims; 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 the actual/candidate structure distinction, an obtaining ArchitectureRelation only when its predicate is satisfied, a bounded ArchitectureClaim when claim content is needed, and any proof, release, or gate claim assigned to its governing pattern.

ModelCardOrSystemCardBoundaryNote@Project ::= {
  sourcePublicationRef,
  entityOfConcernRef,
  entityOfConcernKind:
    model | deployedAISystem | architectureClaim |
    evaluationHarness | policy | otherDeclared,
  architectureStructureKindRefs?,
  intendedUseScope,
  evaluationScopeAndKnownLoss?,
  deploymentInterpretationOrUseMismatch?,
  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, selected structures, structure kind, architecture concern and admissible-use frame, 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,
  actual subject relation occurrences or an explicit candidate/expected stop,
  architectureRelationRefs only when those exact relations obtain,
  claimScope? when claim coverage changes use,
  effectiveReferenceScheme for any claim episteme,
  modelUseStructureRef? only when that structure changes interpretation or selection,
  structureKindRef = <X>StructureKind or a declared local classifier,
  actual selectedStructureRefs or separately named candidateOrExpectedStructureRefs,
  architectureStructuralViewRefs only when a conforming view episteme is being used,
  admissibleUse,
  nonAdmissibleUse.
If <X> is not a declared structure kind, the phrase is plain recognition wording only.

#Architecture characteristic assignment

C.30 recovers the exact bearer before any quality, fitness, measure, metric, score, modularity, or ility wording carries an architecture-adequacy claim. Those words are triggers, not stable architecture adequacy by themselves.

ArchitectureCharacteristicAssignment:

A. SystemQualityAffectedByArchitecture
   Bearer: exact 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: one exact selected U.Structure, obtaining ArchitectureRelation,
           actual subject relation or constraint, or separately admitted
           module/interface relation
   Governing pattern: C.16, A.17-A.19, C.25, or the direct
                      characteristic-space/Q-bundle owner
   Examples: coupling, cohesion, interface alphabet, substitutability,
             hidden coupling, reusable-structure share

C. ArchitectureDescriptionOrViewAdequacy
   Bearer: one exact architecture-description episteme, one exact view episteme,
           one exact correspondence model, or one exact publication-use object
   Governing pattern: C.30.AD, C.30.ASV, E.17.0, E.17, C.16.Q, or C.16
   Examples: viewpoint coverage, correspondence adequacy,
             source-return adequacy, description modularity

An ArchitectureClaim may state a characteristic claim, but the claim episteme is not automatically the characteristic bearer when its content names the holon, direct architecture relation, or selected structure. Select the exact bearer under the characteristic's direct owner. Likewise, a diagram or publication cannot inherit the subject's quality by describing it.

C.30 keeps only a thin bridge from structural characteristics to Q-Bundle relevance. If the claim says architecture causes an outcome improvement, assign causal use to [C.28](/generated/patterns/C.28). If a structural characteristic is used as a mechanism, constraint, predictor, proxy, evidence relation, or causal hypothesis for a Q-Bundle slot, start with ArchitectureStructuralCharacteristicQBundleClaimLine rather than a formula such as low coupling = maintainability.

ArchitectureStructuralCharacteristicQBundleClaimLine is claim content for first contact, not a U.Relation occurrence or reusable relation declaration:

ArchitectureStructuralCharacteristicQBundleClaimLine ::= {
  architectureClaimRef?: ArchitectureClaimRef,
  entityOfConcernRef:
    architectureBearingHolonRef | architectureRelationRef |
    selectedStructureRef | directStructuralRelationRef |
    structuralCharacteristicRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  structuralCharacteristicCueOrRef,
  affectedQBundleSlotRef,
  relationClaimKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidenceRelationForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | causalModelBased | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | reportOnly,
  directRelationDisposition:
    noDirectRelationClaimed | exactDirectOwnerAndOccurrenceRefs |
    directOwnerStillNeeded,
  directRelationOccurrenceRefs?: FinSet(U.RelationRef),
  evidenceOrCausalGoverningPatternRef?,
  nonAdmissibleUse
}

The line supports an inspectable next question without claiming measurement, modularity score, evidence sufficiency, assurance, gate passage, or causal proof. exactDirectOwnerAndOccurrenceRefs is available only when the direct characteristic, evidence, or causal pattern supplies its participant meanings, obtaining predicate, applicability, and occurrence identity and the referenced occurrences actually obtain. If no direct owner exists for a needed reusable relation, use A.6.RCD; neither a local token nor this line admits one.

Minimal structural-characteristic claim-line examples:

ArchitectureCharacteristicQBundleClaim is the triggered full claim episteme. Use it only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case reliance needs a durable bounded claim and the thin line cannot keep the content inspectable.

ArchitectureCharacteristicQBundleClaim ::= {
  claimEpistemeRef: U.EpistemeRef,
  entityOfConcernRef:
    architectureBearingHolonRef | architectureRelationRef |
    selectedStructureRef | directStructuralRelationRef |
    structuralCharacteristicRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  architectureClaimRef?: ArchitectureClaimRef,
  architectureStructuralViewRef?,
  architectureDescriptionRef?,
  structuralCHRRefs,
  affectedQBundleRefs,
  assertedParticipantRefs: {
    structuralCharacteristicRef,
    qBundleSlotRef
  },
  relationClaimPolarity:
    positive | negative | unresolved | candidateOnly,
  relationClaimKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidenceRelationForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | causalModelBased | reportOnly,
  directRelationDisposition,
  directRelationOccurrenceRefs?: FinSet(U.RelationRef),
  scopeOrScaleWindow?,
  viewpointRef?,
  qualifiers?,
  witnessExpectations?,
  admissibleSemanticChangeClasses?,
  bridgeOrLossBoundary?,
  admissibleUse,
  nonAdmissibleUse,
  evidenceOrCausalGoverningPatternRef?
}

The full claim preserves the older branch's inspectable proposal detail: assertion polarity, the exact structural-characteristic and Q-Bundle-slot referents, scope or scale window, viewpoint when it changes interpretation, qualifiers, witness expectations, admissible semantic change classes, and bridge or loss boundary. These are claim-content fields. They neither declare a reusable relation kind nor make an occurrence obtain; a direct relation still needs its own owner, participants, obtaining predicate, applicability, and occurrence identity.

Reusable product-quality vocabularies may supply candidate characteristic names, but they do not become architecture theory. The claim content may connect exact bearers and Q-Bundle slots; only the direct owner makes a relation obtain. Measurement, modularity scoring, reusable-structure accounting, bespoke-residue accounting, evidence, assurance, gate, causal, and scale-audit claims stay with their governing patterns.

#Relation to structural views

C.30.ASV governs structural-view adequacy for an exact architecture-description episteme about one selected structure; E.17.0 alone admits that same episteme as U.View through independently obtaining conformance to an exact viewpoint. C.30 governs direct ArchitectureRelation occurrences and bounded ArchitectureClaim content and, only when durable description use is being made, how its thin ArchitectureDescription bridge cites exact structural views. Hidden/lost structure, correspondence, source or reliance relations, and source-return boundaries stay explicit when they affect action. C.30.AD governs the full 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?:
  nextAdmissibleUse:

This note only names affected architecture structure for the next architecture use. Decision, ADR, gate-passage, evidence-sufficiency, and release-authorization 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 claim or boundary form that preserves the next architecture move. Use a fuller governing claim or relation record only when the content or independently admitted relation being used cannot be inspected, compared, refreshed, or bounded without it. Typical thin forms are ArchitectureMathLensUseBoundary before C.29 Mini or Full, AffectedArchitectureStructureNote before an architecture decision record, and ArchitectureStructuralCharacteristicQBundleClaimLine before full measurement, causal, evidence, or reusable direct-relation records.

InterfaceSignatureBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    interface | signature | port | endpoint | connector | link |
    API | protocol | E.18 transformation-flow relation | E.18 transformation-flow 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?,
  changePolicyOrRelationRef?,
  consumerMigrationBoundary?,
  versionOrUpdateChannelRef?,
  secureDefaultOrHardeningBoundary?,
  governingPatternApplicationRefs,
  admissibleUse,
  nonAdmissibleUse
}

These notes are not substitutes for the module-and-interface repair pattern named by value, 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 a 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

Currentness and smallest reopen. When a decisive input changes, reopen only the C.30 object and use conclusion that depend on it. A changed holon or obtaining subject relation reopens the affected selected structure and, if asserted, the direct ArchitectureRelation predicate; a changed selected structure or predicate result reopens that relation occurrence and any affirmative ArchitectureClaim reference; a changed claim scheme or ClaimScope reopens only that claim; and a changed description, view, or source edition, admissible-use boundary, or direct governor reopens its exact reference and dependent ArchitectureQuestionCard@Project disposition. Admissible results are to update the affected reference or claim mode, narrow use, re-run the direct predicate, or reopen the card when its next architecture move is no longer supported; unrelated structures, descriptions, and claims stay closed.

#Worked slices

"We have the architecture in this diagram." The diagram is a representation or publication form. It creates neither architecture nor U.View; recover an exact ArchitectureDescription episteme and, when view use is claimed, its independently obtaining E.17.0 conformance relation.

ArchitectureQuestionCard@Project:
  describedHolonRef: payment system
  claimScope: checkout-platform architecture use
  effectiveReferenceScheme: checkout-platform architecture terms
  architectureConcernCue: descriptionViewLoss or flowBottleneck
  sourcePhrase?: "architecture in this diagram"; unclear dependency between payment orchestration and fraud scoring
  questionDisposition: architectureClaimReady
  architectureRelationDisposition: actualRelationStillToRecover
  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 claim line:

ArchitectureStructuralCharacteristicQBundleClaimLine:
  architectureClaimRef: ArchitectureClaimRef
  entityOfConcernRef: selected module-interface structure or its exact structural-characteristic referent
  effectiveReferenceScheme: module-interface and maintainability terms used by this claim
  structuralCharacteristicCueOrRef: coupling under module claim, admitted direct module relation, or interface relation as actually grounded
  affectedQBundleSlotRef: maintainability Q-Bundle slot
  relationClaimKind: structuralCharacteristicRelevantToQBundleSlot
  relationGroundingKind: sourceLineageOnly | SoTAActionLineage | modelBased, as actually grounded
  directRelationDisposition: noDirectRelationClaimed | exactDirectOwnerAndOccurrenceRefs | directOwnerStillNeeded
  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, assurance, or direct relation by slogan

Use ArchitectureCharacteristicQBundleClaim only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case claim reliance needs the fuller bounded claim. If repeated use needs an independently admitted direct characteristic, evidence, or causal relation, its direct owner must first supply the participants, obtaining predicate, applicability, and occurrence identity; the useful move is 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, operating claim scope, effective reference scheme when local terms need it, 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 go 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 architecture candidate use; it is not a required project control form and not a substitute for the card, note, view, relation, or repair use above.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

Architecture is most useful in FPF when it stays close to actual selected structure over a holon and far away from document-as-architecture, graph-as-architecture, model-as-architecture, and decision-as-architecture collapses. The direct ArchitectureRelation keeps the exact holon and actual selected structure together without minting U.Architecture; an ArchitectureClaim gives practitioners a claim-bearing handle for affirmative, negative, unresolved, candidate, or expected content without substituting that episteme for the relation.

C.30 and C.30.ASV establish an FPF architecture kernel: actual subject relations first; exact selected A.22 structure; direct ArchitectureRelation to the described holon; separately constituted claim, description, viewpoint, and view epistemes; structure-kind discipline; correspondence and source-return boundaries; and characteristic-claim 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 architecture 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.

Exact episteme identity and direct view conformance also preserve plurality. The same holon, architecture-relation occurrence, or selected structure may be described by several independently identified epistemes; one episteme may conform to several exact viewpoints through distinct occurrences; several publications may render one description. C.30 keeps those variants usable without turning any publication form into architecture or any bundle/list into view membership.

#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, C.32.P2S, C.32, C.32.PAD, C.32.ADR, C.32.ADA, C.33, C.34, and C.35 when problem-to-structure carry-through, candidate-set, architecture-decision, ADR-projection, decision-adequacy, structure-capture, preservation, or discovery-adequacy claim kinds are being made.

Other 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, C.33 for captured and lost selected-structure adequacy plus source return, C.34 for preservation or correspondence adequacy, C.35 for generated or discovered carrier adequacy before C.32 admission, 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.2 for WorkPlan, A.15.5 for work-entry readiness, A.15.1 for performed work, C.11 for decisions, E.11.PUR for pattern-use recommendation, E.10.MOVE for move-like wording outside C.30 architecture-candidate use, C.32.P2S for the connected problem-to-structure architecturing flow, and E.17 for publication. C.30 governs actual ArchitectureRelation occurrences, bounded ArchitectureClaim content, selected structures, and the next admissible architecture candidate use.

#C.30:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)