#Architecture Structural View Adequacy (ASV)

C.30.ASV · 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 an architecture discussion needs to say which selected structure is being viewed, not merely that there is a diagram, model, table, dashboard, ADR, generated relation graph, or generic "view".

#Keywords

• architecture structural view
• ArchitectureStructureKindRef
• VF.ARCH.STRUCTURE
• viewpoint bundle
• structure kind
• hidden/lost structure
• correspondence
• source return.

#Relations

#Content

#Problem frame

Use this pattern when an architecture discussion needs to say which selected structure is being viewed, not merely that there is a diagram, model, table, dashboard, ADR, generated relation graph, or generic "view".

The first useful move is ArchitectureStructureKindTriage@Project:

ArchitectureStructureKindTriage@Project:
architectureClaimRef?:
describedHolonRef?:
boundedContextRef?:

live architecture concern:
suspected wrong collapse:
practitioner prompt label:
candidate structure kinds:
smallest useful structure-kind set:
primaryGoverningPatternApplicationRef:
admissibleArchitectureMove:
governingPatternApplicationRefs:
stop condition:

Ordinary minimum: name the live architecture object or the described holon and bounded context, the one structure kind or structure-kind set that changes action, one non-admissible overread, and the next admissible architecture move or stop. All other fields are conditional and may be not live.

Start with [C.30](/generated/patterns/C.30) when the architecture claim itself is unclear. Use C.30.ASV only when a view over selected architecture-relevant structure changes the next architecture move. Use the triage record when it names the live structure kind and the next admissible architecture move. Open a full ArchitectureStructuralView@Context only when the view changes action, selected support reading, correspondence, source return, publication, comparison, evidence, assurance, gate, decision, or exact governing pattern use.

What goes wrong if C.30.ASV is missed: "architecture" silently means "module diagram"; a view becomes a publication face; a viewpoint becomes a structure kind; TEVB is stretched into a full architecture ontology; a Transduction Graph Architecture (TGA) graph, Layered Control Architecture (LCA)/control sketch, code-agent relation graph, or neural-network block diagram becomes the architecture by appearance.

What C.30.ASV buys in practice: the practitioner can name the architecture claim, selected structures, structure kind, viewpoint, selected relation kinds, selected constraints, selected invariants, live operation or dynamics descriptions, hidden or lost structure, correspondence, source or reliance relation, source-return condition, admissible use, and non-admissible use before relying on a view.

Not this pattern when the live question is only the general architecture claim. Use [C.30](/generated/patterns/C.30). If the live question is structure as such, use A.22. If the view is a TGA graph/path/crossing relation, use [E.18](/generated/patterns/E.18) and C.30.TGA-FLOW-REL when architecture-flow description is live. If the view is used as evidence, assurance, causal proof, gate result, work record, release permission, or decision authority, use the exact governing pattern and keep C.30.ASV only to the view portion.

Thin precision-restoration pointer: if the live issue is still whether view, architecture view, architecture structural view, diagram, model, graph, layer, or functional architecture names a structural view, an architecture description, a publication face, a carrier, a source relation, or another 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 here; C.30.ASV resumes only after the architecture structural-view object or exact non-ASV exit is recoverable.

#Problem

An architecture structural view is not a generic view. It is a D/S view over one or more candidate:U.Structure references selected by an ArchitectureOf@Context claim record. A conforming architecture structural view keeps the D/S relation, described entity, bounded context, structure references, structure kind, viewpoint, hidden or lost structure, correspondence, source or reliance relation, source return, and admissible use recoverable.

Without this pattern:

• a module/interface view is treated as all architecture;
• a TGA graph or control diagram is treated as proof;
• a structure kind is treated as a U.Viewpoint;
• a TEVB viewpoint bundle is mutated to carry architecture-specific structure kinds;
• a diagram, table, dashboard, generated relation graph, or ADR is treated as the view itself;
• functional architecture is treated as a peer ontology rather than a structure-kind reading under C.30;
• cross-view consistency is asserted by prose instead of correspondence records;
• omitted structure is relied on in subsequent work without a source-return condition.

#Forces

#Solution

