C.30.ASV - Architecture Structural View Adequacy (ASV)

Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative

C.30.ASV:1 - Problem frame

Use this pattern when you have a structural description of one selected architecture-relevant U.Structure and need to decide whether that same description is also a U.View under one exact viewpoint.

The first useful move is small. In ordinary prose, name the described holon or actual ArchitectureRelation when known, the selected structure, the smallest useful structure-kind set, any qualifier that changes interpretation, and the next architecture move. If one or two sentences make those values clear, stop.

For example: “The failover diagram describes runtime-interaction and control structures, but it hides the actual failover relation. Recover that relation before relying on the diagram as a view.” This is already a usable triage result. Use ArchitectureStructureKindTriage@Project only when the result must be retained, compared, or handed on.

ArchitectureStructureKindTriage@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureStructuralViewProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains
  architectureClaimRef?: U.EpistemeRef constrained to ArchitectureClaim
  architectureRelationOccurrenceRef?: ArchitectureRelationRef
  describedHolonRef?: U.HolonRef
  candidateViewEpistemeRef?: U.EpistemeRef
  exactViewpointRef?: U.ViewpointRef
  viewpointConformanceRelationRef?: EpistemeViewpointConformanceRelationRef
  claimScope?: U.ClaimScope, byValue
  effectiveReferenceScheme?: U.ReferenceScheme, byValue
  modelUseStructureRef?: U.StructureRef
  candidateStructureKindRefs: FinSet(ArchitectureStructureKindRef)
  smallestUsefulStructureKindRefs: FinSet(ArchitectureStructureKindRef)
  selectedStructureRefs?: FinSet(U.StructureRef)
  claimPatternRefs?: FinSet(PatternRef), if another claim is being made
  admissibleArchitectureMove:
  stopCondition:

@Project is a compatibility and retrieval cue for a project-side use record. It supplies no project identity, authority, context, viewpoint, parthood, or Work occurrence. When one actual project matters to this triage, projectWorkOccurrenceRef identifies the composite U.Work recovered under A.15.6. Include architectureStructuralViewProjectUseRelationRef only when a named pattern defines the relation by which this use concerns that Work and an occurrence of the relation obtains. A Work reference alone does not establish project locality. If locality matters but that relation is not yet defined, use A.6.RCD before filling the field; otherwise omit both project-local fields. claimPatternRefs points only to patterns that define or test separate claims; it does not identify a pattern-application occurrence.

Start with C.30 when the actual architecture relation, exact selected structure, or architecture claim is unclear. Use C.30.ASV only when a structural description over selected architecture-relevant structure changes the next architecture use. Use the full ArchitectureStructuralView record only when one exact description episteme passes E.17.0 conformance to an exact viewpoint and the view changes action, selected reliance relation, correspondence, source return, publication, comparison, or another non-ASV claim or use.

What goes wrong if C.30.ASV is missed: one favored diagram, module view, TEVB viewpoint, generated relation graph, control sketch, or neural-network block diagram is treated as the architecture, selected structure, U.View, or proof without naming the exact description episteme, selected structure kind, viewpoint-conformance occurrence, hidden or lost structure, correspondence, and next architecture use.

What C.30.ASV buys in practice: the practitioner can distinguish description identity, selected structure and structure kind, exact viewpoint conformance, representation, and publication before relying on a view. Construction history, hidden or lost structure, correspondence, source return, and admissible use remain separately inspectable.

Do not use C.30.ASV when the question is only about a general architecture claim, subject-side ArchitectureRelation, structure as such, selected transformation-flow relation, mathematical graph description, transformation-flow path relation, or crossing relation. Use C.30, A.22, E.18, E.18.2, C.29, or C.30.TFS-REL as appropriate. If the view is used for another claim, use the applicable pattern for that claim and keep C.30.ASV only for the view portion.

Thin precision-restoration pointer: if the issue under repair is still whether view, architecture view, architecture structural view, diagram, model, graph, layer, or functional architecture names a structural description, a U.View, an architecture description, a representation, a publication occurrence, a publication form, a source relation, or another claim or relation named by value, use C.30.P first. Apply C.30.ASV only after the architecture structural-view claim or non-ASV claim named by value is recoverable.

C.30.ASV:2 - Problem

