#Architecture Description Adequacy (ADA)

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. Open C.30 when the live question is what architecture claim is being described, what selected structures carry it, what artifact role the current text or model has, and what the next admissible architecture move is.

#Keywords

• architecture description
• ArchitectureOf@Context
• architecture claim
• selected structure
• architecture question card
• 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. Open C.30 when the live question is what architecture claim is being described, what selected structures carry it, what artifact role the current text or model has, and what the next admissible architecture move is.

The ordinary first output is intentionally small:

ArchitectureQuestionCard@Project:
  describedHolonRef:
  boundedContextRef:
  liveArchitectureConcernCue:
  claimPosture:
    preClaimCue | problemCardReady | architectureClaimReady | nonArchitectureClaimReady
  plainPromptLabel?:
  activeStructureKindRefs: FinSet(ArchitectureStructureKindRef)
  currentCollapseCue:
  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
controlRateOrLayerMismatch
dataCustodyOrStateResidenceUnclear
placementOrJurisdictionMismatch
evidenceReuseFailure
sourceReturnNeeded
crossScopeResidual
generatedViewLoss

Use the cue only to choose the first architecture move. The cue is not a quality score, failure proof, risk rating, gate result, or decision.

Do not treat the cue as a quality, measure, risk score, decision, or free ArchitectureConcern ontology. If the concern cannot yet name described holon, bounded context, one candidate structure kind, and one admissible next architecture move, keep it as a concern cue or ProblemCard@Context-style issue; do not promote 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 carrier as liveArchitectureConcernCue, governingArchitectureConcernRefs?, or architectureConcernNotes?.

This is a project-side triage aid, not U.Architecture, not evidence, not a decision, and not a mandatory publication. The action palette for firstArchitectureMove is deliberately short:

• name or narrow the described holon and bounded context;

• choose the live structure kind;

• downgrade an artifact to publication, diagram, carrier, source-relation object, or generated relation graph when it is not a D/S view;

• repair a collapsed function, module, flow, control, interface, or signature claim;

• open a minimal architecture structural view only when it changes the next move;

• assign C.29, A.10, B.3, A.20, A.21, C.28, A.15, C.11, C.16, or another exact governing pattern only when its claim kind is live;

• state NoMLANeeded when no mathematical lens changes the next architecture move;

• stop with one admissible next architecture move.

The full ArchitectureDescription@Context opens only for durable publication, cross-team use, regulated or safety use, reusable design, FPF pattern example, comparison, reuse of a source, evidence, lens, or assurance relation, or a comparable full-mode claim kind. Ordinary use stops at ArchitectureQuestionCard@Project when it makes one next architecture move clear.

What goes wrong if C.30 is missed: a module diagram, Transduction Graph Architecture (TGA) graph, Layered Control Architecture (LCA)/control sketch, mathematical-lens output, generated relation graph, ADR, dashboard, or benchmark result is treated as the architecture; architecture then starts carrying evidence, assurance, gate, work, release, causal, or decision claim kinds it cannot carry.

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 instead of opening a full measurement, synthesis, assurance, or decision apparatus by default.

Not this pattern when the live question is only structure as such. Use A.22. If it is an architecture structural view, use [C.30.ASV](/generated/patterns/C.30.ASV). If it is a TGA graph, path, or crossing relation, use [E.18](/generated/patterns/E.18) and C.30.TGA-FLOW-REL when architecture-flow description is live. If it is evidence, assurance, causal use, gate, work, decision, publication authority, mathematical-lens adequacy, measurement, structural information, structural equivalence, morphism, or discovery aid, use the exact governing pattern or an admitted receiving pattern and keep C.30 only to the architecture-description portion.

Thin precision-restoration pointer: if the live issue is still whether architecture, architecture description, structural view, module diagram, model, artifact, layer, or functional architecture names an architecture claim, description, view, carrier, source, structure, or non-architecture receiving object, use [C.30.P](/generated/patterns/C.30.P) first. Do not copy the [C.30.P](/generated/patterns/C.30.P) trigger table into C.30; C.30 resumes after the architecture-description claim or exact non-architecture exit 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 decision, gate, evidence path, assurance case, or release claim.

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 D/S description 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/interface, work, role/enactor, evidence/assurance, information/data, placement/deployment, scale, or declared logical structure? What artifact are we looking at: architecture claim, description, view, carrier, publication, decision, source-relation object, 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/interface structure;
• 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

Introduce architecture-description adequacy as governance for describing an ArchitectureOf@Context claim record that selects intensional structure for one holon in one bounded context. The description is governed; it is not the architecture itself.