Govern architecture structural views with ArchitectureStructuralView@Context records. A conforming record is a D/S view over selected candidate:U.Structure references in one ArchitectureOf@Context claim record, under one declared ArchitectureStructureKindRef and one DescriptionContext.ViewpointRef.

C.30.ASV does not extend the TEVB core viewpoint set by implication. It defines architecture structure kinds and architecture-specific structure-kind/view-record bindings. TEVB viewpoints are reused when the structure-kind view uses one of the TEVB core viewpoints; other structure-kind views use VF.ARCH.STRUCTURE, a declared local viewpoint bundle, an exact governing FPF pattern, or a source/reliance record.

#Architecture structural view record

StructuralAspectDescription@Context describes one selected structural aspect under A.22. It is not an ArchitectureStructureKindRef by itself. ArchitectureStructuralView@Context is a C.30.ASV view over structures selected by ArchitectureOf@Context and typed by ArchitectureStructureKindRef.

ArchitectureStructuralView@Context ::= {
  viewId,
  architectureClaimRef: ArchitectureOf@ContextRef,
  descriptionContext: DescriptionContext(
    DescribedEntityRef = architectureClaimRef,
    BoundedContextRef = ArchitectureOf@Context.boundedContextRef,
    ViewpointRef = viewpointRef
  ),
  viewpointRef: U.ViewpointRef (= descriptionContext.ViewpointRef),
  structureRefs: FinSet(candidate:U.StructureRef),
  structureKindRef: ArchitectureStructureKindRef,
  recordGoverningPatternRef,
  selectedRelationKinds,
  selectedConstraintRefs?,
  selectedInvariantRefs?,
  selectedOperationOrDynamicsDescriptionRefs?,
  viewConstruction:
    directDescription | projection | query | extraction |
    coarsening | correspondenceSlice | sourceReturnSlice,
  structuralAspectDescriptionRef?,
  hiddenOrLostStructure,
  structureKnowledgePosture?:
    declared | observed | inferred | generated | simulated |
    extracted | hypothesized | unknownRegionPresent,
  correspondenceModelRefs?,
  sourceOrRelianceRelationRefs?,
  sourceReturnCondition?,
  admissibleUse,
  nonAdmissibleUse
}

DescriptionContext.DescribedEntityRef is the ArchitectureOf@Context claim record. The described holon is recovered through architectureClaimRef.describedHolonRef. The bounded context is recovered through the claim record and DescriptionContext.

viewpointRef is a recovery label for descriptionContext.ViewpointRef, not a second independent viewpoint slot. If the implementation stores only DescriptionContext, the viewpoint remains recoverable there.

structureKnowledgePosture? states how the selected structure is known when partial knowledge matters: declared, observed, inferred, generated, simulated, extracted, hypothesized, or with an unknown region present. Unknown or inferred structure may guide inspection or source return; it cannot by itself supply assurance, gate, release, causal proof, or architecture decision.

#Architecture structure-kind classifier

ArchitectureStructureKindRef is a C.30-local DiscriminatorToken enumeration over architecture-relevant candidate:U.Structure references selected by ArchitectureOf@Context. It is not U.Kind, U.Viewpoint, U.ViewpointBundle, StructuralAspectDescription, StructuralView@Context, or a root U.* kind. ArchitectureStructuralView@Context uses structureKindRef to say which selected structure kind is being viewed.

ArchitectureStructureKindRef ::= one of {
  FunctionalStructure,
  FlowTransductionStructure,
  ControlStructure,
  ModuleInterfaceStructure,
  RuntimeInteractionStructure,
  PlacementDeploymentStructure,
  InformationDataStructure,
  SecurityTrustBoundaryStructure,
  ConstraintRequirementStructure,
  MaterialSpatialStructure,
  DeclaredLogicalStructure,

  WorkMethodStructure,
  RoleEnactorStructure,
  EvidenceAssuranceStructure,
  ScaleEvolutionStructure,
  OtherDeclaredStructureKind
}