Architecture structural-view work is selected-structure triage: which architecture-relevant structure is described, which structure kind is under consideration, which exact viewpoint’s fixed rules the description satisfies, and what relation, constraint, invariant, operation, dynamics description, hidden or lost structure, correspondence, source-to-use path or work-reliance relation, and source-return condition changes the next architecture move. The candidate is first one C.2.1 description episteme. That same episteme is a U.View only while an exact EpistemeViewpointConformanceRelation to an independently identified U.Viewpoint episteme obtains. Diagram, representation, publication occurrence, form, carrier, and rendering remain separate.

Without this pattern:

• a module-interface view is treated as all architecture;
• a selected transformation-flow structure, mathematical graph description, or control diagram is treated as proof;
• a structure kind is treated as a U.Viewpoint;
• a viewpoint label, query, authoring route, family-declaration membership, diagram, or publication is treated as enough for U.View;
• E.17.2’s TEVB template or a project-local TEVB declaration is treated as a global bundle and mutated to carry architecture-specific structure kinds;
• a diagram, table, dashboard, generated relation graph, or ADR is treated as the view episteme itself;
• functional architecture is treated as a peer ontology rather than a structure-kind interpretation under C.30;
• cross-view consistency is asserted by prose instead of correspondence claims or independently obtaining relations;
• omitted structure is relied on in subsequent work without a source-return condition.

C.30.ASV:3 - Forces

C.30.ASV:4 - Solution

For an architecture structural view, first identify one candidate description episteme, its exact selected U.Structure EntityOfConcern, effective U.ReferenceScheme, structure kind, exact viewpoint episteme, and the direct conformance occurrence. Then add construction history, correspondence, hidden or lost structure, source-to-use path or work-reliance relation when current, source-return condition when needed, admissible use, and next architecture move. Use ArchitectureStructuralView only for the same episteme whose E.17.0 conformance actually obtains.

A conforming ArchitectureStructuralView is not a second individual beside its description. The candidate retains one C.2.1 identity <exact ClaimGraph, one exact selected-structure EntityOfConcern, effective U.ReferenceScheme>. The exact viewpoint and EpistemeViewpointConformanceRelation qualify that same episteme as U.View; they do not enter its C.2.1 identity.

C.30.ASV is the selected-structure structural-view adequacy pattern for architecture work. It explains how descriptions of different selected structure kinds may satisfy declared viewpoints and concerns. It is not a complete architecture-description pattern; C.30.AD composes separately identified descriptions, view-use claims, and correspondence only when that broader description use is being made.

C.30.ASV does not extend any TEVB family by implication. It defines architecture structure kinds and architecture-specific bindings to exact viewpoint epistemes. A project reuses a TEVB or architecture viewpoint only through an exact U.ViewpointRef resolved from a materialized local declaration in one exact E.17.1 catalogue; E.17.2 and C.30.ASV otherwise provide templates, not current family values. Source-to-use, work-reliance, project-use, representation, and publication relations remain separate from viewpoint conformance.

C.30.ASV:4.1 - Architecture structural view record

StructuralAspectDescription describes one selected structural aspect under A.22. It is not an ArchitectureStructureKindRef or U.View by itself. ArchitectureStructuralView names the same architecture-description episteme only after exact E.17.0 conformance obtains.

ArchitectureStructuralView ::= ArchitectureDescription & U.View & {
  viewEpistemeRef: U.EpistemeRef,
  claimGraph: exactly one C.2.1 ClaimGraph,
  entityOfConcernRef: selectedStructureRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,

  selectedStructureRef: U.StructureRef,
  relatedStructureRefs?: FinSet(U.StructureRef),
  structureKindRef: ArchitectureStructureKindRef,

  viewpointRef: U.ViewpointRef,
  viewpointConformanceRelationRef: EpistemeViewpointConformanceRelationRef,
  concernRefs?: FinSet(U.EntityRef),

  describedHolonRef?: U.HolonRef,
  architectureRelationOccurrenceRefs?: FinSet(ArchitectureRelationRef),
  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim),
  claimScope?: U.ClaimScope, byValue,
  modelUseStructureRef?: U.StructureRef,
  empiricalGroundingRelationRefs?: FinSet(EpistemeEmpiricalGroundingRelationRef),

  recordPatternLocator,
  selectedRelationKindRefs?,
  selectedConstraintRefs?,
  selectedInvariantRefs?,
  selectedOperationDescriptionRefs?,
  selectedDynamicsDescriptionRefs?,
  viewConstruction:
    directDescription | projection | query | extraction |
    coarsening | correspondenceSlice | sourceReturnSlice,
  structuralAspectDescriptionRef?: U.EpistemeRef,
  hiddenOrLostStructure,
  structureKnowledgeState?:
    declared | observed | inferred | generated | simulated |
    extracted | hypothesized | unknownRegionPresent,
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef),
  sourceToUsePathRefs?: FinSet(U.RelationRef),
  workRelianceRelationRefs?: FinSet(U.RelationRef),
  sourceReturnCondition?,

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

