AI Controls and Governance
How do I explain an AI decision to the board?
A board member asks why the agent declined the application, or approved the discount, or flagged the account. You have the logs. You pull them up. They show the timestamp, the model version, the inputs the system received, the output it produced. You walk the room through it.
And you watch the question fail to land — because what you've shown them is what the agent did, and what they asked was why it was reasonable to do it. Those are different questions, and the artefact you reached for only answers the first.
Why the Technical Trace is the Wrong Artefact
The instinct under pressure is to reach for the most detailed record available: the trace, the logs, the prompt that was sent. It feels like the responsible thing — here is exactly what happened, in full.
But a board isn't asking for forensic completeness. A board is asking whether the decision was defensible given what the organisation intended. A trace can't answer that, because it records the mechanism, not the reasoning the mechanism was meant to serve. It shows that the agent received certain inputs and produced a certain output. It does not show what the agent was supposed to be optimising for, what it was constrained from doing, or who decided those things were correct. Hand a board a trace and you have answered a question they did not ask, in a vocabulary they do not use, and the gap between the two reads as evasion even when it isn't.
This is the trap: the more technical detail you produce, the more it looks like you're explaining the system rather than standing behind the decision. Explanation to a board is not a depth problem. It's a framing problem.
What a Board is Actually Asking
Underneath the question about a single decision, a board is usually establishing something larger: whether the organisation remained in control of its own decision-making, or whether it had quietly handed that control to a system nobody could speak for. That is the anxiety a board brings to an AI incident — not "what did the machine output" but "are we still running this, or is it running us?" Every specific question is a probe at that one.
Strip it down and a board wants three things, in plain terms. What was the agent trying to do: the goal it was given, stated as the organisation would state it, not as a configuration value. What was it not allowed to do: the constraints it operated under, and whether they were the right ones. And who decided those things, because a decision the organisation can defend is one a named, accountable person signed off on, not one that emerged from a system nobody can speak for.
None of these is answered by the output record. They are all questions about what the agent was given before it acted. The output tells you what happened; these tell you whether what happened was the organisation operating as intended, or the organisation losing control of its own process. That distinction is the entire content of a board's concern.
Engramic's approach
How Engramic Approaches it
There are multiple ways to keep a record of what an agent was given before it acted. This is one approach.
Engramic authors and records an agent's operating context — its goals, its constraints, the decisions it was built from, and who owns them — before the agent acts. When a board asks why a decision was made, the answer is retrieved from that record rather than reconstructed from logs: here is what the agent was working from, here is the person accountable for it, here is when it was set. The technical trace still exists and still has its uses, but it stops being the thing you reach for to explain a decision, because it was never the right artefact for that question.
The record is only meaningful because the work is scoped. Engramic governs structured, consequential decisions with human checkpoints, which is exactly the class of decision a board asks about. Explaining the output of unbounded, fully autonomous execution is a different and much harder problem, and one no input record fully solves.
In short
A board asking about an AI decision is not asking what the agent did — the logs answer that. It is asking what the agent was working from and whether that was reasonable, which the logs don't contain. The explanation that survives the room is a named person saying what the agent was given, who approved it, and when. That record has to be created before the decision, not reconstructed after it.