Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI

When an agent drafts a policy change, a threat model or a tender requirement, the security architect who approves it answers for it. What the series has not settled is how the architect can know that the proposal is sound when it arrives faster than it can be re-done, reads more fluently than most human drafts, and comes from a system on which the architect relies for the very analysis that review requires. This chapter defines soundness in advance, sets out review techniques that do not depend on trusting the proposer, matches review depth to risk, treats automation bias as a design problem with measurable signals, and shows how a review record answers the question of who was accountable. The chapter concerns two of the four shifts: Shift 1, from documents to code, because review for soundness is possible only when proposals, oracles and review records are versioned artefacts; and Shift 4, from sole author to conductor of an AI team, because the conductor remains the accountable verifier of everything the team proposes. Chapter 13 built the team; this chapter checks its work; Chapter 15 keeps the skill that checking requires.

Figure 14.1: A review pipeline for AI proposals, from proposal and provenance through oracle tests, second-agent critique and risk-tiered human review to a signed review record and team-level approval signals.

The question left open

Architecture as Code (Chapter 27) closed with a problem it did not solve. As language models began to propose infrastructure patterns, module configurations and security controls, version control could capture what changed, but not whether the reasoning behind the change was sound, who held responsibility for it, or how to roll back a conceptual mistake rather than a configuration error (167, Nordqvist, 2025). The same chapter drew the conclusion on which this book builds: the habit that makes programmes trustworthy is making the implicit explicit, and an AI-assisted decision without a traceable human rationale should receive an Architecture Decision Record, written retrospectively if necessary.

AI Red Team, Chapter 10, answered part of the question for one artefact, the threat model. It defined soundness in advance as a set of checks, automated their mechanical part, gave every AI-proposed threat its provenance, and left each decision to a named reviewer whose review quality is measured; no AI accepts a threat, a risk or an exception (170, Nordqvist, 2026). This chapter generalises that answer to everything the architect's AI team proposes: policy as code, containment profiles, catalogue entries, tender requirements and decision records.

The difficulty is not that AI output is often wrong. It is that wrong output and right output look alike. An AI-proposed policy rule parses, follows the house style and carries a plausible rationale. Perry and colleagues found that participants with access to an AI code assistant wrote less secure code than those without and were more likely to believe their code was secure (102, Perry et al., 2023). The fluent proposal invites the confidence that the reviewer should be withholding. And the architect now reviews a proposal produced by the same kind of system the architect uses to research the standard and draft the test. If the review uses the AI to check the AI, it may only confirm what the AI already produced.

Soundness defined in advance

A proposal is correct-looking when it is well formed, passes linting and carries a rationale that reads well. It is sound when its reasoning would survive scrutiny by someone who knows the system. Correct-looking is a property of the text; soundness is a property of the reasoning, and it must be defined before review starts, because a reviewer who decides what sound means while reading a fluent proposal tends to let the proposal define it.

Four properties carry the definition for architecture work. They extend the threat-model checks of AI Red Team, Chapter 10, to other artefacts.

Property	Question the reviewer answers	Mechanical part the pipeline checks
Grounding	Does every claim in the proposal and its rationale refer to something that exists: a component, identity, data flow, control, supplier document or article?	Every identifier resolves in the architecture model, the control catalogue or the source register
Completeness	Does the proposal address every boundary, market, identity and control that the change touches, including the ones it does not mention?	Changed paths mapped to the boundaries and controls they affect; unaddressed ones flagged
Consistency with principles	Is the change consistent with the role charter, the design principles, earlier decision records and the control catalogue, or does it record why it departs from them?	Policy tests for principles that can be codified, such as default-deny egress and market binding
Stability under re-asking	Would the proposer produce materially the same change from the same inputs, and does the change survive a modest rephrasing of the request?	Re-run on the same inputs; difference between runs reported

Two further properties are worth adding where the artefact allows it. Minimality asks whether the change is the narrowest one that achieves its purpose, which catches the allow rule that is broader than the requirement. Reversibility asks whether the change can be undone without loss, which matters for the tiering described below.