recordPatternLocator identifies the pattern whose record form is being used. It is a locator, not a substitute for any rule needed by a current claim.

The selected U.Structure is the one EntityOfConcern. Before that field can be filled, A.22 identifies the structure from exact constituents, selected independently obtaining relation occurrences, applied constraint claims, and one exact receiving-use frame. A description, query, diagram, family declaration, file, representation, or publication creates none of those discriminators. relatedStructureRefs may name structures needed to interpret correspondence, allocation, or crossing, but they do not create a union-valued EntityOfConcern. When another selected structure becomes primary, identify another description episteme under C.2.1. Assert edition continuity only when its historical-continuation predicate obtains, and apply A.6.4 separately when retargeting is claimed; do not overwrite identity through a view field.

The direct conformance occurrence has exactly two participants: viewEpistemeRef as candidate E and viewpointRef as exact P. Its fixed E.17.0 predicate requires: (1) independently identified E and admitted P; (2) exact EntityOfConcern(E) recovered; (3) P’s fixed EntityOfConcern-kind criterion succeeds for that exact object; (4) E has an independently admitted episteme kind accepted by P without circular U.View use; and (5) E’s fixed claim content under its effective scheme satisfies P’s concern-coverage, semantic-form, completeness, and admitted-omission rules. The occurrence is participant-determined by <E,P>.

An architecture claim can carry positive, negative, unresolved, required, desired, expected, or candidate content. architectureRelationOccurrenceRefs is affirmative only for independently obtaining direct ArchitectureRelation occurrences. describedHolonRef and participant traces keep the subject recoverable; neither an optional claim nor a diagram derives the subject-side occurrence.

ClaimScope, concern, model-use structure, and empirical grounding remain optional neighboring qualifiers or relations. modelUseStructureRef appears only when an independently selected DDD-style bounded-model-use structure changes interpretation or selection for this use. None enters base episteme or selected-structure identity.

viewConstruction records provenance only. Direct authoring, A.6.3 construction, projection, query, extraction, selection, bundle inclusion, diagramming, rendering, publication, evaluation, or current use neither satisfies the conformance predicate nor creates selected structure. Representation, publication occurrence, form, and carrier likewise retain their own identities.

structureKnowledgeState? 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 architecture truth, assurance, gate, release, causal proof, or architecture decision.

C.30.ASV:4.2 - Architecture structure-kind classifier

ArchitectureStructureKindRef is a C.30-local DiscriminatorToken enumeration over exact architecture-relevant U.Structure references selected under A.22 and used by C.30. It is not U.Kind, U.Viewpoint, U.ViewpointBundle, StructuralAspectDescription, ArchitectureStructuralView, or a root U.* kind. An ArchitectureStructuralView uses structureKindRef to state which kind of selected structure its claim graph describes; that token neither identifies the structure nor grants U.View membership.

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

  WorkMethodStructure,
  AllocationResponsibilityStructure,
  EvidenceAssuranceStructure,
  ScaleEvolutionStructure,
  OtherDeclaredStructureKind
}

The first group is the seed classifier set for ordinary architecture structural-view use. SecurityTrustBoundaryStructure, WorkMethodStructure, AllocationResponsibilityStructure, EvidenceAssuranceStructure, and ScaleEvolutionStructure are classifier values over selected U.Structure references, not new root kinds. ASV may use them to name the selected architecture-relevant structure, but their full semantics stay in the named security, work and method, allocation-responsibility, evidence and 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 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;
• locally triggered overreads;
• applicable patterns for non-ASV claims;
• a selected-structure admission test, plus the effective U.ReferenceScheme when the local classifier name depends on one.

