Inside the model boundary

Hop 1 set out the core idea. The reasoning behind important decisions was disappearing the moment they were made. The graph fixes that, with a source on every point and every link, and Replay built into how the record works.
That leaves a question. For Replay to mean anything, the record itself has to be trustworthy. And for that, three things have to be right before an AI tool runs. Not afterwards. Not in the app. Before.
Context. Permission. Provenance.
Get any one of them wrong at the foundation and no amount of logging or reporting on top will produce a record that holds up. That is what it means to go inside the model boundary: the line around what an AI tool can see and use for a given task.
Context is not data
A common belief is that giving an AI tool more data makes it more accurate. Sometimes it does. More often it makes the tool more confidently wrong, in ways that are harder to spot.
Take a simple request: "Shortlist remote monitoring suppliers that an ICB could buy from this year." An AI tool can answer that in seconds. But look at what the answer depends on.
Is each supplier's DTAC status current, and from what date? Is a framework listing being read correctly? On Care Tech Directory, a framework listing means a supplier is eligible to be bought from. It does not prove anyone has actually bought from them. Has the ICB changed its name or boundaries? Has the company been renamed or bought?
If the tool has the facts but not the meaning around them, it produces a tidy list built on loose ground. The list looks authoritative. Somebody acts on it. Nobody knows it was shaky.
The same thing happens with trials. A tool that matches a patient group to studies without knowing which trials are still recruiting gives confident, out-of-date advice. The tool is not broken. The context it was given is.
Context, properly understood, is not a pile of data points. It is a set of relationships between things, each with a source, a date and a type of evidence attached. It also has an edge: what was in scope when the tool ran. That edge has to be recorded as part of the decision. Not guessed afterwards. Recorded at the time.
When context lives in the graph, the model boundary becomes visible. You can show exactly what was in scope, what was not, and why.
Permission is a reasoning problem, not an access problem
Most organisations treat permission as access control. Logins, roles and data labels. These are needed, but they are not enough. With AI, permission is also about what a tool is allowed to reason over on behalf of whom.
Take a market-access consultant working with two clients who make similar products. Both clients' plans sit in the Consultant Cockpit. If an AI tool drafts advice for one client using the other client's private evidence, something has gone badly wrong. Not at login. At the reasoning step. The advice is contaminated, and unless the foundation records what was in scope, nobody will ever know.
MIA is built around this rule. Models, prompts and browser state are never trusted to grant access. No model can give itself, or a user, a capability. MIA's kernel checks the user's plan, their workspace and which directories they are allowed to use before any tool is called. Each directory also keeps authority over its own facts, rights and corrections.
When permission is part of the graph, attached to the relationships between people, organisations and records, the model boundary can be drawn correctly before the tool runs. That boundary is recorded. If a decision is ever questioned, you can show what the tool saw, what it was allowed to see, and that the two matched.
Access control keeps the wrong people out. Permission in the graph keeps the reasoning honest.
Provenance is the record that has to survive
Context and permission decide what goes in. Provenance is what comes out. Not just the answer, but a full record of the conditions it was produced under.
Imagine it is eight months after an NHS trust chose a supplier for a pilot. A losing bidder challenges the decision. The trust wants to know how an AI-assisted shortlist shaped the choice, which records it used and whether the human review was real or a box-ticking step.
Without provenance captured at the time, none of those questions can be answered with evidence. The supplier's listing has since changed. The AI tool has been updated. Nobody recorded what was in scope. What is left is a name on a contract and the memory of the people in the room.
Memory does not survive a procurement challenge. It does not survive a clinical safety review or a regulator's questions. In each case the question is the same: can you show what was known, what ran and what was decided, at the moment it was decided?
Provenance in the graph is not a log. A log says something happened. Provenance says what was true when it happened. On our directories, every fact carries its source and the exact place in that source, the date it was observed, the type of evidence, how confident we are, whether a person has reviewed it, and which version of the process read it.
That is what Replay means in practice. Not replaying the screen. Replaying the conditions. Showing, with evidence, what was known, what the tool produced and what the person understood at that moment.
Why the app cannot fix this
Many teams believe context, permission and provenance can be added later. A logging tool here, an audit add-on there.
They cannot, and the reason is structural. An app sits on top of the foundation. It can record what it sees. It cannot record what it never had. If the context was incomplete, the app records incomplete context. If the permission edge was wrong, the app records the wrong edge. Adding more of it does not move the point where the evidence is captured. It just documents the same gap in more detail.
The capture point has to be in the foundation. Context gathered and bounded before the tool runs. Permission checked as part of the graph before the boundary is drawn. Provenance attached at the moment the tool runs, not rebuilt afterwards.
The teams that understand this are not waiting for a rule to force them. They are building on foundations that get these three things right, because the alternative has a known result: paperwork that looks like an audit trail and holds up to almost nothing.
What comes next
Hop 2 is the inside of the model boundary. Context, permission and provenance as the three things that must be right before any AI tool can be trusted with work that matters.
Hop 3 looks at what happens when AI and people decide together. The model suggests. The person acts. The question nobody has fully answered is how to keep both contributions clear in the same record. Two voices. One record.

