Telemetry and retention
What Madebook records about AI-assisted work, the two telemetry modes, how long prompt bodies are kept, and whether Madebook may hold any of your source.
Retaining a customer's source code and prompts is the most dangerous thing this product could do. Two settings govern it, both per organization, both on Organization → Governance. Neither is a platform-level switch — there is no way for Madebook staff to change what your organization keeps.
Changing either needs governance.manage_compliance, which owners and organization admins hold.
Telemetry mode
Panel: "What Madebook keeps about AI work here".
Metadata only is the default and the promise. Enhanced audit keeps the rendered prompt and the model's output for every workflow run Madebook itself executes, for the retention window, so you can analyse them.
| Value | Option text |
|---|---|
metadata_only |
Metadata only — counts, names, versions, durations |
enhanced_audit |
Enhanced audit — also the prompt and the output of workflow runs |
metadata_only is the default for every organization, including one that has never opened this page.
What is always recorded, in both modes
This is the manifest, and it is what makes "why did it say that" an answerable question.
On the run itself: the workflow, the workspace, the organization, the repository, the source item, the user, the status, the provider, the model, whether it was a mock, input tokens, output tokens, cache read and write tokens, cost in cents, start and finish times, duration, and any error.
Alongside it:
- Context items — for each item that went into the prompt: its kind, its reference (a file path, for example, up to 250 characters), the entity it came from, an approximate token count, the reason it was selected, and its position in the order.
- Skills — skill id, version id, name, version, approximate tokens, position.
- Artifacts — kind, entity, title.
- Counters — skills used, context items, files included, system prompt tokens.
What enhanced_audit adds
The rendered prompt and the raw model output, stored on the run, flagged as retained, and stamped with a purge time.
Two limits that hold whatever the mode
Agent sessions never send bodies. A coding client reports counts and names only. The page says it in these words:
Agent-reported runs never carry prompt or output bodies: the client reports counts and names only. Workflow runs Madebook executes keep bodies only while the organization's telemetry mode is enhanced_audit.
The change applies from now on, never retroactively. Turning enhanced audit on does not resurrect bodies from runs that already happened.
The retention window
Keep bodies for (days) — a whole number from 1 to 365, default 30. The field is disabled unless the mode is enhanced_audit.
When a body is stored, a purge time is stamped on the run: the moment it was recorded plus that many days.
The footer under the panel counts what is actually there:
{n} run(s) recorded here · {m} with bodies retained. Agent sessions report counts only — a coding client never sends Madebook its prompts, whatever this is set to. The change is audited and applies from now on, never retroactively.
Saving gives one of two messages:
Prompts and outputs of Madebook workflow runs are kept for {days} days from now onMetadata only — nothing but counts, names and versions is kept
What deletes a body
A background job (retention.purge) sweeps twice:
- Every run whose bodies were retained, that has not been purged, and whose purge time has passed.
- Every run whose bodies were retained but whose organization is no longer on
enhanced_audit— purged regardless of its original window, because withdrawing consent has to be retroactive to mean anything.
The manifest is never purged. Only the bodies go. The purge writes an audit event recording the number of runs affected — never any content.
When it runs
Once a day, and once a minute after the server starts — the second because a deployment that restarts daily would otherwise never reach the first tick of a daily timer. Both intervals are overridable with RETENTION_PURGE_MS and RETENTION_PURGE_DELAY_MS.
The sweep queues the job rather than doing the work itself, so a purge has the same attempts, heartbeat and audit trail as every other background job and shows up under Background jobs. If a purge is already queued or running, the next sweep leaves it alone.
Every run is logged, whether or not anything was purged — runs_purged, the number past their window, and the number of organizations that have since withdrawn consent. A scheduled purge that only spoke when it found something could not be told from one that was not running, which is the question the job exists to answer. The audit event is still written only when something actually changed.
Whether Madebook may hold any of your source
Second panel on the same page.
Nothing is fetched when an agent reports. When somebody opens a specific place to look, the few lines of that one file are fetched and kept, so the change page can show what was flagged and why. A change nobody inspects leaves no source here.
| Value | Option text | What it means |
|---|---|---|
on_inspection |
On inspection — keep the lines of a file somebody opened | The default. Nothing is fetched when an agent reports. When a person opens one specific place to look, the hunks of that one path are fetched and cached against the change's base and head commit. A change nobody inspects leaves no source in the database. |
none |
Never — Madebook holds none of our code | Madebook holds no source at all. The focused diff says so and names the setting. The place to look and the rule that flagged it still appear; the lines themselves are read in the pull request. |
Switching to none purges what is already cached, immediately. The footer explains why:
Currently holding {x} excerpt(s) across {y} file(s). Switching this off deletes them — a retention setting that only applied to the future would be one you were surprised by. With it off, the change page still names the place to look and the rule that flagged it; you read the lines themselves in the pull request.
The purge is audited with the count of excerpts removed. The content never is.
Beyond these two settings
Some facts about data handling are not settings at all — they are how the product is built.
- Source is never stored as a matter of course. Files are fetched, used, and dropped. Madebook keeps paths, sizes, roles, modules, symbols and manifests.
- Files matching a secret pattern never enter a prompt, unconditionally.
- Secrets — provider keys, repository credentials, the GitHub App private key — are stored with AES-256-GCM. There is no plaintext fallback; if no encryption key is configured, the store refuses to save rather than degrading. Secrets are never returned to the browser, never logged, never put in a prompt, and never written to an audit entry. The audit log records that a secret changed, not what it became.
- The audit metadata field is not a payload dump. Every value is stringified and truncated to 200 characters, and any nested object is replaced with the literal
[object]— so a prompt, a diff or a file body cannot land there by accident.
How long evidence is kept
Evidence retention is a property of your plan, not of these settings.
| Plan | Evidence retention |
|---|---|
| Free | 14 days |
| Pro | 180 days |
| Business | 1095 days |
When a service is unavailable
Source retention is an application policy, so checking it does not depend on a live SSO organization lookup. A temporary SSO outage cannot turn off a saved restriction. If MadeBook cannot read the retention setting itself, it refuses to retain source quotations and focused diffs until the setting can be verified.
Governance analysis also requires a verified SSO organization. If it cannot resolve the organization, it reports the lookup failure and requires a retry instead of returning a clean assessment with policy checks skipped.
Related
- AI runs — where the manifest is shown.
- The audit log
- Organizations