The first group is the seed classifier set for ordinary architecture structural-view use. WorkMethodStructure, RoleEnactorStructure, EvidenceAssuranceStructure, and ScaleEvolutionStructure are neighbor-governed classifier values: ASV may use them to name the selected architecture-relevant structure, but their full semantics stay in the named work/method, role/enactor, evidence/assurance, scale, characterization, or mathematical-lens patterns. Do not enumerate structure kinds by default. Choose the smallest useful structure-kind set that changes the next architecture move. If no structure kind changes action, keep the phrase as ordinary recognition wording or a source note. This does not weaken kind discipline; it prevents ArchitectureStructureKindRef from becoming an audit checklist.

Inside C.30.ASV, OtherDeclaredStructureKind is always an architecture-structure-kind classifier value over candidate:U.Structure; it does not mint a general FPF root kind.

OtherDeclaredStructureKind is admissible only when the local text names:

• declaredStructureKindName;
• declaredStructureKindDefinition;
• allowed relation families;
• common false readings;
• exact governing pattern applications;
• boundedContextRef.

Each structure kind needs a short definition, allowed relation families, common false readings, typical exact governing pattern applications, and example architecture structural view records. This is not a new root-kind set; it is a controlled classifier set over candidate:U.Structure.

#Small triage output

Use ArchitectureStructureKindTriage@Project before a full view record when the practitioner only needs to identify the live structure kind and next architecture move.

ArchitectureStructureKindTriage@Project ::= {
  architectureClaimRef?: ArchitectureOf@ContextRef,
  describedHolonRef?: U.HolonRef,
  boundedContextRef?: U.BoundedContextRef,
  liveArchitectureConcernCue,
  suspectedWrongCollapse,
  plainPromptLabel,
  candidateStructureKindRefs: FinSet(ArchitectureStructureKindRef),
  smallestUsefulStructureKindRefs,
  structureKnowledgePosture?,
  primaryGoverningPatternApplicationRef,
  temptingWrongPatternRefs?,
  admissibleArchitectureMove:
    inspect | split | relate | downgrade | assignNeighbor | stop |
    otherDeclared,
  candidateGenerationPatternApplication?: yes | no,
  governingPatternApplicationRefs,
  stopCondition
}

primaryGoverningPatternApplicationRef names the pattern that carries the next live claim kind. candidateGenerationPatternApplication? marks that the next admissible move is to leave ASV for candidate generation; it is not ASV work. temptingWrongPatternRefs? names tempting wrong first patterns when that repair is needed. None of these fields governs the triage record itself; C.30.ASV governs the triage record family. When architectureClaimRef is absent, describedHolonRef and boundedContextRef are required for triage. This pre-claim form does not create a new kind and does not publish an ArchitectureOf@Context claim by itself; it only lets the practitioner identify the live structure kind before opening a full architecture claim. A full ArchitectureStructuralView@Context still requires architectureClaimRef; do not promote triage to a full view record until that architecture claim is available.

Practitioner prompt labels are first-entry cues, not ArchitectureStructureKindRef values. FPF-force-bearing records use the Tech values below:

Functional -> FunctionalStructure
Flow -> FlowTransductionStructure
Control -> ControlStructure
Module -> ModuleInterfaceStructure
Method/work -> WorkMethodStructure
Role -> RoleEnactorStructure
Evidence -> EvidenceAssuranceStructure
Scale -> ScaleEvolutionStructure
Security -> SecurityTrustBoundaryStructure

#Architecture viewpoint bundle and binding rows

Architecture structural views use VF.ARCH.STRUCTURE without turning structure kinds into viewpoints. The bundle is separate from VF.TEVB.ENG: it may import TEVB, but it does not expand the TEVB core engineering viewpoint set.

Declaration basis: VF.ARCH.STRUCTURE is an E.17.1/F.18 declared viewpoint bundle for architecture structural-view records. Its VP.Architecture* ids are viewpoint ids only. They do not add TEVB viewpoints, name structure kinds, define publication faces, or carry decision, evidence, gate, or assurance authority.

VF.TEVB.ENG core stays:
  { VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface }

TEVB is the small engineering viewpoint bundle over holons. The architecture problem is broader than TEVB, but the broader coverage is not solved by placing record sets inside a U.ViewpointBundle. The U.ViewpointBundle carries viewpoints; a separate architecture-local description binds structure kinds, view record sets, construction modes, correspondence obligations, and exact governing pattern applications.