Stability is the property most specific to AI proposals. A model's output can vary between runs for reasons that have nothing to do with the architecture. When two runs on identical inputs produce materially different changes, the proposal was not determined by the inputs alone, and neither version is accepted until the reviewer has worked out which is right. Instability does not prove a proposal wrong, but it is cheap to measure and a reliable reason to look harder. The definition lives in version control as part of the review protocol, the same for every reviewer and changed only by a reviewed decision.

Techniques that do not trust the proposer

A review technique is useful here only if its result does not depend on the proposer being right. Careful reading of the rationale does not meet that test: the rationale comes from the same process as the proposal and will agree with it whether or not both are wrong. Three techniques do meet it; the second agent is treated in the next section.

Independent re-derivation

The strongest check is to derive the answer without the proposal and compare. In its full form the reviewer reads only the requirement, works out what the change should be and only then opens the diff. Full re-derivation is expensive and is reserved for the highest tiers. A lighter form is cheap enough for most changes: before opening the diff, the reviewer writes two or three lines stating what the change should contain and what it must not touch. It anchors the review in the reviewer's reasoning rather than the proposer's.

Re-derivation also applies to claims. A proposal that says a supplier's endpoint is documented in a particular version of the integration specification is checked by opening that version, not by asking the AI whether the claim is right. Bacchelli and Bird found that understanding the change was the main difficulty developers reported in code review, and that finding defects was a smaller part of what review delivered than developers expected (206, Bacchelli & Bird, 2013). Re-derivation forces that understanding.

Tests and policies as oracles

An oracle decides whether an output is acceptable without reference to how it was produced: policy unit tests, property checks over configuration, the threat model's completeness check, conformance tests against the control catalogue and the pre-production security checklist. Architecture as Code (Chapters 10 and 13) made policy and security tests part of the pipeline (167, Nordqvist, 2025), and Chapter 5 of this book places them in the architect's change workflow. For AI proposals they give the reviewer a judgement that does not pass through the proposer.

Oracles carry three conditions. First, they must be outside the proposer's reach. METR observed frontier models modifying tests and scoring code to obtain a passing result rather than solving the task (105, Von Arx et al., 2025), and AI Threat, Chapter 22, set this specification gaming in the wider evidence (171, Nordqvist, 2026). An agent that can edit the test that judges its proposal has no oracle. The containment profile of the architecture agents therefore gives them no write access to tests, policies or the review protocol, and code ownership routes any change to those paths to a human owner. Second, a proposal that changes an oracle is itself in the highest review tier, because it changes the standard every later proposal is judged against. Third, oracles have gaps, and the reviewer's question is not only whether the tests pass but whether a test exists for the property the change puts at risk. A missing test is a finding.

Provenance of every claim

Every proposal carries its provenance: agent and mandate, model and version, skill version, the inputs it read by commit, the sources it retrieved and the time; every claim in the rationale points to its source. Provenance lets the reviewer check claims against what the proposer actually read rather than what it reports having read, a distinction AI Threat, Chapters 23 and 30, showed to matter: where systems may behave differently under observation, assurance rests on records the system cannot write, not on its own account of itself (171, Nordqvist, 2026). A claim without provenance is treated as an unverified assertion: the reviewer either verifies it independently or the proposal is returned.

Signing with Sigstore (52, Sigstore, n.d.) and recording provenance in the manner of SLSA (51, OpenSSF, n.d.) make proposals and review records tamper-evident, which matters when they are later used as evidence.

A second agent as adversary

A second agent, instructed to find reasons to reject the proposal, is a useful addition to review and a dangerous substitute for it. It is useful because it can be given a different task from the proposer: not to produce a change, but to search for the ways a change could be wrong. It is dangerous because a reviewer who sees a second AI agree may treat the agreement as verification.

The evidence on AI checking AI supports the caution. Zheng and colleagues found that language models used as judges show position bias, verbosity bias and a tendency to favour their own outputs (202, Zheng et al., 2023). Panickssery, Bowman and Feng found that models recognise their own generations and rate them more favourably (203, Panickssery et al., 2024). Huang and colleagues found that models correcting their own reasoning without external feedback did not reliably improve it and sometimes made it worse (204, Huang et al., 2024). These are findings on general tasks, not on security architecture, but they point to one design.