C.30 does not mint U.Architecture and does not redefine U.Viewpoint. It specializes A.22 structure records and U.MultiViewDescribing for architecture descriptions whose described entity is the ArchitectureOf@Context claim record for a holon, while preserving the I/D/S distinction between architecture and its descriptions.

C.30 governs architecture-description adequacy for one ArchitectureOf@Context claim record over selected candidate:U.Structure references for one described holon in one bounded context. It governs ArchitectureOf@Context, ArchitectureQuestionCard@Project, ArchitectureDescription@Context, architecture-description publication boundaries, architecture name formation, characteristic assignment, first architecture-question assignment, and small boundary notes. It does not mint U.Architecture and does not govern all architecture structure-kind views; C.30.ASV governs architecture structural views.

#Architecture claim record

ArchitectureOf@Context ::= {
  describedHolonRef: U.HolonRef,
  boundedContextRef: U.BoundedContextRef,
  structureRefs: FinSet(candidate:U.StructureRef),
  structureKindRefs: FinSet(ArchitectureStructureKindRef),
  liveArchitectureConcernCue?,
  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 D/S description, 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.DescribedEntityRef for architecture D/S descriptions and views. The holon whose architecture is claimed remains ArchitectureOf@Context.describedHolonRef; it is not the D/S DescribedEntityRef for those architecture descriptions unless a separate direct holon description is opened.

#Architecture description record

ArchitectureDescription@Context is a governed multi-view D/S description record set over one ArchitectureOf@Context claim record and selected StructuralDescription@Context or StructuralView@Context records. It is used for engineering reasoning about the described holon's design, operation, evolution, interfaces, work, evidence, adequacy, and scale behavior through typed relations to exact non-architecture records; it does not collect those non-architecture claim kinds as architecture-description ontology.

ArchitectureDescription@Context ::= {
  architectureDescriptionId: ArchitectureDescriptionId,
  architectureClaimRef: ArchitectureOf@ContextRef,
  descriptionContext: DescriptionContext(
    DescribedEntityRef = architectureClaimRef,
    BoundedContextRef = ArchitectureOf@Context.boundedContextRef,
    ViewpointRef = viewpointRef
  ),
  selectedStructureRefs: FinSet(candidate:U.StructureRef),
  structureKindRefs: FinSet(ArchitectureStructureKindRef),
  architectureStructuralViewRefs: FinSet(ArchitectureStructuralViewRef),
  structuralAspectDescriptionRefs: FinSet(StructuralAspectDescriptionRef),
  correspondenceModelRefs: FinSet(CorrespondenceModelRef),
  structuralRelationRecordRefs: FinSet(QualifiedRelationRecordRef),
  descriptionRelianceRelationRefs?: FinSet(
    CharacteristicRelationRef | EvidencePathRef | AssuranceCaseRef |
    TGASourceRelationRef | MLALensBoundaryRef | SourceReturnRef
  ),
  freshnessCueRefs?: FinSet(ArchitectureDescriptionFreshnessCueRef),
  sourceReturnCondition?,
  admissibleUse,
  nonAdmissibleUse
}

ArchitectureDescription@Context is not the holon itself, not the selected structure, not identical to the ArchitectureOf@Context claim record, and not the publication face, carrier, or rendering. It is a D/S episteme record whose DescriptionContext.DescribedEntityRef points to the ArchitectureOf@Context claim record.

Use an ArchitectureDescriptionFreshnessCue when the admissible use of an architecture description depends on source edition or structure edition:

ArchitectureDescriptionFreshnessCue:
  sourceEditionRefs:
  structureEditionRefs?:
  knownRefreshTrigger:
    sourceChange | deploymentChange | interfaceChange | controlRateChange |
    modelEditionChange | evidenceDecay | toolApiChange |
    legalRegulatoryChange | incidentFinding | unknown
  admissibleUseUntil:
  sourceReturnCondition:

The freshness cue is not evidence sufficiency and not assurance. It only bounds the architecture description's admissible use.

#Publication boundary

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

ArchitectureDescriptionPublication@Project is E.17/MVPK-subordinate. It publishes one source episteme or episteme-lane view reference. mvpkFaceRef is a publication-lane face reference, not an alternative source object. Publication does not add architecture claims, evidence sufficiency, gate status, work authority, assurance, decision authority, or release permission.

Model cards, system cards, and evaluation harness reports enter C.30 through the same publication/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,
  describedEntityRef,
  describedEntityKind:
    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 live architecture structure kind 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-force-bearing use is conforming only with:
  describedHolonRef,
  boundedContextRef,
  structureKindRef = <X>StructureKind or declared local relation,
  structureRefs,
  ArchitectureStructuralViewRefs if this is a description/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 architecture-adequacy force. Those words are triggers for bearer recovery, not stable architecture adequacy by themselves.

ArchitectureCharacteristicAssignment:

A. SystemQualityAffectedByArchitecture
   Bearer: described U.Holon or named product/system entity
   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/interface relation
      Governing pattern: C.16 / A.17-A.19 / admitted architecture-characterization receiving pattern
   Examples: coupling, cohesion, interface alphabet, substitutability, hidden coupling, reusable-structure share

C. ArchitectureDescriptionAdequacy
   Bearer: ArchitectureDescription@Context / architecture structural view / correspondence model
   Governing pattern: C.30 / E.17 / C.16.Q / C.16
   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 causal-use governance 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; send measurement, modularity scoring, reusable-structure share or accounting, bespoke-residue accounting, evidence sufficiency, assurance, gate, causal proof, and scale audit to their exact 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,
  relationBasisKind:
    modelBased | empirical | causalModelBased | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | reportOnly,
  evidenceOrCausalGoverningPatternRefIfLive?,
  nonAdmissibleUse
}

