#Architecture Description Adequacy

C.30.AD · 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

Plain-name. Architecture-description adequacy.

Intent. Keep an architecture description useful without letting the description, view, diagram, publication, or tool publication face become the architecture itself.

Builds on. C.30, C.30.ASV, A.1, A.22, E.24.PUB, A.7, A.6.3, E.17.0, E.17.1, E.17.2, E.17, C.2.P, E.10, and E.10.ARCH.

Coordinates with. C.30.AD.BA, C.30.P, C.30.TFS-REL, C.30.LCA, C.30.ILC, C.32.P2S, C.32, C.32.MLAO, C.32.PAD, C.32.ADR, C.32.ADA, A.6.3.NAR, A.19.CPM, A.19.SelectorMechanism, C.18, C.19, G.5, A.6.F, A.6.M, C.29, C.16, C.16.P, A.10, B.3, A.20, A.21, A.15, A.15.5, C.11, C.28, E.8, E.10.MOVE, E.11.PUR, E.24.CD, and F.18.

Use this pattern when current work must create, inspect, compare, reuse, or rely on a durable architecture-description episteme, a multi-view description set, a generated architecture-relation view, or a specification-use record. Open it only after the practitioner can name the exact described object: one holon, one obtaining ArchitectureRelation occurrence, or one exact selected U.Structure.

#Keywords

• architecture description
• ArchitectureDescription@Context
• architecture description use card
• architecture structural view
• viewpoint
• correspondence
• source return
• specification-use boundary
• candidate-description boundary.

#Relations

#Content

#Use this when

Use this pattern when current work must create, inspect, compare, reuse, or rely on a durable architecture-description episteme, a multi-view description set, a generated architecture-relation view, or a specification-use record. Open it only after the practitioner can name the exact described object: one holon, one obtaining ArchitectureRelation occurrence, or one exact selected U.Structure.

Use C.30.AD when the practitioner needs to know:

• which exact holon, architecture-relation occurrence, or selected structure each description episteme is about;
• which architecture claim is being carried or inspected, without substituting that claim for the description's EntityOfConcern;
• which selected structures or architecture structure kinds are described;
• which descriptions qualify as U.View under which exact U.Viewpoint epistemes and independently obtaining EpistemeViewpointConformanceRelation occurrences;
• which cross-view correspondence claims, source-to-use paths, source-return conditions for stronger use, freshness boundaries, and specification-use boundaries make the description usable;
• what the description can guide and which uses are non-admissible.

What goes wrong if missed. A diagram, documentation set, generated relation graph, model card, ADR publication set, file, or architecture model starts acting as architecture, selected structure, U.View, proof, gate, assurance, decision, work authorization, or release authorization by presentation alone.

What this buys. The practitioner can keep architecture descriptions inspectable across exact subjects, views, viewpoints, selected structures, cross-view correspondence claims or separately governed relations, source-to-use paths, applicable source-return conditions, representations, publications, and direct governing-pattern applications.

First useful description-use output. Write one ArchitectureDescriptionUseCard@Project:

ArchitectureDescriptionUseCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureDescriptionProjectUseRelationRef?: U.RelationRef governed by the exact description-use or work-use pattern
  architectureDescriptionRef?: U.EpistemeRef constrained to ArchitectureDescription
  entityOfConcernRef: exactly one of (
    describedHolonRef | architectureRelationOccurrenceRef | selectedStructureRef
  )
  effectiveReferenceScheme: U.ReferenceScheme, byValue
  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim)
  claimScope?: U.ClaimScope, byValue
  concernRefs?: FinSet(U.EntityRef)
  modelUseStructureRef?: U.StructureRef
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
  descriptionPurpose:
  selectedStructureRefs: FinSet(U.StructureRef)
  structureKindRefs: FinSet(ArchitectureStructureKindRef)
  viewpointRefs?: FinSet(U.EpistemeRef constrained to U.Viewpoint)
  architectureStructuralViewRefs?: FinSet(U.EpistemeRef constrained to ArchitectureStructuralView)
  viewpointConformanceRelationRefs?: FinSet(EpistemeViewpointConformanceRelationRef)
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef)
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  sourceReturnCondition?:
  representationRefs?: FinSet(U.EntityRef)
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef)
  publicationFormRefs?: FinSet(U.EntityRef)
  carrierRefs?: FinSet(U.EntityRef constrained to U.PresentationCarrier)
  specificationUseBoundary?:
  admissibleUse:
  nonAdmissibleUse:
  firstGoverningPatternApplication?:

@Project is a compatibility and retrieval cue for a project-side use card. The suffix supplies no project identity, authority, context, viewpoint, parthood, or work occurrence. When one actual project matters, projectWorkOccurrenceRef identifies the composite U.Work recovered under [A.15.6](/generated/patterns/A.15.6), and architectureDescriptionProjectUseRelationRef identifies the exact obtaining relation by which this description use concerns that work. Name that relation's direct governing pattern; the reference to work alone does not establish project locality.

The card is a controlled first-pass slice, not an identity constructor. It can close ordinary use only when it names one exact EntityOfConcern, the effective U.ReferenceScheme, one usable description purpose, the selected structures and their structure-kind classifications, admissible use, non-admissible use, and one remaining architecture candidate use or direct governing-pattern application. If it calls the description a U.View, it also names the exact viewpoint episteme and the separately obtaining conformance relation. Expand to the fuller ArchitectureDescription record when cross-view correspondence, source use, a stronger-use source-return condition, freshness, specification use, regulated use, comparison, publication, representation, or project-side authority use is current.

Not this pattern when.

• If the current use is a grounded architecture claim, an obtaining ArchitectureRelation, or one first architecture question, use [C.30](/generated/patterns/C.30).
• If the current use is a selected structure or structural description outside architecture, use [A.22](/generated/patterns/A.22).
• If the current use is one architecture structural view and its viewpoint-conformance test, use [C.30.ASV](/generated/patterns/C.30.ASV).
• If the current use is built-asset architecture-description, BIM, IFC, asset-information, digital-twin, or reference-designation specialization, use [C.30.AD.BA](/generated/patterns/C.30.AD.BA).
• If architecture or structure wording is still ambiguous, use [C.30.P](/generated/patterns/C.30.P).
• If the current use is only a representation, publication occurrence, publication face, publication form, report, dashboard, file, carrier, source-expression relation, or publication-currentness relation, use [C.2.P](/generated/patterns/C.2.P), [E.17](/generated/patterns/E.17), [E.24.PUB](/generated/patterns/E.24.PUB), or the direct representation, publication, or source-use pattern governing the claim.
• If the description is being used as pattern-use recommendation, work-entry readiness, evidence, assurance, gate passage, decision, work authorization, causal-use claim, release authorization, deontic permission, or mathematical-lens use, keep [C.30.AD](/generated/patterns/C.30.AD) only for the description boundary and apply the direct pattern governing that claim to the claim being made.

#Problem frame

Architecture practice needs durable descriptions: multi-view documents, view models, generated relation graphs, architecture transformation-flow views, LCA control sketches, module or interface diagrams, deployment views, model cards, system cards, and architecture decision description sets. These descriptions are useful because they let teams compare, reuse, refresh, inspect, and use architecture claims across viewpoint families and working concerns; A.15 allocation-responsibility semantics apply only when a project role relation itself is being governed.

The difficulty is that a description is not the architecture, an obtaining architecture relation, or its selected structure. The same holon and architecture-relation occurrence can have several descriptions. A description set can contain several separately identified epistemes. One such episteme is a U.View only while an exact EpistemeViewpointConformanceRelation obtains between that same episteme and one exact viewpoint episteme. Each view can hide, lose, coarsen, or emphasize different structure. A view can describe functional structure, flow or transformation-flow structure, control structure, module or interface structure, placement structure, information custody, evidence-reuse relation, assurance relation, scale or coarsening relation, or another declared architecture-relevant structure.

The first-minute practitioner can ask:

• What exact holon, obtaining ArchitectureRelation occurrence, or selected structure is this description episteme about?
• What exact claim graph, one EntityOfConcern, and effective U.ReferenceScheme keep that episteme identifiable?
• Which selected structures or structure kinds does this description carry?
• Which exact viewpoint episteme and conformance relation, if any, make this same episteme a U.View?
• What correspondence connects this description to architecture claims and other view epistemes without inventing a subject relation?
• Which source episteme, source view, representation, or publication enters this use through which source-to-use path, and what stronger use would activate a source-return condition?
• What admissible architecture move remains after the description has been used?

#Problem

How can FPF govern architecture descriptions without:

• treating a description, model, view, diagram, graph, card, table, dashboard, file, publication occurrence, publication form, carrier, or rendering as the architecture, an obtaining relation, or a selected structure;
• treating all architecture documentation as one generic description with no exact EntityOfConcern or selected-structure recovery;
• granting U.View membership because an episteme was authored, constructed, queried, selected, bundled, diagrammed, or published;
• losing the link between one exact viewpoint episteme, the five-part conformance predicate, and the architecture structure kind being described;
• letting one attractive view hide lost structure, stale source, or missing correspondence;
• letting publication quality become empirical grounding, evidence sufficiency, assurance, gate passage, decision claim, work completion, or release authorization;
• making ordinary architecture triage too heavy for a first useful architecture move.

#Forces

#Solution

Use ArchitectureDescription when current work must create, inspect, or rely on a C.2.1 U.Episteme about exactly one architecture-side EntityOfConcern: one holon, one obtaining ArchitectureRelation occurrence, or one exact selected U.Structure. The episteme keeps the C.2.1 identity triple <exact ClaimGraph, one exact EntityOfConcern, effective U.ReferenceScheme>. An ArchitectureClaim can be cited as carried claim content or trace, but the claim record is not automatically the description's EntityOfConcern and does not replace the described subject.

Keep ClaimScope, empirical grounding, concern, viewpoint, view membership, selected model-use structure, representation, publication occurrence, publication form, carrier, project Work, and project-use relation outside that identity triple. Add each only when it independently applies. modelUseStructureRef is optional and appears only when an actually selected DDD model-use structure changes interpretation or selection.

C.30.AD does not mint U.Architecture, does not redefine U.Viewpoint, and does not replace generic Description, view, representation, publication, or publication-form machinery. It specializes those objects for architecture-description use while keeping every selected architecture-relevant structure directly recoverable.

Built-asset architecture-description, BIM, IFC, asset-information, digital-twin, and ISO/IEC 81346 reference-designation detail is governed by C.30.AD.BA. C.30.AD keeps the general architecture-description bridge and does not absorb that built-asset specialization.

#Architecture-description record

ArchitectureDescription ::= U.Episteme & {
  architectureDescriptionRef: U.EpistemeRef,
  claimGraph: exactly one C.2.1 ClaimGraph,
  entityOfConcernRef: exactly one of (
    describedHolonRef | architectureRelationOccurrenceRef | selectedStructureRef
  ),
  effectiveReferenceScheme: U.ReferenceScheme, byValue,

  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim),
  selectedStructureRefs: FinSet(U.StructureRef),
  structureKindRefs: FinSet(ArchitectureStructureKindRef),

  claimScope?: U.ClaimScope, byValue,
  concernRefs?: FinSet(U.EntityRef),
  modelUseStructureRef?: U.StructureRef,
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef),

  architectureStructuralViewRefs?: FinSet(U.EpistemeRef constrained to ArchitectureStructuralView),
  viewpointConformanceRelationRefs?: FinSet(EpistemeViewpointConformanceRelationRef),
  descriptionSetUseClaimRefs?: FinSet(U.EpistemeRef),
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef),

  sourceEpistemeRefs?: FinSet(U.EpistemeRef),
  sourceViewRefs?: FinSet(U.ViewRef),
  sourceToUsePathRefs?: FinSet(U.RelationRef),
  sourceReturnCondition?,
  freshnessClaimRefs?: FinSet(U.EpistemeRef),

  representationRefs?: FinSet(U.EntityRef),
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef),
  publicationFormRefs?: FinSet(U.EntityRef),
  carrierRefs?: FinSet(U.EntityRef constrained to U.PresentationCarrier),
  specificationUseBoundary?,
  publicationUseBoundary?,
  admissibleUse,
  nonAdmissibleUse
}

