Decision Rights and Evidence: Who Decides, and How We Know

In the scenario of Chapter 18, the group chief information security officer of Hansa Mutual reports to the executive board on 31 March 2027. The episode is illustrative, like everything about Hansa Mutual in this book. The first stop drill of the IT-operations agent, the agent that executes pre-approved operations with write access to the group's production systems, took 17 minutes against a budget of 5. The alert reached a duty analyst who did not hold the decision, and the 15-minute access tokens outlived the revocation (4, Nordqvist, 2026).

The board does not ask how the agent works. It asks one question, for every agent with write access to production: how long does it take to stop it. Then it does something the landscape model records on the same date. The decision right over write access to production, which until that morning sat with the head of the group AI platform, moves to the executive board itself. Nothing about the agent changes: its permissions, its playbook and the policy that checks each of its actions stay as they were. What changes is who holds the seat, and the board wants a number, in minutes, every quarter.

That meeting contains the chapter. A decision right is the authority to say what an AI use may do, to change that, and to stop it. Evidence is how anyone, inside the organisation or outside it, knows that what was decided is what happens. A decision right without evidence is a hope; evidence without a decision right is a report nobody has to act on. Contour draws them as two of its six standard views. V4, the decision-rights view, shows for every unit who decides, up to which autonomy level, for which class of action, and whether anything outside the model enforces the limit. V5, the evidence view, shows where the proof comes from and whether the system produced it or a person declared it. This chapter teaches both, shows how a board member, an auditor and an engineer read them, and ends with a one-page review and a record you can copy.

Both views draw the same marks as the one-page landscape of Chapter 14: one mark for each AI use, coloured by usage mode (Mode 0 Ambient AI to Mode 5 Autonomous production agents) and placed by autonomy level (Level 0 Advisory to Level 4 Autonomous), as Chapters 3 and 4 explained. The decision tiers T0 to T4 and the line between automatic and attested evidence are the book's own, defined below.

Figure 17.1: Hansa Mutual's decision-rights view (V4) on 31 December 2027, with the executive board holding the seat for every agent with write access to production. Illustrative: rendered from landscape/models/hansa_mutual.yaml.

The seat

Find the small grey circles at the right-hand end of the bars in Figure 17.1. Each carries a digit. The circle is the seat, and the digit is the decision tier of the person who holds the decision right for the unit. It sits at the end of the bar because the right it names is the right over the ceiling: the holder decided how far the bar reaches and may move it or cut it short.

The tiers are a scale of who, not of what. T1 is the operator or user. T2 is the system owner or the architect. T3 is an executive. T4 is a board, a management body or an elected body. T0 is nobody named, drawn by drawing nothing: a mark without a seat. The tiers grade the holder's standing; they are not the four tiers of AI Governance, Chapter 13, which route each decision to the lowest tier that can take it with the necessary evidence (2, Nordqvist, 2026).

Most seats in Figure 17.1 read 2, as they should: the system owner knows the unit. The seats that move are the chapter's story.

Figure 17.2: The same view on 1 January 2027. Between the two dates three seats move and no bar moves: the IT-operations agent from T2 to T4, the claims-triage agent from T2 to T3, and the ambient AI from no seat to T2. Illustrative: rendered from landscape/models/hansa_mutual.yaml.

The IT-operations agent's seat moves to T4 in March, in the opening scene. The claims-triage agent's moves to T3 in April, when the group reassesses the agent's work-allocation function under its policy on AI in management. The third move is the easiest to miss and the most instructive. At the start of the year the top row, the AI features vendors switch on inside licensed software across seven markets, has a bar running the full width to Level 4 Autonomous, no diamond and no seat: the vendors set that level, and nobody at Hansa Mutual is named. By the end of the year the row has a seat reading 2, because the head of the group AI platform, as owner of the AI inventory, takes the right to say which supplier-enabled features the group relies on and writes notice clauses into its register of contracts. The bar is unchanged, because the group cannot change what a vendor's product does; the seat is the one thing an organisation can always add.