Minimal structural-characteristic relation-line examples:

ArchitectureCharacteristicQBundleRelationRecord is a triggered/full-mode record, not the ordinary first-contact shape. Open the full record only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case relation reliance is live 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 are live. 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 posture, evidence or causal governing patterns, or report-only posture.

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

#Relation to structural views

C.30.ASV governs ArchitectureStructuralView@Context. C.30 only governs the architecture-description relation to the structural views it uses, with hidden/lost structure, correspondence, source or reliance relation, and source-return boundaries recoverable when those boundaries affect action.

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 opening 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. It is not an architecture decision, not an ADR, not gate passage, not evidence sufficiency, and not release authority.

#Minimal boundary notes

Use these notes when a common architecture phrase is close to a exact governing pattern but the full governing pattern is not yet live.

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

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

ModuleRelationBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    module | component | package | platform | stack | open architecture |
    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 exact module/interface repair pattern, interface specifications, signature records, conformance evidence, or module/interface repair. An open or platform label is not substitutability proof, security proof, scale proof, assurance, or universal maturity evidence. 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 exact module/interface relation ref, exact governing relation record, or governing FPF pattern carrier is named. The note keeps first use honest until the exact non-architecture claim kind opens.

#Architecture mathematical-lens boundary

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

ArchitectureMLABoundary:
  noMLANeeded?: yes | no
  lensOneLine?:
    lensRef,
    structureClaimRef,
    preservedStructure,
    lostStructure,
    lensRelationBasisKind,
    stopCondition,
    governingPatternApplicationRefs?

Use the one-line boundary only when it is enough to keep the lens from being overread. Open C.29 Mini or Full cards when the lens choice, preserved/lost structure, relation posture, 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 adequacy, preserved/lost structure, relation posture, and stop condition when those are live.

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
liveArchitectureConcernCue: unclear dependency between payment orchestration and fraud scoring
plainPromptLabel: "architecture in this diagram"
activeStructureKindRefs: FunctionalStructure, ModuleInterfaceStructure, FlowTransductionStructure
currentCollapseCue: 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/interface relation
  affectedQBundleSlotRef: maintainability Q-Bundle slot
  qBundleRelationKind: structuralCharacteristicRelevantToQBundleSlot
  relationBasisKind: sourceLineageOnly | SoTAActionLineage | modelBased, as actually grounded
  evidenceOrCausalGoverningPatternRefIfLive?: C.28 / B.3 / A.10 / G.6 when the stronger claim is live
  nonAdmissibleUse: causal proof or assurance by slogan

Open 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." 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 object, 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 live move; it is not a required project control form and not a substitute for the card, note, view, relation, or repair move above.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

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 intensional structure for a described holon, with D/S descriptions 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 live structure kind, 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, or source/reliance reuse is live.

The D/S split 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.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 receiving patterns for architecture decision and candidate-set claims when those claim kinds are live.

Does not replace: A.22 structure carrier, C.30.ASV structural-view adequacy, E.TGA graph/path/crossing discipline, C.29 mathematical-lens adequacy, C.16 characterization, C.25 Q-Bundles, C.28 causal-use support, A.10/G.6 evidence, B.3 assurance, A.20/A.21 gate/release records, A.15 work, C.11 decisions, or E.17 publication.

#C.30:End

Last Updated: 2026-05-26 — this section last modified in upstream FPF commit a7be1428 (github.com/ailev/FPF)