Each structure kind needs a short definition, allowed relation families, locally triggered overreads, applicable patterns for its non-ASV claims, and example architecture structural-view records. This is not a new root-kind set; it is a controlled classifier set over exact U.Structure values.

C.30.ASV:4.3 - Small triage output

When triage must be retained, compared, or handed on, use ArchitectureStructureKindTriage@Project before a full view record when the practitioner only needs to identify the structure kind under consideration and next architecture move.

ArchitectureStructureKindTriage@Project ::= {
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work,
  architectureStructuralViewProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains,
  architectureClaimRef?: U.EpistemeRef constrained to ArchitectureClaim,
  architectureRelationOccurrenceRef?: ArchitectureRelationRef,
  describedHolonRef?: U.HolonRef,
  candidateViewEpistemeRef?: U.EpistemeRef,
  exactViewpointRef?: U.ViewpointRef,
  viewpointConformanceRelationRef?: EpistemeViewpointConformanceRelationRef,
  claimScope?: U.ClaimScope, byValue,
  effectiveReferenceScheme?: U.ReferenceScheme, byValue,
  modelUseStructureRef?: U.StructureRef,
  architectureConcernCue?,
  sourcePhrase?,
  inspectedDescriptionOrViewRef?: U.EpistemeRef,
  candidateStructureKindRefs: FinSet(ArchitectureStructureKindRef),
  smallestUsefulStructureKindRefs: FinSet(ArchitectureStructureKindRef),
  selectedStructureRefs?: FinSet(U.StructureRef),
  hiddenOrLostStructureCueRefs?,

  admissibleArchitectureMove:
    inspect | split | relate | downgrade | nameApplicablePattern | stop |
    otherDeclared,
  claimPatternRefs?: FinSet(PatternRef),
  nonAdmissibleOverread?,
  stopCondition
}

architectureConcernCue? and sourcePhrase? are recognition wording. claimPatternRefs? names only patterns that define or test separate claims; it does not assert that a pattern-application occurrence exists. inspectedDescriptionOrViewRef? and candidateViewEpistemeRef? name actual epistemes only when identified under C.2.1. None creates an ArchitectureStructureKindRef, selected structure, architecture relation, or U.View. Fill exactViewpointRef when the exact independently admitted viewpoint is identified; fill viewpointConformanceRelationRef only when the same candidate episteme actually conforms to that viewpoint.

When architectureClaimRef is absent, describedHolonRef, architectureRelationOccurrenceRef, or at least one exact candidate selected structure must keep the subject recoverable for the intended triage. claimScope, effectiveReferenceScheme, and modelUseStructureRef are present only when they change this use. The card publishes no architecture claim and creates no subject relation. A full ArchitectureStructuralView requires the candidate episteme’s exact C.2.1 identity plus obtaining E.17.0 conformance; it does not require an architecture-claim record when the exact selected-structure EntityOfConcern and subject trace are otherwise recoverable.

Practitioner prompt labels are first-entry cues, not ArchitectureStructureKindRef values. When the triage is retained as a record, use the technical values below:

Functional -> FunctionalStructure
Flow -> TransformationFlowStructure
Control -> ControlStructure
Module -> ModuleInterfaceStructure
Method and work -> WorkMethodStructure
Allocation and responsibility -> AllocationResponsibilityStructure
Evidence -> EvidenceAssuranceStructure
Scale -> ScaleEvolutionStructure
Security -> SecurityTrustBoundaryStructure

C.30.ASV:4.3a - Evolutionary-engineering candidate structural view

Use this branch when a retained variant, front member, selected set, or architecture-candidate palette needs structural-description triage. The claim is not “this archive is architecture” and not “this record is already a U.View.” It is “this candidate makes an exact selected structure or structure kind current for an architecture claim or possible architecture move.”

ArchitectureCandidateStructuralDescription:
  CandidateSetOrArchiveRef:
  CandidateRef:
  DescribedHolonOrArchitectureRelationRef:
  SelectedStructureOrStructureKindRef:
  CandidateDescriptionEpistemeRef:
  ExactViewpointRef?:
  ViewpointConformanceRelationRef?:
  AffectedCharacteristicRef:
  CorrespondenceOrLossRef?:
  NextQuestionPatternLocator:

If the candidate cannot name an exact selected structure or structure kind, keep it in C.18, C.19, or G.5. If the description is used only to publish, compare, or explain the candidate, use C.30.AD, the comparison pattern, or the publication-use pattern named by value. It is an ArchitectureStructuralView only when the same candidate description episteme independently conforms to the exact viewpoint under E.17.0.

C.30.ASV:4.4 - Project-local architecture viewpoint-family template and binding rows

C.30.ASV ships no exact architecture viewpoint catalogue, family value, reference, or viewpoint episteme edition. VF.ARCH.STRUCTURE, VF.TEVB.ENG, and VP.Architecture* are therefore not current global values. A project may use similarly spelled ordinary designators only after it constitutes exact catalogue episteme L and binds exact local references.

Architecture structural views can reuse a materialized local family without turning structure kinds into viewpoints. The project first:

1. constitutes exact L through obtaining EpistemeConstitutionRelation(G_L, K_L, R_L);
2. places one local declaration claim block inside exact G_L, retrieved by ordinary familyDesignator = f_arch under R_L;
3. states the exact target-kind compatibility condition and a finite non-empty set of exact U.ViewpointRef members;
4. resolves every retained reference under R_L to one exact P already admitted under E.17.0; and
5. preserves exact catalogue and member provenance for any imported project-local TEVB reference rather than importing a family label.

Until those bindings exist, use this only as an authoring template:

ArchitectureViewpointFamilyTemplate ::= {
  catalogueConstitution: <G_L, K_L, R_L>,
  catalogueEpistemeRef: L,
  catalogueLocator: <editionDesignator(L), f_arch>,
  targetKindCompatibilityCondition: exact criterion that candidate E has recoverable C.2.1 identity and EntityOfConcern(E) is one selected U.Structure, stated by value or by ClaimGraph reference,
  viewpointRefs: {
    r_architecture_structure,
    r_architecture_correspondence,
    r_architecture_source_return,
    r_architecture_decision_affected_structure
  },
  resolutions: {
    resolve_R_L(r_architecture_structure) = P_architecture_structure,
    resolve_R_L(r_architecture_correspondence) = P_architecture_correspondence,
    resolve_R_L(r_architecture_source_return) = P_architecture_source_return,
    resolve_R_L(r_architecture_decision_affected_structure) = P_architecture_decision_affected_structure
  },
  optionalReaderDesignators: {
    d_architecture_structure,
    d_architecture_correspondence,
    d_architecture_source_return,
    d_architecture_decision_affected_structure
  },
  importedReferenceProvenance?: {
    <editionDesignator(L_source), sourceFamilyDesignator, exactSourceViewpointRef>
  }
}

ArchitectureStructureKindViewRecordBinding ::= {
  catalogueEpistemeRef: L,
  catalogueLocator: <editionDesignator(L), f_arch>,
  structureKindRef: ArchitectureStructureKindRef,
  allowableViewpointRefs: FinSet(U.ViewpointRef),
  candidateViewRecordSetRef,
  allowedViewConstructionModes,
  requiredConformanceRuleRefs,
  requiredCorrespondenceClaimOrRelationRefs?,
  sourceReturnRequirement?,
  claimPatternRefs: FinSet(PatternRef)
}

Every r_*, P_*, d_*, L, and f_arch above is a variable until one project supplies the exact binding. A d_* value is only P’s ordinary designator; it is neither a reference nor P. Another project with matching spellings has not reused this family unless it resolves the same exact L, declaration, and members.

Project-local TEVB reuse follows the same rule. A project may retain one or more exact references from a materialized local TEVB declaration when their exact P rules fit. It preserves each <editionDesignator(L_source), sourceFamilyDesignator, sourceViewpointRef> tuple and any omission decision. It does not expand a global TEVB core, infer a cross-family import relation from labels, or claim that E.17.2’s four-position template is a materialized family.

candidateViewRecordSetRef names an exact C.13 collection of permitted description or specification-use record forms for one structure-kind binding. The binding and family declaration may help retrieve candidate E and resolve exact P, but neither makes the fixed E.17.0 predicate true, identifies an EpistemeViewpointConformanceRelation occurrence, grants U.View membership, or creates the selected structure. The collection is not a publication face or package grouping, and it neither supplies a ViewFamilyId nor adds a viewpoint; publication forms, carriers, catalogue locators, and family designators remain separate.

C.30.ASV:4.4a - Structural-view publication-use boundary

