Appendix C — Design Principles
We organize our design principles across two levels. Eight core principles form a concise set we carry into any unfamiliar architecture problem. Our chapter principles apply these cores to formulation, data, methods, tools, verification, execution, transfer, evaluation, and responsibility. Each chapter introduces its principles when it resolves distinct engineering choices, each presenting different failure modes and review artifacts.
C.1 Core Principles
Our framework rests on a small set of design principles that guide how we evaluate and refine computer architectures using automated methods. This appendix serves as our operational reference. Each principle states the failure it predicts, the review question that makes it inspectable, and the boundary beyond which it stops applying.
C.1.1 1. Make the architecture decision executable
Failure prediction. We risk optimizing a convenient artifact when the workload, software behavior, credible alternatives, physical constraints, and acceptance checks required for our architecture decision remain implicit.
Review question. What choice are we making, under which conditions, and what observation would distinguish the alternatives?
Boundary. We may begin our exploration before a decision is fully executable, and some architectural obligations remain qualitative. However, these obligations must stay visible, and our exploratory output cannot support a final commitment until the comparison and evidence paths are explicit. Here, executable means we can carry the decision into our tools and check it. It does not mean reducing architectural judgment to a single runnable artifact or metric.
Chapter applications. Chapter 1 expands a compact request into a real architecture decision. Chapter 11 returns to the framing, abstraction, and cross-layer judgment that keep our decisions coherent.
C.1.2 2. Follow the bottleneck, not the novelty
Failure prediction. We adopt a novel method that accelerates candidate construction, only to find that simulation, implementation, verification, or review dictates the time and cost of reaching a supported decision. This apparent gain merely shifts our work or risk elsewhere.
Review question. What work currently blocks our next supported decision, and where will that limiting work move if this stage becomes faster?
Boundary. We may pursue a novel method in capability research before it improves our current workflow, provided that capability discovery is our stated goal. For any workflow improvement claim, however, we must count the complete path and identify the next bottleneck, including both human and machine costs.
Chapter applications. Chapter 2 diagnoses the work limiting our architecture progress. Chapter 5 uses that diagnosis to help us choose the smallest sufficient approach.
C.1.3 3. Preserve decision-critical meaning across every transformation
Failure prediction. When we transform a design representation, translation, wrapper, retry, or parser, we risk preserving an artifact’s name and provenance while erasing a required relationship or silently altering the design we evaluate. Our later checks then qualify evidence for the wrong candidate, or for an abstraction that cannot express the property under decision.
Review question. What must remain true as our design crosses this boundary, and how will we determine that the transformation properly preserved it?
Boundary. Our abstractions may omit details that do not affect the current decision, and a wrapper may change syntax without altering meaning. However, these omissions and equivalence obligations must be explicit. A meaning-changing transformation creates a new candidate and requires us to re-establish the affected claims. Complete provenance cannot compensate for lost design meaning.
Chapter applications. Chapter 4 chooses representations by the specific properties our architecture decision must preserve. Chapter 6 applies this rule to tool translation, execution, and returned artifacts.
C.1.4 4. Every result carries its conditions
Failure prediction. We treat a valid local result as general truth, only for it to become false evidence after its underlying design, workload, software, tool path, process condition, operating envelope, or neighboring component changes.
Review question. Under exactly which conditions does this result apply, and can we reliably recover both these conditions and the check that originally qualified the result?
Boundary. Our conditions may travel through a durable reference to an authoritative record rather than being copied into every artifact. We should record the conditions that affect applicability and avoid metadata for its own sake. Reusing a component does not guarantee we can reuse its conclusion if a relevant condition changes. For learned results, applicable conditions include the support of the training or feedback data, representation choices, information loss, model or policy state, retrieval state at the time of use, and the uncertainty attached to the result.
Chapter applications. Chapter 4 binds our observations to the specific conditions that give them meaning. Chapter 6 preserves runtime identity and lineage. Chapter 9 helps us determine what remains applicable after a target changes.
C.1.5 5. Different failures require different repairs
Failure prediction. We trigger the same generic retry or regeneration step across a malformed candidate, an invalid execution, a misleading measurement, an unsupported interpretation, or an unsafe commitment. Consequently, our workflow changes the wrong thing, obscures the root cause, and corrupts later results.
Review question. What specific property failed, where was the failure introduced, and which part of our work can remove its cause?
Boundary. This rule separates our questions, outputs, and repair paths, rather than artificially dividing people or organizations. One person or system may handle several responsibilities, and multiple symptoms may share a common repair if our evidence supports that diagnosis.
Chapter applications. Chapter 3 separates our lifecycle responsibilities by their corresponding questions, failures, and repairs. Chapter 6 contains execution failures inside recoverable tool boundaries. Chapter 7 routes our qualified results to the next eligible technical action.
C.1.6 6. Stronger claims require stronger checks
Failure prediction. We treat a proxy, prediction, simulation, or pass label as support for a broader implementation or signoff claim than it can falsify. The opposite failure occurs when we demand signoff-strength checks as a prerequisite for every reversible exploration.
Review question. Could this specific check actually falsify our claim at its stated scope and consequence?
Boundary. Cheap, fast checks can guide our reversible exploration as long as their limits remain explicit. However, as our claim broadens or its potential consequences increase, we must proportionally strengthen our checks along the dimensions relevant to their failure modes. These dimensions may include fidelity and coverage, calibration and uncertainty, support and shift analysis, hard or negative cases, contamination controls, independence from adaptive search, adversarial pressure, and adequate statistical power. While falsifiability is necessary, it is not sufficient. Verification throughput remains a bottleneck question (under Principle 2), never a valid reason to weaken a consequential claim.
Chapter applications. Chapter 1 separates artifacts from architecture results. Chapter 7 matches our checks to our claims and qualifies the resulting action. Chapter 8 stops at the limit of its checked record. Chapter 10 keeps our decisive evaluation checks safely outside the system being evaluated.
C.1.7 7. Judge the architecture before crediting the assistance
Failure prediction. We credit a good candidate to artificial intelligence (AI) tools without establishing a credible alternative or attribution test, or we allow a faster workflow to unjustifiably excuse an inferior architecture.
Review question. Did our architecture improve under matched conditions, and did the assistance cause that improvement at complete human and machine cost, within a stated accounting boundary?
Boundary. Our exploratory work may leave attribution unresolved as long as we clearly state that limit. However, any formal claim of improvement requires separate judgments of architecture quality, specific contribution, total cost, and robustness, not just a single favorable score. Our accounting boundary must be symmetric and decision-relevant across all alternatives. It must include differential setup, data, adaptation, integration, tools, verification, human review, recovery, and any amortized reuse cost that might change our adoption decision.
Chapter applications. Chapter 1 introduces separate tests for the architecture result and the complete approach. Chapter 10 owns the matched evaluation we need to accurately attribute value to the assistance.
C.1.8 8. Delegate technical work, not architectural accountability
Failure prediction. Automation changes register-transfer level (RTL) code, constraints, tool state, or a recommendation while no named human authority owns the commitment, the residual risk, the ongoing monitoring, or the responsibility to reopen the decision after conditions change.
Review question. What exactly may the automated system change, within which permission, isolation, observation, and recovery boundaries, and who owns our architecture commitment?
Boundary. We may safely automate routine and reversible actions inside an explicitly approved scope. However, the named authority must remain technically qualified and institutionally empowered to stop, commit, or reopen the work, backed by an accountable organization able to support those decisions. While the owner need not repeat the delegated work, they must be able to inspect its underlying basis, accept its consequences, and secure the monitoring and recovery resources the commitment demands.
Chapter applications. Chapter 6 bounds and contains our automated tool actions. Chapter 10 preserves evaluator control over decisive checks. Chapter 11 formally defines the architect’s technical role, commitment authority, and continuing accountability.
C.2 Chapter Applications
The core principles recur because different stages expose different versions of the same engineering tension. Each chapter principle states the specific operational rule we apply at that stage.
Each row below reproduces a chapter’s design-principle callout title verbatim, so a reader can match the wording here against the box in the chapter that earns it.
| Chapter | Chapter principle | Core principle |
|---|---|---|
| Chapter 1 | An architecture moonshot must expand expressible and checkable design | 1, 6 |
| Chapter 2 | Relieve the true limiting constraint | 2 |
| Chapter 3 | Isolate failure domains to enable targeted repair | 5 |
| Chapter 4 | Choose representations by what the decision must preserve | 3 |
| Chapter 4 | Keep every observation tied to the conditions that produced it | 4 |
| Chapter 5 | Choose the smallest sufficient approach | 2 |
| Chapter 6 | An unrecorded execution cannot justify an architectural claim | 4, 5 |
| Chapter 6 | Automate tool actions only inside a recoverable boundary | 5, 8 |
| Chapter 7 | Stronger claims require stronger checks | 6 |
| Chapter 7 | Only let qualified results drive the next architecture action | 5, 6 |
| Chapter 8 | Prospective intent versus executed evidence | 4, 6 |
| Chapter 8 | Claim only what the checked record supports | 4, 6 |
| Chapter 9 | Transfer components, not conclusions | 4 |
| Chapter 10 | Isolate decisive evaluation checks from the system under test | 6, 8 |
| Chapter 10 | Prioritize architectural soundness over assistance credit | 7 |
| Chapter 11 | Architecture judgment does not begin where automation ends | 1, 8 |
| Chapter 11 | Delegate technical work, not architectural accountability | 8 |
| Chapter 12 | Build open foundations before scaling autonomous tools | 1, 8 |
| Chapter 12 | Build what makes other teams’ claims checkable, not just your own | 4, 7 |
The nineteen chapter principles are not nineteen competing fundamentals. They are the practical forms in which the eight core principles become inspectable during real architecture work, which is why several chapters map to the same core rule from different stages of the design work.