The governance handoff to MadeBook
In a workspace linked to MadeBook, MadeBook holds the rules and the record and CodeBook enforces its answers — models asked before use, sessions ended, evidence reported, one audit trail and retention of run bodies.
When a CodeBook workspace is linked to MadeBook, MadeBook is where governance lives: it holds the rules, gives the verdicts and keeps the tamper-evident record. CodeBook enforces MadeBook's answers at the moment it acts. An unlinked workspace behaves exactly as it does without MadeBook; nothing on this page applies to it.
Everything here concerns stations worked by CodeBook's own AI agents. Stations worked by outside runtimes, crews or another factory are not registered with MadeBook, so their results do not reach it as evidence.
Approved models: asked before every call
Before a governed run's first model call, and whenever the model changes within the run, CodeBook asks MadeBook whether that model is approved for the organization. The question sits inside the one place a run calls a model, after the budget check, for every attempt of a fallback chain — so a fallback model is asked about before it is tried. A resumed run asks again.
- Refused: the run stops, and the card names the model and MadeBook's reason. CodeBook never swaps to another model silently, and a refusal is never treated as the model failing, so it does not trigger a fallback.
- MadeBook unreachable, or an answer CodeBook does not understand: the run is held, like any governed run waiting on MadeBook, and retried. It never proceeds unchecked.
- The session has ended in MadeBook: that is a stop, not a hold.
After each call CodeBook reports it — model, purpose, status, tokens and time — through its outbox, with an ID that makes a retried report a no-op. If MadeBook refuses a model at that point, the run stops exactly as for a refusal beforehand. A governed run's evaluators call models through the same gate.
Ending a session
However a governed run ends other than by finishing normally, CodeBook tells MadeBook, once, with the reason: cancelled by a person, the kill switch, the card moved away, the run failed, a newer run superseded it, or an emergency revoke. MadeBook then ends the session, withdraws its open decision gates and cancels callbacks still owed for it. A background sweep ends any session whose run is over without MadeBook having been told.
Pausing the factory is not an end. Each held session is reported as blocked, and as working again on resume.
The card's MadeBook panel shows that the session was ended and why, and whether MadeBook has heard; a message that failed has Send again.
Finishing: CodeBook's checks first
When a worker finishes, CodeBook runs the station's contract and evaluators first, and only then reports to MadeBook. The report carries:
- the files the pull request changed, read against the base branch;
- the packages the change adds, read from the manifests it touched (
package.json,requirements.txt,pyproject.toml,go.mod,Gemfile,Cargo.toml,pom.xml,build.gradle,*.csproj), so MadeBook's dependency rules apply — a manifest whose base could not be read is reported as unreadable, never guessed; - one evidence entry per contract line and per evaluator: passed, failed, partial, not run (with why) or unavailable.
MadeBook records this as evidence reported by CodeBook, which counts only once CI or a person confirms it. CodeBook tells MadeBook the implementation is complete only when its own checks passed, so the two never disagree about finished work. A retry after MadeBook was down sends exactly the same report.
The card's panel lists what was reported: files, checks and new packages.
One verdict on the pull request
Whether a pull request may merge is MadeBook's verdict, posted as the madebook/compliance check. CodeBook shows it on the card as it arrives, never re-derives it and never passes or fails a worker's run because of it. For the same reason, every check whose name starts with madebook/ is left out of CodeBook's "CI checks passed" evaluators, in every workspace.
One audit trail
For a linked workspace, CodeBook sends its governance events to MadeBook's sealed audit trail, through the signed, retried outbox:
- a run approved or rejected under an autonomy level;
- an override — a person moving a card past a failed contract or evaluator;
- factory, station or worker permissions changed;
- factory policy or budgets changed;
- the kill switch and an emergency revoke;
- a factory version published, and a rollback.
Each names the person by their SSO identity, or the system. Text is cut to MadeBook's limits at a word boundary before sending. When a link ends, whatever the outbox still owed for it is dropped rather than retried. Where a factory's changes need a second person (an environment stage that requires approval), the event is sent when the change is published. CodeBook's own run logs remain operational data; the audit record is MadeBook's.
Retention of run bodies
CodeBook reads the organization's retention settings from MadeBook when its credential is issued and daily after that, and applies them to the bodies its runs store — prompts, model output, tool output, summaries, evaluator notes and crew briefs — in every factory of the linked workspace. The trail's own events (started, routed, handed off) are metadata and stay.
| MadeBook setting | What CodeBook keeps |
|---|---|
| Metadata only (the default) | Bodies for at most 24 hours after the run ends, then metadata only |
| Enhanced audit | Bodies for the organization's prompt retention period (30 days by default) |
| No code retention | No source or diff text in stored run output after the run ends |
If a read fails, the last settings stay in force and the link records the failure. A setting CodeBook does not recognise is applied as the strictest it knows. Workspace settings → Linked products shows the settings in force for each MadeBook link and when they were read.
Chat conversations with a worker are not run bodies and are not swept; they are removed when their owner deletes them.
Who started it
A session is started by the person whose action started that run — who moved the card into this station, created it, ran it, or approved its held run — and MadeBook checks that person may start sessions in the workspace. It is never inherited: the next station after a pass, a fallback worker, a remediation MadeBook asked for, a retry, a schedule, an inbound event and a supervisor are started by the link's credential, with no person named. Separation of duties in MadeBook is judged on this.
Supervisors on governed cards
A supervisor asked about a governed card is registered as a MadeBook session of its own, because the run it supervises has already ended. Its model call goes through the same gate and is reported. If MadeBook holds or stops it, the job is parked or the decision goes to a person, and no model is called.
Not built, and not run for real
- Outside runtimes and the dedicated adapters are not registered with MadeBook, so their contract and evaluator results never reach it.
- CodeBook and MadeBook read
DECISION_REQUIREDdifferently: CodeBook stops the whole job, MadeBook models it as partial. The products have not yet agreed one reading. - A governed run against a real MadeBook covering this page — the model check, ending a session, the report's files, packages and evidence, and retention — has not been run; it is covered by tests against a MadeBook stand-in that speaks this protocol. See what has run for real.