AI runs
The accountability record for everything a model did — what is recorded, what never is, and the manifest that answers "why did it say that".
Workspace → AI runs.
A run belongs to the workspace whose code it touched, so it lives in the workspace's sidebar and nowhere else. An organization-wide list of every run across every workspace is a feed, not a place anyone works from.
Two different things land here.
Runs Madebook executed
When Madebook itself calls a model — to read a repository into the context, to draft a mission contract, to summarise a change, to mine decisions — it records the run with a full manifest.
| Recorded | |
|---|---|
| The workflow, workspace, organization, repository, source item and user | |
| Status, provider, model, and whether it was a mock | |
| Input, output, cache-read and cache-write tokens | |
| Start, finish, duration, and any error | |
| Every context item | its kind, its reference, the entity it came from, its token estimate, its position, and the reason it was selected |
| Every skill | id, version, name, token estimate, position |
| Every artifact | kind, entity, title |
| Counters | skills used, context items, files included, system prompt tokens |
That manifest is what makes "why did it say that" an answerable question. The model is never asked which files it consulted, because Madebook chose them.
Madebook does not record money. A run used to carry a
cost_centscolumn computed from per-million rates on the model row; it has been dropped, because those rates do not exist. A self-hosted organization is billed by its provider directly and the platform is not in that invoice; a managed one is metered in tokens against the owner's allowance. The four token counts above are that unit, and are what the bar on the AI page adds up. See The token allowance.
The capsule and the repository analysis both link to their run with a label reading "See what it was given."
Runs an agent reported
When a coding agent reports a change through the MCP, it can attach one model invocation as metadata only:
provider, model, purpose (plan, implement, test, review, explain, fix, other), status, error, duration, files read, files changed, commands, tests run, and the four token counts.
Never the prompt. Never the output. The agent does not send a body, and Madebook does not ask for one — whatever the organization's telemetry mode.
Every agent run is recorded with bodies_retained = 0 from the start.
The model gate
Before an agent's run is recorded, the model is checked against the organization's allow-lists. A refusal writes a timeline event on the session:
claude-opus-5 is not approved for this organization: claude-opus-5 is not on Acme Financial's approved model list.
and the run is refused with MODEL_NOT_APPROVED — or, if your organization has set that subject to monitor rather than refuse, the run proceeds and the breach is recorded anyway.
It also raises an attention item at disposition inform, urgency 30:
{session} tried a model this organization has not approved
The run was refused and not recorded as work. If the model should be allowed, approve it under Organization › Governance › AI; otherwise the session's client needs reconfiguring.
Mock runs
When no approved model is available, Madebook does not ask a mock provider to invent plausible text. It assembles a deterministic skeleton from what the workspace already knows, stamps it as a mock, and attaches a confidence note saying what was not inferred.
The contract generator, the test planner and the capsule summariser all work this way.
Plausible invented text with a mock badge is the failure this product argues against.
Prompt and output bodies
Whether the rendered prompt and the model's output are kept depends on your organization's telemetry mode, which is metadata_only by default. See Telemetry and retention.
The manifest is never purged. Only bodies are.
Every metric carries a source
Anywhere Madebook shows a number, it also records how it knows: measured, manual, ai_estimated or unavailable.
An unmeasurable quantity is never rendered as 0. It is rendered as not measured, with the reason:
Not measured — no deployment integration is connected
Runs that never finish
A run is running from the model call until the workflow writes its result. If the process dies in between — a deploy, a crash — the row would stay running forever. Two sweeps prevent that: at boot, every run still marked running belonged to the process just replaced and is failed as "Abandoned: the process running it was restarted before it finished."; every five minutes, any run without a result after twenty minutes is failed as "Abandoned: no result after twenty minutes — the worker running it stopped." A run that shows running for hours is therefore a bug, not a wait.