The record identifies one episteme, not a document container. Its one entityOfConcernRef is supplied directly and is never derived merely from an architecture-claim field. When the EntityOfConcern is an architecture-relation occurrence or selected structure, participant traces can still recover its holon without changing episteme identity. architectureClaimRefs carries relevant claim content or trace only. selectedStructureRefs names the architecture-relevant structures described by the claim graph, while structureKindRefs classifies those structures.

Minimum conformance for the record:

• the exact claim graph, one exact EntityOfConcern, and effective U.ReferenceScheme are all present;
• actual architecture-relation references identify independently obtaining ArchitectureRelation occurrences; required, desired, expected, candidate, unresolved, or negative architecture content stays claim content;
• selectedStructureRefs names the architecture-relevant structures being described, and structureKindRefs classifies those selected structures;
• any cited ArchitectureStructuralView is the same description episteme admitted as U.View only by a separately obtaining E.17.0 conformance relation to one exact viewpoint episteme;
• cross-view composition uses explicit description-set use claims, correspondence claims, or separately governed obtaining relations; source use names source-to-use paths; a source-return condition appears only when stronger use requires return to a named source or governing pattern;
• representation and publication fields identify their own objects and occurrences; they do not establish the description, architecture, selected structure, view membership, empirical grounding, or truth;
• admissibleUse and nonAdmissibleUse say what the description can and cannot carry.

#Traceable architecture multi-view description chain

A full architecture description is traceable only when the reader can recover the chain that makes a view useful without turning the view into the architecture or letting a list create view membership. The chain is a trace requirement, not a prescribed method or work plan:

workingConcernRef
-> exact viewpoint episteme
-> independently obtaining EpistemeViewpointConformanceRelation
-> the same ArchitectureDescription episteme admitted as U.View
-> exact entityOfConcernRef
-> selectedStructureRef and, when actual, ArchitectureRelationOccurrenceRef
-> optional ArchitectureClaimRef
-> ArchitectureDescriptionUseCard or multi-view description-set use claim
-> admissibleArchitectureMove or governing-pattern application

When allocation-responsibility semantics are current, the direct A.15 relation joins the working concern. When a source episteme or source view is used, a source-to-use path joins it to the view or description. Representation adds its own representation relation or object. Publication adds a publication occurrence with its form and carrier kept distinct. Cross-view use adds a correspondence claim or a direct correspondence relation only under its own admitted owner. A source-return condition is added only when a stronger use must return from a derivative or reused expression to a named source or governing pattern.

[E.17.0](/generated/patterns/E.17.0) carries the generic viewpoint-conformance test and the rule that the same episteme is a U.View iff the direct relation obtains. [C.30.ASV](/generated/patterns/C.30.ASV) carries selected-structure and architecture-view adequacy. [C.30.AD](/generated/patterns/C.30.AD) carries the architecture-specific composition and use boundary: which exact objects each description is about, which structural views it uses, which correspondence claims or relations connect them, which source-to-use paths support source use, which stronger uses activate a source-return condition, and which architecture move or governing-pattern application remains admissible.

If any link in the chain is absent, do not fill it with a documentation label, query result, bundle membership, diagram, file, or publication. Either add the missing exact reference or independently obtaining relation, reduce the admissible use, or apply the governing pattern that can recover it.

#View membership, viewpoint, and structure-kind binding

An architecture description episteme is not a U.View because it is put in a multi-view set, authored under a viewpoint label, constructed by A.6.3, returned by a query, selected, bundled, diagrammed, rendered, or published. First identify the candidate episteme by its C.2.1 identity. Then identify one exact viewpoint episteme and test the fixed five-part E.17.0 predicate. Only a separately obtaining EpistemeViewpointConformanceRelation(candidateEpisteme, exactViewpoint) admits that same episteme as U.View.

