#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 an architecture description is the current EntityOfConcern: a durable description, multi-view description set, architecture documentation set, model set, generated architecture relation graph, view set, or specification-use record over one ArchitectureOf@Context.

#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 an architecture description is the current EntityOfConcern: a durable description, multi-view description set, architecture documentation set, model set, generated architecture relation graph, view set, or specification-use record over one ArchitectureOf@Context.

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

• which ArchitectureOf@Context claim the description is about;
• which selected structures or architecture structure kinds are described;
• which views are used under which viewpoints;
• which correspondences, source returns, freshness boundaries, or 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, or architecture model starts acting as architecture, proof, gate, assurance, decision, work authorization, or release authorization by presentation alone.

What this buys. The practitioner can keep one architecture description inspectable across views, viewpoints, selected structures, correspondences, publications, source returns, and direct governing-pattern applications.

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

ArchitectureDescriptionUseCard@Project:
  architectureClaimRef:
  describedHolonRef:
  boundedContextRef:
  descriptionPurpose:
  selectedStructureRefs:
  structureKindRefs:
  viewpointRefs:
  architectureStructuralViewRefs:
  correspondenceRefs:
  sourceReturnCondition?:
  specificationUseBoundary?:
  admissibleUse:
  nonAdmissibleUse:
  firstGoverningPatternApplication?:

@Project guard: in this card name, @Project marks a project-side use card for first-pass triage or specification-use control. It is not U.Project, not a bounded context, not project authority, and not a part-whole relation. If one of those claims is current, use the governing project, context, authority, or part-whole pattern named by value.

The use card is a controlled first-pass slice. It can close ordinary use only when it names one architecture claim, one usable description purpose, the selected structures or structure kinds being described, viewpoint refs being used, admissible use, non-admissible use, and one remaining architecture candidate use or direct governing-pattern application. Expand to the fuller ArchitectureDescription@Context record when cross-view correspondence, reuse, source return, freshness, specification use, regulated use, comparison, or project-side authority use is being made.

Not this pattern when.

• If the current use is a grounded architecture claim 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, 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 publication face, publication form, report, dashboard, file, or source-current relation, use [C.2.P](/generated/patterns/C.2.P), [E.17](/generated/patterns/E.17), or the publication or source 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 the description is not the architecture. The same architecture can have several descriptions. The same description set can contain several views. Each view is written from one viewpoint or concern-framed practice and 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 ArchitectureOf@Context is this description about?
• Which selected structures or structure kinds does this view describe?
• Which viewpoint makes this view useful?
• What correspondence connects this view to the architecture claim and other views?
• When does source return to a source episteme, source view, or direct governing pattern for that claim become necessary?
• 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, publication form, or rendering as the architecture itself;
• treating all architecture documentation as one generic description with no selected-structure recovery;
• losing the link between a viewpoint and the architecture structure kind being described;
• letting one attractive view hide lost structure, stale source, or missing correspondence;
• letting publication quality become 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@Context when the current EntityOfConcern is the description episteme or specification-use record over one ArchitectureOf@Context. The described holon is recovered through ArchitectureOf@Context.describedHolonRef; the DescriptionContext.EntityOfConcernRef for the architecture description points to the architecture claim record.

C.30.AD does not mint U.Architecture, does not redefine U.Viewpoint, and does not replace generic Description, view, publication, or publication-form machinery. It specializes those records for architecture descriptions whose views remain tied to selected architecture-relevant structures.

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@Context ::= {
  architectureDescriptionId: ArchitectureDescriptionId,
  architectureClaimRef: ArchitectureOf@ContextRef,
  descriptionContext: DescriptionContext(
    EntityOfConcernRef = architectureClaimRef,
    BoundedContextRef = ArchitectureOf@Context.boundedContextRef,
    ViewpointRef = primaryViewpointRef?
  ),
  describedHolonRef: U.HolonRef,
  selectedStructureRefs: FinSet(U.StructureRef),
  structureKindRefs: FinSet(ArchitectureStructureKindRef),
  architectureStructuralViewRefs: FinSet(ArchitectureStructuralViewRef),
  correspondenceRefs: FinSet(CorrespondenceRef),
  sourceEpistemeRefs?: FinSet(U.EpistemeRef),
  sourceViewRefs?: FinSet(U.ViewRef),
  sourceReturnCondition?,
  freshnessCueRefs?: FinSet(ArchitectureDescriptionFreshnessCueRef),
  specificationUseBoundary?,
  publicationUseBoundary?,
  admissibleUse,
  nonAdmissibleUse
}

