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.