When a receiving use needs one multi-view description set, recover an exact collection of independently identified description epistemes under C.13; set membership is ordinary collection membership. A shared file, bundle, heading, graph, publication, or query result neither identifies that collection nor grants U.View membership. The collection keeps no second episteme identity for its members.

C.30.AD can record use of already recoverable architecture structural views inside one description set without minting a local relation kind:

ArchitectureDescriptionViewUseClaim ::= U.Episteme & {
  claimGraph: {
    architectureDescriptionSetRef,
    usedArchitectureStructuralViewRef,
    usePurpose:
      orientation | comparison | implementationGuidance |
      assuranceInput | sourceUse | strongerUseReturn | declaredOther,
    correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef),
    sourceToUsePathRefs?: FinSet(U.RelationRef),
    sourceReturnCondition?,
    admissibleUse,
    nonAdmissibleUse
  },
  entityOfConcernRef: exactly one architectureDescriptionSetRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue
}

The use claim does not grant U.View membership and does not make its view, set, viewpoint, or selected structure obtain. Each usedArchitectureStructuralViewRef must already identify the same description episteme whose exact E.17.0 conformance relation obtains. Use [C.30.ASV](/generated/patterns/C.30.ASV) when the current question is whether the episteme has the right selected structure, structure kind, exact viewpoint, conformance relation, hidden or lost structure note, source-to-use path, or source-return condition activated by stronger use. Use [A.22](/generated/patterns/A.22) when the current question is structure as such. Use [C.30](/generated/patterns/C.30) when the current question is an obtaining architecture relation or grounded architecture claim. Use [C.30.AD](/generated/patterns/C.30.AD) only for description identity, description-set use, cross-view correspondence, source use, an applicable source-return condition, freshness, specification use, publication use, or the remaining architecture candidate-use boundary. Common architecture-description views:

#Cross-view correspondence, source use, and return conditions

Architecture descriptions become risky when a reader cannot tell whether two view epistemes concern the same holon, the same architecture-relation occurrence, the same selected structure, related structures, or different EntitiesOfConcern. A description set therefore carries explicit correspondence claims or references an independently admitted direct correspondence relation. Merely placing two views in one file, model, list, or publication creates neither correspondence nor shared identity. Use source-to-use paths when source epistemes, views, generated outputs, representations, or publications enter current use. Add a source-return condition only when stronger use requires return from a derivative or reused description to a named source or governing pattern.

ArchitectureDescriptionCorrespondenceClaim ::= U.Episteme & {
  claimGraph: {
    architectureDescriptionSetRef,
    fromViewRef,
    toViewRef,
    correspondenceKind:
      sameDescribedHolon | sameArchitectureRelationOccurrence |
      sameSelectedStructure | refinement | abstraction | projection |
      sourceDerived | conflict | declaredOther,
    preservedStructureRefs?,
    lostStructureRefs?,
    directCorrespondenceRelationRefs?: FinSet(U.RelationRef),
    sourceToUsePathRefs?: FinSet(U.RelationRef),
    sourceReturnCondition?,
    admissibleUse,
    nonAdmissibleUse
  },
  entityOfConcernRef: exactly one architectureDescriptionSetRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue
}

This local record is claim content and does not itself instantiate a world-side correspondence relation. A directCorrespondenceRelationRef is affirmative only when that relation's own governing pattern admits it and the occurrence independently obtains. Correspondence is not proof, empirical grounding, assurance, gate passage, shared EntityOfConcern, or architecture identity; it lets a reader use more than one view without silently changing what each episteme is about.

#Freshness and currentness boundary

Use a freshness claim only when the architecture description's admissible use depends on source edition, structure edition, model version, deployment state, or an external condition. Keep this bounded claim distinct from any publication-currentness relation:

ArchitectureDescriptionFreshnessClaim ::= U.Episteme & {
  claimGraph: {
    sourceEditionRefs,
    structureEditionRefs?,
    modelOrToolEditionRefs?,
    knownRefreshTrigger:
      sourceChange | deploymentChange | interfaceChange |
      controlRateChange | modelEditionChange | evidenceDecay |
      toolApiChange | regulatoryChange |
      incidentFinding | declaredOther | unknown,
    admissibleUseUntil?,
    sourceReturnCondition?
  },
  entityOfConcernRef: exactly one ArchitectureDescriptionRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue
}