This is the C.30.ASV structural-view publication-use boundary. C.30.ASV covers the description episteme’s identity, selected architecture-relevant structure, structure kind, E.17.0 viewpoint conformance, construction history, correspondence, hidden and lost structure, source return, and the next architecture move. When a view, diagram, graph, card, benchmark, probe output, model publication, or architecture note is used for evidence sufficiency, safety assurance, gate passage, release permission, work record, or decision authority, use the applicable pattern for that claim; keep only the structural-view record and next architecture move in C.30.ASV.

C.30.ASV:4.5 - 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 structure kind under consideration and the applicable pattern for any non-ASV claim.

Classifier values defined outside C.30.ASV remain admissible when they are the architecture-relevant structure under consideration, but C.30.ASV does not define their full record families:

Minimum useful seed examples:

Minimal SecurityTrustBoundaryStructureView fields:

SecurityTrustBoundaryStructureView ::= {
  architectureStructuralViewRef:
  protectedAssetOrEffectRefs:
  trustBoundaryRefs:
  untrustedInputRefs:
  privilegeOrAuthorityRefs:
  dataFlowOrControlFlowRefs:
  attackExposureRefs:
  abuseOrMisusePathRefs:
  secureDefaultOrHardeningBoundary:
  updateOrSupplyChainChannelRefs:
  detectionResponseBoundaryRefs?:
  claimPatternRefs:
    A.10 | G.6 | B.3 | C.28 | A.20 | A.21 |
    C.16 | C.25 | C.24 call planning after the action or option is fixed | C.30.LCA when a control relation is being claimed
  admissibleUse:
  otherClaimBoundary:
    compliance, risk-score, assurance, checklist-security, and zero-trust claims use the applicable evidence, assurance, risk, gate, or security pattern
}

SecurityTrustBoundaryStructure carries adversarial-boundary interpretation: which protected assets or effects are under consideration, 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.

Apply evidence, assurance, gate, or compliance patterns only when the architecture move relies on evidence sufficiency, assurance verdict, gate passage, regulatory acceptance, or release authority. If the selected move is structural, first recover the structure: trust boundary, loss-control relation, control relation, evidence reuse structure, or affected structure or affected 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
  claimPatternRefs:
    A.3.3 dynamics, C.27 temporal or rate,
    C.28 causal-use, A.10 or G.6 evidence,
    B.3 assurance, A.20 internal-constraint validity, A.21 gate decisions
  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.

C.30.ASV:4.5a - Select structures for a Method and its uses

Use this profile when “the architecture of the method” is too vague to decide what can change, what must remain compatible, or what a drawing leaves out. Start from one identified Method and the decision at hand. A.3.1 supplies that non-agentive holon’s identity; C.30 relates an exact holon to a selected A.22 structure when its architecture predicate obtains. For several independently usable Methods, retain that plurality until a particular encompassing Method is established. A useful account of their connections can remain ordinary prose.

Start with the Method concern and intended effect or preserved condition under A.3.1:4.1 and :4.4. They explain what future enactments are for. A proposed receiving use, an actual use of a particular recording, a statement in a description and a binding in a declaration answer different questions; state the one needed by the architecture decision. E.10:0.2c.7–7a helps when result, purpose or work-product wording hides that choice.

Choose questions that change the decision. The following questions are a first-use repertoire, not a mandatory collection of views or new universal structure kinds. Answer in the language of the work. Select an A.22 structure only when reliance on its organization matters, and apply the rule that defines each relation. A proposed dependency or correspondence remains a claim until its obtaining relation is established; a convenient name or a local graph edge does not admit it.

Connect the answers through one changed condition. Suppose a studio proposes a recording-preparation Method for correcting relative timing while preserving the recorded movements. Its construction requires corresponding time marks and observed offsets, a calculation of the correction, a domain basis for applying it between marks, a suitable editing operation, and a check against the receiving-use criterion. B.1.5 supplies the question for admitting the constituent calculation as part of this exact preparation Method under its stable construction rule. Another calibration Method could include that same calculation under its own rule; the shared part would not merge the two wholes.

