The Assumptions Page Is the Risk Register

A risk register is the easiest document in a programme to produce and the easiest to stop reading. Columns for likelihood and impact, a colour in the middle, an owner who was not in the room when the row was written, a mitigation phrased so that nobody can say whether it has happened. By the second month the colours have stopped moving and the file is opened only to be pasted into a steering pack.

The strongest risk treatment I have written was not on a page called risk. It sits in a kick-off deck for the re-tender of an outsourced IT service desk at a large European public-sector organisation. The agenda lists five items and the fourth is Assumptions and Risks. Go looking for it and you find one page, headed Assumptions, carrying fifteen bulleted lines. There is no risk page.

I keep going back to it because most AI programmes I see have the opposite shape: a longer register and unwritten assumptions.

What a kick-off page is allowed to claim

Nothing in that deck reports anything; it states what will be examined. No contract had been read, no workshop run, no supplier spoken to. The plan behind it runs across seven phases, from gathering documents and assessing the current state, through business requirements and a supply-market evaluation, into reporting and sign-off, with four progress reviews and a final presentation booked in advance.

The kick-off itself had one job, and the plan is explicit: six things had to be closed in that session. Objectives and goals. What the client expects the deliverable and its outputs to be. The inputs required to produce that output. Risks and assumptions. Governance, team, roles and responsibilities. Milestones and reviews.

Notice the third. Most kick-offs agree what the supplier will hand over and leave what the client will hand over as an understanding. Naming the required inputs as a first-class agreement is what makes the assumptions page possible, because most of what a supplier assumes is an obligation on somebody else that nobody has said out loud.

The fifteen lines, and what they are for

They fall into five families, each a place programmes die.

Where the team sits and what that costs. The team will work out of the service desk's own location, with a single possible visit to one other site, and only one site visited in a week in order to hold travel expenses down. Consultants work from their own offices when not needed on site, and the line adds three words in brackets: with your approval. Where the supplier sits is a client decision, written as one.

What converts into money. The structure and content of each deliverable is agreed in writing at start-up. Any later change to those descriptions is a change request, and so is any scope change during the assignment. That is the enforcement mechanism for everything else on the page.

Where the scope stops. No more than three vendors are assumed to respond to the tender and be evaluated later. Up to twenty-five business users will be consulted, in groups, by video conference if required. The conditional second deliverable begins only when its extension is confirmed.

What the client owes. Their service desk team supplies the information on current state and future requirements, and leads the deliverables the consultants only advise on. Administration and programme office support comes from the client. The key people on that team have already been told the project is coming and will be available at reasonable notice. The service reports, their named owners and the documents from existing programmes will be accessible, preferably by self-service.

Cadence and continuity. Weekly meetings, with a fixed three-part agenda written into the assumption itself: challenges, achievements, proposed next steps. One draft per deliverable, with one week for client feedback. Team continuity across the later deliverables is best effort, and if it cannot be held, the account leadership layer guarantees equally qualified replacements.

Read as assumptions it is administrative. Read as a risk register it is complete: travel and cost exposure, scope creep, evidence availability, stakeholder access, supplier market thinness, review latency, key-person dependency. Every one treated, and not one scored.

Why the unscored version works better

A register row is unfalsifiable by construction. Stakeholder engagement, likelihood medium, impact high, mitigation ongoing. Nobody can be wrong about that, so nobody objects, so it survives to the end of the programme unchanged and unread.

An assumption is a claim about the world in the future tense with somebody's name behind it. The key people on that team already know the project is happening. Either they do or they do not, and the person who would know is sitting in the kick-off. The self-service line has the same shape: it says the documents will be reachable without a request queue, which anyone who has tried to get a report out of an operations team knows is the most optimistic sentence on the page. Written as an assumption, it invites the client to say on day one that it will not be true, while the fix costs a conversation.

An assumption dies in the room or it lives with a price attached. A register entry does neither.

The price is the second half of the design, which is why the change-request clause matters more than any single line. When an assumption fails, something happens: the plan or the fee moves, in a way both sides agreed in advance. Compare a register whose owner is expected to mitigate. Mitigate is not an event, and nothing changes on the day a risk turns amber.

I read the missing page as deliberate rather than sloppy, because of what the deck commits to next. The weekly reporting template it adopts gives every issue and every risk a paired line for the action agreed against it, on a page both sides countersign. Risk there is not a page. It is a line item that has to produce a decision every seven days.

The same page, for the work we are scoping now

I am writing this in a season of retrieval-augmented generation pilots and internal copilots, and the governance packs around them are heavier than anything on that service desk. Model risk, hallucination risk, adoption risk, regulatory risk, all rated, all owned by a committee.

Underneath, the same category of thing goes unwritten. Try turning them into lines somebody has to object to.

Somebody will produce the document corpus, and it will be the current version. Somebody will confirm that its permissions are correct today, so retrieval does not surface a file to a reader who should not see it. A named domain expert will spend real hours building the evaluation set, and will still be there to rebuild it when the corpus changes. There is lineage for every number the copilot repeats, so we can answer where a figure came from when a user challenges it. The vector store gets refreshed when source documents change, and somebody owns that refresh. Legal will state the answer quality bar before the pilot, and it will be one we can reach. The early autonomous experiments stay scoped to actions that are cheap to reverse, and that list is written down and signed rather than assumed.

Every one of those sentences can be contradicted by a specific person in a specific meeting, which is what makes it worth writing. Some will be refused on the day, and the refusal is the finding: if nobody will promise the evaluation set, you have learned in week one that you are building something you cannot measure.

The regulatory line deserves the same treatment. The AI Act has reached political agreement and the obligations it will carry are not in force, so nobody can hand you a checklist yet. What you can write is an assumption: we will be able to evidence what this system was trained on, what it was tested against and who approved its release. If your data readiness work cannot support that sentence, let somebody object now rather than when the rules land.

How to write one that holds

Four tests, all of which the fifteen lines pass.

Could someone in this room say no. If the sentence is safe from contradiction, it is decoration. Say who supplies the thing, by name or role, rather than saying it will be available. Say what happens when it breaks, and give that a cost, since an assumption with no consequence is a wish. Keep the page short enough to read aloud, because the objection you need only arrives if the person who would raise it heard the line.

Then review the page with the client before the work begins, as that engagement committed to doing at start-up. It turns a supplier's disclaimer into a jointly held document, which is the difference between assumptions as legal cover and assumptions as risk management. We open a RealAI Consult engagement with that page rather than with a register.

A register row says something might go wrong and nobody can be wrong about it. An assumption says somebody has already agreed it will not, names them, and prices the moment it stops being true.

15

Bulleted assumptions carrying the engagement's whole risk treatment

0

Separate risk pages, against an agenda that promised risks

3

Maximum vendors assumed to respond to the tender

1

Draft per deliverable, with one week for client feedback

The page I keep going back to has no technology in it at all. Fifteen sentences, written before anything was known, each arranged so that the person best placed to contradict it was in the room while it was read. That is harder to produce than a register, and not because it takes longer. Every line exposes somebody to being told no, including the people who wrote it.

Drawn from the kick-off document for a service desk re-tender at a large European public-sector organisation: its agenda, its seven-phase plan, its assumptions page and the weekly report template beside it. That document commits to work and reports no findings. Reading the assumptions as a risk register is ours.