A freshness claim carries a source-return condition only when a stronger use must return to a named source or governing pattern. It does not make the description empirically grounded, evidence-sufficient, true, or publication-current; it only bounds current use of the exact description episteme under the stated scheme.

#Specification-use and publication boundary

An architecture description can be used as a specification only when that use is declared. Specification use is not a new architecture kind; it is a bounded use of an exact description episteme or of one of its publications.

ArchitectureDescriptionSpecificationUse@Project ::= {
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work,
  architectureDescriptionProjectUseRelationRef?: U.RelationRef governed by the exact specification-use or work-use pattern,
  architectureDescriptionRef: U.EpistemeRef constrained to ArchitectureDescription,
  sourceEpistemeRef?: U.EpistemeRef,
  sourceViewRef?: U.ViewRef,
  sourceToUsePathRefs?: FinSet(U.RelationRef),
  representationRef?: U.EntityRef,
  publicationOccurrenceRef?: EpistemePublicationRelationRef,
  publicationFormRef?: U.EntityRef,
  carrierRef?: U.EntityRef constrained to U.PresentationCarrier,
  governedUse:
    coordination | implementationGuidance | procurement |
    verificationPlanning | assuranceInput | releaseInput |
    declaredOther,
  directGoverningPatternRef?: U.EntityRef, referencing one U.MethodDescription,
  admissibleUse:
  nonAdmissibleUse:
}

The two project fields preserve the ordinary boundary: projectWorkOccurrenceRef identifies an actual composite U.Work; architectureDescriptionProjectUseRelationRef identifies a separately obtaining project-use relation under its direct owner. Neither a project label nor this use record creates that Work or relation.

If specification use becomes pattern-use recommendation, work-entry readiness, evidence, assurance, gate passage, performed work, work authorization, decision claim, causal-use claim, or release authorization, apply the direct pattern governing that claim to the claim being made. The architecture description remains the description boundary, not the governing claim.

Keep the description episteme, its possible U.View membership, diagram or other representation, publication occurrence, publication form, and carrier distinct. Authoring, construction, querying, selection, bundling, rendering, filing, or publication creates none of the subject-side architecture relation, selected structure, description truth, empirical grounding, project Work, or project-use relation by itself.

#Direct governing-pattern applications

#Candidate, front, and selected-set description boundary

An architecture description can also carry claims about a project architecture decision or selected structures cited by an ADR-like publication. Use C.32.PAD for the project architecture decision relation, C.32.ADR for publication projection of an architecture-decision description, and C.32.ADA for adequacy of that decision for a declared use. C.30.AD keeps only the exact description identity, possible E.17.0 view conformance, description-set use claims, cross-view correspondence claims or governed relations, source-to-use paths when sources are used, applicable source-return conditions, freshness, representation, publication use, and specification use.

An architecture description may carry claim content about an archive, front, selected set, candidate palette, local choice, or planned architecture move. That does not make the description the archive-governing pattern, selector, choice rule, pattern-use recommendation, work-entry readiness relation, work authorization, or deontic permission. Use C.32.MLAO for residual-reducing multilevel candidate frames, C.32 for candidate architecture palettes, C.18 for archive and front relations, C.19 for current-pool treatment, G.5 only for selected-set publication, C.11 for local choice, C.30 for the architecture move, C.30.ASV for selected-structure view triage, E.11.PUR for recommended pattern use, A.15.5 for work-entry readiness, and the A.15 family for planning or performed work.