describedHolonRef is a recoverable field copied from the referenced ArchitectureOf@Context; it is not the architecture description's DescriptionContext.EntityOfConcernRef.

Minimum conformance for the record:

• architectureClaimRef names one ArchitectureOf@Context;
• selectedStructureRefs or structureKindRefs name the architecture-relevant structures being described;
• every architecture structural view names its viewpoint and selected structure or structure kind;
• correspondenceRefs or a source-return condition is present when cross-view or source reuse is being made;
• 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. The chain is a trace requirement, not a prescribed method or work plan:

workingConcernRef
  or A15AllocationResponsibilityFamilyRef when A.15 allocation-responsibility semantics apply
-> viewpointRef
-> selectedStructureRef or structureKindRef
-> ArchitectureOf@ContextRef
-> ArchitectureStructuralView@ContextRef governed by C.30.ASV
-> ArchitectureDescription@ContextRef governed by C.30.AD
-> sourceEpistemeRef or sourceViewRef when source use is being made
-> PublicationUnitRef, publication face, or publication form only when published
-> correspondenceRef or sourceReturnCondition when cross-view or source reuse is being made
-> admissibleArchitectureMove or governing-pattern application

[E.17.0](/generated/patterns/E.17.0) carries the generic multi-view Description machinery. [C.30.ASV](/generated/patterns/C.30.ASV) carries the selected-structure-kind-to-view relation and view adequacy. [C.30.AD](/generated/patterns/C.30.AD) carries the architecture-specific composition and use boundary: which architecture claim the description is about, which structural views it uses, what correspondence or source return keeps the use honest, and which architecture move or governing pattern remains admissible.

If any link in the chain is absent, do not fill it with a documentation label. Either add the missing reference, reduce the admissible use, or apply the governing pattern that can recover the missing relation.

#View membership, viewpoint, and structure-kind binding

Architecture descriptions can contain several ArchitectureStructuralView@Context records. Each such view remains governed by C.30.ASV; C.30.AD does not mint a second structural-view record and does not decide whether the view has the right structure kind, viewpoint, hidden or lost structure note, correspondence, or source return.

C.30.AD records only membership or use of an already recoverable architecture structural view inside one architecture description:

ArchitectureDescriptionViewMembership@Context ::= {
  architectureDescriptionRef: ArchitectureDescriptionRef,
  architectureStructuralViewRef: ArchitectureStructuralViewRef,
  architectureClaimRef: ArchitectureOf@ContextRef,
  membershipPurpose:
    orientation | comparison | implementationGuidance |
    assuranceInput | sourceReturn | declaredOther,
  correspondenceRefs?: FinSet(CorrespondenceRef),
  sourceReturnCondition?,
  admissibleUse:
  nonAdmissibleUse:
}

Use [C.30.ASV](/generated/patterns/C.30.ASV) when the current question is whether the view has the right structure kind, viewpoint, hidden or lost structure note, correspondence, or source return. 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 the grounded architecture claim. Use [C.30.AD](/generated/patterns/C.30.AD) only for the description's membership, composition, correspondence, source-return, freshness, specification-use, publication-use, or remaining architecture candidate-use boundary.

Common architecture-description views:

#Correspondence and source return

Architecture descriptions become risky when a reader cannot tell whether two views describe the same architecture claim, the same selected structure, related structures, or different entities of concern. Use correspondence records or source-return conditions when the description is reused across viewpoints, source editions, tool outputs, generated views, or regulated use.

