10 What the Architect Owns
“The architect’s two most important tools are the eraser at the drafting board and the wrecking bar at the site.”
— Frank Lloyd Wright, Architect
Author’s Note: Frank Lloyd Wright, the iconic American pioneer of organic architecture, recognized that the power to destroy and revise is just as important as the power to create. For us, this summarizes the conclusion of the book: while AI will generate the designs, the human architect retains the ultimate authority to reject them and owns the final deployment commitment.
The crux
To answer those questions, consider the lighthouse prompt that opened the book. It asked for a low-power, 64-bit RISC-V-based compute subsystem for real-time mobile XR under a 3 W target in a 3 nm-class low-power mobile process. At the start of the book, that prompt was a provocation. It looked like a request for a future hardware foundation model. At this point, it should read differently. The prompt is not powerful because it is short. It is powerful because it exposes a missing design loop.
Hardware foundation model: a foundation model is a large-scale machine learning model trained on a vast quantity of data that can be adapted to a wide range of downstream tasks; a hardware foundation model would apply this approach to hardware design representations.
That loop includes workload definition, architecture representation, tool interfaces, compound method roles, feedback budgets, evidence ledgers, rejection authority, and human decisions. It also exposes the central conclusion of Architecture 2.0. AI systems do not eliminate the computer architect. They change what the architect must own.
10.1 The Architect Owns the Loop
The architect’s responsibility moves upward. The architect does not own every intermediate answer alone; the architect owns the loop and the commitment it supports. Instead of owning every step of manual artifact construction, the architect owns the framing of the problem, the abstractions that make it tractable, the representations that make it legible, the evidence standards that make it believable, the rejection authority that makes it safe to use, and the commitment behind the final decision. This is why Architecture 2.0 is not simply an automation story. It is a responsibility story about loops in which AI-assisted systems can act but cannot own the commitment.
That responsibility is sharper in hardware than in software. A generative model or an automated optimizer does not sign a tapeout check, and unlike a software defect that an overnight update can patch, a hardware bug ships in silicon, where a respin costs millions of dollars and months of schedule. The architect therefore has to own the commitment gate explicitly. The job shifts from crafting the artifact by hand to standing behind the evidence that justifies committing it, without ceasing to own the artifact’s consequences.
What this chapter gives you
After this chapter you can draw the architect-owned commitment boundary for a loop. That means you can:
- name which architecture responsibilities remain human-owned when automated tools act inside the loop;
- decide which state, evidence, rejection authority, and workload records a loop must expose before delegation is credible;
- answer the strongest objections to Architecture 2.0 without treating automation as ownership;
- identify the community infrastructure the field still needs for comparable, evidence-bearing loops;
- state why every field of the design-loop card ultimately resolves to an accountable human owner.
10.2 Return to the Moonshot
To see how these shifted responsibilities manifest in practice, we must return to the lighthouse prompt that provoked this inquiry in the first place:
Design a low-power, 64-bit RISC-V-based compute subsystem for an XRBench-class real-time mobile XR workload. Realize it as a vector-capable CPU, accelerator, or SoC block under a 3 W TDP target in a 3 nm-class LP mobile process, and return a design-space report with evidence and rejected alternatives.
This prompt may seem straightforward, but it implies a set of complex interface contracts. At first glance, it looks like a standard hardware specification—a list of targets, constraints, and deliverables. However, beneath the surface, it binds together workload assumptions, software dependencies, architectural representations, and physical constraints. For an AI-assisted loop to act on this prompt, these implicit contracts must be explicitly surfaced as machine-readable constraints and rejection criteria.
Lighthouse prompt: The prompt hides interface contracts
In the Lighthouse prompt. “XRBench-class real-time mobile XR workload” creates an obligation to specify a workload distribution, quality-of-experience target, benchmark version, traces, and software stack. For an automated system, this workload obligation has to be represented as machine-readable data: scenario labels, trace provenance, coverage limits, excluded cases, quality-of-experience labels, and out-of-distribution (data or inputs that differ significantly from the examples a model was trained on, often degrading performance) rejection conditions. “64-bit RISC-V-based” means the AI loop needs access to correct compiler toolchains, simulators, and instruction semantics, rather than just generating text that looks like RISC-V. The fragment “vector-capable CPU, accelerator, or SoC block” defines the system’s allowed action space. The loop must be given explicit rules about which integration paths it can explore and which interfaces are fixed.
Evidence boundary. “3 W TDP target” and “3 nm-class LP mobile process” create power, thermal, and physical-design constraints; an optimizer evaluating candidates must not confuse a fast proxy average-power estimate with the sustained thermal or signoff evidence required for a final commitment.
Takeaway. The architect-owned work is deciding which contracts are fixed, which are exposed as actions to the automated tool, and which have enough evidence to support a human commitment.
This need for explicit evidence introduces a hierarchy of commitment. As an AI-assisted design loop explores candidates, it must navigate different levels of fidelity—from fast, imprecise proxies to expensive, cycle-accurate physical simulations. The architect must define the escalation path, deciding exactly what level of evidence is required to advance a design to the next stage without incurring unacceptable risk. This progression is captured in the commitment ladder (Figure 10.1), which maps the rising standard of evidence against the increasing cost of being wrong.
The requested deliverable also matters. A design-space report is different from RTL. RTL is different from a verified implementation. A verified implementation is completely different from a physically routable, timing-closed tapeout. (Logical correctness in RTL tells us nothing about whether power delivery, thermal bounds, and wire routing can physically close through rigorous signoff tools.) Each step changes the evidence standard. The same prompt can support a brainstorming loop, a research prototype, a simulator-backed design-space exploration, or a high-commitment implementation loop. Treating all of those deliverables as the same is one of the fastest ways to overclaim.
To avoid this overclaiming, the framework developed here turns the prompt into a set of explicit questions: What task is being solved? What representation is available? What world model does the loop assume? What tools can the system act on? What method roles are allowed? What feedback is affordable? What evidence would make the result credible? What alternatives were rejected? Who can stop the loop? Who is accountable for the decision?
Together, those questions define the part of the design space the architect exposes to methods, tools, and AI-assisted systems. Choosing what to expose is an architectural act. Expose too little and the loop cannot find useful alternatives. Expose too much without constraints, evidence, and rejection authority, and the loop can optimize the wrong object or cross a commitment boundary before anyone understands what happened.
Architect’s checkpoint: The Exposure Gate
Enforcing those boundaries marks the shift from prompt to loop. The prompt motivates the work. The loop makes the work inspectable.
The phrase prompt-to-loop is deliberately more durable than prompt-to-chip. Prompt-to-chip asks whether a system can produce an impressive final artifact from a sentence. Prompt-to-loop asks whether it can preserve the task, state, tools, evidence, rejected alternatives, and human decision boundary that make the next architectural commitment believable. The second question remains important even after today’s models and tools are obsolete.
10.3 Nondelegable Architectural Responsibilities
Even the most explicitly defined, inspectable loop still leaves work the architect cannot hand off, and nondelegable does not mean unaided. An architect can use models, AI-assisted systems, search procedures, simulators, compilers, profilers, EDA tools, benchmarks, and critics. The point is narrower and more important. The architect cannot transfer responsibility for the architectural judgment itself into a model. Nor does responsibility become distributed simply because several automated participants divide the work. Splitting a loop across these tools can make delegation more effective, but it also creates more places where authority can become ambiguous. The architect still has to decide which roles may act, which system or tool can stop another, which evidence crosses an escalation threshold, and who owns the commitment when the tools disagree or all agree for the wrong reason.
Architect’s checkpoint: The Multi-Agent Authority Gate
Other high-stakes fields have already learned, at real cost, where that authority has to sit.
Field note: The reviewers who could say no, too late
Takeaway. When a loop delegates work across tools, the authority to halt on independent evidence must be seated before the commit, not discovered after the tapeout.
Because authority must not diffuse, the architect’s responsibility becomes more explicitly full-stack as automated tools enter the loop. A future architect may not be only a CPU architect, accelerator architect, compiler specialist, or physical-design expert. The nondelegable work is composition across those boundaries: deciding which hardware knobs to expose, which software contracts must remain stable, which workload scenarios matter, which tool feedback has authority, and which deployment consequences are acceptable. Automated systems can help operate pieces of the stack, but the architect owns the decisions that connect those pieces into a defensible system claim.
Figure 10.2 visualizes this fundamental division, separating assistable loop work from the high-stakes commitments the architect must own. Automated methods may help represent state, generate candidates, evaluate proxies, call tools, critique results, summarize evidence, and preserve provenance. Those are substantial contributions. But they do not decide what problem matters, which abstraction is legitimate, what evidence is enough, which failure is acceptable, when to reject a result, or who answers for the consequences. An automated optimizer might tune a core’s thermal profile, for instance, but the architect owns the call if that profile melts the package or breaks the product’s safety certification. That line separates work a loop may assist from the commitments the architect still owns: intent, abstraction, evidence standards, rejection authority, deployment risk, and responsibility for consequences. It is the boundary the rest of this chapter defends.
As depicted in Figure 10.2, this establishes a clear ownership boundary. The loop can automate work inside the boundary, but only the human architect can accept the risk of crossing it to make a deployment commitment.
Table 10.1 turns this claim into a practical review object. It is not meant to romanticize human judgment. Human judgment can be biased, inconsistent, and incomplete. The reason it remains central is that architecture decisions bind technical artifacts to organizational, economic, ethical, and deployment consequences. A model can help reason about those consequences, and a tool-using system can help surface them, but neither owns them when the loop crosses a commitment boundary.
| Responsibility | Why it cannot be delegated | How AI can assist |
|---|---|---|
| Intent and constraints | The loop must serve a real architectural objective, not merely an available benchmark or proxy. | Elicit missing constraints, surface conflicts, and compare formulations. |
| Abstraction and representation | The encoded state determines what the loop can see, optimize, ignore, or falsely simplify. | Translate artifacts, organize traces, find gaps, and suggest structured schemas. |
| Evidence standard | A result is useful only if the evidence matches the commitment level and cost of being wrong. | Build evidence ledgers, track provenance, estimate uncertainty, and summarize rejected runs. |
| Escalation thresholds | The moment when proxy evidence is no longer enough depends on risk, reversibility, blast radius, and organizational context. | Detect threshold crossings, surface missing evidence, and route decisions to review. |
| Rejection and commitment | Someone must decide when a candidate is invalid, too risky, insufficiently supported, or ready to use. | Critique assumptions, flag rule violations, and compare alternatives. |
| Accountability and boundaries | Architecture choices affect users, teams, IP, security, cost, reliability, and long-lived systems. | Maintain audit trails, identify policy conflicts, and make tradeoffs explicit. |
Those responsibilities become easier to review when they are attached to ordinary artifacts. Table 10.2 regroups them into the concrete records a team can inspect. It surfaces environment and action authority as its own row and folds escalation into the evidence standard and accountability into rejection and commitment.
| Architect-owned responsibility | Inspectable artifact |
|---|---|
| Intent and constraints | Problem statement, non-goals, workload slice, hard constraints, and decision owner. |
| Abstraction and representation | Architecture schema, exposed design space, assumptions, hidden-state list, and redaction boundary. |
| Environment and action authority | Tool contract, legal actions, invalid-action rules, cost model, and provenance requirements. |
| Evidence standard | Fidelity ladder, calibration record, evidence ledger, and escalation threshold. |
| Rejection and commitment | Rejected-alternative log, review note, waiver record, commitment level, and rollback or next-evidence plan. |
This boundary also clarifies the word agentic. The book is not arguing that every architecture loop should become autonomous. Agentic systems are useful because they can act inside represented loops: call tools, maintain state, revise plans, use feedback, and coordinate method roles. But action is not ownership. As loops become more capable, the architect’s responsibility is not reduced; it becomes more explicit.
Agentic system: an AI system capable of pursuing complex goals over time, making its own decisions about which tools to use and what steps to take next.
Architect’s checkpoint: The Ownership Test
10.4 Extracting and Codifying Tacit Knowledge
If the architect must own the constraints and accept the risk, where do those constraints actually come from if they are not written down?
The reality of engineering in complex organizations is that the most valuable knowledge often resides not in formal specifications, but in the hard-won, tacit wisdom of domain experts. It is the packaging engineer knowing that a specific chiplet partition will silently break the power delivery mesh, the compiler lead knowing that their LLVM backend cannot lower a proposed matrix layout, or a senior architect anticipating that an accelerator’s coherency traffic will starve the XR display controller—integration failures that a local proxy would never catch.
A skilled human engineer naturally performs the work of hunting down this context before acting. They know who holds the undocumented knowledge, they pull it from them, and they synthesize it so that work does not stall on missing context.
An autonomous or AI-assisted system, however, expects to run end-to-end based on explicit inputs. If the rules are tacit, the AI behaves like an ML model encountering out-of-distribution data or a reinforcement learning agent engaging in reward hacking1. It will either stall out due to missing context or, worse, hallucinate a mathematically optimal design that exploits loopholes in the incomplete constraints, completely violating the unwritten physical or software realities of the system.
1 A failure mode in reinforcement learning where an agent discovers a way to maximize its objective function through unintended or physically impossible loopholes rather than solving the actual task.
This forces a shift in the architect’s daily work. Before the AI can run the loop, the human architect must act as the knowledge extractor. As illustrated in Figure 10.3, they must bridge the gap between undocumented organizational wisdom and explicit loop state.
Translating hallway conversations and senior-engineer intuition into formal Environment Contracts and Rejection Gates allows bounded automation to reject bad designs before they waste simulation time.
The AI agent cannot query the unwritten wisdom directly; it relies entirely on the architect to explicitly bound the environment. In Architecture 2.0, extracting tacit knowledge is no longer just good communication—it is the prerequisite engineering step for automation.
10.5 The Strongest Objections
This insistence on explicit human ownership—and the prerequisite that architects must extract and codify tacit knowledge before AI can act safely—is a strong stance. A field-defining claim should survive its sharpest critics, so it is worth stating the strongest objections plainly.
The first objection is that Architecture 2.0 is just good experimental methodology with new names. Provenance, baselines, rejection criteria, and held-out validation are not new; careful architects have always done them. The response concedes the lineage and locates the difference. What changes is who acts inside the loop and how fast. When a human runs the loop, tacit judgment supplies the missing rigor. The architect remembers why a workload was excluded or distrusts a proxy on instinct. When a method runs the loop at machine speed, that tacit layer no longer makes the loop reviewable unless it is recorded, so the discipline must be made explicit and machine-readable. Architecture 2.0 is the claim that the methodology must become an engineered object, not a craft, once automated tools participate. The book borrows established forms deliberately: the evidence ledger is an assurance case (Kelly and Weaver 2004), a discipline already mandatory in safety-critical domains such as automotive functional safety, where a safety case must argue that a design meets its requirements before it ships (International Organization for Standardization 2018); the fidelity ladder is multi-fidelity modeling (Peherstorfer et al. 2018). Naming the lineage is the point, not a weakness.
Held-out validation: in machine learning, the practice of reserving a portion of the dataset during training exclusively for evaluating a model’s performance on unseen data.
Multi-fidelity modeling: an optimization technique that combines cheap, low-accuracy simulations with expensive, high-accuracy simulations to explore a design space efficiently.
The second objection is that AI for systems design is overhyped, and the most cited result, learned chip placement, is contested. That is true, and this book treats it as evidence rather than embarrassment. The placement dispute in Chapter 7 is exactly why the field needs reproducible, end-to-end benchmarks and explicit rejection authority. An honest framework predicts that some flagship results will not survive scrutiny; its value is a standard that makes the difference visible.
The third objection is that the design-loop card is process bureaucracy that will not survive a deadline. The card is not a mandatory form; it is a diagnostic for loops where tools or automated participants can advance candidates faster than reviewers can reconstruct the evidence. A team under deadline can fill it in a few minutes and learn whether its result rests on a proxy nobody validated or a baseline nobody documented. The cost of skipping that check is paid later, at higher commitment, where it is most expensive. The card earns its place only when it is shorter than the mistake it prevents.
The fourth objection is that the framework is too conservative, preserving human authority when the goal is to deploy more capable AI systems. Architecture 2.0 does not oppose automation; it places automation where it can be inspected, rejected, and improved. A loop can be highly automated in low-commitment exploration and deliberately conservative near signoff. The design principle is not less automation. It is evidence-matched automation.
None of these objections is fatal, but each sharpens the claim. Architecture 2.0 is not the assertion that AI will design chips. It is the narrower, more defensible claim that the design loop must become explicit enough to act on, judge, and trust.
10.6 Community Infrastructure for Architecture 2.0
Making the loop explicit within a single team is a start, but individual practice is not enough to move a field. The ownership test names who owned each decision inside one loop, but those names can only be compared across loops when the field shares a record format that carries them. Agentic architecture work becomes cumulative only when loops, not just artifacts, can be compared, reproduced, criticized, taught, and extended. Architecture 2.0 therefore needs community infrastructure, not only better private loops.
The infrastructure does not have to expose proprietary designs or internal company data. It can start with shared conventions: design-loop cards, paper-facing claim-card views, environment schemas, provenance records, benchmark versions, negative traces, source records, tool-interface descriptions, and review rubrics. These are small artifacts, but they change what the community can ask of a claim. They let reviewers ask not only “What result did you get?” but also “What loop produced it? What feedback did it use? What did it reject? What evidence supports the decision?”
Providing a useful answer to those questions does not require raw design disclosure. If the only way an AI can learn is by reading proprietary physical EDA failure logs, Architecture 2.0 risks becoming a closed oligopoly. To survive, the open-source architecture community must federate and share loop integrity. We need an ISA for Evidence—a common, standardized interface and protocol for exchanging verification data and “negative traces” without central corporate control or NDA violations. Just as a traditional ISA separates hardware implementation from software, an ISA for Evidence separates proprietary physical details from shared architectural learning.
The community can establish this mechanism through Projected Proxies and Redacted Traces. When a corporate AI loop rejects a candidate due to a proprietary NDA constraint (e.g., TSMC 3nm wire congestion), the loop automatically maps that failure to an open-source proxy (e.g., ASAP7 or FreePDK45). The company publishes the relative failure, not the absolute proprietary data.
# Example: A Redacted Negative Trace (RNT) shared to the open-source commons
schema_version: "Arch2.0-RNT-v1"
context:
workload_class: "XRBench-mobile-vision"
baseline_architecture: "urn:riscv:microarch:rocket:default"
proxy_environment: "Chipyard + ASAP7 (Open PDK)" # The open projection
action:
type: "microarch_parameter_sweep"
delta:
- component: "L2_Cache"
parameter: "associativity"
changed_from: 4
changed_to: 16
evaluation:
status: "REJECTED"
rejection_authority: "PhysicalDesign_Oracle"
redacted_reason:
category: "PHYSICAL_VIOLATION"
sub_category: "ROUTING_CONGESTION"
relative_impact: >
Pin density exceeds 85% in L2 array macros;
unroutable at target utilization
# Note: Absolute cell dimensions and NDA PDK DRC rules are redacted.
lessons_learned:
- >
Non-linear routing congestion in high-associativity arrays
negates IPC gains in XR workloads.Listing \(\ref{lst-redacted-trace}\) illustrates this projected proxy pattern. It captures the essential context of the architectural exploration—the workload, baseline, and parameter sweep—while strictly redacting the absolute cell dimensions and proprietary design rules that triggered the rejection. Instead, it provides a relative impact statement and a generalized lesson. This redacted evidence ledger acts as a small public record that names the loop well enough for another group to understand what was attempted, what was observed, what was rejected, and what kind of commitment the evidence can support. Table 10.3 gives the minimum version. Anything less makes the claim hard to compare; anything more may be impossible to share.
| Field | Public record | Why it matters |
|---|---|---|
| Task and workload class | Workload family, scenario, benchmark or trace version, and excluded cases. | Prevents a result from being read as broader than the task that produced it. |
| Action-observation interface | What the loop could change, what it could observe, and which tools or environments returned feedback. | Makes the exposed design space inspectable. |
| Tool and model versions | Simulator, compiler, EDA flow, benchmark, model, and prompt or policy versions when they affect the result. | Makes drift and reproduction failures diagnosable. |
| Accepted and rejected candidates | A compact list of advanced candidates, rejected candidates, and the rule or evidence that separated them. | Turns negative traces into reusable evidence. |
| Evidence stages | Proxy, simulation, compiler/runtime, RTL, physical, silicon, or deployment feedback used, with fidelity limits. | Shows whether the evidence matches the claimed commitment. |
| Redaction and ownership | What was hidden, why it was hidden, and who owned the final decision. | Keeps IP boundaries explicit without hiding accountability. |
A redacted record has a failure condition. If redaction hides the workload class, action-observation interface, evidence stage, or decision owner, the record may still provide context, but it should not be treated as comparable loop evidence.
Architect’s checkpoint: The Redaction and Comparison Gate
When evaluating new benchmarks against this standard, read them by the loop fields they expose, not by their names. ArchGym and QuArch, met earlier, contribute environment/action interfaces and question-to-evidence review tasks. Two further examples fill fields the book has not yet seen instantiated: CircuitNet, an open dataset of physical-design flow records, contributes design-flow data, and ChiPBench, the end-to-end placement benchmark that grew out of the placement dispute (Chapter 7), contributes final power-performance-area rejection against proxy wins (Krishnan et al. 2023; Prakash et al. 2025b, 2025a; Chai et al. 2022; Wang et al. 2025). The common test is whether an AI-mediated architecture claim can show what state it used, what it changed, what feedback it received, what failed, and who owned the commitment.
The missing pieces are just as important. Architecture work rarely preserves negative traces: failed runs, rejected candidates, invalid configurations, stale benchmarks, bad proxies, tool errors, and ideas that were ruled out by expert judgment. Yet these traces are exactly what an AI-assisted design loop needs to learn from the field’s failures rather than rediscover them. A community that records only successful artifacts gives future systems a distorted view of architecture practice.
Community infrastructure should also respect privacy and IP boundaries. The goal is not to force every organization to publish internal traces. The goal is to build schemas, examples, synthetic tasks, open benchmarks, redacted records, and review artifacts that make credible loop design discussable. That is how Architecture 2.0 can become a research area rather than a set of private demos.
10.7 Open Research Questions
Building this shared infrastructure and navigating the transition to AI-assisted architecture introduces several unsettled research directions within the Architecture 2.0 ontology. For architect-owned work, the community must answer the following:
How do we mathematically verify redacted loop integrity in competitive, federated ecosystems? Building on the public evidence ledger (Table 10.3), future research must explore cryptographic guarantees—such as zero-knowledge proofs—to verify that an automated optimizer’s reported constraints, proxy simulations, and evidence ladder are authentic. This poses a thesis-level systems challenge, enforcing rigorous loop integrity and escalation protocols across organizational boundaries without leaking proprietary physical design IP or violating the redaction and comparison gate.
Can we construct predictive architecture foundation models entirely from federated negative traces? While this chapter argues for treating rejected alternatives as first-class evidence, learning from design failure at a discipline-wide scale remains unsolved. The open challenge is to formulate novel representation learning techniques capable of ingesting a shared, cross-organizational corpus of negative traces. This would enable an AI-assisted design loop to zero-shot2 anticipate complex physical integration faults in novel domains, effectively turning aggregated industry failures into a generalized architectural world model.
How can environments dynamically synthesize context-aware evidence gates under profound uncertainty? Expanding on the escalation rules and review artifacts (Table 10.2), future autonomous systems must transcend static heuristics. A major research frontier is architecting environments that automatically generate, calibrate, and enforce dynamic rejection thresholds when a method encounters out-of-distribution workloads or unmodeled technology nodes. This requires deep advances in uncertainty quantification to proactively trigger human stop authority long before a catastrophic deployment commitment is made.
How do we preserve continuous human accountability across asynchronous, multi-agent drift? As formalized in the long-horizon challenge tasks (Table 10.4), architecture decisions rapidly age as workloads, compilers, and surrogate models evolve. It is a fundamental open question how to cryptographically and organizationally re-verify the “named human owner” across continuous, asynchronous drift events when the original decision maker is unavailable. Addressing this necessitates entirely new frameworks for long-term algorithmic liability that keep multi-agent loops anchored to explicit human commitment boundaries.
2 The ability of a machine learning model to correctly perform a task or make predictions on data it has never seen during training, without requiring any specific fine-tuning.
10.8 Long-Horizon Challenge Tasks
To answer these open questions, the field needs realistic evaluations. Short demonstrations are useful for tool development, but they are too small to define the field. A model that writes a plausible RTL fragment, proposes a cache configuration, or summarizes a paper may be helpful without changing the architecture loop. The harder question is whether an AI-mediated system can participate in architecture work over the time scale on which architecture decisions actually mature: days, weeks, months, tool versions, workload updates, rejected alternatives, and design reviews.
Long-horizon architecture task. A long-horizon architecture task is a challenge in which a method or AI-assisted system must maintain design state across multiple steps, act through valid tools or interfaces, gather feedback at appropriate fidelities, preserve rejected alternatives, expose uncertainty, and support a human architectural commitment over an extended design interval.
Figure 10.4 visualizes the target shape of these benchmarks. The task is defined as long horizon because the state, actions, evidence, rejections, and human commitment have to survive across revisions, not because the prompt is longer.
This framing changes what the community should ask for. The canonical challenge is not prompt-to-chip. It is prompt-to-loop. Can a system preserve enough state, evidence, and rejection history that an architect can trust the next commitment? Table 10.4 sketches a starting set of tasks. The success criterion is whether the loop leaves a named human able to accept, reject, or escalate that next commitment. Each row names the paper object: a corpus or task source, the loop representation or environment to build, the evidence and rejection gate to test, and the commitment boundary the task may authorize.
| Challenge task | Corpus or task source | Representation / environment | Evidence and rejection gate | Commitment boundary |
|---|---|---|---|---|
| Design-loop memory | Multi-step DSE traces, notebooks, and review decisions. | Replayable candidate records with assumptions, tool outputs, failures, decisions, and timestamps. | Reviewer reconstructs why each candidate advanced, changed, or was rejected. | Supports the next exploration decision, not implementation readiness. |
| Workload drift tracking | Benchmark or trace-family versions plus affected conclusions. | Workload-version monitor with coverage, stale assumptions, and revalidation actions. | Drift detector weakens or invalidates claims whose workload support changed. | Maintains or withdraws a bounded workload claim. |
| Evidence-aware generation | Candidate proposals paired with predicted benefit and feedback costs. | Generator constrained by an evidence-gate policy and escalation rule. | Cheapest independent rejection test catches unsupported proposals before expensive checks. | Suggests next evidence to spend, not final design commitment. |
| Paper-to-loop reproduction | Published claims, missing artifacts, assumed settings, and negative traces. | Paper-to-loop reproduction packet with task, environment, evidence, and falsification needs. | Independent reviewer states what would reproduce, weaken, or refute the claim. | Makes the paper auditable, not automatically reproducible. |
| Simulator trust calibration | Proxy and higher-fidelity runs across workload slices and tool versions. | Proxy-calibration record with support region, observed errors, and invalidation cases. | Escalation gate rejects proxy wins outside calibrated support. | Authorizes proxy screening inside the support region only. |
| Cross-stack co-design | Workload, compiler, mapping, memory, accelerator, runtime, and deployment changes. | Co-design card with layer owners, interface contracts, and changed assumptions. | Interface and system-objective gates reject local wins that break another layer. | Supports a bounded cross-layer claim with named owners. |
| Negative-trace corpus | Failed mappings, invalid RTL, bad floorplans, stale benchmarks, and misleading proxy wins. | Redacted failure corpus with trigger, evidence, rejected fix, redaction boundary, and reusable lesson. | Reuse test shows whether a new loop avoids or reopens the old failure correctly. | Treats rejected alternatives as evidence, not universal design rules. |
| Design-review assistant | Design-review notes, risks, missing evidence, sensitivity checks, and rejected alternatives. | Review packet organized by design-loop card fields and human decision owner. | Human veto and evidence-gap checks reject unsupported recommendations. | Improves review judgment without owning the commitment. |
These challenges also give Architecture 2.0 a way to remain architecture centric. A generic AI benchmark can reward answer fluency. A long-horizon architecture challenge should reward state, interfaces, feedback economics, evidence quality, and rejection. That is where the computer architecture community has something specific to contribute.
10.9 From Capability to Standard
Building those capabilities is one thing; turning one into a shared field standard is another, and that path is gradual. The standard is not a governance process for its own sake; it is a shared loop contract. Automated systems need comparable action spaces, feedback contracts, workload/data boundaries, rejection logs, leakage controls, and named human commitment owners so that a claim can be inspected across labs without pretending every lab uses the same tools.
That progression should not be rushed. Premature standardization can freeze weak tasks, reward narrow metrics, and encourage benchmark gaming. But the opposite failure is also real. If every project defines its own task, wrapper, metric, and evidence standard, the field cannot accumulate knowledge. The right target is not a single universal benchmark. It is a family of interfaces, cards, tasks, and evidence conventions that make claims reviewable and contrastable without pretending all architecture work is the same. Full comparability, in MLPerf’s sense, is a stronger and later goal: it needs a fixed task, workload, metric, and submission rules, and a neutral referee that can reject a published claim, none of which a self-attested card supplies on its own.
A credible standard should make six things visible: the task/workload state, the legal actions and observations, the versioned tools/models/data, the evidence and rejected alternatives, the leakage/redaction boundary, and the accountable human or gate that can stop or accept a commitment.
Architecture 2.0 will likely mature unevenly. Fast software loops may standardize earlier than RTL and physical-design loops. Workload and benchmark loops may become more public than industrial signoff loops. That unevenness is acceptable. What matters is that the field learns how to name the loop and state its evidence burden.
Different communities can start at different leverage points. Table 10.5 states the first useful artifact each group can contribute without waiting for a complete field standard.
| Community | First useful artifact | Evidence or rejection obligation | First shared task |
|---|---|---|---|
| Practicing architects | A design-loop card attached to a design review or DSE report. | Name the workload, exposed design space, evidence stages, rejected alternatives, and decision owner. | Compare two candidate loops for the same design question. |
| ML researchers | A method report that states action space, observation space, training data, leakage risks, and failure cases. | Show what the method can reject, not only what it can generate. | Reproduce or stress-test an architecture claim with explicit missing evidence. |
| EDA and tool researchers | An environment contract for a simulator, compiler, or physical-design flow. | State legal actions, feedback latency, fidelity limits, provenance, and invalid actions. | Build a benchmark where proxy wins must survive a stronger tool check. |
| Systems researchers | A workload and deployment evidence ledger. | Track software stack, runtime policy, operating point, and drift. | Show when a local optimization stops supporting the end-to-end claim. |
| Authors and reviewers | An Architecture Claim Card attached to a paper claim. | Separate generated candidates from supported decisions. | Convert a result into task, representation, environment, method role, evidence, rejection, and commitment fields. |
For a team that wants to start immediately, the minimum useful target is one credible loop packet, not a process program. Table 10.6 turns the field agenda into three artifacts a reviewer can inspect.
| Packet component | What to attach | Evidence that it worked |
|---|---|---|
| Claim packet | A design-loop card for one active design review, DSE result, or paper discussion. | The team can name the task, exposed design space, evidence, rejected alternatives, commitment boundary, and decision owner. |
| Environment packet | One tool path wrapped as an environment contract with logged runs and invalid-action records. | A second person can replay or audit at least one successful run and one failed run. |
| Evidence packet | One shared evidence ledger or negative-trace format for a recurring architecture decision. | Future reviews reuse prior failures instead of rediscovering them, and claims state their commitment level. |
10.10 Loop Invariants as Review Checks
Just as classic computer architecture relied on rigorous quantitative metrics to evaluate artifacts, Architecture 2.0 relies on the verifiable loop. A first packet is where adoption starts; the design principles are how any loop, including that packet, gets quantitatively and qualitatively checked. Each chapter has contributed one such principle, and together they test whether an AI-mediated loop has represented workloads and state, bounded its actions, preserved provenance, gathered evidence, rejected candidates, and assigned ownership. They are more useful than a list of fashionable tools because they give reviewers, authors, and builders a stable way to inspect new work. Table 10.7 collects those principles as review checks and pairs each one with the design challenge it leaves behind.
| Principle | Where it comes from | Design challenge to keep in mind |
|---|---|---|
| Design the loop, not only the artifact. | Chapter 1 | A prompt or generated artifact is not enough; the loop must expose state, action, feedback, rejection, and decision. |
| Treat feedback as the bottleneck. | Chapter 2 | More candidates do not help if the loop cannot evaluate, reject, and justify them. |
| State the claim as a review object. | Chapter 3 | A result should name workload, baseline, design space, objective, constraints, evidence, rejection rule, and decision owner. |
| Make architecture work legible. | Chapter 4 | Data must include provenance, assumptions, costs, failures, and negative traces, not only successful endpoints. |
| Turn tools into environments. | Chapter 5 | A wrapper is credible only when it defines legal actions, observations, costs, invalid states, and rejection paths. |
| Match methods to roles. | Chapter 6 | A method should be chosen for the loop bottleneck it relieves, not for its reputation. |
| Escalate with commitment. | Chapter 7 | Evidence requirements should rise with rollback cost, blast radius, and independence of rejection authority. |
| Stop at an honest evidence level. | Chapter 8 | A loop should report what its evidence supports, what it rejected, and what would overturn the decision. |
| The loop is rejection-bound, not generation-bound. | Chapter 9 | Fast software loops, co-design loops, systems loops, and silicon-facing loops scale only as far as their cheap independent rejectors. |
| Keep a human accountable. | Chapter 10 | A named owner must explain what was accepted, rejected, waived, and what would force revision. |
These principles are deliberately phrased as checks, not slogans. A reader reviewing a paper can ask which principle is visible and which is missing. A researcher building a tool can ask which principle the tool makes easier to practice. A program committee, artifact committee, or internal review group can apply the same checks to a new paper, environment, or design-review packet.
These principles also change what counts as a mature research contribution. When the architect’s work moves toward setting evidence standards, exercising rejection authority, and judging what to trust under automation, papers should make those obligations inspectable rather than treating them as process details outside the contribution.
10.11 Beyond the Current Loop
Mastering those review skills is what carries an architect past the current loop, and the horizon beyond this book is not another autonomy level. It is the moment when loops begin to improve their own representations, propose new tasks, repair tool interfaces, organize negative traces, and recalibrate evidence standards. That possibility is powerful, but it does not change the core obligation. A loop that can adapt can also adapt toward benchmark gaming, hidden failures, tool overfitting, or biased traces.
This matters most because the design target no longer holds still. When software is continuously regenerated and retrained, as Chapter 2 argued and Chapter 9 showed at fleet scale, a specific artifact ages as the workload it served moves on. The artifact remains the thing committed at a point in time; the loop is the durable discipline for deciding whether that commitment is still supported. What remains stable is how intent is bounded, evidence is demanded, candidates are rejected, and commitment is decided as the target moves.
The durable way to read emerging design assistants is therefore not by their feature lists, which will change, but by the partition of design autonomy: which decisions a human still makes, which decisions the loop may make within stated bounds, and which decisions the loop is never allowed to make alone (Janapa Reddi and Yazdanbakhsh 2025). That partition, not the autonomy label, is what the architect must keep designing.
10.12 The Architect’s Standing Obligation
Designing that partition does not require a new instrument, because the operational checklist already exists. The trust checklist in Chapter 7 and the design-loop card and rubric in Appendix B give it for a single claim and for a whole project, and this chapter does not reprint them. The closing point is narrower and harder to delegate. Accountability. Every field on that card ultimately resolves to a person who answers for the commitment. The card makes the loop visible; the architect decides what the visible loop is allowed to do, and owns the consequences when it is wrong.
That bar is intentionally modest. It does not claim that every Architecture 2.0 project must solve every problem in the field. It asks for something more basic and more durable. Make the loop visible, then keep a human accountable for it. Once the loop is visible, the community can critique it, improve it, compare it, reproduce it, and build on it.
That is the promise of Architecture 2.0. The field does not need to wait for a single model that designs a computer from a sentence. It can start by changing the unit of architectural practice: from isolated artifacts to represented, instrumented, evidence-bearing design loops. The architect still owns the judgment. The opportunity is to build loops worthy of that judgment.
Design principle: Keep a human accountable
This obligation to maintain a visible, accountable loop defines the agenda for the field as we transition to Architecture 2.0.
What to carry forward: The Final Loop State
- Public agenda: Build evidence ledgers, long-horizon loop challenges, environment contracts, design-loop cards, and negative-trace corpora that let the field compare loops rather than admire isolated demos.
- Reader test: If the loop is wrong, who can explain what happened, what should have rejected it, and who accepted the commitment?
- Standing obligation: Make the loop visible enough that the community can critique, compare, reproduce, and improve it.
10.13 Final Thoughts: Engineering Discipline in a Fast-Moving Field
When this book opened with the lighthouse prompt—asking a generative method to generate an entire XR subsystem from a text description—it may have sounded like a prediction that the human architect’s job was ending. The framework developed across these chapters argues the exact opposite.
The tools, models, and automated systems driving this shift are changing at breakneck speed, and any catalog of today’s capabilities will quickly become obsolete. Because this transition is a massive work in progress, the one durable anchor is engineering discipline. We are crossing the threshold from artifact scarcity to commitment scarcity. When generating a plausible accelerator or floorplan becomes fast and cheap, the bottleneck shifts to the loop that produced it.
Architecture 2.0 is not about trusting machines more. It is about building loops that earn our trust. The AI-assisted system can generate, predict, and optimize, but only the human architect can accept the risk and sign their name to the final commitment. The task ahead is not to wait for an AI that can design a computer from a single sentence. It is to enforce the engineering discipline, the evidence standards, and the rejection boundaries that make those AI-assisted claims credible. Designing the loop is now part of designing the architecture, alongside the artifact it produces, never in place of it.