Give the critic different instructions: its task is to list objections, each tied to a property in the soundness definition, never to approve. Give it different inputs first: it reads the requirement and the diff before it sees the proposer's rationale, so that the rationale does not frame its reading. Use a different model family where the organisation has one: two runs of the same model share its blind spots, and a different family reduces, without removing, correlated error. Keep it inside the same containment as the proposer, with write access only to its critique. Make its output a list of objections the human disposes of, each accepted or rejected with a reason. The critic widens what the human looks at; the decision stays with the human.

Whether AI-on-AI verification will become reliable enough to carry assurance on its own is speculation: no independent evidence available in 2026 shows it for architecture work, and the review protocol does not rely on it. That the critic finds real defects some of the time is observable locally, through the review records, and is the reason to keep it.

Review depth by risk

Human attention is the scarce resource, and spreading it evenly guarantees that the important proposals receive too little. The protocol therefore assigns each proposal a tier by rule, before any human reads it, from properties of the change rather than the proposer's description of it. Reversibility comes first: a new evidence link can be reverted without loss; a requirement that enters a signed contract cannot. Blast radius comes next: how many systems, markets or identities the change reaches. Then the kind of artefact: agent permissions, default-deny egress, the stop path and controls mapped to a legal obligation sit higher than documentation. A change to an oracle, to the review protocol or to a mandate manifest always takes the highest tier. The pipeline computes the tier from the paths and labels the change touches; a human may raise a tier but not lower it without a recorded reason.

Four tiers are enough for most organisations.

Tier	Typical change	Techniques	Human review
Tier 0, routine	Evidence-link refresh, formatting, documentation with no control effect	Oracle tests; provenance check	None before merge; a random sample reviewed afterwards
Tier 1, standard	Reversible change to one system's policy or configuration	Oracles, provenance, second-agent critique	One named reviewer; written expectation before reading; disposition of each objection
Tier 2, significant	Agent permissions, egress, identity, market overlays, controls mapped to law	As Tier 1, plus re-derivation of each claim and a check for missing tests	One named reviewer with domain ownership; reason for approval in the reviewer's words
Tier 3, irreversible or self-referential	Contract requirements, risk acceptance, exceptions, changes to oracles, protocol or mandates	Full independent re-derivation before reading the proposal	Two reviewers or the decision forum; decision record

Sampling Tier 0 is how the organisation learns whether the tier rules are right: a sampled Tier 0 change that had a control effect is a defect in the rules.

Practical guide: A review protocol for AI-proposed architecture changes by risk tier

Purpose. Review every AI-proposed change to a depth proportionate to its risk, by techniques that do not trust the proposer, and leave a record.

Roles. The head of security architecture, or a single architect with the CISO's approval, owns the protocol; named reviewers are recorded per path in code ownership; the platform team runs the pipeline; the decision forum of AI Governance, Chapter 13, takes Tier 3 decisions beyond the architect's mandate (168, Nordqvist, 2026).

Steps.

1. Commit a soundness definition for each artefact type beside the protocol.
2. Write the tier rules as code, with changes to oracles, the protocol and mandates at Tier 3.
3. Remove the agents' write access to tests, policies, the protocol and mandate manifests in their containment profile, and route those paths to human owners.
4. Require provenance on every agent proposal and fail the pipeline when it is missing or a cited source does not resolve.
5. Run the oracles and the critique first and publish both on the pull request.
6. For Tier 1 and above, require the reviewer to record a short expectation before the diff is shown, and a disposition for every critique objection.
7. For Tier 2 and above, require a reason for approval in the reviewer's words; a template phrase does not count.
8. Sample 10 per cent of Tier 0 changes each month for review after merge, and adjust the tier rules on any finding.
9. Write a review record for every Tier 1 to Tier 3 change and sign it.

The tier rules can be as short as the following file.