ArchitectureDescriptionCorrespondence@Context ::= {
  architectureDescriptionRef:
  architectureClaimRef:
  fromViewRef:
  toViewRef:
  correspondenceKind:
    sameArchitectureClaim | sameSelectedStructure |
    refinement | abstraction | projection |
    sourceDerived | conflict | declaredOther,
  preservedStructureRefs?:
  lostStructureRefs?:
  sourceReturnCondition?:
  admissibleUse:
  nonAdmissibleUse:
}

Correspondence is not proof, assurance, or gate passage. It is a relation that lets a reader use more than one architecture view without silently changing the EntityOfConcern.

#Freshness and currentness boundary

Use a freshness cue only when the architecture description's admissible use depends on source edition, structure edition, model version, deployment context, or external condition.

ArchitectureDescriptionFreshnessCue:
  sourceEditionRefs:
  structureEditionRefs?:
  modelOrToolEditionRefs?:
  knownRefreshTrigger:
    sourceChange | deploymentChange | interfaceChange |
    controlRateChange | modelEditionChange | evidenceDecay |
    toolApiChange | regulatoryChange |
    incidentFinding | declaredOther | unknown,
  admissibleUseUntil?:
  sourceReturnCondition:

Freshness does not make the description evidence-sufficient. It only bounds the use of the description.

#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 use boundary over a Description episteme or its publication.

ArchitectureDescriptionSpecificationUse@Project ::= {
  architectureDescriptionRef:
  sourceEpistemeRef | sourceViewRef,
  publicationUnitRef?:
  governedUse:
    coordination | implementationGuidance | procurement |
    verificationPlanning | assuranceInput | releaseInput |
    declaredOther,
  selectedNeighborPatternRef?:
  admissibleUse:
  nonAdmissibleUse:
}

If the 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.

Publication forms, diagrams, model faces, files, cards, dashboards, and generated relation graphs remain publications, views, faces, source-current records, or renderings unless the source episteme and use boundary are explicit.

#Direct governing-pattern applications

#Candidate, front, and selected-set description boundary

Architecture-description material can also describe a project architecture decision or the source structure used by an ADR-like projection. Use C.32.PAD when the claim is the project architecture decision relation. Use C.32.ADR when the claim is publication projection of an architecture-decision description. Use C.32.ADA when the claim is adequacy of that decision for a declared use. C.30.AD keeps only architecture-description membership, correspondence, source return, freshness, publication use, and specification use.

An architecture description may describe 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 only description membership, view membership, viewpoint, correspondence, source return, freshness, publication use, and specification use. If the 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 owns 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 itself.
• Multi-view work can keep viewpoints, views, selected structures, correspondences, source return, freshness, and specification use inspectable.
• Description, publication, evidence, assurance, gate, decision, work, release, and mathematical-lens claims stay with separate 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 ArchitectureOf@Context, selected structures, viewpoints, and admissible use.
• Reused or regulated descriptions may need correspondence, source-return, and freshness fields before they can be relied on.
• Familiar document forms lose implicit authority; 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 relation to the described architecture claim, selected structures, viewpoints, views, source material, publication form, and admissible use is recoverable.

The pattern therefore specializes generic Description and publication machinery for architecture use. It does not mint a new architecture kind, does not replace C.30, and does not let diagrams or documentation formats establish non-description claims by presentation alone.

#SoTA-Echoing

#Relations

• C.30 governs grounded architecture and selected-structure adequacy.
• C.30.P normalizes overloaded architecture or structure wording before this pattern is used.
• C.30.ASV governs architecture structural views and structure-kind and viewpoint separation.
• 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 remains the owner for architecture-description adequacy; NAR owns only the structure-to-sequence relation, selected-source carry-through, lost structure, reader-use boundary, and source return.
• 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-return, or actual-structure feedback.
• A.7, E.17.0, E.17.1, E.17.2, and E.17 govern generic EntityOfConcern, Description, view, viewpoint, publication, and MVPK machinery.
• C.2.P normalizes source-current and publication-form 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; C.30.AD only records description, view, correspondence, source-return, freshness, publication-use, and specification-use relations.
• 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-07-09 — this section last modified in upstream FPF commit e2453d1a (github.com/ailev/FPF)