At three marks the observed offsets are 40, 42 and 45 ms. Subtracting 42.5 ms gives residuals −2.5, −0.5 and 2.5 ms; no constant correction can lower the largest absolute residual at these marks below 2.5 ms. Separately, stipulate that the recording engineer supplies a justified domain claim that the relative offset remains within 40–45 ms throughout the stated interval, and an editing operation qualified to apply the chosen constant correction without adding timing distortion. That timing envelope is a supplied premise of this hypothetical case, not an inference from three observations. With those premises, the corrected recording has an absolute timing error of at most 2.5 ms throughout the interval. Without them, the calculation qualifies only the marks.

Now select only the structures needed by the studio’s choice:

1. The composition account explains why the calculation is a constituent of preparation. An interface account says whether the receiving Method gets the corrected recording alone or also the timing qualification and its limits.
2. The result-use account connects preparation to movement analysis and demonstration viewing. Under the separately supplied timing envelope and qualified editing operation, the recording meets the interval bound of 2.5 ms. Analysis accepts 3 ms and viewing 8 ms, so both receiving conditions are met. Neither receiving use becomes a constituent of preparation by consuming the recording.
3. Analysis tightens its requirement to 2 ms. The lower bound at the marks rules out meeting it with any constant correction of these offsets. Viewing remains supported under its 8 ms condition while the timing envelope and editing qualification remain valid. The failed analysis connection calls for a warranted better correction, another recording or a justified change of requirement. If the envelope or editing qualification instead loses its basis, reopen interval qualification for both uses; the pointwise calculation alone preserves neither one.
4. If the team develops a replacement correction rule, compare it against the affected preparation and receiving uses before introduction. If only the editor workstation moves to another room, inspect the changed access, timing or resource conditions; Method identity changes only if its own defining conditions change.

C.39:5.3 develops the same calculation and changed-condition case for ordinary method development; E.4.CM:5.4 applies it to framework authorship. The interval claim here depends on the separately stipulated domain envelope and editing qualification; neither the numbers at the marks nor a diagram supplies those premises. This is a conditional construction, not evidence of practitioner success. Performing the preparation later supplies Work occurrences and evidence under their own rules.

Choose the picture last. A composition drawing may place the preparation above its constituents, with each edge naming Method parthood. A result-use drawing may place preparation to the left of analysis and viewing, with each edge naming the used result and its acceptance condition. These are the vertical and horizontal directions of those particular representations, as A.22:4.3a explains. Neither axis gives a universal Method level, a lattice, a performer hierarchy or a place in a room.

The first useful result is a short explanation of what changes and what remains usable. A typed structural view adds value when the decision depends on exact correspondence, hidden structure or viewpoint conformance. If several structures expose a conflict or move burden between participants, C.32.MWA supplies the synthesis and comparison; a clear single connection can stop here.

C.30.ASV:4.6 - Functional structure view boundary

A FunctionalStructureView under C.30.ASV does not mint U.Function, U.Transformation, or a bearer relation. It is the same ArchitectureStructuralView episteme whose EntityOfConcern is one selected functional U.Structure and whose exact viewpoint conformance obtains. It may carry FunctionalElementClaim epistemes when the claim graph relates that selected functional structure to required or desired behavior or effect content and to a bearer or candidate-bearer locus. The claim is not identical with any actual behavior occurrence, bearer, capability, port, allocation, or relation.

Keep three branches explicit:

• required or desired behavior or effect: a C.2.1 claim; use the applicable requirement, architecture, capability, method, or functional-view pattern for that claim;
• actual transformation: an independently identified U.Transformation only after A.3.4 recovers the changed referent, extent or boundary, boundary conditions, actual before, during, and after facts, and continuity or reidentification basis;
• compound flow organization: an exact selected TransformationFlowStructure under E.18, whose constituents and selected obtaining relations are independently identified; the structure is not itself an actual transformation.

FunctionalElementClaim has ordinary C.2.1 identity <exact ClaimGraph, one exact EntityOfConcern, effective U.ReferenceScheme>. For this use its EntityOfConcern is the selected functional structure. Its claim content may name:

• one or more required or desired behavior or effect claim refs;
• actual transformation refs only when the complete A.3.4 basis independently obtains;
• selected transformation-flow structure refs for compound flow organization;
• a bearer or candidate-bearer locus, normally a U.System or candidate system for a separately established transformer system-role-kind claim;
• capability, input and output condition, functional-port, dependency, allocation, and correspondence refs only when the applicable pattern defines or tests that relation or claim.

