#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.P, C.30.TFS-REL, C.30.LCA, C.30.ILC, A.6.F, A.6.M, C.29, C.16, C.16.P, A.10, B.3, A.20, A.21, A.15, C.11, C.28, E.8, E.24.CD, and F.18.

Use this pattern when an architecture description is the EntityOfConcern under repair: 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.

#Relations

#Content

#Use this when

Use this pattern when an architecture description is the EntityOfConcern under repair: 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 authority, or release permission by presentation alone.

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

First useful move. Write one ArchitectureDescriptionUseCard@Project:

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

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 move or neighboring-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 use under repair is a grounded architecture claim or one first architecture question, use [C.30](/generated/patterns/C.30).
• If the use under repair is a selected structure or structural description outside architecture, use [A.22](/generated/patterns/A.22).
• If the use under repair is one architecture structural view, use [C.30.ASV](/generated/patterns/C.30.ASV).
• If architecture or structure wording is still ambiguous, use [C.30.P](/generated/patterns/C.30.P).
• If the use under repair 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 evidence, assurance, gate passage, decision, work authority, causal-use claim, release permission, or mathematical-lens use, keep [C.30.AD](/generated/patterns/C.30.AD) only for the description boundary and apply the neighboring 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 role-enactor 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 neighboring pattern governing 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 authority, work completion, or release permission;
• making ordinary architecture triage too heavy for a first useful architecture move.

#Forces

#Solution

Use ArchitectureDescription@Context when the EntityOfConcern under repair 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.

#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 A15RoleEnactorFamilyRef when A.15 role-enactor 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 neighboring-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 neighboring 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 question under repair 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 question under repair is structure as such. Use [C.30](/generated/patterns/C.30) when the question under repair 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-move 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 | legalRegulatoryChange |
    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 evidence, assurance, gate, work, decision, causal-use, or release authority, apply the neighboring pattern governing that claim to that authority claim. The architecture description remains the description boundary, not the authority.

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.

#Neighboring-pattern applications

| Generic description, view, viewpoint, publication, publication form, MVPK face | A.7, E.17.0, E.17.1, E.17.2, E.17, or C.2.P | | Function or functionality wording | A.6.F | | Module, interface, port, signature, or reusable structure relation | A.6.M, a signature or interface pattern named by value, C.31, or C.31.RSA | | Mathematical lens or preserved and lost mathematical structure | C.29 | | Characteristic, scale, coordinate, score, or quality claim | C.16.P, C.16, A.19, C.25, or quality pattern governing the claim | | Evidence, assurance, gate, work, decision, causal-use, release | A.10, B.3, A.20, A.21, A.15, C.11, C.28, release or admissibility pattern, or governing pattern |

#Worked cases

#Conformance checklist

#Common anti-patterns

#SoTA-Echoing

#Related patterns

• C.30 governs grounded architecture and selected-structure adequacy.
• C.30.P repairs overloaded architecture or structure wording before this pattern is used.
• C.30.ASV governs architecture structural views and structure-kind and viewpoint separation.
• C.30.TFS-REL, C.30.LCA, and C.30.ILC govern architecture structure-relation subcases named by value.
• 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 repairs source-current and publication-form relation-set overreads.

#C.30.AD:End

Last Updated: 2026-06-15 — this section last modified in upstream FPF commit c092a1f2 (github.com/ailev/FPF)