Now the first of three conclusions this chapter rests on. A seat is a name, and AI Boss, Chapters 4 and 33, concludes that a name is necessary and not sufficient (7, Nordqvist, 2026). Attaching a person to a system's output does not make that person a decider. That volume lists six capabilities the named person must have: they can be identified; they can decide otherwise with real authority; they can see the information the recommendation rested on, what it did not use and what the person affected has said; they have the time the decision deserves; they are protected if they deviate; and they answer for the decision. A person with the name and without the means is in what it, borrowing the phrase, calls the moral crumple zone: the part of the arrangement that absorbs the blame on impact. The review below asks the six questions before the seat is drawn, because a seat for someone who could not in practice stop the unit is worse than none: it tells the board the question is answered.

Author's note needed: a short account, 150 to 250 words, from the author's own practice of a post-incident review in which the named owner of a system turned out never to have been given the means to stop it, to sit here before the six capabilities are applied to the two landscapes. It should show the gap between the name and the right, not assign blame.

The seat is the same neutral grey whoever holds it, because the question this book asks about people is not where they sit in the hierarchy but whether they hold the right.

The ceiling

The bar in V4 is the unit's ceiling: the highest autonomy level at which it may act for any of its actions. A unit at Level 1 Assisted has a short bar; the AI drafts, a person reviews and executes. A unit at Level 3 Bounded has a bar reaching the fourth column; the AI executes pre-approved, reversible actions within a codified playbook, and a person is informed and can stop it. AI Red Team, Chapter 6, concludes that the line between Level 2 Supervised and Level 3 Bounded is the most important in the scheme, because above it a class of actions happens without a person approving each one (4, Nordqvist, 2026).

A unit rarely does only one kind of thing, which is why the view has thin bars under the thick one. Each thin bar is one action class with its own level. Read the SOC investigation agent in Figure 17.1. Its thick bar reaches Level 3 Bounded and its seat reads 2, the group chief information security officer. Underneath are four thin bars. Enriching an alert, gathering context and writing a summary, runs at Level 4 Autonomous, the full width, because nothing about an enrichment needs undoing. Isolating a workstation and revoking a session run at Level 3, within the playbook. Wiping a host runs at Level 0: the AI may propose it and a person does it. One unit, four levels, and the thick bar shows the highest among the actions that change something. Where a thin bar runs the full width, something happens without approval, and the reader should ask what it would take to undo it.

The shading answers the undo question before it is asked. Three rows in Figure 17.1 have a faint tinted cell in the Level 4 column: the IT-operations agent, the recruitment screening and the underwriting-support model, all at R3 Hard to reverse. The renderer shades the Level 4 cell of every unit at R3 or R4, the empty-corner rule of Chapter 4: a well-governed landscape has nothing both autonomous and irreversible, and anything drawn into that cell is the first question in the room. No bar reaches a shaded cell.

The diamond and the stop path

The small black diamond at the end of a bar is the policy point: a policy decision point outside the model that evaluates every action the unit attempts against a versioned manifest before the action executes, and refuses what the manifest does not allow. What matters, as AI Platform and Security, Chapter 11, puts it, is that deterministic code outside the model makes the decision, and that a skill changes what the agent is told, never what it is permitted to do (3, Nordqvist, 2026). The diamond is filled when such a point enforces, hollow when one is planned, absent when there is none, and in V4 it is drawn at the ceiling, where its job is to say whether the ceiling is a rule or a hope.

Here is the second conclusion, which the notation enforces by rule. AI Red Team, Chapter 6, concludes that a Level 3 capability without a policy point is Level 4 with a misleading label (4, Nordqvist, 2026). A playbook in the model's instructions bounds nothing; one enforced outside the model bounds the agent. So the renderer draws any mark at Level 3 Bounded without a filled diamond with a thin red outline. There is no red in Figure 17.1, because each of Hansa Mutual's units at Level 3 has an enforced policy point.