For an architecture-description claim, record exact episteme identity plus only the view conformance, description-set use, viewpoint, cross-view correspondence, source-to-use path, applicable stronger-use return condition, freshness, representation, publication use, and specification use that actually apply. If the current source claim only grounds a first architecture move, return to C.30. If it synthesizes alternatives, use C.32 or C.32.MLAO according to the residual frame. If it changes which variants are archived, kept in a pool, compared, selected, published, locally chosen, or decided, return to the pattern that governs that relation.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Conformance checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Architecture descriptions become reusable without pretending to be the architecture, an obtaining relation, or selected structure.
• Multi-view work can keep each episteme identity, exact viewpoint conformance, selected structures, cross-view correspondence, source-to-use paths, applicable source-return conditions, freshness, representation, publication, and specification use inspectable.
• Description, view membership, representation, publication, empirical grounding, evidence, assurance, gate, decision, Work, project use, release, and mathematical-lens claims stay distinct and return to their governing patterns.
• C.30 can stay focused on architecture while C.30.AD carries the heavier description machinery.

Costs:

• A useful architecture document needs explicit links to exact description epistemes, EntitiesOfConcern, effective schemes, selected structures, and admissible use.
• A claimed view additionally needs the exact viewpoint episteme and independently obtaining E.17.0 conformance relation.
• Reused or regulated descriptions may need correspondence refs, source-to-use paths, source and structure editions, applicable source-return conditions, and freshness claims before they can be relied on.
• Familiar diagrams, files, and publication forms lose implicit authority; grounding, evidence, assurance, gate, decision, and release claims must be established by their own patterns.

#Rationale

Architecture work needs descriptions, but architecture-description adequacy is not architecture adequacy. A description can guide architecture work only when its own C.2.1 identity and its relation to exact subject-side objects, selected structures, architecture claims, exact viewpoint conformance, other descriptions, source epistemes or views actually used, source-to-use paths, representation, publication, and admissible use are recoverable.

The pattern therefore specializes generic Description and publication machinery for architecture use. It does not mint a new architecture kind, direct subject relation, local view-membership relation, or second meaning of U.View; it does not replace C.30; and it does not let diagrams or documentation formats establish non-description claims by presentation alone.

#SoTA-Echoing

#Relations

• C.2.1 governs the exact identity of every architecture-description episteme.
• C.30 governs obtaining architecture relations, selected-structure adequacy, and bounded architecture claims.
• C.30.P normalizes overloaded architecture or structure wording before this pattern is used.
• C.30.ASV governs architecture structural-view adequacy, while E.17.0 alone admits the same episteme as U.View through exact viewpoint conformance.
• C.33 governs capture and loss of selected structure when an architecture description, generated relation graph, ADR-like record, or view set carries only part of the architecture content for a declared use.
• C.34 governs preservation or correspondence adequacy when the architecture description is being compared with another view, source model, generated output, candidate, or realized structure.
• A.6.3.NAR governs a reader-facing narrative rendering made from an architecture description, description set, view set, or architecture-decision route. C.30.AD governs architecture-description adequacy; A.6.3.NAR governs only the structure-to-sequence relation, selected-source carry-through, lost structure, reader-use boundary, and applicable source-return condition.
• C.30.TFS-REL, C.30.LCA, and C.30.ILC govern architecture structure-relation subcases named by value.
• C.32.P2S governs the connected architecturing flow when the description carries only part of selected structure, decision handoff, method expectation, source-to-use continuity, an applicable source-return condition, or actual-structure feedback.
• A.7, E.17.0, E.17.1, E.17.2, E.17, and E.24.PUB govern generic EntityOfConcern, view, viewpoint, representation, publication occurrence, form, carrier, and MVPK machinery.
• C.2.P normalizes source-expression, source-to-use, publication-form, and publication-currentness relation-set overreads.
• E.11.PUR governs recommended FPF pattern use after an architecture description has been read; C.30.AD only records the description-use boundary.
• A.15.5 governs work-entry readiness and full-kit condition for intended architecture work; the A.15 family governs Work and project-use relations. C.30.AD records only exact descriptions and their view conformance, description-set use, correspondence, source-to-use paths, applicable source-return conditions, freshness, representation, publication use, and specification use.
• E.10.MOVE restores move-like wording when source prose about an architecture description does not mean a C.30 architecture move or a C.30.AD remaining architecture candidate use.

#C.30.AD:End

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