| Structure-first architecture | Architecture uses obtaining relations between an exact described holon and selected structures for a named architecture question and use; the flow is not reducible to documents, labels, stages, tools, or a generic context participant. |
| Structural uncertainty | Architecturing often starts before structure kinds, bearers, interfaces, allocations, or variation points are known. |
| Characteristic trade-off | Architecture characteristics compete; optimizing one can damage another or hide Goodhart pressure behind a metric. |
| Candidate plurality | Useful architecture work keeps structurally different alternatives alive until comparison, selected-set, local choice, or architecture decision becomes the current question. |
| Realization gap | Selected and expected structures do not become actual structures by decision, model, description, or matching labels. When claiming that work realized a structure, establish the domain work, actual changes, work-to-change facts, and the facts that make the subject-side structure obtain. |
| Architecture-influence constraint | One typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source can enable or block the transformed-side architecture content needed for the changed referent without thereby becoming an actor or transformation participant. |
| Description loss | Views, descriptions, decision records, method descriptions, and eval reports capture only part of the structural content needed for later use. |
| Evolution and feedback | Operation, use, telemetry, inspection, evaluation, decay, and new sources can reveal the next question. The practitioner then uses the matching pattern: C.32 for synthesis, C.32.PAD or C.32.ADA for repair or supersession, E.23 for improvement, G.11 for currentness refresh, E.18 for transformation-flow slice-local refresh, C.18 or C.19 for archive, front, and pool update, or C.30.AD or C.30.ASV for architecture-description or structural-view loss. |