3 Architectural Claims and Design Loops
“All models are wrong, but some are useful.”
— George E. P. Box, Robustness in the Strategy of Scientific Model Building (1979)
Author’s Note: George E. P. Box, a British statistician who made major contributions to time-series analysis, famously noted that while all models are flawed, the good ones are practically useful. For us, this perfectly captures the role of proxies and surrogate models. While fast proxies are inherently inaccurate, they are absolutely essential for accelerating an AI agent’s search.
The crux
Computer architecture has always depended on disciplined abstraction. An architect rarely reasons directly from every transistor to every application behavior. The field instead builds models, simulators, workload characterizations, cost estimates, design rules, and review practices that make large design spaces tractable. That quantitative tradition is central to modern architecture practice (Hennessy and Patterson 2017). It also explains why Architecture 2.0 should not be framed as a sudden break from the past. The continuity is the existence of the loop; the field has always designed through loops of abstraction, measurement, feedback, and judgment. The discontinuity is its automation. Historically, humans drove this loop; in Architecture 2.0, AI systems can execute steps of it programmatically, acting inside the loop while the architect owns the commitment. That automation is why the failure mode changes from slow human drift to high-velocity, catastrophic failure when the verification and rejection mechanisms collapse.
What becomes first-class alongside the artifact is the loop that produces and tests claims about it. In Architecture 1.0, the architect uses tools to design artifacts: an ISA extension, a cache hierarchy, an accelerator, a memory system, a chiplet partition, a compiler policy, or a system configuration. But an artifact matters because it supports an architectural claim. These claims collapse into two orthogonal system axes: Pareto efficiency (optimizing latency, energy, correctness, and useful work along an existing frontier) and boundary expansion (shifting the frontier to make previously impossible systems possible under a workload and set of constraints). In Architecture 2.0, the architect must also design the loop that produces, tests, rejects, and revises those claims. The loop itself must be formalized as a five-part execution state: what state it saw, what actions it allowed, what alternatives it rejected, what evidence supports the result, and who owns the commitment if the claim is wrong (Janapa Reddi and Yazdanbakhsh 2025). Without those pieces, an AI system may still produce plausible text, code, or configurations, but it is not participating in architecture work in a way the field should trust.
Making a design process explicit is what mature engineering fields do once the cost of an undetected error grows. Aviation did not become safe by trusting more skilled pilots; it formalized the process with checklists, assurance cases (Kelly and Weaver 2004), and certification standards that make the evidence for a safety claim auditable. Software operations did not become reliable by hiring more careful engineers; DevOps and site-reliability engineering, disciplines focused on automating and monitoring software deployment, made deployment, monitoring, and rollback explicit, with error budgets and runbooks that state what evidence justifies a change (Beyer et al. 2016). The common pattern is a move from individual judgment to a represented process with explicit evidence and rejection rules. Architecture 2.0 makes the same move for computing-system design. The alternative is not creative freedom; it is an ad hoc loop whose assumptions, rejected alternatives, and evidence live only in people’s heads, which is exactly the state that stops scaling when the design space and the verification burden grow together.
This chapter gives the reusable language for that shift. The goal is not to classify every paper or tool. A taxonomy of current systems will age quickly. The more durable contribution is a consistent way to state the architectural claim being made, together with an ontology of the entities and relationships that must exist before AI systems can act inside the architecture design loop credibly.
The ontology has to earn its space by being useful. A researcher should be able to cite it when explaining the structure of an Architecture 2.0 contribution. A reviewer should be able to use it to ask what state, action, feedback, evidence, and rejection authority a paper exposes. A tool builder should be able to use it as a checklist for a harness or environment. An author should be able to use it to state the claim and loop for a concrete design problem. If the ontology cannot support those uses, it is only vocabulary. Its test is whether it exposes enough state for a generative method to act within bounds and enough evidence for a human architect to reject or commit the result.
The deeper reason we need such an ontology is that architecture reasoning still lacks a durable structured layer above RTL. Below RTL, design flows already have artifacts that tools can parse, transform, reject, and sign off. Above RTL, much of the reasoning that decides what should be built still lives in whiteboards, spreadsheets, scripts, slides, review memories, and natural-language specs. The design-loop card, loop contract, environment contract (Chapter 5), and evidence ledger are not paperwork around the real work. They are candidate structured abstractions for the part of architecture practice that has not yet been made inspectable.
The hierarchy in this chapter is simple. The artifact is what may eventually be built. The architectural claim is what a reviewer accepts or rejects about that artifact. The design loop is the process that tests the claim. The ontology names the state and relationships the loop must expose. The design-loop card is the compact record that makes the claim and loop reviewable. The loop contract from Chapter 1 is the same object seen before action: it states the task, state, actions, feedback, evidence standard, and decision owner the loop promises to expose, and the card records how the loop kept that promise.
Figure 3.1 places that layer between tacit reasoning and implementation flows. Its purpose is not to add ceremony. It is to make the part of architecture reasoning above RTL explicit enough that tools, automated participants, reviewers, and architects can all see the same loop state.
What this chapter gives you
After this chapter you can turn an AI prompt, paper, tool, or project into a reviewable design-loop card. That means you can:
- write an AI-generated architectural claim as a reviewable object: workload, baseline, design space, objectives, constraints, evidence, rejection authority, commitment boundary, and human decision;
- audit an AI-assisted paper, tool, or project by naming the loop state, legal actions, environment feedback, evidence ledger, rejection and escalation rules, and human-owned commitment it exposes;
- explain how artifact, claim, loop, ontology, checklist, and design-loop card fit together in an AI-assisted workflow;
- distinguish an ontology from a taxonomy and say why ontology comes first;
- judge how much autonomy an AI-driven loop has actually earned.
3.1 The Architectural Claim Is the Unit of Review
Asking whether a generative model1 can design hardware is too coarse a framing. The more architecture-native approach focuses on identifying the specific claim being made and determining the evidence required to make that claim credible. Architects rarely accept an artifact by itself. They accept or reject a claim about that artifact relative to a workload, baseline, design space, objectives, constraints, and evidence. The definition below names that review object so the rest of the chapter can ask what state a loop must carry before an AI-assisted result can be accepted or rejected.
1 A class of AI models designed to generate new data, such as text or configurations, that resembles its training data.
Architectural claim. An architectural claim is a statement that a proposed artifact, method, or loop improves, preserves, or explains a hardware/software behavior for a specified workload or scenario relative to a baseline, under explicit objectives, constraints, evidence, rejection conditions, and decision authority.
The clause “for a specified workload or scenario” is doing real work, and a neighboring field paid to learn it.
Field note: Valid for the last rocket, not this one
Takeaway. A claim carries the scenario it was verified under. Reusing a cheap, trusted component still means re-checking its evidence against the new workload, because the claim, not the code, is what has to hold.
A plain-language version might say, this candidate improves useful work for this workload, relative to this baseline, inside this design space, under these constraints, using this evidence, and with this rejection authority. A compact way to write the same review object is \[ \mathcal{C} = \langle W, B, \mathcal{D}, \mathbf{J}, \mathcal{K}, E, R, M, H \rangle . \] Here, \(W\) is the workload or scenario, \(B\) is the baseline, \(\mathcal{D}\) is the legal design space, \(\mathbf{J}\) is the objective vector, \(\mathcal{K}\) is the constraint set, \(E\) is the evidence, \(R\) is the rejection authority, \(M\) is the commitment boundary, and \(H\) is the human or organizational decision authority. This tuple is the claim slice of the design-loop card, not a second schema. The notation prevents a generated artifact from masquerading as an architectural result before the comparison, constraints, evidence, rejection authority, and commitment boundary are visible.
In card terms, \(W\) and \(B\) anchor the task and evidence comparison, \(\mathcal{D}\) is the design space, \(\mathbf{J}\) and \(\mathcal{K}\) belong in the representation and evidence standard, \(E\) is the evidence ledger, \(R\) is the rejection authority, \(M\) is the commitment boundary, and \(H\) is the human decision owner.
Table 3.1 turns the tuple into a reader checklist for the lighthouse prompt. The important point is that the prompt’s compact wording hides a large amount of architectural state. A credible answer must expose that state before the reader can judge whether the result deserves trust.
| Claim field | Reader question | Lighthouse instance |
|---|---|---|
| Workload or scenario | What behavior is the design supposed to serve? | XRBench-class real-time mobile XR workloads, with latency, sensing, graphics, and interaction requirements. |
| Baseline | Compared to what architecture, software stack, or prior result? | A scalar CPU-only baseline, a vector-capable CPU, an accelerator baseline, or an existing mobile XR subsystem. |
| Design space | What choices are legal, and which regions are invalid? | RISC-V ISA options, vector width, CPU/accelerator partitioning, memory hierarchy, clocking, compiler/runtime path, and tool-flow limits. |
| Objective vector | What counts as improvement, and what tradeoffs matter? | Throughput, tail latency, energy, area, programmability, verification burden, and evidence cost under the 3 W target. |
| Constraints | What cannot be violated even if a metric improves? | ISA compatibility, correctness, thermal limits, process assumptions, package limits, software compatibility, and 3 nm-class low-power envelope. |
| Evidence | What supports the claim at the required commitment level? | Workload traces, simulations, power model, sensitivity checks, rejected candidates, tool logs, and comparison against baselines. |
| Rejection authority | What observation, tool, review, or rule can invalidate or weaken the result? | Missed latency target, power envelope violation, invalid RTL/configuration, compiler failure, simulator mismatch, or weak coverage. |
| Commitment boundary | What claim is the evidence strong enough to support, and what remains uncommitted? | Exploration, RTL study, implementation, deployment, or silicon-facing commitment, with stronger evidence required at each boundary. |
| Human decision | Who can accept, revise, escalate, or commit the claim? | The architect or review process that owns assumptions, evidence thresholds, risk, and final commitment. |
This schema also clarifies what AI systems are being asked to do. Generation can propose artifacts inside \(\mathcal{D}\). Prediction can estimate components of \(\mathbf{J}\) before expensive feedback. Optimization can search tradeoffs under \(\mathcal{K}\). Critique and verification can apply \(R\). The architectural result is not any one of those operations. It is the claim that survives the loop.
Design principle: State the claim as a review object
3.2 The Design Loop Is the Unit of Analysis
Once the claim is explicit, the architect must define the design loop that can test it. That shift matters because architecture work is not a single act of generation. It is a repeated process of framing a problem, choosing abstractions, exploring alternatives, measuring candidates, rejecting weak results, revising assumptions, and deciding when evidence is strong enough to commit.
Architecture design loop. An architecture design loop is the repeated process that carries architecture state through bounded actions, feedback, evidence, rejection, revision, and architect-owned commitment until it produces an artifact or a revised loop.
For Architecture 2.0, this is the loop an AI system enters. If its state, actions, feedback, and stopping rules are implicit, the system is only producing outputs, not participating credibly in architecture work.
For the lighthouse prompt, the distinction is immediate. A request for a low-power, 64-bit RISC-V-based compute subsystem, using the open standard instruction set architecture, for XRBench-class mobile XR, a mixed-reality workload suite, under a 3 W, 3 nm-class low-power mobile envelope sounds compact. But the prompt does not define the design loop. It does not say which workload traces are authoritative, which vector operations matter, which memory hierarchy is admissible, which software stack must run, which simulator is trusted, which power model applies, which process assumptions are available, which alternatives must be considered, or what evidence is enough to reject a candidate. These are not details to add after a generative method responds. They are the architecture problem.
In practice, the loop has at least the following elements. It has a state: what is known about the workload, design, tools, constraints, and prior evidence. It has actions: what can be changed, generated, queried, tuned, or tested. It has observations: what the loop can see after an action. It has objectives and constraints: what counts as progress and what is not allowed. It has a feedback path: the measurement, simulation, synthesis report, trace, review, or deployment signal returned by the environment. It has stopping and escalation rules. It has decisions: accept, reject, revise, or request stronger evidence. It has artifacts: reports, configurations, design descriptions, plots, RTL fragments, benchmarks, or implementation plans.
A compact way to write the loop is \[ s_{t+1} = \operatorname{Update}(s_t, a_t, o_t, e_t, d_t). \] Here, \(s_t\) is the represented architecture state, \(a_t\) is the bounded action taken by the loop, \(o_t\) is the observation returned by the environment, \(e_t\) is the evidence ledger entry that makes the observation auditable, and \(d_t\) is the human or policy decision to accept, reject, revise, or escalate. The equation is not claiming that every architecture loop is a Markov decision process. It is a bookkeeping discipline. If a loop cannot say how actions, feedback, evidence, and decisions update state, then it is not yet represented well enough for credible AI-mediated architecture work. Figure 3.2 visualizes how these pieces form a unified design loop.
Markov decision process (MDP): A mathematical framework for modeling decision-making where outcomes are partly random and partly under the control of a decision maker; it forms the foundation of reinforcement learning.
Architecture 2.0 uses that loop as the unit of analysis. A model is one participant in the loop. It may generate candidates, summarize evidence, predict outcomes, call tools, critique assumptions, or coordinate subtasks. But the credibility of the result comes from the whole loop, not from the model in isolation.
The cross-layer reach of architectural decisions is another reason the loop, not the model, is the unit of analysis. An architecture decision moves through the whole stack at once. A choice that is legal at the microarchitecture level can still force a new compiler pass above it or trip a timing and routing bottleneck below it. The model that proposes the choice sees only its own layer, while the consequences ripple up into software and down into physical design. Representing those layers as intertwined, rather than as isolated abstractions, is part of what the loop has to carry, because that cross-layer state is what lets a reviewer reject a candidate that looks valid in one layer but breaks another the model never saw.
3.3 Design Spaces Make Claims Meaningful
An architectural claim is meaningful only relative to a design space. A system that reports “the best” candidate without exposing the alternatives, invalid regions, baseline, and tradeoffs has not made an architecture result easy to review. It has hidden the comparison that gives the result meaning.
In architecture, the design space is not the set of all strings a model might emit. It is a constrained set of legal choices: \[ \mathcal{D} = \{x \in X \mid x \text{ is valid under the task, tool chain, and constraints}\}. \] Here, \(X\) is that unconstrained space of candidate artifacts, everything a method could emit. The validity conditions may include ISA compatibility, memory semantics, software support, timing assumptions, power limits, package constraints, verification requirements, and deployment policy. A candidate outside \(\mathcal{D}\) is not a bold design. It is an invalid action unless the loop explicitly revises the design space and records why.
The lighthouse prompt makes this concrete. A 64-bit RISC-V-based mobile XR subsystem might vary vector width, cache and memory hierarchy, accelerator partitioning, dataflow, clocking, voltage assumptions, compiler/runtime support, and verification scope. Some choices are legal but unattractive. Some are attractive under a proxy but fail at higher fidelity. Some violate the power envelope, process assumptions, software contract, or workload coverage. An Architecture 2.0 loop must represent those distinctions. Otherwise it cannot know whether it is improving a design or exploiting a hole in the problem statement.
The design space is also where multiobjective efficiency enters the ontology. The objective is rarely a scalar reward. It is a vector of performance, energy, latency, area, reliability, programmability, verification burden, cost, and evidence requirements. A design-space report is therefore an evidence object. It should show what was explored, what was rejected, what tradeoffs remain, and what the architect must still decide.
3.4 The Architecture 2.0 Ontology
A method label is not enough to review an architecture claim. A paper can say it uses an LLM, reinforcement learning, Bayesian optimization, or a surrogate model and still leave the important state invisible: what task was bounded, what actions were legal, what feedback was used, what failed, and who accepted the commitment. A taxonomy groups things. It can list tasks, methods, benchmarks, tools, system architectures, or evaluation settings. Taxonomies are useful, and this chapter will use them where they help a reader make decisions. But a taxonomy is not enough for a field that is still moving. Model interfaces will change. Method harnesses will change. Benchmarks will change. Electronic Design Automation (EDA) flows and simulator stacks will change. If the book is organized only around today’s artifacts, it will age with them.
Bayesian optimization: A strategy for optimizing expensive black-box functions, where each candidate evaluation (such as a cycle-accurate simulation) is costly.
Architecture 2.0 ontology. The Architecture 2.0 ontology names the entities and relationships that must exist for AI-mediated architecture work to be represented, acted on, evaluated, rejected, and committed by a human architect.
Two of those entities matter enough to name now, because the rest of the book leans on them: the world model the loop reasons with, and the evidence ledger it reasons from.
World model. A world model is the loop’s belief about how architecture actions change outcomes, whether that belief lives in a simulator, a learned surrogate, a cost model, or design rules. This chapter uses the term only at that working level; Chapter 4 gives the canonical definition and shows what such a model must encode, scope, and keep credible.
Both entities are critical, but while the world model focuses on prediction and belief, the evidence ledger serves as the historical record of truth.
Evidence ledger. An evidence ledger is the durable record that ties a candidate to the feedback that evaluated it, the constraints it faced, and the decision that accepted or rejected it. To flatten the learning curve, consider these terms as the automated equivalent of a scientific peer-review loop or a Design Space Exploration (DSE) review board: a rejection gate is analogous to a reviewer rejecting a paper for a methodological flaw, and an evidence ledger is a multidimensional record capturing the Pareto tradeoffs and justifying exactly why alternative architectures were rejected during exploration.
Read the chapter as a chain of loop obligations. The claim states what is at stake; the ontology names the state, action, feedback, evidence, and decision relationships; the checklist tests whether an automated system can act safely; and the design-loop card records the contract for review. Within this framework, architecture environments act as the tool-connected settings that define legal actions, observable feedback, costs, failure modes, provenance, and invalid-action behavior; Chapter 5 gives the canonical definition.
Zooming out, the ontology establishes the fundamental requirements for AI-mediated architecture work to be credible by defining which entities must exist and how they must relate. The important pieces are not only the nouns. They are the relationships. Intent constrains tasks. Tasks determine what must be represented. Representation limits what the loop can observe and modify. The world model encodes beliefs about how actions change outcomes. Tools and environments define valid actions and measurable feedback. Methods are selected for the task, representation, and feedback budget. Feedback becomes evidence only when fidelity, provenance, uncertainty, and relevance are understood. Human decisions accept, reject, revise, or escalate the result. This is why ontology should precede taxonomy. Rather than immediately classifying whether a paper uses an LLM2, reinforcement learning3, Bayesian optimization, a surrogate model, or a simulator wrapper, the analysis must first identify the exposed loop. The evaluator must determine the task, the represented state, the legal actions, the environment returning feedback, the feedback budget, the supporting evidence, the rejection conditions, and the remaining architectural decisions. Once those components are clear, a taxonomy of methods becomes useful. Before that, method labels can hide more than they reveal.
2 Large Language Model, a neural network trained on vast amounts of text to understand and generate human-like language.
3 A machine learning training method based on rewarding desired behaviors and punishing negative ones.
4 A statistical model trained to predict the next word or token in a sequence, forming the foundation of modern AI text generation.
The practical implication is not to build a chip-specific language model4 first. A field becomes AI-addressable only when its objects of work, legal actions, feedback, evidence, rejection rules, and commitment boundaries are represented well enough for methods to act and for experts to judge. For architecture, those objects are not only papers or text. They include workloads, design states, tool configurations, invalid actions, failure records, fidelity levels, and commitment decisions. That is why this book starts with an ontology of the design loop rather than a catalog of current models.
3.5 The Compact Framework
Figure 3.3 asks what has to become explicit before an AI method can participate in architecture work. Read it left to right as a chain of obligations: intent bounds the task, representation and world model bound what can be known, architecture environments return feedback, and the evidence ledger plus human decision determine commitment.
The change is that the loop, not the model, becomes the review object; missing links are reasons to withhold commitment rather than details to fill in later.
For practical use, this book compresses the ontology into five framework elements. They group the same twelve fields the design-loop card records: intent, task, design space, representation (which carries the world model), environment, method role, feedback budget, evidence, negative traces, rejection authority, commitment boundary, and human decision. These elements name what a loop is made of, distinct from the five-part execution state of Chapter 1, which names what one turn records. There is one artifact, the twelve-field design-loop card; every other list in this book, the five framework elements, the five-part execution state, the nine-field claim tuple, and the seven-question loop contract, is a view of it (Appendix B), not a competing schema.
First, there is task, intent, and design space. Intent states what the architect or organization is trying to achieve, what constraints matter, what risks are acceptable, and what cost of failure is tolerable. The task is the bounded work unit that can be assigned, repeated, measured, or decomposed. The design space states which choices are legal, which regions are invalid, and which tradeoffs the loop is allowed to explore.
Second, there is representation and world model. A representation is the encoded design state: specifications, workload traces, architecture descriptions, graphs, RTL, compiler IR, simulator configurations, EDA reports, benchmark metadata, tool logs, design documents, or review notes. A world model is the loop’s belief about how architecture actions change outcomes. It may be explicit, learned, simulator-backed, symbolic, statistical, or partly implicit in tools.
Third, there is the architecture environment. Tools become environments when they define actions, observations, constraints, costs, rewards or objectives, latency, provenance, and invalid-action behavior. An architecture simulator is not merely a measurement device in such a loop. It is part of the state transition and feedback system.
Fourth, there are method roles. The credible unit is rarely a single model. It is a composition of roles: generator, predictor, optimizer, searcher, critic, verifier, planner, tool caller, and coordinator. Some roles may be played by language models, some by search algorithms, some by learned surrogates, some by scripts, some by formal tools, and some by humans.
Fifth, there is feedback, evidence ledger, and human decision. Feedback is any signal returned by the loop. Evidence becomes useful when it is tied to provenance, fidelity, assumptions, uncertainty, coverage, rejection, and a decision. The decision is where the architect accepts, rejects, revises, or escalates the result.
Table 3.2 gives the checklist version. It is the question a reader should be able to ask of a paper, benchmark, tool, or internal loop before trusting an Architecture 2.0 claim.
| Framework piece | Reader question | Lighthouse instance |
|---|---|---|
| Task, intent, and design space | What architectural objective is being pursued, under what constraints, risk, and legal choices? | Improve mobile XR efficiency within a 3 W, 3 nm-class low-power mobile envelope while exploring legal RISC-V, vector, memory, accelerator, and software-stack choices. |
| Representation and world model | What state is encoded, and what does the loop believe about how actions change outcomes? | Workload traces, parameters, compiler assumptions, power model, memory behavior, and constraints. |
| Architecture environment | What actions are legal, what feedback is returned, and what failures are observable? | Simulator, cost model, workload harness, and invalid-configuration checks. |
| Method roles | Which roles generate, predict, search, critique, verify, call tools, or coordinate? | Candidate generator, surrogate or search method, verifier, evidence writer, coordinator, and human reviewer. |
| Feedback, evidence ledger, and human decision | What supports the claim, what can reject it, and what remains an architect-owned commitment? | Pareto evidence, sensitivity checks, failure records, rejection authority, and final architectural judgment. |
This checklist is intentionally stricter than many current demonstrations. A system can be a useful demonstration while still not being a credible Architecture 2.0 loop; unanswered rows identify where a method lacks action bounds, evidence standards, rejection authority, or a human commit gate.
The practical artifact is the design-loop card introduced later in this chapter and expanded in Appendix B. The card is not a new concept on top of the framework. It is the same framework compressed into a reusable review object, with the five framework pieces serving as grouped views of the card fields. Appendix B also gives the card a machine-checkable schema and four conformance levels, from context-only to an independently rejectable loop, so “we used the card” becomes a claim a tool and a reviewer can check rather than a gesture.
Beyond structuring the review process, the checklist also keeps the vocabulary from drifting into generic AI language. Words such as state, action, observation, environment, reward, and critic are useful only after they are translated into architecture objects. Table 3.3 gives the translation rule. If a paper says an automated method acts in an environment, the reader should be able to name the architecture state it reads, the action it is allowed to take, the tool feedback it observes, and the authority that can reject the result.
| Generic term | Architecture translation | Example artifacts or observations | What can reject it |
|---|---|---|---|
| State | Workload, design, software, tool, constraint, and evidence state. | Traces, configs, RTL, compiler IR, simulator stats, EDA reports, review notes. | Missing provenance or hidden assumptions. |
| Action | Legal architecture, compiler, runtime, or tool-flow change. | Change cache size, vector width, mapping, schedule, constraint, partition, or test. | Invalid parameter, noncompilable code, nonsynthesizable RTL, or policy violation. |
| Observation | Feedback returned by a tool, benchmark, review, or deployment path. | Latency, energy, area, timing, congestion, warnings, failures, telemetry. | Wrong workload, stale tool version, simulator mismatch, or weak fidelity. |
| Environment | Tool-connected harness that defines legal actions and feedback. | Simulator wrapper, compiler pipeline, RTL flow, EDA stage, benchmark harness. | Unmodeled constraints, nondeterminism, incomplete logging, or invalid actions. |
| Objective | Explicit architecture tradeoff, not a generic reward. | Performance, power, and area; tail latency; power envelope; reliability; carbon; cost; evidence budget. | Proxy gaming, lost Pareto tradeoff, or missing human decision rule. |
| Critic/verifier | Independent check that can challenge or reject a claim. | Tests, formal checks, baseline replay, cross-simulator comparison, signoff review. | Unsupported claim, failed check, counterexample, or insufficient evidence. |
The five pieces are not a pipeline that runs once. They form a loop. A failed simulation may revise the representation. A weak benchmark result may revise the task. A provenance problem may invalidate the evidence. A human rejection may change the environment, not merely reject a candidate. Architecture 2.0 is therefore not only about adding AI into existing work. It is about designing the loop so that AI participation is bounded, observable, and accountable.
Architect’s checkpoint: The Loop Revision Gate
3.6 Autonomy Is Earned, Not Declared
The first stress test for the framework is autonomy. Evaluating Architecture 2.0 systems simply as autonomous or non-autonomous lacks sufficient nuance. Autonomy is not a personality trait of a model. It is a property of a bounded loop, and broader autonomy must be earned by stronger evidence.
Figure 3.4 shows four stages of allowed loop authority. The point is not that the automated system gradually replaces the human architect. The point is that each stage grants the AI participant a larger role only when the loop also defines the allowed action space, feedback budget, evidence standard, rollback or escalation path, and architect-owned commitment boundary. The human and the automated system are both visible because Architecture 2.0 is a shared loop with asymmetric responsibility. The AI participant may act inside the loop, but the architect owns the boundary conditions. The figure draws one automated participant to keep the contract legible. The same autonomy test applies when the implementation uses several AI-assisted systems. Every generated proposal, tool call, critique, repair, verification, or coordination step must still be bound to the loop’s state, allowed actions, evidence obligations, rejection path, and architect-owned commitment boundary.
At the lowest level, AI systems support assisted exploration. They summarize prior work, draft experiment scripts, explain tool output, suggest candidate parameters, or help prepare design reviews. The architect still directly drives the loop.
At the next level, AI systems provide coordinated intelligence. A model or agent can call tools, track state, propose alternatives, compare candidates, and route work among specialized components. The loop becomes more explicit, but human approval remains frequent.
At a higher level, semiautonomous human-in-the-loop systems can perform bounded subtasks: search a design space, tune a configuration, generate a benchmark variant, build a surrogate, or identify invalid candidates. These systems need clear action spaces, feedback budgets, logging, and rejection authority.
The strongest level is bounded autonomous ecosystems. Here, agents can adapt parts of the loop, choose among methods, allocate feedback budget, and revise representations within a constrained domain. Even then, autonomy is bounded by commitment cost, evidence standards, and human accountability.
The stage of autonomy depends on architecture-specific risk. A compiler flag that can be rolled back after telemetry is not the same as an RTL change that affects timing closure. A simulator configuration is not the same as a mask-level choice. A benchmark-generation loop is not the same as a signoff loop. The more irreversible the action, the stronger the evidence and rejection authority must be.
Architect’s checkpoint
- the allowed action space, and which actions are illegal;
- the feedback budget and evidence standard the stage requires;
- the rollback or escalation path when a candidate fails;
- the rejection authority that can still say no;
- the architect-owned commitment boundary the automated participant may not cross.
If any of these is missing, the autonomy is declared, not earned.
With that stress test in place, the rest of the chapter walks through the framework pieces in order.
3.7 Intent Defines the Task
Architecture tasks do not appear naturally. They are carved out of messy intent. A product goal such as “improve mobile XR efficiency” is not yet a task. It must be translated into bounded work: characterize the workload, choose a candidate ISA extension, compare vector and accelerator organizations, estimate memory traffic, build a power model, explore clock and voltage points, evaluate compiler support, or prepare a design-space report.
This translation is architectural judgment. It decides what is in scope, what is out of scope, what can be measured, and what cost of being wrong is acceptable. It also decides how ambitious an AI-assisted loop can be. A loop that critiques a design report needs different state and evidence than a loop that edits RTL. A loop that predicts energy needs different calibration than a loop that generates workload questions. A loop that searches an accelerator tiling space needs different invalid-action semantics than a loop that proposes chiplet partitionings.
To ground this translation of intent into tasks, this book treats several task families as recurring: design-space exploration, workload characterization, generation, prediction, optimization, critique, verification, and benchmark construction. The list is not meant to be exhaustive. Its purpose is to remind the reader that “use AI” is never a task. The task must be bounded before the method can be chosen, and each family becomes an Architecture 2.0 task only after its action space, feedback budget, evidence standard, rejection rule, and owner are named. These are not content categories; they are recurring loop shapes that differ in represented state, legal actions, feedback cost, invalid-action semantics, escalation rules, and ownership.
3.8 Representations and World Models
Representation is the first hard problem because it determines what the loop can see. Architecture knowledge lives in many forms: natural-language specifications, ISA documents, traces, graphs, simulator configurations, RTL, compiler IR, EDA reports, design reviews, benchmark metadata, spreadsheets, scripts, and plots. Much of the most important state is implicit. It may live in default flags, workload selection, tuned scripts, undocumented assumptions, or the memory of the architect who knows why one experiment was abandoned.
AI systems are brittle around hidden state. If a constraint is not represented, the automated optimizer may violate it. If a simulator option is undocumented, a result may not be replayable. If rejected candidates are missing, a method may relearn known failures. If benchmark provenance is unclear, a comparison may be misleading.
A world model is different from a representation. The representation says what is encoded. The world model says what the loop believes will happen when an action is taken. A simulator embodies one kind of world model. A learned surrogate embodies another. A set of design rules, expert heuristics, or calibrated equations can also function as a world model. None is automatically true. Each has a scope, fidelity, uncertainty, and failure mode.
Distinguishing between representations and world models helps clarify what we are testing. For example, QuArch, an architecture-centric benchmark dataset, is useful as a boundary test. It can assess whether a model knows architecture concepts, but not whether an automated participant has the represented workload, tool, action, evidence, and rejection state needed to synthesize or reject a candidate (Prakash et al. 2025). That distinction is the bridge to Chapter 4.
3.9 Tools Become Environments
Architecture tools become Architecture 2.0 environments when they define how an automated participant or method can act. A simulator, compiler, profiler, RTL tool, EDA flow, runtime system, or fleet telemetry pipeline does more than return a number. It defines which actions are legal, how long feedback takes, what observations are available, what costs are incurred, what provenance is recorded, and what failure means.
Figure 3.5 turns the distinction into a visual test. A wrapper connects a method to a tool, while an environment exposes the contract that lets the loop audit action, feedback, failure, and rejection.
This is why wrapping tools is not mere engineering plumbing. The wrapper defines the research question. If the action space permits invalid configurations, the loop needs invalid-action semantics. If the observation schema hides memory traffic, the loop cannot reason about data movement. If the reward combines performance and energy without preserving the separate components, the method may optimize a proxy that the architect cannot audit. If the environment does not log tool versions, seeds, workload revisions, and failed runs, the feedback may not become evidence.
Building on this need for principled tool wrappers, ArchGym, an open-source evaluation environment, is an important example because it treats the connection between search algorithms and architecture simulators as a first-class interface (Krishnan et al. 2023). Its durable lesson is that a simulator wrapper becomes architectural only when it exposes legal actions, invalid-action semantics, feedback cost, provenance, comparable baselines, and rejection conditions. Chapter 5 expands this point and asks what such environments can and cannot prove.
3.10 Agents and Methods Have Roles in a Compound System
The word “agent” can hide too much. In credible Architecture 2.0 systems, there may be several roles rather than one monolithic actor. A generator proposes candidates. A predictor estimates behavior before expensive evaluation. An optimizer chooses what to try next. A critic challenges assumptions. A verifier checks constraints. A planner decomposes work. A tool caller executes actions. A coordinator tracks state, provenance, and dependencies. A human architect sets intent and decides what evidence is enough.
These roles can be implemented by different mechanisms. A language model may draft an architecture description or critique a result. Bayesian optimization may choose the next candidate. Reinforcement learning may learn a policy for a bounded environment. A surrogate model may estimate energy or latency. A formal tool may reject invalid behavior. A script may maintain the experiment ledger. The critical evaluation metric is not which method is fashionable, but rather the specific role the method plays in the loop, the state it consumes, the action it takes, the feedback it receives, and the evidence that can reject its output.
This role-based view is also more faithful to architecture practice. Even before AI systems entered the discussion, architects already worked through compound systems: simulators, models, scripts, profilers, spreadsheets, benchmarks, reviews, and signoff processes. Architecture 2.0 makes that compound structure explicit and asks where AI systems can participate without erasing accountability.
3.11 Feedback Becomes Evidence
Feedback is not evidence by default. A simulator result, benchmark score, synthesis report, generated explanation, or model confidence value is feedback. It becomes evidence only when it is tied to a claim, a decision, and a provenance trail.
Lighthouse prompt: A 3 W claim needs evidence, not a number
In the Lighthouse prompt. If a generative method claims that a “vector-capable CPU, accelerator, or SoC block” for the “XRBench-class real-time mobile XR workload” meets the “3 W TDP target in a 3 nm-class LP mobile process,” the loop must record the workload, input distribution, memory traffic, power model, process assumptions, compiled software stack, rejected alternatives, uncertainty, and rejection rule.
Evidence rule. The same power number has different authority as a proxy estimate, cycle-level simulation, synthesis result, post-layout estimate, or silicon measurement. A proxy estimate may support exploration; post-layout or silicon evidence is needed before stronger implementation or deployment commitments.
Takeaway. The design-space report must say which evidence level supports the claim and which commitment boundary it has not crossed.
Evidence also includes negative information. Rejected candidates, failed simulator runs, invalid configurations, proxy wins that disappear at higher fidelity, and assumptions that had to be abandoned are not waste. They are architecture data. They tell the loop where not to go and tell the human reviewer why a surviving candidate deserves attention.
This distinction between feedback and evidence is one of the main safeguards against hype. Architecture 2.0 is not credible because a generative method can produce outputs quickly. It is credible only when the loop can explain why an output should be believed, what evidence would overturn it, and who has authority to say no.
Architect’s checkpoint: The Feedback vs. Evidence Gate
3.12 The Design-Loop Card
The ontology becomes operational through a design-loop card. The card is the practical payload of the ontology, a compact way to describe a paper, project, tool, benchmark, or internal loop. It asks for the loop, not only the result.
Figure 3.6 shows a compact example for the lighthouse prompt. The point is not that the card completes the design. The point is that it exposes the state a credible loop must carry before any generated candidate should be trusted.
The card is deliberately simple. Its purpose is not to create paperwork. Its purpose is to reveal whether a claimed Architecture 2.0 contribution exposes the loop that makes it credible. A paper that reports a better search result but hides its feedback budget, rejected candidates, or environment validity is hard to compare. A tool that produces designs but cannot say what rejects them is hard to trust. A benchmark that measures model accuracy but not architecture-relevant reasoning may be useful, but it should not be mistaken for a complete design-loop evaluation. Missing card fields are review outcomes, not formatting problems: ask for evidence, escalate fidelity, reject the claim, or narrow the commitment until the loop can support what it reports.
Appendix B gives the full 12-field card and review rubric. The important point here is that every major Architecture 2.0 claim should be able to expose its loop.
3.13 How the Rest of the Book Uses the Ontology
The remaining chapters unpack the ontology as missing conditions for credible AI participation. Chapter 4 asks what architecture data must encode before AI systems can reason about it. Chapter 5 asks how simulators, compilers, EDA flows, benchmarks, and deployment systems become action settings. Chapter 6 asks which method roles are valid under a feedback budget. Chapter 7 asks when feedback becomes evidence strong enough for rejection and commitment. Chapter 8 runs one loop end to end on the lighthouse prompt. Chapter 9 applies the framework across loop patterns in software, architecture DSE, co-design, systems, and high-commitment silicon-facing work. Chapter 10 returns to the architect: what remains nondelegable, what the community must build, and what it would mean for Architecture 2.0 to become a discipline rather than a collection of demonstrations.
3.14 Conclusion
This chapter asked what a design loop must make explicit before an AI output can be accepted or rejected as an architectural claim. The continuity with classical practice is the loop itself, since architecture has always advanced through cycles of abstraction, measurement, feedback, and judgment. The discontinuity is automation, and with it a change in the failure mode, from slow human drift to fast, confident, catastrophic error when verification and rejection go missing.
The ontology answers that question by naming the minimum a claim must expose to be reviewable. A claim has to show the task and state it represents, the environment it acts in, the method roles that produced it, the feedback turned into an evidence ledger, the authority that can reject it, and the commitment boundary that stays human-owned. Stated as a review object rather than a result, a claim can be compared, reproduced, and contested by someone who never ran the loop. The design-loop card is simply that object made routine.
The ontology guarantees no correctness, and that is the point. It does not pick winning models or tools. It exposes what must be represented, measured, checked, rejected, and decided, which is exactly why it can outlast whichever models and tools are current. A claim that cannot expose the loop that produced it is not yet an architectural claim, however good its numbers look.
3.15 Open Research Questions
The ontology and framework proposed here map the known requirements for Architecture 2.0, but establishing them as standard practice exposes several unsettled research directions. The following open questions push beyond the current conceptualization to explore how these loops can be formalized, enforced, and scaled into rigorous, thesis-level challenges:
How can the design-loop card be elevated from a static review checklist into an executable, zero-knowledge verifiable schema for multi-organizational architecture verification? While the design-loop card (Appendix B) provides a structured review object, establishing it as a universal protocol requires mechanisms for automated systems to cryptographically prove that a candidate survived the exact claimed environment. A thesis-level challenge is designing executable schemas where constraints, baseline comparisons, and evidence ledgers can be independently verified without exposing proprietary RTL or toolchains.
What are the foundational limits of wrapping legacy, opaque simulation infrastructure into formal Architecture 2.0 environments? Retrofitting decades of tacit, black-box EDA tools and simulators into formal environments (see the discussion on “Tools as Architecture Environments” in Chapter 5) exposes severe friction. Research must determine how to mathematically bound the invalid-action semantics of these legacy tools so that high-speed generative optimizers cannot silently exploit abstraction inaccuracies to fabricate false Pareto frontiers.
How can the “dark matter” of architectural exploration—rejected candidates, failed timing closures, and proxy-fidelity mismatches—be formalized into a causal world model? Current AI methods often discard the failure traces that teach human architects the true boundaries of a design space. A major open question is how to continuously extract and encode these negative paths into a rigorous representation of architecture state (see the discussion on “The Architecture 2.0 Ontology” in Section 3.4) that actively regularizes generative models against out-of-bounds hallucinations5 and causal errors.
Can formal, mechanically-checked protocols enforce human-in-the-loop commitment boundaries in high-velocity autonomous design ecosystems? As automated loops scale toward bounded autonomous ecosystems (Figure 3.4), policy-based rejection becomes insufficient. A critical systems challenge is engineering strict, verifiable commit-gate protocols that isolate generation from deployment, ensuring that no architectural claim can cross a fidelity boundary without unforgeable, explicit human authorization.
5 Instances where an AI model generates false, fabricated, or nonsensical information confidently.
What to carry forward
- Reader test: Can you review an AI-generated architectural claim through the loop that produced it: its environment, method roles, evidence ledger, rejection authority, and commitment boundary?
- Up next: The next chapter asks what representations and world models must encode before an AI-assisted loop can synthesize systems credibly.