If no bearer or candidate allocation is current, do not claim a filled functional element. Record a required-behavior gap, required-effect gap, capability gap, functional-behavior slot, or candidate allocation question. This preserves the practical architecture move without pretending that a module, component, diagram row, function word, requirement, or selected flow structure has already supplied the bearer or actual change.

FunctionalStructureViewUse ::= {
  architectureStructuralViewRef: U.EpistemeRef constrained to ArchitectureStructuralView,
  functionalElementClaimRefs?: FinSet(U.EpistemeRef),
  sourceFunctionWordingRefs?,
  functionalBehaviorClaimRefs?: FinSet(U.EpistemeRef),
  requiredOrDesiredEffectClaimRefs?: FinSet(U.EpistemeRef),
  actualTransformationRefs?: FinSet(U.TransformationRef),
  selectedTransformationFlowStructureRefs?: FinSet(U.StructureRef constrained to TransformationFlowStructure),
  transformerSideFillerRefs?: FinSet(U.SystemRef),
  candidateBearerRefs?: candidate system refs; explicit gap refs,
  holderAbilityClaimRefs?: qualified A.2.2 claims about identified holder Systems,
  inputConditionRefs?,
  outputConditionRefs?,
  functionalPortRefs?,
  functionalDependencyRefs?,
  allocationRefs?,
  correspondenceClaimOrRelationRefs?,
  nonFunctionClaimNotes?,
  flowRelationRefs?,
  moduleInterfaceClaimOrRelationRefs?,
  admissibleUse,
  nonAdmissibleUse
}

Required cooling effect followed by actual cooling. Requirement episteme RequiredCoolingEffect-1 says that Rack 7 should be brought below 30 °C during declared operation. Before the rack or cooling loop has changed, that is required effect claim content: there is no actual U.Transformation, even if a functional-view row, flow diagram, or selected TransformationFlowStructure cites it. Later, Rack7CoolingTransformation-42 may be identified under A.3.4 when the exact changed referent and boundary are fixed, operating and ambient boundary conditions are stated, actual before facts show 38 °C, actual during facts recover heat removal, actual after facts show 27 °C, and continuity or reidentification keeps the same referent recoverable. A separate satisfaction or realization predicate is still needed before claiming that the later transformation satisfies RequiredCoolingEffect-1; temporal succession or matching labels alone is insufficient.

A selected transformation-flow structure, mathematical graph description, transformation-flow path slice, crossing, or flow valuation is not a functional element or actual transformation by default. When a transformation-flow relation is being used, connect the functional view to the exact TransformationFlowStructure through C.30.TFS-REL. When a mathematical graph description is being used, connect it through E.18.2; when math-lens use is being claimed, connect it through C.29. When module allocation is being claimed, use A.6.M to repair the module claim and identify the admitted allocation or interface relation separately rather than treating function and module as one kind. Functional ports and module interfaces can both use U.Signature discipline, but functional ports specify behavior input and output slots while module interfaces specify substitution, compatibility, boundary, and change-policy claims.

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

Composability:
  "A and B can be assembled under interface X."
  recoveredRelationOrRecordKind: ModuleAllocationRelation | InterfaceSpecification
Quality compositionality:
  "The assembled whole preserves safety, latency, or reliability."
  recoveredRelationOrRecordKind: QBundleSlot | structuralCharacteristicQBundleInputSlot | structuralCharacteristicCausalHypothesisForQBundleSlot | structuralCharacteristicEvidenceRelationForQBundleSlot(A.10 describes bounded source-to-use reliance; cited direct relations require their own defining patterns)
Non-admissible:
  successful assembly is not quality propagation

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

C.30.ASV:4.7 - 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, law-domain review, regulatory review, comparison, or reopening.

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

When the view is used to name affected structures for a next architecture use but no decision record is being used, 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 use. 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. Use fuller source, evidence, assurance, or claim-kind relation only when the source or reliance relation being used cannot be inspected, used, compared, refreshed, or bounded without it. A ControlStructureViewNote may precede full C.30.LCA use or use of the applicable proof or assurance pattern when one control relation and its boundary are enough for the architecture move being made.

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 |
    lawDomainOrRegulatoryUse | assuranceOrDecisionUse
  nextSourceReturnAction:
    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 reliance relation, assurance, law-domain, comparison, causal, gate, or decision commitment. The condition is needed only when the repaired text still relies on the hidden source-side distinction.