VF.ARCH.STRUCTURE : U.ViewpointBundle {
  viewFamilyId = VF.ARCH.STRUCTURE,
  imports = { VF.TEVB.ENG },
  EoIClassSpec = {
    a : ArchitectureOf@Context |
    a.describedHolonRef and a.boundedContextRef are recoverable
  },
  viewpoints = {
    VP.ArchitectureStructure,
    VP.ArchitectureCorrespondence,
    VP.ArchitectureSourceReturn,
    VP.ArchitectureDecisionAffectedStructure
  }
}

ArchitectureStructureKindViewRecordBinding ::= {
  structureKindRef: ArchitectureStructureKindRef,
  allowableViewpointRefs: FinSet(U.ViewpointRef),
  viewRecordSetRef,
  allowedViewConstructionModes,
  requiredCorrespondenceRefs?,
  sourceReturnRequirement?,
  governingPatternApplicationRefs
}

viewRecordSetRef names the allowed D/S record set for one structure-kind binding. It is not a package grouping, not a U.ViewpointBundle, not a ViewFamilyId, and not a new TEVB viewpoint.

#Initial architecture structure kinds and view records

The initial set is a seed for first architecture moves, not an atlas. Use the table to choose one live structure kind and the exact governing pattern application that carries any stronger claim.

Externally governed classifier values remain admissible when they are the live architecture-relevant structure, but C.30.ASV does not define their full record families:

Minimum useful seed examples:

SecurityTrustBoundaryStructureView@Context ::= {
  architectureStructuralViewRef:
  protectedAssetOrEffectRefs:
  trustBoundaryRefs:
  untrustedInputRefs:
  privilegeOrAuthorityRefs:
  dataFlowOrControlFlowRefs:
  attackExposureRefs:
  abuseOrMisusePathRefs:
  secureDefaultOrHardeningBoundary:
  updateOrSupplyChainChannelRefs:
  detectionResponseBoundaryRefs?:
  governingPatternApplicationRefs:
    A.10 | G.6 | B.3 | C.28 | A.20 | A.21 |
    C.16 | C.25 | C.24 when tool authority or agentic tool-use is live | C.30.LCA when control relation is live
  admissibleUse:
  nonAdmissibleUse:
    not compliance proof, not risk score, not assurance verdict, not security by checklist, not secure because a diagram says "zero trust"
}

SecurityTrustBoundaryStructure carries adversarial-boundary reading: which protected assets or effects are live, who or what is trusted, where untrusted input crosses, what authority or privilege is exposed, which adversarial paths and attack exposures matter, which data-flow or control-flow security boundaries matter, and where secure defaults, hardening, update or supply-chain channels, detection, or response boundaries change the next architecture move.

Do not open evidence, assurance, gate, or compliance pattern use only because the topic is safety, security, or regulation. Open it when the architecture move relies on evidence sufficiency, assurance verdict, gate passage, regulatory acceptance, or release authority. If the live move is structural, first recover the structure: trust boundary, loss-control relation, control relation, evidence reuse structure, or affected structure/view.

Use a SafetyLossControlStructureNote when a safety-architecture concern first needs the architecture-side loss-control structure rather than a safety-case verdict:

SafetyLossControlStructureNote:
  lossOrHarm:
  hazardOrUnsafeState:
  unsafeControlActionOrMissingControl:
  controlledProcessOrPlantRef:
  controlConstraintRef:
  feedbackOrObservabilityBoundary:
  timingOrRateBoundary:
  operationalDesignScopeOrMisuseScope:
  foreseeableMisuseRefs?:
  architectureStructureKindRefs:
    ControlStructure | ConstraintRequirementStructure |
    SecurityTrustBoundaryStructure | InformationDataStructure |
    EvidenceAssuranceStructure
  governingPatternApplicationRefs:
    A.3.3 dynamics, C.27 temporal or rate,
    C.28 causal-use, A.10/G.6 evidence,
    B.3 assurance, A.20/A.21 gate
  nonAdmissibleUse:
    not safety proof, not safety-case verdict, not regulatory acceptance

The note gives a positive first architecture move: find the loss-control structure, controlled process or plant, constraint, foreseeable misuse, operational design scope, and action-relevant boundary. It does not replace evidence, assurance, gate, causal, dynamics, or temporal claims.