The policy point says what the unit may not do. Neither it nor the seat says what happens when the unit should be stopped altogether. That is the stop path: the named people who may stop the unit, the mechanism they use and the time it takes. A stop path that runs inside the system it stops fails when it is needed. AI Governance, Chapter 13, names the stop decisions in advance, so that the on-call incident commander and the use-case owner may each stop a system unilaterally; AI Threat, Chapter 24, builds the path from signals the agent does not produce to named stop holders and a platform kill switch that revokes the agent's credentials from outside its reach (2, Nordqvist, 2026) (5, Nordqvist, 2026).

Contour gives the stop path no glyph of its own. I considered one and decided against it, because a symbol would say "there is a kill switch" with nothing behind it. Instead the stop path is a property the decision record names, the drill measures and the evidence view shows as a test result. A seat is real when its holder can produce a recent measured time for a stop, from a drill, not from a design.

Evidence against attestation

Turn to the second view and the third conclusion. Evidence, in this book, is a machine-generated artefact that demonstrates that a control operated: a log the system wrote, a test that ran, a gate that passed or failed. Attestation is a person or a supplier asserting that a control operated: a questionnaire answer, a contract clause, a policy document, a signature. AI Governance, Chapter 11, draws the line in those words and concludes that attestation is not evidence (2, Nordqvist, 2026). It matters more with AI because an agent's own report of what it did is attestation by the thing being checked.

V5 draws the distinction so that it cannot be missed. There is one row per unit and five columns: logs, tests and evaluations, gates and policies as code, attestations, and none. A filled cell means automatic evidence of that kind; a hatched cell means attested evidence; the word "none" in red means no evidence at all. Read Nordvik Region at the start of 2027.

Figure 17.3: Nordvik Region's evidence view (V5) on 1 January 2027, before the supplier evidence schedule. Illustrative: rendered from landscape/models/nordvik_region.yaml.

The pattern is that of an organisation which builds a little and buys a lot. The units the Region built or hosts itself, the citizen-service assistant, the correspondence classifier, the case-note summariser, the staff assistant, the agentic work tools and the benefits-triage system, have two or three filled cells each. The units it procures, the rostering system, the enterprise conversational assistant, the embedded workplace assistant and the paused recruitment screening, have one hatched cell each and nothing else: the proof that those controls hold is a supplier's word. And the top row, the AI features vendors switch on inside licensed software, has a red "none".

Figure 17.4: Nordvik Region's evidence view (V5) on 31 December 2027, with the supplier evidence schedule in force. Illustrative: rendered from landscape/models/nordvik_region.yaml.

Three changes by the end of the year teach three different lessons. The red "none" is gone: the ambient features that process personal data are inventoried in June and notice clauses requested, so the top row has a hatched cell, which is progress and still a promise. The rostering system moves from one hatched cell to two filled cells and a hatched one: when travel-time and rest constraints become hard constraints in March, the system begins to produce logs and gate results of its own. And the benefits-triage system, the Region's high-risk unit, gains a hatched cell beside its three filled ones.

That last change shows what attestation is for. Because the benefits-triage system runs in the Region's own data centre, the Region has always had its own logs, evaluation gates and tests. What it lacked was a dated set of declarations about the supplier's side: the stop path outside the supplier's system that the tender required, the notice period before a model change, the retention of decision logs. The supplier evidence schedule, in force from October after the external stop drill is re-run within its budget, is that list with a date against each item. It is drawn hatched, because that is what it is: the supplier's word, next to the logs.

The reading rule for V5 follows. A hatched cell beside filled cells is honest. A hatched cell alone on a unit at R3 Hard to reverse is the question to ask, because a control whose proof is a promise is protecting an outcome that takes weeks to undo. AI Threat, Chapter 30, and The Transformed Security Architect, Chapter 9, give the three words an auditor uses: a control is verified when a test that re-runs its scenario has passed recently and produced evidence by operation, declared when somebody says so, and failed when the test ran and did not pass (5, Nordqvist, 2026) (6, Nordqvist, 2026). Filled is verified or failed; hatched is declared. The result sits in an evidence manifest behind each cell: a list of what was collected, by what, from where and who may read it, kept where the agent cannot alter it. The stop drill is one more test in it, a number produced by running the stop and read by the board as one line on one page.