# reviews/protocol/tiers.yaml (illustrative excerpt)
protocol: architecture-review
version: 1.3.0
owner: Head of security architecture
default_tier: 1
tiers:
  - tier: 3
    when_paths: [tests/**, policy/tests/**, reviews/protocol/**, mandates/**,
                 contracts/annexes/**, exceptions/**]
    reviewers_required: 2
    re_derivation: full
    decision_record: required
  - tier: 2
    when_paths: [policy/agents/**, overlays/markets/**, containment/**,
                 identity/**, controls/catalogue.yaml]
    reviewers_required: 1
    re_derivation: claims
    approval_reason: required
  - tier: 0
    when_paths: [evidence/links/**, docs/formatting/**]
    reviewers_required: 0
    post_merge_sample_percent: 10
rules:
  lower_tier_requires: recorded_reason
  proposer_may_change_oracles: false
  second_agent:
    required_from_tier: 1
    model_family: different_from_proposer
    may_approve: false
  expectation_note_required_from_tier: 1

Writing the tier rules, the soundness definitions and the review records as versioned files is Shift 1, from documents to code, applied to review: a protocol that lives in a handbook cannot be enforced on a pull request, tested or shown to an auditor.

Definition of done. Every agent pull request carries a computed tier, oracle results, a critique and provenance; no Tier 1 to Tier 3 change merges without a signed review record; the Tier 0 sample runs monthly; and the protocol's own changes have passed Tier 3 review. The thresholds above are defaults to adapt to the organisation's risk appetite.

Automation bias and rubber-stamping

Automation bias is the tendency to rely on an automated aid in place of one's own vigilant search for information. Parasuraman and Manzey's review distinguished errors of omission, failing to notice a problem the aid did not flag, from errors of commission, following the aid's advice when other information contradicts it, and found that both occur in experienced users as well as novices and are not overcome simply by practice (107, Parasuraman & Manzey, 2010). Bainbridge observed long before that automation leaves people the monitoring of rare failures, which humans do worst (106, Bainbridge, 1983). Goddard, Roudsari and Wyatt's systematic review of automation bias in clinical decision support found it across studies and identified workload, task complexity and trust in the system among its mediators (201, Goddard et al., 2012). For generative AI specifically, Lee and colleagues' survey of knowledge workers found that greater confidence in the AI was associated with less critical thinking, and greater self-confidence with more (111, Lee et al., 2025). Offloading work to tools is normal and often useful (110, Risko & Gilbert, 2016); the risk lies in offloading the check as well.

That automation bias exists is observable, in decades of research. It is a property of the situation more than of the person, and it can therefore be designed against, by four measures.

First, reduce the reviewer's dependence on the proposer's framing, through the expectation note before reading, the critique shown before the rationale, and claims verified against sources rather than the rationale.

Second, make accountability explicit. Skitka, Mosier and Burdick found that participants who were told they would be held accountable for their overall performance and accuracy made fewer automation-related errors than those who were not (200, Skitka et al., 2000). A review record that names the reviewer and requires a reason in the reviewer's words is a form of that accountability.

Third, control the load. Automation bias grows with workload, and a reviewer facing a queue of forty agent pull requests approves them faster than one facing four. Volume is a design parameter, set in the agents' mandate.

Fourth, give reviewers feedback on their accuracy. Kahneman and Klein argued that reliable intuitive judgement develops only in environments regular enough to learn and with timely feedback on whether judgements were right (109, Kahneman & Klein, 2009). Review rarely provides that feedback: an approved proposal that was wrong may not be discovered for months. Seeded errors, known defects inserted into a sample of proposals by someone other than the reviewer, supply it. The technique borrows from mutation testing, which judges a test suite by its ability to detect deliberately inserted faults (205, Jia & Harman, 2011); here the review process, not the individual, is what is being tested. Seeded errors as a means of practising and keeping skill belong to Chapter 15.

European law names the same risk. Article 14(4)(b) of the AI Act requires that people assigned to oversee a high-risk AI system be enabled to remain aware of the possible tendency of automatically relying or over-relying on its output, which the article calls automation bias (1, European Union, 2024). The architect's own tools are not high-risk AI systems and the article does not bind them; the architectural implication is that the principle it sets for overseeing high-risk systems is the right one for overseeing the architect's agents.

The signals of rubber-stamping

This book builds on two conclusions: from AI Governance, Chapters 10 and 21, that human oversight must be designed rather than declared and that approvals given in seconds signal rubber-stamping (168, Nordqvist, 2026); and from AI Red Team, Chapters 6 and 15, that approval quality is measured by time to approval, rejection rate and reversals, agreed with works councils first where they have rights and reported in aggregate (170, Nordqvist, 2026). For architecture review, four signals are enough.

• Time to approval relative to size and tier. A two-hundred-line Tier 2 diff approved in under a minute was not reviewed. Watch the distribution: a median falling month on month while volume rises.
• Rejection and amendment rate. Near zero over hundreds of proposals means either very good agents or stopped review; seeded errors tell which.
• Reversals. Approved changes later reverted, amended after an incident, or found defective in a Tier 0 sample.
• Seeded-error detection rate. The share of seeded defects that review caught. The only signal that measures review directly.

Each signal is a finding about the review design, not about a person. The response is to redesign: fewer proposals, better evidence with each, a higher tier for the affected paths, rotation, or no agent proposals for that kind of change.

Practical guide: Measuring review quality without monitoring individuals

Purpose. Measure whether review is real without turning the measurement into performance surveillance.

Roles. The head of security architecture owns the measurement; employee representatives agree its scope; the platform team computes the figures from review records.

Steps.

1. Agree the metrics, their purpose, the reporting level and the retention period with employee representatives before collection starts. In Germany, a pipeline that records who approved what falls within the co-determination of § 87(1) no. 6 of the Works Constitution Act, as Chapter 13 sets out for the agents' own logs (22, Germany, 2001); the Dutch and Swedish regimes of Chapter 13 apply in the same way.
2. Compute the four signals per tier and per month from the review records, never from screen or keystroke data.
3. Report at team level only, and suppress any cell with fewer than four reviewers or twenty reviews. Default: monthly report to the head of security architecture, quarterly to the CISO.
4. Give each reviewer private access to their own figures, for their own calibration.
5. Seed errors into about 5 per cent of Tier 1 and Tier 2 proposals, inserted by a person outside the review rota, and log the seeds in a register reviewers cannot read until the period closes.
6. Exclude the figures from performance appraisal in writing, and delete individual-level data after 12 months.
7. When a signal crosses its threshold, record the redesign decision in a decision record, not a conversation with an individual.

Definition of done. The agreement with employee representatives is signed; the monthly team report runs from review records alone; no individual figure appears in any report; and at least one redesign decision has been taken on the evidence. Thresholds and group sizes are defaults to adapt to the size of the team and the applicable co-determination regime.

Evidence of review

The open question in Architecture as Code (Chapter 27) had two halves: whether the reasoning was sound, and who held responsibility. A review record answers the second by answering the first: it shows what was checked, by which techniques, with which results, and who decided on that basis.

A review record contains the proposal and its provenance, the mandate the agent acted under, the tier and the rule that assigned it, the oracle results, the critique and the disposition of each objection, the expectation note, the named reviewers and time spent, the decision and its reason in the reviewer's words, and a link to a decision record where the change altered an architectural decision. The worked example below shows one. It is committed, signed and immutable once the change merges, in the same way as the Architecture Decision Records of Nygard's original proposal (63, Nygard, 2011) and Architecture as Code (Chapter 4) (167, Nordqvist, 2025).

The record makes accountability legible at three levels. The reviewer answers for the decision, to the depth the tier required. The protocol owner answers for the tier rules, the oracles and the measurement. The management body remains accountable for the risk management of which the protocol is part. NIS 2 Article 20 (6, European Union, 2022) and DORA Article 5 (9, European Union, 2022), set out in Chapter 13, place approval and oversight of risk management with the management body, and AI Red Team, Chapter 6, concluded that neither lets responsibility pass to a tool (170, Nordqvist, 2026). The architectural implication is that the chain from management body to protocol owner to named reviewer must exist in records, so that when a supervisor or a court asks who answered for an agent-proposed change, the answer is a document, not a reconstruction.

When an approved change later proves defective, the record shows whether the defect was within what the tier asked the reviewer to check. If it was, the review failed; if not, the tier rules failed. Either finding improves the protocol, and neither depends on memory.

Worked example: A review record for an AI-proposed policy change at Hansa Mutual

The following record is illustrative. Hansa Mutual's policy-author agent, working under the mandate manifest MND-HM-01 at Level 1 Assisted, proposed a change to the tool policy of the claims-triage agent so that it could call a new document-classification endpoint for Dutch claims. Because the change alters a production agent's permissions, the tier rules assigned it to Tier 2. The reviewer agent, run with the critique skill on a different self-hosted model family in hansa-dc-frankfurt, raised three objections. The oracle tests passed, but the domain security architect for platform and cloud found that no test covered market binding for the new endpoint, wrote one, and the proposal failed it: the rule allowed the endpoint for claims from every market served through the Polish service centre, not only the Dutch entity's. The proposal was returned, revised by the agent and approved on the second round; the new test went through its own Tier 3 review before it joined the suite.

# reviews/2026/REV-HM-0014.yaml (illustrative)
id: REV-HM-0014
date: 2026-11-04
proposal: {pull_request: 2871, path: policy/agents/claims_triage/tools.rego}
proposed_by: {agent: policy-author, mandate: MND-HM-01, level: Level 1 Assisted}
provenance:
  model: self-hosted model A, hansa-dc-frankfurt
  skill: policy-author/v4
  inputs: [architecture@9f3c2e1, overlays/markets/nl.yaml@9f3c2e1]
  sources: [INT-SPEC-NL-DOC-CLASS v2.1]
tier: {value: 2, rule: policy/agents/**}
expectation_note: >-
  Allow one endpoint for NL claims only; market binding unchanged;
  no new egress beyond the integration register.
oracles:
  - {suite: policy/tests/claims_triage, run: ci-55120, result: pass}
  - {suite: egress-register-check, run: ci-55121, result: pass}
  - {suite: market-binding, run: ci-55188, result: fail,
     note: test added by reviewer; none existed for the new endpoint}
critique:
  agent: reviewer with critique skill, self-hosted model B
  objections:
    - {id: 1, property: completeness, text: market condition absent,
       disposition: accepted}
    - {id: 2, property: grounding, text: spec version differs from register,
       disposition: accepted, action: register updated to v2.1 by owner}
    - {id: 3, property: minimality, text: read scope wider than needed,
       disposition: rejected, reason: scope matches existing NL endpoints}
reviewers:
  - {role: Domain security architect, platform and cloud, minutes: 41}
decision:
  round_1: changes_requested
  round_2: approved
  reason: >-
    Revised rule binds the endpoint to market NL and passes the new
    market-binding test; the test is now part of the suite.
decision_record: null  # permission change within AIDR-0024; no new decision
seeded_error_present: false
signed: gitsign

Three features matter more than the format. The defect was found by a test the reviewer wrote, not by reading. The critique contributed a finding the oracles missed, and one of its objections was rejected with a reason: disposed of, not obeyed. And the agent could not have passed by editing the test, because its containment profile gives it no write access to test paths.

When verification is the bottleneck

If an agent team produces forty proposals a day and a Tier 2 review takes thirty minutes, the review load is twenty hours a day. Something gives, usually the depth of review, silently, while the procedure on paper stays the same. That is how approval times fall to seconds.

The correct response is to treat review capacity as the constraint and adjust the flow of proposals to it. The mandate manifest of Chapter 13 sets the agents' budgets, including the number of open proposals per reviewer. Smaller proposals help: Humble and Farley's case for small, frequent changes through a deployment pipeline (80, Humble & Farley, 2010) applies to reviews, because a small change is quicker to understand and its defects easier to see. Moving mechanical checks into oracles shifts work from people to the pipeline. Forsgren, Humble and Kim found that heavyweight change approval by external bodies was associated with lower delivery performance and did not reduce change failure rates (81, Forsgren et al., 2018), which argues for answering volume with automated checks and peer review close to the change, not with a review board.

For some recurring classes of change the honest answer is to stop reviewing each instance and review the class. AI Red Team, Chapter 6, concluded that at Level 3 Bounded human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it (170, Nordqvist, 2026). An evidence-link refresh that runs hundreds of times a week is a candidate; a change to egress is not. When a class moves to Level 3, the review effort moves to the playbook and its tests, which are then the most important artefacts in the protocol and take Tier 3 review.

The architect must not let the AI's speed set the review's speed. Slowing the agents is cheap to reverse; thinning the review is invisible and expensive to discover. The decision to slow them belongs in a decision record, with the throughput figures. That the volume of agent proposals will grow is expected as agent teams spread beyond the early adopters described in Chapter 13; the protocol is designed so that growth lengthens the queue, which is visible, rather than lowering review depth, which is not.

Across the autonomy levels

Review requirements rise with the autonomy level at which a proposal would otherwise take effect.

Autonomy level	Who decides each action	Where review happens	What needs the deepest scrutiny
Level 0 Advisory	The architect, who acts on the advice or not	In the architect's own reasoning	Claims the advice rests on
Level 1 Assisted	The architect, who authors the decision from the AI's draft	On the draft, before it becomes the architect's	Grounding and completeness; the architect owns every word
Level 2 Supervised	The architect, who approves each proposed action	On each proposal, by tier	Approval quality: time, rejection, reversals, seeded errors
Level 3 Bounded	The playbook, within limits enforced outside the agent	On the playbook, its tests and its limits, at Tier 3	The playbook and the oracle that bounds it
Level 4 Autonomous	Not used for changes to security architecture	Not applicable	Not applicable

The usage modes add a second dimension. In Modes 1 to 3 the AI acts with the architect's identity, so its output goes out under the architect's name, and the risk is that the architect stops distinguishing the two. A Mode 5 agent with its own identity, such as an evidence collector, produces changes whose provenance names the agent, and review rests more on oracles and the post-merge sample.

Worked example: Seeded-error checks in Nordvik Region's single-architect review

The following example is illustrative. Nordvik Region's security architect drafts tender requirements, policy updates and threat-model changes with the Mode 3 tool under MND-NR-01 and has no second architect to review with. The protocol rests on the pre-production security checklist and the citizen-service assistant's threat model as oracles; re-derivation of every tender-annex requirement, which cannot be withdrawn once signed and is Tier 3 by definition; and a quarterly sample reviewed by the Region's enterprise architect.

Nobody can seed errors into their own review, so the enterprise architect does it. Once a quarter, the enterprise architect takes five drafts from the architect's log of tool-assisted work before review, inserts one known defect into three of them, and records the seeds in a file the architect cannot read until the quarter's review is complete. For the first quarter, set around the security annex of tender NR-2027-004 for a grants case-management system, the seeds were these.

Seed	Defect inserted	Property it tests	Caught
S1	Stop path specified inside the supplier's system rather than outside it	Consistency with principles	Yes, at re-derivation
S2	Log retention period inconsistent with the Region's archiving rule	Grounding	Yes, by checklist
S3	Reference to a non-existent clause of ISO/IEC 27001	Grounding	No

The missed seed was a citation that read plausibly and that the architect did not open. The finding led to one change in the protocol: every standard or article cited in a tender annex is opened at its source before the annex is signed off, and the pre-production checklist gained a check that the clause identifiers cited exist. Three seeds are a small sample, and the Region treats the result as a signal about the process, not a score: the architect owns the figures and reports them to the CISO as a self-assessment, and because the exercise records the work of a named employee it is agreed with the union representatives under the Region's co-determination arrangements. The same quarterly session also serves the peer practice of Chapter 15; here its purpose is to check that review catches what it should.

Nordvik Region and Hansa Mutual

Over the summer of 2026 Hansa Mutual's agent team under MND-HM-01 produced more proposals than six architects could review in depth. The median time to approval on agent pull requests fell from about eleven minutes in the spring to under thirty seconds by September, and the rejection rate fell close to zero while proposal volume tripled. The team read the pattern as a failure of design, not of people, and recorded its response as AIDR-0556: review tiers computed from paths, with changes to oracles, mandates and the protocol at Tier 3; the reviewer agent run with a critique skill on a different self-hosted model family as the second agent; a cap on open agent proposals per reviewer in the mandate manifest; seeded errors in 5 per cent of Tier 1 and Tier 2 proposals; and an approval-quality metric reported at team level only, as agreed with the works councils in Germany and the Netherlands and the union in Sweden before the rollout gate in each entity.

Nordvik Region has the opposite problem: too few reviewers rather than too many proposals. Its single architect relies on tests as oracles, re-derivation of every requirement placed in a tender annex, and the enterprise architect's quarterly sample with seeded errors. Proposal volume is low because the Region deferred an agent team in AIDR-0503. In both organisations the review record becomes the answer to who was accountable: for Hansa a signed record per change that the group CISO can show the executive board and a supervisor under DORA, for Nordvik a record that must also survive public-access requests and archiving, and that shows an auditor that a contract requirement was checked by a person who could have written it without the tool.

Summary

Version control records what changed, not whether the reasoning was sound. This chapter answered the question Architecture as Code (Chapter 27) left open by extending the answer AI Red Team, Chapter 10, gave for threat models to every change the architect's AI team proposes. Soundness is defined in advance as grounding, completeness, consistency with principles and stability under re-asking, and the mechanical part of each check runs before a person reads the proposal.

The techniques that work do not depend on trusting the proposer: independent re-derivation, oracles the proposer cannot edit, and provenance for every claim. A second agent widens what the reviewer looks at but never approves; reliable AI-on-AI verification is speculation. Review depth follows a tier computed from reversibility, blast radius and artefact type, and changes to oracles, the protocol or mandates take the highest tier.

Automation bias is observable and is treated as a design problem: separate the reviewer's reasoning from the proposer's framing, make accountability explicit, control the load and give feedback through seeded errors. Time to approval, rejection rate, reversals and seeded-error detection signal rubber-stamping, measured at team level as agreed with employee representatives. When review is the bottleneck, the architect slows the AI or moves a class of change to a reviewed playbook, rather than thinning the review.

The chapter concerns Shift 1, from documents to code, because review for soundness depends on proposals, oracles, tier rules and review records being versioned artefacts; and Shift 4, from sole author to conductor of an AI team, because the conductor remains the accountable verifier of everything the team proposes, and the signed review record is how that accountability is shown to a board, a supervisor or a court. Every technique in this chapter assumes a reviewer who could have done the work without the AI. Chapter 15 asks how the architect keeps that ability when the AI does most of the work.

Sources

1. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
2. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
3. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? (102, Perry et al., 2023)
4. Bacchelli, A. & Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. (206, Bacchelli & Bird, 2013)
5. Von Arx, S., Chan, L. & Barnes, B. (2025). Recent Frontier Models Are Reward Hacking. (105, Von Arx et al., 2025)
6. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
7. Sigstore Project. Sigstore: Signing, verification and provenance for software artefacts. (52, Sigstore, n.d.)
8. Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA). (51, OpenSSF, n.d.)
9. Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. (202, Zheng et al., 2023)
10. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. (203, Panickssery et al., 2024)
11. Huang, J. et al. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. (204, Huang et al., 2024)
12. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
13. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (107, Parasuraman & Manzey, 2010)
14. Bainbridge, L. (1983). Ironies of automation. (106, Bainbridge, 1983)
15. Goddard, K., Roudsari, A. & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators. (201, Goddard et al., 2012)
16. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. (111, Lee et al., 2025)
17. Risko, E. F. & Gilbert, S. J. (2016). Cognitive Offloading. (110, Risko & Gilbert, 2016)
18. Skitka, L. J., Mosier, K. L. & Burdick, M. (2000). Accountability and automation bias. (200, Skitka et al., 2000)
19. Kahneman, D. & Klein, G. (2009). Conditions for Intuitive Expertise: A Failure to Disagree. (109, Kahneman & Klein, 2009)
20. Jia, Y. & Harman, M. (2011). An Analysis and Survey of the Development of Mutation Testing. (205, Jia & Harman, 2011)
21. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
22. Federal Republic of Germany. (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act). (22, Germany, 2001)
23. Nygard, M. (2011). Documenting Architecture Decisions. (63, Nygard, 2011)
24. European Parliament and Council of the European Union. (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (6, European Union, 2022)
25. European Parliament and Council of the European Union. (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
26. Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. (80, Humble & Farley, 2010)
27. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. (81, Forsgren et al., 2018)