#Functional structure view boundary

FunctionalStructureView@Context under C.30.ASV does not mint U.Function. A functional element is a description-side architecture element under VP.Functional unless separately grounded as U.Capability, U.Method, U.Work, U.Role, or another existing FPF kind.

FunctionalStructureView@Context ::= {
  architectureStructuralViewRef: ArchitectureStructuralView@ContextRef,
  functionOrEffectRefs?,
  capabilityRefs?,
  functionalDependencyRefs?,
  allocationRefs?,
  nonFunctionCarrierNotes?,
  flowRelationRefs?,
  moduleInterfaceRelationRefs?,
  admissibleUse,
  nonAdmissibleUse
}

A transduction graph, path slice, crossing, or flow valuation is not a functional element. When flow is live, connect the functional view to FlowTransductionStructure through C.30.TGA-FLOW-REL. When module allocation is live, connect the functional view to the exact module/interface repair pattern rather than treating function and module as one object.

Composability and quality compositionality are separate claims. If the view says parts can be assembled, keep that as a structure/use claim. If it says a whole-system quality follows from parts, assign the quality-composition claim to [C.25](/generated/patterns/C.25) and C.16-backed measurement or quality claim.

Composability:
  "A and B can be assembled under interface X."
  recoveredCarrierKind: ModuleAllocationRelation | InterfaceSpecification
Quality compositionality:
  "The assembled whole preserves safety, latency, or reliability."
  recoveredCarrierKind: QBundleSlot | structuralCharacteristicSupportsQBundleSlot | structuralCharacteristicCausalHypothesisForQBundleSlot | structuralCharacteristicEvidenceSupportForQBundleSlot
Non-admissible:
  successful assembly is not quality propagation

Compositional formalisms may express explicit composition structures and view/model relations. They do not make safety, latency, reliability, or another quality propagate automatically.

#Correspondence and source return

Use correspondence records when the view relates functional, flow, control, module/interface, information, runtime, placement, work, evidence, scale, or logical structures. Do not assert cross-view consistency by prose alone.

Correspondence examples:

Use SourceReturnCondition when compression, extraction, coarsening, evidence reuse, ML evaluation, bounded exception, many-to-many allocation, publication, or decision claim hides a distinction needed for action, assurance, causal use, legal review, regulatory review, comparison, or reopening.

If viewConstruction is query, extraction, coarsening, correspondenceSlice, or sourceReturnSlice, and omitted structure changes action, assurance, causal use, legal or regulatory review, or subsequent decision reopening, SourceReturnCondition is live.

When the view is used to name affected structures for a next move but no decision record is live, use C.30 AffectedArchitectureStructureNote: affected structure kinds, affected structure refs when known, affected ASV refs, accepted or suspected view loss, source-return condition, and the next admissible move. The note is not an architecture decision, ADR, gate passage, evidence sufficiency, or release authority.

Use the thinnest source or reliance relation that preserves the next architecture move. Open fuller source, evidence, assurance, or claim-kind relation only when the current source or reliance relation cannot be inspected, used, compared, refreshed, or bounded without it. A ControlStructureViewNote may precede full C.30.LCA use or proof-governing pattern applications when one control relation and its boundary are enough for the current move.

Treat source return as a user action, not only a metadata field:

SourceReturnAction:
  returnTo:
    sourceStructure | sourceEpisteme | sourceView | sourceTrace |
    sourceCorpus | sourceModel | sourceEvidence | sourcePublication
  because:
    hiddenRelation | lostConstraint | coarsenedScale |
    ambiguousExtraction | staleEdition | crossViewMismatch |
    legalOrRegulatoryUse | assuranceOrDecisionUse
  nextMove:
    inspect | split | downgradeUse | addCorrespondence |
    openNeighborPattern | stop

Do not make source return mandatory for ordinary local recognition when no hidden distinction is being used for action. Do not omit source return when a hidden distinction carries a selected support reading, assurance, legal, comparison, causal, gate, or decision claim force. The condition is live only when the repaired text still relies on the hidden source-side distinction.

