Appendix B — Design-Loop Card and Review Rubric
This appendix exists because Architecture 2.0 work will often arrive as papers before it arrives as stable infrastructure. The field is moving quickly, so a paper’s result is not the whole review question. What matters is whether the reader can see the design loop that produced the result and can judge whether the evidence supports the commitment.
The design-loop card is the practical form of the Architecture 2.0 ontology. Rather than maintaining separate claim cards for research and evidence ledgers for projects, the design-loop card provides a single, unified framework that adapts to both. It is meant to be filled in for a paper, a project proposal, a class exercise, or an internal design review. The review packet replaces a summary of the architecture. It exposes the loop behind the report. It shows what the system is trying to do, what it can see, what it can change, how feedback is obtained, what evidence supports a claim, what was rejected, and what judgment remains with the architect. In this appendix, the card becomes a one-page review record for those loop fields.
The card should be short enough to use. If it becomes a long form, people will not fill it in. If it is too vague, it will not reveal anything. The right level is one page for a first pass and a few supporting notes for the fields where evidence is disputed.
B.1 Why a Card, Not a Paper Summary
A conventional paper summary usually asks for the problem, method, result, and limitations. That is useful, but it often hides the design loop. It may not say what simulator state was assumed, which actions were illegal, how many samples were spent, what alternatives failed, how a proxy was calibrated, or what could have rejected the result. Those omissions matter more once AI systems begin to generate candidates, call tools, choose experiments, or summarize evidence.
The card borrows the reporting discipline of a datasheet, both the component datasheet architects already trust and the “datasheets for datasets” practice that carried it into machine learning (Gebru et al. 2021), without pretending a paper is only a dataset. It also borrows the discipline of compact disclosure without pretending a paper is only a model release. Model cards made intended use, evaluated conditions, and limitations visible for trained models (Mitchell et al. 2019). Datasheets for datasets did the same for data provenance, composition, collection process, maintenance, and recommended uses (Gebru et al. 2021). Assurance cases and Goal Structuring Notation connect claims to evidence, assumptions, and residual risk (Kelly and Weaver 2004). Architecture Decision Records preserve context, decision, alternatives, and consequences in a lightweight form (Nygard 2011). Reproducibility programs and reporting checklists show that reviewer-facing fields matter only when they make omissions visible (Pineau et al. 2021; Page et al. 2021). The evaluation is limited by the constraints of the evaluation budget. Benchmarking and supply-chain records add two more lessons. Claims need scenario rules and versioned provenance, while machine-readable manifests such as SPDX (Software Package Data Exchange) and SLSA (Supply chain Levels for Software Artifacts) should be linked when they exist rather than recreated inside the card (Mattson et al. 2020; SPDX Project 2021; Open Source Security Foundation 2026).
The design-loop card adapts that pattern to architecture work. It treats an architecture result as credible only once the loop behind it is on the record: the claim, scope, evidence, failed alternatives, rejection authority, and human commitment boundary.
The design-loop card shifts the focus to the loop’s structure and constraints. It captures the architectural intent being translated into work, the bounded task being performed, and the boundaries of the design space—including what is legal, invalid, or deferred. It exposes the representation and world model that make the work legible, along with the environment defining valid actions and feedback. Crucially, the card records the method role, the feedback budget, the evidence supporting the claim, and any negative traces captured during exploration. Finally, it specifies the rejection authority, the commitment boundary supported by the evidence, and the remaining decisions requiring human judgment.
This makes the card useful in three settings. In research, it helps compare papers that may use different methods but operate on similar loops. In design reviews, it reveals whether a result is backed by enough evidence for the commitment being made. In artifact review, it gives authors and reviewers a disciplined way to read Architecture 2.0 work without reducing it to a list of model names.
Table B.1 summarizes the borrowed pattern. The table does not mean an architecture team must fill out all of these precedent records for every artifact. It is a reminder that the card’s fields have jobs to bound a claim, make hidden assumptions visible, connect evidence to commitment, and give a reviewer a way to find omissions.
| Precedent | What it makes visible | What the design-loop card borrows |
|---|---|---|
| Model cards | Intended use, evaluated conditions, limitations, and risks. | Claims should name the conditions under which the reported behavior was evaluated and where it should not be used. |
| Datasheets for datasets | Motivation, provenance, composition, collection, maintenance, and recommended uses. | Workload, trace, benchmark, and artifact records need provenance and usage limits, not only final metrics. |
| Assurance cases and GSN | Claim, context, argument strategy, evidence, defeaters, and residual risk. | A loop record should say why the evidence supports the claim, what cuts against it, and what uncertainty remains. |
| Architecture Decision Records | Context, decision, alternatives, and consequences. | A design claim should preserve the rejected or deferred alternatives that make the decision meaningful. |
| Reproducibility and reporting checklists | Reviewer-facing fields that expose missing evidence or unsupported generalization. | Missing fields should weaken or bound the claim rather than disappear inside prose. |
| Benchmark governance and provenance records | Versioned scenarios, run rules, inputs, dependencies, and comparable reporting. | A loop claim should carry workload versions, tool versions, evidence IDs, and pointers to deeper artifacts where needed. |
Figure B.1 shows the operating pattern. Fill the card, apply the review lens, and assign a readiness status. The point is not to grade the prose of a paper. The point is to expose whether the loop behind the claim is visible enough for another architect to judge.
B.2 The Design-Loop Card Fields
Table B.2 gives the working card. The fields are ordered to match the ontology used throughout the book.
| Field | Question |
|---|---|
| Intent | What architectural objective is being pursued, and what constraints, non-goals, risks, or deployment assumptions matter? |
| Task | What bounded work is the loop doing? Examples include generation, prediction, optimization, critique, verification, workload characterization, benchmark construction, or design-space exploration. |
| Design space | Which choices are legal, invalid, out of scope, or intentionally left for a later turn? |
| Representation | What does the loop know, read, write, or assume? What state, dynamics, objectives, constraints, costs, and uncertainties are represented? |
| Environment | What can the loop act on, observe, and measure? Which actions are invalid, expensive, nondeterministic, or irreversible? |
| Method role | Is the method generating, predicting, optimizing, critiquing, verifying, planning, calling tools, coordinating, or combining several roles? |
| Feedback budget | How many evaluations are available, at what latency, cost, fidelity, and sample efficiency requirement? |
| Evidence | What supports the claim, and against which baseline is it measured? Sources can include baseline replay, proxy metrics, simulation, synthesis, verification, deployment telemetry, silicon data, expert review, or sensitivity analysis. |
| Negative traces | What failed, was rejected, violated constraints, crashed tools, disappeared at higher fidelity, or was ruled out by human judgment? |
| Rejection authority | What can say no? Examples include type checks, simulator segfaults, CDC/RDC errors, routing congestion, compiler fusion failure, tests, formal tools, signoff, cross-tool disagreement, deployment signals, or expert review. |
| Commitment boundary / would overturn | What claim level does the evidence support, what stronger claim is not yet authorized, and what evidence would overturn the decision? |
| Human decision | What remains an architect-owned judgment, and what commitment does the decision authorize? |
The card deliberately includes negative traces and rejection authority. These are often missing from published artifacts, but they are essential for AI-mediated design loops. A system that only remembers successful candidates does not learn the shape of the design space. A system that cannot say what rejects a candidate has not earned architectural trust.
B.3 A Machine-Checkable Schema
The card is a review artifact first, but it is meant to become a machine-checkable record so tools can validate it, ledgers can index it, and claims can be compared. The schema below names the required fields, gives stable IDs for the records a loop must preserve, reuses the commitment levels of the commitment ladder (Chapter 7), and compresses the fidelity ladder of Chapter 6 into six machine-checkable rungs. It is a minimum, not a standard to freeze; the point is that “we filled the card” becomes something a validator can check.
design_loop_card:
card_id: string
intent: { objective, constraints, non_goals }
task: { enum: [generation, prediction, optimization, critique,
verification, characterization, benchmark, dse] }
design_space: { legal, invalid, deferred }
representation: { state_schema_id, ir_level, reads, writes, uncertainties }
environment:
environment_id: string
actions: [string]
invalid_actions: [string]
blast_radius_limit: string
observations: [string]
fidelity: { enum: [proxy, simulation, rtl, synthesis_with_sdc,
silicon, shadow_traffic, canary, global_fleet] }
method_role:
roles: [ { enum: [generate, predict, optimize, critique,
verify, plan, tool_call, coordinate] } ]
actor_map: [ { actor_id, role, reads, writes, authority } ]
feedback_budget: { evaluations, latency, cost, fidelity }
evidence:
baseline_id: string # what the claim is measured against
records: [ { evidence_id, kind, workload_id, seed, provenance } ]
negative_traces: [ { candidate_id, reason, stage, gate } ]
rejection_authority: { gates, independent_of_producer, independence_basis }
commitment_boundary:
level: { enum: [exploratory, experimental, implementation,
integration, irreversible] }
strongest_supported_claim: string
would_overturn: string
human_decision: { owner, authorizes }Which fields are required depends on the conformance level the card claims (defined below): Level 0 requires card_id, intent, task, and design_space; Level 1 adds representation, environment, feedback_budget, evidence (with a baseline_id), and negative_traces; Level 2 adds the stable IDs and provenance; Level 3 adds rejection_authority (independent of the producer), commitment_boundary, and human_decision. The independence_basis field captures why the rejection authority is independent (e.g., a separate reporting chain or a formal verification tool). A validator checks a card against the level it claims. The stable IDs (card_id, workload_id, evidence_id, candidate_id, and the other *_id fields) are what let one loop’s ledger reference another’s, so a rejected candidate, a workload packet, or a baseline can be cited across cards rather than re-described. For a single-actor, workflow, or multi-actor loop, actor_map records the component, tool, or human participant playing each role, what state it reads and writes, and what authority it has. Simple loops may have one entry; split-role loops may have many.
B.4 The Review Rubric
The review rubric asks whether each field is strong enough for the claim being made. The standard should rise with commitment. A speculative idea can survive with weak evidence if it is labeled as such. A tool recommendation, RTL change, or physical-design decision needs a stronger evidence ledger.
Table B.3 makes that standard inspectable. It separates a pass signal from a warning sign so review can focus on evidence, rejection, and commitment rather than polish.
| Field | Pass signal | Warning sign |
|---|---|---|
| Intent and task | The task is bounded, measurable, and tied to an architectural objective. | The task is “use AI” or “generate a design” without a clear decision boundary. |
| Design space | Legal, invalid, and out-of-scope choices are named before the method acts. | The loop can wander into unreviewed choices or silently exclude alternatives. |
| Representation | The loop exposes the state needed to make valid architectural actions. | Important constraints live in hidden scripts, defaults, or informal assumptions. |
| Environment | Actions, observations, invalid states, costs, and provenance are defined. | The tool wrapper returns numbers but hides semantics, failures, or version state. |
| Method role | The method’s job is clear and matched to the feedback budget. | The method is chosen because it is fashionable, not because the task needs it. |
| Feedback budget | Latency, fidelity, sample count, and cost are explicit. | Claims ignore simulator time, EDA cost, expert review, or license limits. |
| Evidence | The evidence is relevant to the claim and calibrated to the commitment level. | A proxy metric is treated as truth without validation or uncertainty. |
| Negative traces | Failed candidates and rejected alternatives are captured with reasons. | Only successful runs are recorded. |
| Rejection authority | The loop states what can reject a candidate and what happens next. | There is no clear way to say no to a plausible but invalid result. |
| Commitment boundary / would overturn | The strongest supported claim and the evidence that would overturn it are explicit. | A proxy result is allowed to authorize a stronger commitment than it supports. |
| Human decision | Human judgment and accountability are explicit. | The loop implies that the method decides, but no one owns the commitment. |
The rubric is not a scoring system by default. A simple three-level annotation is often enough:
- Ready: the field is explicit and adequate for the commitment.
- Needs evidence: the field is plausible but underspecified.
- Unsafe: the field is missing or inconsistent with the claim.
The most important review question is not whether every field is perfect. It is whether the loop exposes enough structure for another architect to judge, repeat, reject, or extend the work.
B.5 Card Conformance Levels
A card can be filled at increasing strength, and naming the level turns “we used the card” into a checkable claim rather than a gesture. Each level inherits the one below it. The rubric’s pass and warning columns and its Ready/Needs-evidence/Unsafe annotations judge each field’s content; the conformance levels judge the card as a whole; the required, optional, and redaction-allowed marks below connect the two.
- Level 0, context only. Intent, task, and design space are named. Enough to understand what the loop was for; not enough to audit it.
- Level 1, auditable ledger. Adds representation, environment, feedback budget, evidence with a named baseline, and negative traces. A reader can see what was tried, what it cost, and what was rejected.
- Level 2, replayable loop. Adds the stable IDs and provenance (workload, seed, tool version, parameter hash) that let another team re-run the evidence and reproduce the ledger.
- Level 3, independently rejectable loop. Adds a rejection authority that is independent of the producer actor, an explicit commitment boundary, and a named human decision owner. The result can be rejected by someone other than the party that produced it.
Within a level, mark each field as required (its absence caps the conformance level), optional, or redaction-allowed (the content may be confidential, but its presence and a hash are still disclosed so the record stays auditable). A missing required field does not lower the score a little; it caps the whole card at the highest level whose required fields are all present.
B.6 Adapting the Card for Different Contexts
The Design-Loop Card is the core artifact. However, you will use it differently depending on your audience. You do not need to create separate “Claim Cards” or “Evidence Ledgers”; rather, you simply emphasize different fields of the Design-Loop Card depending on the context.
B.6.1 1. For Research Papers (Architecture Claim Card View)
When publishing an Architecture 2.0 paper, the card answers the author and reviewer question that sits one level above the loop: what exact claim is being made, what evidence supports it, and what commitment does the evidence authorize?
Focus on:
- Claim boundary: The exact architectural claim and non-claim.
- Evidence ledger: Proxy metrics, simulation, synthesis, signoff, hardware measurement, and their uncertainty.
- Negative traces: Crashes, invalid actions, constraint violations, and rejected alternatives. This prevents success-only reporting.
- Rejection authority: Tests, tools, constraints, or reviewers that can reject the candidate.
A paper may be technically interesting while leaving the loop underdescribed. The review question is whether a reader can tell what was tried, what failed, what was measured, what could reject the claim, and what decision the evidence actually supports. (See Table B.4 for how to categorize the evidence made available).
B.7 Paper-to-Loop Exercise
To use the card in a reading group or class, choose a paper and fill in the fields before discussing the claimed result. The exercise usually reveals one of three things.
First, some papers make the loop explicit. They name the task, action space, environment, feedback budget, and evidence ledger. These papers are easier to explain and compare because their claims are grounded in visible state, legal actions, feedback budget, evidence, rejection authority, and decision ownership.
Second, some papers have strong technical results but implicit loop structure. They may report a better Pareto point or speedup without exposing enough about the search budget, failed candidates, tool settings, or rejection authority. The card helps readers separate a useful artifact from a fully auditable loop.
Third, some papers make broad claims from narrow evidence. A method may work for one benchmark, simulator, or proxy metric but be presented as a general design method. The card reveals the mismatch between claim scope and evidence scope.
A simple reading-group exercise is to assign two readers the same paper. One summarizes the paper conventionally. The other fills in the design-loop card. The group then discusses what the card exposed that the summary hid.
B.8 Lighthouse Card Sketch
Table B.5 gives a deliberately incomplete card sketch for the lighthouse prompt. It is not a finished design. It shows how a short prompt becomes a loop that must be specified before any result can be trusted.
| Field | Sketch |
|---|---|
| Intent | Improve efficiency for real-time mobile XR under strict power, memory, software, reliability, and deployment constraints. |
| Task | Bounded design-space exploration for a RISC-V-based compute subsystem, initially scoped to accelerator/memory organization for an XRBench-class workload slice. |
| Design space | RISC-V ISA options, vector width, memory hierarchy, accelerator coupling, compiler/runtime path, and voltage/frequency assumptions; technology, package, and deployment policy changes are outside this first turn. |
| Representation | Workload traces, architecture description, configurable memory/compute parameters, compiler assumptions, power model, latency targets, and uncertainty about workload drift. |
| Environment | Simulator or cost model plus workload harness, with actions such as changing vector width, memory hierarchy parameters, accelerator tiling, voltage/frequency assumptions, or dataflow choices. |
| Method role | For one loop turn, choose one bounded role, such as generating legal candidates, searching exposed parameters, predicting proxy outcomes, critiquing invalid assumptions, or summarizing evidence for human review. |
| Feedback budget | Many cheap proxy evaluations, fewer simulator evaluations, and only a small number of high-fidelity checks before human review. |
| Evidence | Pareto comparison over latency, energy, area proxy, memory traffic, software compatibility, and sensitivity to workload assumptions. |
| Negative traces | Configurations that violate the 3 W target, miss real-time latency, exceed memory bandwidth, require unsupported software, or fail at higher fidelity. |
| Rejection authority | Constraint checker, simulator failure, CDC/RDC violation, routing congestion, power/thermal limit, workload quality-of-service violation, compiler/runtime incompatibility, framework dispatch failure, or architect review. |
| Commitment boundary / would overturn | Advance only to a stronger modeling or RTL-study question; overturn with higher-fidelity latency, power, software-path, or workload-coverage evidence. |
| Human decision | Decide whether the candidate merits deeper modeling, different representation, stronger fidelity, or rejection. |
This sketch also shows why the book does not treat the lighthouse prompt as a one-shot generation request. The prompt is useful because it exposes the state that must be represented, not because it eliminates the loop.
B.9 Common Failure Modes
The card is most useful when it reveals failures early. Common failure modes include:
- Missing evidence: the claim is plausible, but the supporting measurement is absent, low fidelity, or unrelated to the decision.
- No negative traces: the loop records only successful candidates, so future methods repeat known failures.
- Hidden simulator state: defaults, flags, seeds, workload versions, and tool revisions are not recorded.
- Proxy mismatch: the method improves a metric that does not track the architectural objective.
- Invalid action space: the generative method can propose configurations that cannot compile, simulate, synthesize, meet timing, or satisfy constraints.
- Unsupported autonomy: the method is allowed to make decisions whose commitment level exceeds the evidence available.
- No rejection authority: there is no explicit mechanism that can reject a plausible but wrong result.
- Unowned commitment: the loop obscures who accepts risk and who remains accountable for the final decision.
These are not only documentation failures. They are design-loop failures. A loop that hides negative traces, invalid actions, or rejection authority is hard to improve because it cannot distinguish a weak candidate from a weak process.
B.10 Blank Template
Table B.6 is the one-page blank form. It is sufficient for a first pass because it forces the loop owner to name the task, design space, evidence, rejection path, commitment boundary, and decision owner before running the loop.
| Field | Entry |
|---|---|
| Intent | |
| Task | (What is the architectural goal? e.g., generation, verification) |
| Design space | |
| Representation | (Including intermediate representation level, e.g., MLIR, gate-level) |
| Environment | |
| Method role | (How is the algorithm specifically used? e.g., predict, critique) |
| Feedback budget | |
| Evidence | |
| Negative traces | |
| Rejection authority | |
| Commitment boundary / would overturn | |
| Human decision |
Field note: Practical workflow tips for solo researchers
For Negative traces, simply saving a local CSV of failed parameters and the tool’s error code is sufficient to prove you explored the space. For Rejection authority, a “simulator segfault” or “failed to compile” is a perfectly valid gate to record. The goal is clarity and intellectual honesty, not compliance paperwork.
After filling in the card, run the final review gate.
Architect’s checkpoint
Before treating a filled card as a credible loop, ask:
- Is the task bounded enough that the loop can be evaluated?
- Is the representation sufficient for the actions the method is allowed to take?
- Is the feedback budget realistic for the method and claim?
- Does the evidence match the commitment level?
- What can reject the result, and who owns the final decision?
If those questions cannot be answered, the project may still be promising, but it is not yet a credible Architecture 2.0 loop.