Reading the two views

Three short scenes, all illustrative, show three readers holding the same two pages, drawn from one model.

A board member

A member of Hansa Mutual's executive board opens Figure 17.1 and does what Chapter 4 told every reader to do first: looks for anything in a shaded cell. There is nothing. Then the seats that read 4: one, the IT-operations agent. Then the thick bars that run the full width: one only, the ambient AI, with a seat but no diamond. The thin bars at Level 4, enrichment and telemetry reading, are reversible actions. Three questions follow. For the unit whose seat we hold, what was the time to stop at the last drill. For the unit whose seat rose to the executive level in April, who on the executive holds it and what are they answerable for. For the top row, what are we relying on from vendors that we have not decided.

An auditor

An internal auditor, or a supervisor's, opens Figure 17.4 and reads it as a sampling frame. Every filled cell is a claim that automatic evidence exists; the auditor samples, asks for the manifest behind each cell and re-performs: runs the test again, reads the log for the period, checks that the gate result matches the release that went out. Every hatched cell is a claim that somebody declared something; the auditor asks who, when, and what would have been visible if the declaration were false. The hatched cell on the benefits-triage row is picked first, because the unit is high-risk and the cell is new: the auditor wants the schedule, its dates and the drill result that preceded it. The view does not tell a verified cell from a failed one; the manifest does.

An engineer

An engineer on Hansa Mutual's platform team opens Figure 17.1 at the SOC investigation agent and reads the thin bars, because they are the permission manifest drawn: enrichment at Level 4, two containment actions at Level 3, wiping a host at Level 0. The diamond says a policy point outside the model refuses anything the manifest does not allow, so a new playbook step is a change to the manifest, reviewed in a pull request and validated against a schema, not a change to a prompt. If the step would move "wipe a host" from Level 0 to Level 3, the view tells the engineer whose seat the change needs: the group chief information security officer's.

What to do

For an executive

Ask for the two views and for three numbers: how many units have no seat, how many agents have no enforced policy point, and how long the last drill took to stop the agent with the widest access. Ask, for each seat, whether its holder passes the six tests. The picture cannot tell a board whether the holder of a seat could use it.

For an architect

The review of one unit fits on a page. Start with the mark that worried you most in the one-page landscape: a square at Level 3, a mark without a seat, a dashed baseline at R3.

1. Name the unit and list its action classes. One AI use, not a product, and everything it can do that touches a person, a record, money or a system, each with its reversibility tier, including actions the logs show and the vendor does not list.
2. Set the ceiling per class. The autonomy level for each class and the reason. A level nobody set is written "found, not decided" and is the result of the review.
3. Name the holder and test the name. The role that holds the decision right and its tier, then the six capabilities of the named decider from AI Boss, Chapter 4: identified, able to decide otherwise, able to see what the recommendation rested on, given time, protected, answerable. A "no" to any of the six means the seat is not drawn yet.
4. Find the policy point and trace the stop path. What outside the model enforces the ceiling, and who may change its manifest; who may stop the unit, by what mechanism, within what budget, and when it was last drilled with what result. If the answer is "the instructions", there is no policy point; a stop that runs through the unit itself is not a stop path.
5. Sort the evidence. For logs, tests and evaluations, and gates and policies as code: does it exist, who produces it, where is it kept, who reads it. Then the attestations: who declared what, and when it expires.
6. Write the finding and the triggers that reopen it. One sentence on what the review found, and the events that reopen it: a new model version, a change to the manifest, an incident, a change of mode or a failed drill.

The output is a decision record and the unit's row in the evidence view. This one, illustrative, is the record behind the IT-operations agent's seat at Hansa Mutual:

# Illustrative decision record: Hansa Mutual, IT-operations agent (HM-ITO)
record: decision-rights/hm-ito/2027-03-31
unit: HM-ITO                     # Mode 5, an identity of its own, R3 Hard to reverse, XL
context: >
  The first stop drill took 17 minutes against a budget of 5. The executive
  board asked for the time to stop for every agent with write access to production.
decision: >
  The decision right over write access to production moves to the executive
  board. The ceilings per action class are unchanged.