Model cards, system cards, and evaluation harness reports may publish or substantiate an architecture structural view only when the structural-view claim is recoverable. The view must name the relevant structure kind, such as RuntimeInteractionStructure, InformationDataStructure, SecurityTrustBoundaryStructure, EvidenceAssuranceStructure, ModuleInterfaceStructure, or another declared structure kind; it must also state intended-use scope, evaluation scope and known loss when evaluation is used, deployment-context mismatch when live, and the evidence or assurance governing pattern when the publication is used beyond transparency. A card or harness is not architecture adequacy, safety proof, or release/gate claim by publication alone.

#Worked slices

Runtime degradation. A team says, "The architecture is fine, but incidents happen when failover starts." The first architecture move is to recover runtime interaction, control/failover, placement, and evidence-assurance structures before turning a dashboard or deployment diagram into proof:

Runtime degradation slice:
  active structure kinds:
    RuntimeInteractionStructure
    ControlStructure
    InformationDataStructure
    PlacementDeploymentStructure
    EvidenceAssuranceStructure
  first architecture move:
    recover runtime interaction topology, control/failover relation,
    state custody, placement/locality, evidence path, and observability relation
  nonAdmissibleUse:
    deployment diagram as runtime proof,
    observability dashboard as evidence sufficiency,
    green status as gate/release authority

Use [C.24](/generated/patterns/C.24) only when tool-use, call planning, call graph, work execution, or budgeted agentic tool-use is the live claim. Do not absorb those claims into architecture structure.

CPS or plant architecture. A plant drawing, P&ID-like artifact, LCA sketch, or safety-case view is not the plant architecture by itself. First recovery may need:

CPS/plant architecture first recovery:
  MaterialSpatialStructure:
    physical separation, adjacency, energy/material path
  ControlStructure:
    controller, plant, observer, supervisor, control rate
  InformationDataStructure:
    sensor data semantics, provenance, custody, source return
  PlacementDeploymentStructure:
    locality, environment, jurisdiction, safety separation
  EvidenceAssuranceStructure:
    evidence reuse boundary and affected structures
first architecture move:
  relate physical separation, sensor data semantics, control rate,
  placement boundary, and evidence reuse
correspondenceOrLossLine:
  record which separation, data, control-rate, placement, or evidence-reuse
  relation is preserved by the slice and which structure is hidden or lossy
stop condition:
  no P&ID, LCA diagram, or safety case is treated as the architecture

Chiplet or device architecture. A packaging diagram or interconnect sketch may open several structure kinds:

Chiplet/device architecture first recovery:
  MaterialSpatialStructure:
    packaging, adjacency, thermal path, energy path
  FlowTransductionStructure:
    interconnect topology, data/energy/signal flow path
  ModuleInterfaceStructure:
    interface specification, protocol, conformance boundary
  PlacementDeploymentStructure:
    physical locality, substrate, host environment
first architecture move:
  separate interconnect topology, packaging/thermal/energy path,
  interface specification, and evidence/conformance boundary
correspondenceOrLossLine:
  record the preserved relation among interconnect, physical package,
  interface, and placement, plus any benchmark or packaging-view loss
stop condition:
  no packaging diagram or benchmark becomes performance, safety,
  evidence, or gate proof by appearance

Organization or operating-model architecture. An org chart or work-method diagram can be architecture-relevant only after the work, role, information, and evidence carriers are separated:

Organization/operating-model architecture first recovery:
  RoleEnactorStructure:
    responsibility allocation and enactment boundary
  WorkMethodStructure:
    repeatable work method and exception path
  InformationDataStructure:
    information custody, state residence, provenance
  EvidenceAssuranceStructure:
    evidence reuse, approval, audit trail, source return
first architecture move:
  relate responsibility allocation, work repeatability,
  information custody, and evidence reuse
correspondenceOrLossLine:
  record the preserved relation among role, work, information, and evidence
  structures, plus any org-chart or work-method-diagram loss
stop condition:
  no org chart or work-method diagram is treated as the architecture, decision,
  evidence sufficiency, or assurance verdict

Evidence reuse across product variants. A certification or test package reused across module variants may be architecture-relevant as an evidence/assurance structure view, but it is not an assurance verdict:

