7 Feedback, Evidence, and Trust
“Program testing can be used to show the presence of bugs, but never to show their absence!”
— Edsger W. Dijkstra, Notes on Structured Programming (1970)
Author’s Note: Edsger W. Dijkstra, a Turing Award-winning pioneer in algorithm design, highlighted the fundamental limitation of testing. For us, this frames the role of verification gates. We use tests not to definitively prove an AI-generated design is perfect, but to aggressively reject the bad ones in a “red-teaming” approach.
The crux
Chapter 6 treated methods as roles inside a design loop. This chapter asks when the outputs of that loop should be believed. The answer is deliberately conservative. An Architecture 2.0 result is credible only when the feedback supporting it has been turned into evidence, the evidence can be audited, an independent authority can reject the result, and the commitment boundary matches the cost of being wrong.
This distinction between generated output and verified evidence is central to the book. A model can generate a plausible architecture description. A search method can find a strong proxy score. A surrogate can rank candidates. A tool-using agent can call simulators and summarize results. None of those actions creates trust by itself. Trust begins when the loop records what was measured, why it was relevant, how much it cost, what assumptions it used, where the feedback is weak, which alternatives failed, and what can say no.
Tool-using agent: an AI system that can programmatically invoke external software tools or APIs to solve tasks.
The lighthouse prompt makes this need for evidence concrete. A proposed low-power 64-bit RISC-V compute subsystem for XRBench under a 3 W, 3 nm-class low-power mobile envelope might look reasonable under an analytic proxy, promising under simulation, and broken under synthesis or timing. It might meet performance while missing an energy or thermal target. It might pass a benchmark but fail a real deployment scenario. Architecture 2.0 therefore needs an evidence discipline that is as explicit as its representations, environments, and methods. At the center of that discipline is verification, used here more broadly than its usual formal-methods sense.
Verification. Verification is used broadly in this chapter. It includes formal methods when formal properties are available, but it also includes type checks, interface checks, regression tests, baseline replay, simulator cross-checks, synthesis constraints, physical-design warnings, security review, workload coverage, and expert design review. The common requirement is independence. The check should be able to reject the claim, not merely restate the method’s output.
Verification is therefore a family of rejection authorities, not a single tool category. Table 7.1 details a taxonomy of these checks and what they can reject. Inside AI-assisted loops, these authorities are not generic quality checks; they define which generated state transitions may continue, be revised, or be blocked.
Inside an Architecture 2.0 loop, each check is bound to a represented state field, a legal action, and a commitment boundary. It says which action may continue, which state update is invalid, and when the loop must revise or escalate.
To put these rejection authorities into practice, read the chapter as a sequence of review records rather than as separate trust concepts. Each record answers a different question about the same claim; Table 7.2 is the chapter’s map. Two further sections, on proxy mismatch and on confidentiality boundaries, defend the evidence ledger and the trust checklist against gamed metrics and hidden evidence.
| Review record | Role in the loop | Reviewer question |
|---|---|---|
| Feedback budget ledger | Records what feedback the loop can afford and what each source costs. | What evidence can the loop realistically buy? |
| Evidence ledger | Turns feedback into claim support with fidelity, provenance, uncertainty, and negative traces. | What supports or weakens the claim? |
| Commitment ladder | Matches evidence requirements to rollback cost, blast radius, and ownership. | How far may this claim go? |
| Rejection authority | Names the independent check that can say no. | What can stop a plausible but unsupported result? |
| Trust checklist | Combines claim, feedback, fidelity, provenance, confidentiality, rejection, and decision ownership. | Is the loop asking for a level of belief it has earned? |
What this chapter gives you
After this chapter you can write or review the trust checklist for an AI-assisted loop output. That means you can:
- turn feedback into evidence through fidelity, provenance, and an evidence ledger;
- map the chapter’s review records: feedback budget, evidence ledger, commitment ladder, rejection authority, and trust checklist;
- set escalation thresholds and commitment boundaries by reversibility and blast radius;
- name what can reject a result, and why rejection authority must be independent;
- review a claim with the trust checklist instead of by its tone.
7.1 Feedback Budget Ledger and Feedback Economics
Chapter 5 used feedback regimes to design environments, and Chapter 6 used them to choose method roles. This chapter uses the same economics for trust: escalation, rejection, and commitment.
In any loop, the first barrier to establishing this trust is economic. Feedback is not free, uniform, or automatically useful. An architecture loop may have thousands of cheap proxy evaluations, hundreds of simulations, tens of synthesis or physical-design runs, a few emulation opportunities, and almost no chances to learn from silicon or deployment mistakes. It may also have scarce human review time, limited tool licenses, long queue delays, confidential workloads, and organizational deadlines. These limits shape which methods are appropriate and how much autonomy is acceptable.
This is why a loop needs a feedback budget ledger, a record of which evaluations, measurements, tool runs, human reviews, and deployment signals are available, what they cost, how long they take, how reversible they are, and what level of decision they can support. The ledger is not accounting bureaucracy. It is the object that tells the method what kind of learning is possible. A Bayesian optimizer1, reinforcement-learning policy, surrogate model2, critic, or tool-using agent should behave differently when a feedback source takes milliseconds versus days, when a failed action is reversible versus costly, and when the signal is a rough proxy versus a signoff report. Table 7.3 materializes these constraints into a structured working form.
1 A Bayesian optimizer builds a probabilistic model of an objective function to efficiently find its optimal parameters with few evaluations.
2 A surrogate model is a cheaper, learned approximation of a complex, expensive simulation.
Policy: in reinforcement learning, a function that maps an agent’s state to a chosen action.
Critic: in this book, the critique method role of Chapter 6, a component that challenges assumptions, evidence, or claims inside the loop; reinforcement learning uses the same word more narrowly for a learned estimator of expected future returns.
| Budget item | What to record | Why it matters |
|---|---|---|
| Latency and cost | Runtime, queue time, dollar cost, tool hours, license limits, and human review time. | Determines whether the loop should search broadly, sample carefully, or mostly critique. |
| Signal quality | Fidelity level, metric definition, noise, determinism, coverage, and uncertainty. | Separates raw feedback from decision-grade evidence. |
| Sample budget | Number of possible runs at each fidelity, including failed runs and invalid candidates. | Forces sample-efficient methods and preserves negative traces. |
| Reversibility | Whether the action can be undone cheaply, re-run, patched, or rolled back. | Connects autonomy to risk. Reversible actions can tolerate weaker evidence than irreversible commitments. |
| Commitment and rejection | Claim level supported, gate triggered, escalation required, and decision owner. | Keeps feedback comparable across claims by tying each source to what it can reject or commit. |
| Scarce attention | Expert review, debugging effort, validation bandwidth, security review, and integration time. | Prevents the loop from outsourcing cost to people whose time is the real bottleneck. |
Beyond just tracking costs, the ledger also changes what a result means. A method that finds a good point after 10,000 cheap proxy evaluations has learned something different from a method that selects three candidates for expensive synthesis. A loop that records failures, timeouts, warnings, rejected candidates, and review notes has more evidence than a loop that records only the winning score. This is the connection to sample efficiency from Chapter 6. Sample efficiency is not only about using fewer evaluations. It is about making each evaluation carry more architectural information.
To make that discipline concrete, we can write the feedback budget and sample value explicitly:
\[ B = \sum_i n_i \cdot c_i, \qquad V_i \approx \frac{\Delta \mathrm{Conf}(d \mid e_i)}{c_i}. \]
This notation is a review prompt, not a universal evidence metric. Here, \(n_i\) is the number of evaluations of feedback type \(i\), \(c_i\) is the cost of one such evaluation, \(B\) is the total feedback budget, \(e_i\) is the evidence produced by that evaluation, \(\Delta \mathrm{Conf}(d \mid e_i)\) is the change in confidence for the decision \(d\), and \(V_i\) is the resulting decision value of one such evaluation. It is the per-feedback-type form of the sample-value rule from Chapter 6; ordinal confidence changes or decision-relevance labels are often more honest than unjustified numeric confidence.
Just as the quantitative approach historically weighed performance gains against silicon area and power, Architecture 2.0 weighs confidence gains against computational and human costs. For example, spending 100 CPU-hours (\(c_i\)) on a cycle-accurate simulation to gain a modest reduction in PPA uncertainty (\(\Delta \mathrm{Conf}\)) might be less valuable than spending 1 hour of expert review to catch a fundamental security flaw. The notation is a question the loop designer must answer before each stage. Will another simulation, synthesis run, expert review, or deployment experiment change a decision enough to justify its cost? Chapter 8 makes the question concrete, spending the proxy budget freely, the cycle-level budget carefully, and a high-fidelity power check only on the surviving candidate. The unit being priced is not just another evaluation; it is a rejectable loop transition: state before, legal action, feedback source, rejection gate, and next state if the gate fails.
7.2 Fidelity Ladders and Evidence Ledgers
Feedback becomes evidence only when it is tied to fidelity, provenance, uncertainty, and a decision. A simulator result is feedback. It becomes evidence when the workload, simulator version, configuration, random seed, assumptions, metric definition, failure status, and acceptance criterion are recorded. A synthesis report is feedback. It becomes evidence when the technology assumptions, constraints, tool versions, warnings, and comparison baseline are explicit.
Feedback regime. A feedback regime is a class of checks at a particular fidelity, cost, and commitment level, from cheap proxies to high-commitment verification, deployment, or silicon evidence.
To structure this transition from feedback to evidence, each rung of the fidelity ladder from Chapter 6 is a feedback regime: the ladder names the ordered levels a loop can climb, and the regime names the class of checks at one level. The evidence ledger records which rung produced which entry.
This idea of tracking evidence across regimes is not new to engineering. Safety-critical fields formalize it as an assurance case, a structured argument that links a top-level claim to sub-claims, assumptions, and supporting evidence, often written in Goal Structuring Notation so that each inference and the evidence under it are explicit and reviewable (Kelly and Weaver 2004). An Architecture 2.0 evidence ledger is an assurance case for a design decision that moves across feedback regimes. It is the five-part execution state materialized as an audit trail. It records the candidate (actions allowed), the feedback and fidelity (state seen), the provenance and uncertainty (evidence), what could block the claim (alternatives rejected), and the required escalation boundary (ownership). Naming the lineage helps, because that field already catalogs how such arguments fail: unstated assumptions, evidence that does not support the claimed scope, and confidence that outruns the proof.
Goal Structuring Notation (GSN): a graphical argumentation notation used in safety-critical engineering to formally document the elements of an assurance case.
For Architecture 2.0, Figure 7.1 illustrates this working model. Rather than treating all feedback as equal, a claim must move through a chain of increasingly costly feedback sources, recording a rejection gate and evidence ledger entry at each stage.
Crucially, the figure changes the meaning of trust. Trust is not a model property or a single score. It is a staged loop property. A claim becomes more credible only when each feedback regime records what it saw, what it cannot support, what would reject it, and what commitment boundary it is allowed to cross.
However, moving up the fidelity ladder is not a simple ranking from false to true. Higher fidelity is not automatically truth if the wrong workload, objective, constraints, or baseline were used. A detailed physical-design result can still answer the wrong architecture question. A deployment signal can still be confounded by a software change. A benchmark can still be too narrow. The purpose of the feedback-regime view is therefore not to worship expensive tools. It is to make the path from weak feedback to stronger evidence explicit.
Returning to the lighthouse prompt, low-fidelity feedback may be useful for eliminating obviously infeasible vector widths, memory sizes, or accelerator partitions. Simulation may then test workload behavior and data movement. Synthesis or emulation may expose timing, area, or power problems. Deployment-like traces or silicon evidence may reveal workload drift or integration effects. At each stage, the loop should ask whether the earlier conclusion survived, changed, or should be rejected.
This framing is consistent with the quantitative tradition in computer architecture, where measurement, abstraction, and careful comparison are central (Hennessy and Patterson 2017). Architecture 2.0 adds a loop-level requirement. The evidence ledger itself must be represented so that a compound method system and a human reviewer can inspect it.
7.3 Commitment Levels and Reversibility
An evidence ledger shows how strong the support for a claim is; how strong that support needs to be is a separate question, and trust requirements should rise with commitment. A loop that generates a candidate simulator configuration can tolerate more automation than a loop that changes RTL, partitions a chiplet boundary, selects a package interface, or recommends a deployment policy. The difference is not whether AI is involved. The difference is rollback cost, blast radius (how far a wrong change can propagate), and who bears the consequence when the loop is wrong.
Table 7.4 gives a commitment-level view. The exact ordering will vary across organizations, but the pattern is stable. Reversible exploration can use lighter evidence, while irreversible or high-blast-radius decisions require stronger evidence, independent rejection, and human ownership. The trigger for moving between these levels is the escalation threshold.
Escalation is the price of trust. It is the boundary where the loop refuses to commit because it lacks the evidence to proceed. An escalation threshold is the stated condition under which a loop must stop relying on its current feedback source and move to stronger evidence, independent review, or explicit human approval.
The architect owns these thresholds because they depend on consequences, not only on model confidence. A proxy win may be enough to keep exploring. It is not enough to change a subsystem interface, waive a verification concern, or commit to a power claim. The loop should therefore state in advance which events force escalation: uncertainty outside the calibrated range, a benchmark coverage gap, a failed tool check, a security boundary, a high rollback cost, or a decision that would affect another team or product.
Architect’s checkpoint: The Escalation Threshold Check
| Commitment | Example actions | Required discipline | Automation stance |
|---|---|---|---|
| Exploratory | Generate hypotheses, configs, candidate questions, or design cards. | Basic validity checks and provenance. | Broad assistance acceptable. |
| Experimental | Run simulator sweeps, tune compiler flags, select candidates for deeper study. | Workload versions, seeds, baseline, rejected candidates, and uncertainty. | Automation with review. |
| Implementation | Change RTL, generators, tool constraints, tests, or runtime interfaces. | Tool checks, regression tests, synthesis or integration evidence. | Bounded automation plus rejection gates. |
| Integration | Change subsystem interfaces, chiplet boundaries, memory contracts, or product-facing policies. | Cross-tool checks, compatibility, security, and explicit escalation. | Advisory or human-approved. |
| Irreversible | Mask-level choices, committed signoff decisions, fleet-wide rollouts, or customer-visible deployments. | Independent evidence ledger, rejection authority, audit trail, and accountable human decision. | Commitment boundary dominates. |
This commitment structure keeps Architecture 2.0 from making a naive autonomy argument. Autonomy is not a virtue by itself. A loop may be highly automated for low-commitment exploration and deliberately conservative for high-commitment decisions. In fact, some of the most valuable near-term systems may not be systems that make final design choices. They may be systems that narrow a space, identify contradictions, preserve evidence, and prepare the human architect to make a better decision.
Design principle: Escalate with commitment
7.5 Proxy Mismatch, Metric Gaming, and Calibration
The failure an independent rejection authority most often has to catch is proxy mismatch. A loop optimizes the measurement it can see, while the architect cares about a broader objective. IPC may improve while energy, area, or tail latency worsens. A simulator metric may improve while synthesis exposes timing or power problems. A benchmark result may improve while the real workload distribution changes. A Pareto frontier may look convincing because all points were evaluated under the same flawed proxy. An automated optimizer may appear capable because it overfits the evaluation loop, not because it understands the architecture problem. In the machine learning literature, this active exploitation of a flawed metric is known as reward hacking or Goodhart’s Law.
Two distinct failure modes hide within this proxy mismatch, and they need different cures. First, a proxy can simply be miscalibrated or too narrow, mis-estimating the objective even when nothing is pushing on it; a better-fitted or wider-coverage proxy helps. Second, a method can engage in reward hacking, driving the design toward exactly what the proxy fails to penalize (e.g., maximizing IPC by silently sacrificing thermal limits). Here, a better proxy is not enough; only an independent rejection authority can catch the spurious win.
This is not a new problem created by AI. Benchmarks, simulators, cost models, and design rules have always been approximations. What changes in Architecture 2.0 is the speed and persistence with which a method can exploit the approximation. A human may notice that a score is improving for the wrong reason. A search method may happily continue. A compound system may even produce a persuasive narrative for a proxy win unless the loop asks for calibration and counterevidence.
Failure mode: The AI-generated win that vanished at signoff
To prevent this vanishing win, calibration acts as an escalation contract. It defines where a generative method may use a proxy to rank candidates, where it must escalate, and what stronger evidence can reject a proxy win. Prediction models used in architecture have long needed validation against held-out data, higher-fidelity measurements, or carefully designed experiments (Lee and Brooks 2006; Ipek et al. 2006). The same principle applies to AI-assisted loops. If a loop claims a candidate satisfies the 3 W lighthouse envelope, the evidence must show how the power estimate was calibrated, what workload region it covers, what uncertainty remains, and what higher-fidelity result could overturn the claim.
Held-out data: a subset of a dataset reserved during model training, used exclusively to test the model’s ability to generalize to unseen inputs.
Architect’s checkpoint: The Calibration Gate Check
Beyond model calibration, benchmark governance also matters because benchmark rules are part of the loop’s evidence contract. If those rules are hidden or stale, automated optimizers can optimize version quirks, protocol gaps, or unowned metrics while appearing to make progress. As Chapter 2 and Chapter 9 show, a benchmark becomes community infrastructure only when it defines rules, versions, and submission practices that make results interpretable across a changing field. Architecture 2.0 needs a similar instinct for design loops: define the evaluation contract, preserve provenance, track versions, and treat benchmark changes as part of the evidence story.
7.6 Security, IP, and Confidentiality Boundaries
Calibration, provenance, and benchmark governance make a claim accurate, but a claim whose evidence cannot be exposed cannot be fully believed. Confidentiality is therefore part of the same machinery of graded belief and rejection as fidelity and provenance, not a separate compliance concern. Evidence that must stay private still has to be auditable enough to grade the claim and to reject it, otherwise a loop can hide an unsupportable result behind a claim of confidentiality. Architecture state is often sensitive: RTL, design specifications, process assumptions, timing constraints, floorplans, tool logs, customer workloads, proprietary traces, compiler settings, design reviews, and deployment telemetry can all reveal valuable or restricted information.
This need for auditable privacy has a direct technical consequence. Security boundaries are part of the environment and evidence design. A loop must define what data can leave an organization, what must remain local, what can be summarized, which artifacts can be shared publicly, which logs should be redacted, and which generative methods or tools can access each class of information. The trust question is not only whether the method is accurate. It is whether the loop preserves the constraints under which architecture work actually happens. The failure mode is not only leakage; it is a generative method producing a claim from evidence it cannot expose, audit, or legally reuse.
Architect’s checkpoint: The Confidentiality Boundary Check
This requirement also defines the bounds of microarchitectural security. If an unconstrained generative AI strictly maximizes Instructions Per Cycle (IPC), it acts as an accidental adversary. It will aggressively share microarchitectural state—branch predictors, translation lookaside buffers, or cache hierarchies—to squeeze out performance, silently inventing new side-channels by trading isolation for speed. The proxy mismatch here is that IPC is visible to the AI, but side-channel leakage is not. Architecture 2.0 requires a non-interference screen, a cheap structural check that a generated layout does not silently share state across trust boundaries. It is necessary but not sufficient, since it misses contention, transient-execution, and SMT channels, so passing it only earns escalation to formal side-channel verification, not commitment. A complete security screen also covers memory-integrity and disturbance faults, not only information-flow side channels. A design that trims DRAM refresh to meet a power budget can open a RowHammer path, so read-disturbance is a rejection gate in its own right.
Field note: When the missing gate shipped: Spectre and Meltdown
Takeaway. The missing rejection gate, non-interference, not any single bug, was the price, a whole verification dimension left outside the loop and run at industry scale for twenty years.
def check_side_channel_interference(rtl_candidate, isolation_policy):
"""
Rung 1 Security Gate: Rejects RTL that shares speculative structures
across defined security domains before physical synthesis.
"""
shared_structures = find_shared_state(
rtl_candidate, type=["BPU", "Cache", "TLB"]
)
for struct in shared_structures:
if crosses_domain(struct, isolation_policy):
return Reject(
reason=(f"Security violation: {struct.name} shares "
"state across trust boundaries."),
action="Partition the structure or flush on context switch."
)
return Authorize()Listing \(\ref{lst-side-channel}\) shows an example of how an automated environment might implement this requirement. It scans the candidate design for shared structures—like branch predictors or caches—and checks them against the system’s isolation policy. If a shared structure crosses a trust boundary, the loop rejects the candidate and suggests a remediation action. Codified as an explicit screen, this check catches the most obvious performance-for-isolation trades early. It does not by itself prove isolation, so a surviving candidate must still escalate to formal non-interference or side-channel verification (for example, information-flow tracking) before commitment.
For shared community infrastructure, this means the field should distinguish between public artifacts and private state. Public benchmarks, datasets, papers, and gym environments can help bootstrap shared progress. Private workloads, proprietary RTL, product traces, and process-specific assumptions often cannot be released. Architecture 2.0 should support both. The design-loop card, environment contract, and evidence checklist should let a project describe what kind of evidence exists without forcing disclosure of sensitive material. That record should include a data-access and evidence-scope field: what private state was used, what public proxy cannot support, which generative methods or tools may access each artifact, and who owns disclosure exceptions.
The practical rule for AI-assisted systems is therefore simple. Do not make confidentiality invisible. If a claim depends on private data, say what class of data supports it, what auditing is possible, what cannot be disclosed, and what public proxy would be insufficient. That is more honest than pretending every architecture loop can be reproduced from public web data.
7.7 Evidence Disputes and the Trust Checklist
Once accuracy and confidentiality are both handled, trust still has to survive disagreement, and evidence disputes are inevitable. One group may claim that a learning-based method improves a design flow. Another may argue that the baseline, workload, constraint set, tool version, or evaluation protocol was incomplete. A company may have private evidence that cannot be released. A paper may report a strong result but omit negative traces. A benchmark may reward behavior that matters less in deployment. These disputes should not be treated as distractions from Architecture 2.0. They are part of the field learning how to assign trust.
While the specifics vary, the anatomy of an evidence dispute is stable:
claim; proxy; fidelity level; assumptions; workload coverage; provenance; counterevidence; rejection authority; and final human decision.
Figure 7.2 makes that anatomy visible by tracing how a contested claim is evaluated. A dispute is not resolved by the system’s confidence; it is resolved by exposing which part of the evidence packet can support, weaken, reject, or escalate the claim.
In recent years, learned chip placement has become the field’s most public worked example of this anatomy. A 2021 result reported that a reinforcement-learning method produced floorplans competitive with human experts in far less time (Mirhoseini et al. 2021). Independent groups then disputed the claim on exactly the axes above: the baselines, the released code, and the reproducibility of the protocol (Cheng et al. 2023). The point here is not to adjudicate that dispute. The point is that the disagreement was never about whether the model ran; it was about provenance, baselines, and what evidence could reject the result. One constructive response has been to build reproducible, end-to-end benchmarks that score placement by final power, performance, and area rather than an intermediate proxy (Wang et al. 2025). That is the anatomy doing its work. A contested claim becomes tractable once the loop’s evidence, baselines, and rejection authority are made explicit. For Architecture 2.0, the reusable lesson is not the controversy itself; it is that a loop claiming placement quality must expose represented floorplan state, legal move/action space, workload and PPA records, baseline receipts, rejected alternatives, and the independent authority that can block commitment. Furthermore, because AI-assisted EDA is highly sensitive to initial conditions, true reproducibility requires exposing exact toolchain versions, environment constraints, and deterministic seeds, not just model weights.
To make this dispute anatomy practical, Table 7.5 turns it into a checklist. It is intended for reading papers, reviewing internal tools, evaluating student projects, and deciding whether an AI-assisted loop is ready for a more expensive commitment.
| Question | What a credible answer contains | Warning sign |
|---|---|---|
| What output is being trusted? | Candidate, ranking, report, code/RTL change, or commitment recommendation, with generator and method role named. | The result is described only as an AI improvement. |
| What is the claim? | A bounded architecture task, objective, workload, and commitment level. | Vague claims of automation or improvement. |
| What loop state and action contract are exposed? | State fields, legal actions, tool or environment APIs, invalid transitions, and replay receipts. | The loop can act through hidden state or unlogged tool semantics. |
| What feedback supports it? | Metrics, tool outputs, logs, reviews, and negative traces tied to a feedback budget. | Only the winning score is shown. |
| What is the fidelity? | Proxy, simulation, synthesis, emulation, signoff, deployment, or silicon level stated explicitly. | Treating all measurements as equivalent. |
| What is the provenance? | Workload and exact tool versions, tech nodes, configs, deterministic seeds, constraints, assumptions, and baselines for replay. | Hidden scripts, unstated defaults, or non-deterministic environments. |
| What is the security or confidentiality boundary? | Data classes, access rules, redaction limits, public proxy limits, and an audit path. | Private evidence is treated as invisible or unverifiable. |
| What can reject it? | Tests, formal checks, simulators, signoff rules, deployment signals, or expert review. | No independent authority can say no. |
| Who commits? | A named human or process accepts, rejects, escalates, or revises the artifact. | The loop silently turns output into decision. |
This checklist gives the book one of its practical tests. A paper, tool, or project does not need to solve the whole lighthouse prompt to be valuable. It does need to say where it sits in the loop, what evidence it produces, what it cannot prove, and what can reject it. That is how Architecture 2.0 can remain ambitious without becoming credulous.
7.8 Conclusion
This chapter asked how much an architect should believe a loop’s AI-assisted result, and what evidence can reject it before commitment. Belief is never owed to the loop. It is earned, one claim at a time, by the machinery the architect builds around the result. A feedback budget records what the check cost. An evidence ledger states what was measured and under which assumptions. A fidelity level is named honestly rather than implied. An independent authority can say no. A confidentiality boundary keeps private evidence auditable. And a commitment boundary matches the cost of being wrong.
Read together, these are not six separate safeguards but one discipline. Trust in Architecture 2.0 is a property of the loop, not of the model running inside it. A confident report, a strong proxy score, or a fluent explanation moves none of this. Each stays generated output until an authority that could have blocked it declines to. That is why the chapter treats verification as a family of rejection authorities rather than a single tool, and why the fidelity ladder and evidence ledger exist at all. They let a claim carry, wherever it stops climbing, an honest account of what it has shown and what it still cannot.
The durable move is to escalate with commitment. Cheap feedback screens, expensive feedback commits, and the loop should climb the fidelity ladder only as far as a decision’s reversibility demands before stopping at an honest level, rather than dressing a proxy win as silicon-grade proof. A result that cannot name what would overturn it, or who holds the authority to reject it, has not yet met the bar this chapter sets, however plausible it looks.
7.9 Open Research Questions
The mechanisms of trust and verification presented in this chapter establish a foundation, but turning them into robust, automated systems exposes several unsettled research directions.
Cryptographic and Formal Binding of Multi-Fidelity Evidence Ledgers. Building on the frameworks of fidelity ladders and evidence ledgers (see the discussion on “Fidelity Ladders and Evidence Ledgers” in Section 7.2) as well as commitment levels and reversibility (see the discussion on “Commitment Levels and Reversibility” in Section 7.3), tracking provenance across fragmented simulators and proprietary physical design tools is currently an informal, error-prone process. A fundamental systems challenge is designing cryptographic or formally checked evidence ledgers that bind disparate multi-fidelity traces into a unified, auditable claim. Can we construct a verification architecture where an AI-generated architecture candidate carries, when available, checkable evidence for its performance, timing, and power, helping prevent the loop from exceeding its authorized commitment boundary even under adversarial or buggy toolchains?
Autonomous Detection and Mitigation of Proxy Exploitation. As highlighted in the discussion on proxy mismatch, metric gaming, and calibration (see the discussion on “Proxy Mismatch, Metric Gaming, and Calibration” in Section 7.5), AI-assisted generators can overfit and exploit the blind spots of cheap architectural proxies. Because identifying when a candidate drifts outside a simulator’s calibrated support is largely manual, generative loops are fragile. A thesis-level challenge is to develop algorithms that dynamically map the epistemic uncertainty3 of architectural surrogates in high-dimensional design spaces, triggering high-fidelity checks, such as RTL synthesis, when proxy trust bounds are violated. How can we design compound AI agents4 that co-optimize performance and calibration while making escalation likely before a loop commits to an adversarial proxy win?
Adversarial Red-Teaming5 and the Quantification of Trust Machinery. While the trust checklist for resolving evidence disputes (see the discussion on “Evidence Disputes and the Trust Checklist” in Section 7.7) shows how to audit a single claim, we lack the experimental methodology to measure the robustness of an entire closed-loop generative system. The community must establish adversarial environments that systematically inject hidden workload drift, compromised baselines, microarchitectural side-channels, and deceptive proxies into the design process. This seeds a new class of evaluation methodology. How do we quantitatively stress-test the trust machinery itself to measure false commitment rates, bound the cost of escalation, and formally verify the efficacy of human rejection authority at scale?
3 Epistemic uncertainty refers to uncertainty in a model’s predictions caused by a lack of training data in that region, which can be reduced by gathering more data.
4 Compound AI agents are systems composed of multiple interacting AI models, tools, and logical components working together to solve a complex task.
5 Red-teaming in AI refers to proactively testing a system using adversarial techniques to identify vulnerabilities or unintended behaviors.
What to carry forward
- Reader test: What evidence would overturn the AI model’s result, and who or what has authority to reject it?
- Up next: Once trust can be evaluated for an AI-assisted claim, the next step is to run a complete loop and inspect the residue it leaves behind.