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.