Evidence reuse across product variants:
  structureKindRef: EvidenceAssuranceStructure
  structuralFeature:
    evidence package shared across module variants
  affectedQBundleSlot:
    assurance maintainability or release readiness
  architectureMove:
    name affected structures, variant boundary, hidden view losses,
    and source-return condition
  governingPatternApplicationRefs:
    A.10/G.6/B.3 for evidence sufficiency or assurance verdict
  nonAdmissibleUse:
    evidence-structure view as assurance verdict

AI agent diagram. A "planner-memory-tools" diagram is not the agent's architecture by itself. It may open first recovery as a structure-kind set, without minting an AI-domain ontology:

AI-agent architecture first recovery:
  RuntimeInteractionStructure:
    model-tool-memory-planner-evaluator-human topology
  InformationDataStructure:
    memory scopes, data custody, provenance, retention,
    context-window/source-return
  SecurityTrustBoundaryStructure:
    untrusted content channels, prompt-injection or instruction boundary,
    tool authority, secret-bearing contexts, memory/data custody crossing,
    output handling, supply-chain or update path
  ModuleInterfaceStructure:
    tool/API/interface specs and substitutability limits
  EvidenceAssuranceStructure:
    eval harness, human approval, evidence decay, incident feedback
admissibleArchitectureMove:
  split runtime interaction, information, security boundary, module-interface, and evidence-assurance claims before relying on the diagram
correspondenceOrLossLine:
  record the preserved relation among runtime topology, information custody,
  security boundary, module-interface, and evidence-assurance structures,
  plus any diagram or evaluation-harness loss
governingPatternApplicationRefs:
  C.30.TGA-FLOW-REL when E.18 flow relation is live,
  exact module/interface repair pattern for tool, API, or interface relation claims,
  A.10/G.6/B.3 when evidence or assurance reliance is live,
  C.24/E.16/A.20/A.21 when tool-call, autonomy, constraint, or gate authority is live
stop condition:
  no evidence sufficiency, assurance, gate, autonomy, or tool-call authority remains inside ASV

Structural AI-agent security is architecture structure when these structure kinds change the next architecture move. When the live claim is latent representation, decoding, or effect adequacy rather than architecture structure, keep the phrase as a reduced-use source cue until the exact governing representation, decode, or effect-adequacy pattern carries that claim.

Generated code-agent relation graph. A probe JSON or code-agent architecture relation graph can be an architecture structural view publication only after observed/inferred/unknown status, evidence/source pointers, unexplored regions, typed relation semantics, and source-return conditions are present. It is not proof of the agent's internal belief and not assurance that a downstream code change is safe.

Neural-network block replacement. Replacing attention, FFN, convolution, SSM, recurrent, memory/cache, MoE expert-selection, pruning, distillation, or another block is an architecture move only when the changed structure kind, flow relation, module/interface claim kind, preserved and lost structure, affected characteristic, source relation, and decision or evidence governing pattern are named.

#Archetypal Grounding

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Prag, Did, Gov. Scope: architecture structural-view claims 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

C.30.ASV exists because architecture descriptions are multi-view by nature, but FPF cannot let "view" absorb every architecture claim. A structure kind and a viewpoint are different. A structure kind says what kind of selected structure is being described; a viewpoint says how an episteme or view is oriented toward a concern. They may be bound, but they are not interchangeable.

The pattern keeps first use light by providing ArchitectureStructureKindTriage@Project. If triage identifies the live structure kind and the next admissible architecture move, no full view record is needed. The full record opens when a view changes action, correspondence, publication, source return, source or reliance use, or non-view claim kind.

The TEVB decision is conservative. TEVB remains the small engineering viewpoint bundle over holons. Architecture may import it, but architecture-specific structure kinds and view-record bindings live beside TEVB rather than mutating TEVB.

#SoTA-Echoing

#Relations

Builds on: C.30.P, C.30, A.22, A.6.3, E.17.0, E.17.1, E.17.2, A.7, E.10.D2, E.10, C.2.P, and F.18.

Coordinates with: 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, the exact module/interface repair pattern when the module/interface claim kind is live, and named receiving patterns for architecture decision and candidate-set claims.

Does not replace: C.30 architecture-description adequacy, A.22 structure carrier, 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.ASV:End

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