C.30:2 - Problem

Engineering teams use “architecture” for several different things:

• the selected structure of a holon;
• a diagram, model, table, dashboard, generated relation graph, or document;
• a module layout;
• a selected transformation-flow structure, flow description, or mathematical graph description;
• a functional, control, information, deployment, logical, or physical structure view;
• an ADR-like publication;
• a project-side claim defined or tested by another FPF pattern.

These uses are all useful in ordinary engineering speech, but they cannot carry the same FPF claim. The core distinction is the one already used across FPF: actual subject-relation occurrences; the exact A.22 structure selected from them; the direct ArchitectureRelation that may obtain between that structure and one holon; a C.2.1 claim about the holon, relation, or structure; the Description episteme or view; the representation and publication objects; and any project decision about changing architecture are different objects.

The first-minute practitioner asks four questions:

1. Are we recovering an actual architecture relation, considering a candidate structure, or only reading a representation?
2. Which subject relations actually obtain, and which exact A.22 structure is selected from them?
3. Which structure kind is in view—function, flow, control, module, Work, system-role-kind or assignment, enactor, information, data, placement, deployment, scale, or a declared logical structure—and which adjacent interface, evidence, or assurance relations matter?
4. How is the inspected material being used: as claim content, description, view, representation, publication form, decision, source relation, or mathematical lens?

How can FPF describe architecture without:

• creating U.Architecture as a new root kind;
• treating a description, view, diagram, graph, ADR, dashboard, or generated relation graph as the architecture;
• reducing architecture to module structure or interface relation;
• letting E.18 transformation-flow structures, LCA structures, control structures, C.29 lenses, quality language, evidence, assurance, gates, work, or decisions silently become architecture ontology;
• making architecture descriptions so heavy that ordinary practitioners cannot get a first useful architecture move.