holder:
  tier: T4
  role: Executive board (management body)
  operated_for_the_holder_by: Head of the group AI platform (system owner, T2)
ceiling:
  restart a service: Level 3 Bounded
  change configuration: Level 2 Supervised
  delete data: Level 0 Advisory
policy_point:
  state: enforced
  enforced_by: policy decision point outside the model, reading the permission manifest
stop_path:
  holders: [agent operator on call, head of the group AI platform]
  mechanism: revoke the workload identity from outside the agent's reach
  budget_minutes: 5
  last_drill: {minutes: 17, result: failed}
  next_drill: quarterly
evidence:
  automatic: [logs, tests, gates]
  attested: []
review_triggers: [next stop drill, model version change, manifest change, incident]

The record names the holder and tier, the ceiling per class, the policy point, the stop path with its last measured time and the kinds of evidence. The renderer reads the tier, the ceiling and the policy point to draw the row in V4; the drill result is not drawn there, on purpose, and appears in V5 through the evidence manifest.

For a public official

An authority that buys most of its systems can write the decision right and the evidence into the contract: a named holder for each unit, a stop path outside the supplier's system with a time budget, and a dated schedule of what the supplier will declare and what the authority will produce itself. The test of a good contract is the V5 row it would produce: the more filled and the less hatched, the more of the proof the authority owns.

Nordvik Region and Hansa Mutual

Both organisations are illustrative, and the two views show the two kinds of year they have. Hansa Mutual's decision-rights view changes by seats and not by bars: its agents already act at Level 3 Bounded inside enforced policy points when the year begins, and the year adds standing. Its leverage is its platform. Nordvik Region's year is the opposite picture: one seat moves, and what moves are the cells of the evidence view. Its leverage is the contract, and the evidence schedule is a contract read as a picture.

Together the views say what neither says alone. For Hansa Mutual the seats are real because the evidence is automatic: the board can hold a right it can check. For Nordvik Region the seats are real to the extent that the hatched cells become filled ones. Each has drawn where it stands and can read, in the empty and hatched cells, what to do next.

Summary

This chapter taught the two views that answer the questions a board asks once it is shown more than one box labelled "AI": who decides, and how do we know. The decision-rights view, V4, gives every unit a bar from Level 0 Advisory to its ceiling, a thin bar for each class of action, a diamond where a policy point outside the model enforces the ceiling, and a grey seat carrying the tier of the person who holds the right, from T1 the operator to T4 the board, with T0, nobody named, drawn as nothing. The evidence view, V5, gives every unit a row of cells, filled where the system produces proof and hatched where a person or a supplier declares it, with a red "none" where there is neither.

The views rest on three conclusions of the series, each turned into a drawing rule. A name is necessary and not sufficient, so the seat is drawn only for a holder who has the six capabilities that AI Boss, Chapter 4, requires of a decider. Level 3 Bounded without a policy point is Level 4 Autonomous with a misleading label, so a Level 3 mark without a filled diamond carries a red outline. Attestation is not evidence, so the two have separate columns, separate hatching and separate baselines, and the stop path, which the notation refuses to draw as a symbol, appears only as a drill result among the tests, a number nobody can declare.

The views draw the records as they stand on the dates shown. The two organisations are illustrative, and the figures make no statement about what either will do next. Chapter 18 takes the views of Part III together and follows both organisations through the scenario year in the time and comparison frames, where the seats that move and the cells that fill here appear as trails.

Sources

1. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Transformed Architecture, Book 4, published at aired.geon.se. (4, Nordqvist, 2026)
2. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2, published at aig.geon.se. (2, Nordqvist, 2026)
3. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Transformed Architecture, Book 7, published at aiboss.geon.se. (7, Nordqvist, 2026)
4. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3, published at aips.geon.se. (3, Nordqvist, 2026)
5. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Transformed Architecture, Book 5, published at aithreat.geon.se. (5, Nordqvist, 2026)
6. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Transformed Architecture, Book 6, published at tsa.geon.se. (6, Nordqvist, 2026)