Violations

Organization → Violations, and Workspace → Violations for one workspace's.

The record of your written policies being broken. Opening a record marks it seen.

The page carries an explainer worth reading once:

Attention is "someone must look"; this page is the narrower, harder fact that a rule you wrote was broken.

What lands here

Two things, and only two.

A policy rule that is a breach. A forbidden dependency was added, or a file matching a secret pattern was committed. A file_trigger never creates a violation — it only raises the gate.

An allow-list breach. A session used a provider, model or client your organization has not approved. These are recorded whatever the enforcement mode — refused or merely monitored — and the policy column shows Allow-list rather than a policy name.

Both are deduplicated: a second identical breach while the first is still open does not make a second row.

What a violation record holds

Field	Notes
Policy	The policy name, Allow-list, or Deleted policy if the policy was removed.
Rule	Which rule fired.
Severity	From the policy, or from the enforcement setting for an allow-list breach.
Matched	The thing that matched — a path, a package, model:gpt-4o.
Detail	The sentence explaining it.
Change and session	Where it happened.
Status	open, resolved, accepted or false_positive.
Seen	When a person first opened the full record.

The detail strings are written to be read:

• "node_modules/auth0 was added; "Authentication and authorization changes" forbids auth0."
• ".env.production was committed; "Secrets management" says files matching .env must never be."

Closing one

Three buttons, all needing governance.manage_policies — owner or organization admin. Members and viewers see violations but get no buttons.

Button	Status	What it means
Fixed	resolved	It was real, and it has been dealt with.
Accept	accepted	It was real, and this instance is allowed. This is the waiver.
False positive	false_positive	The rule fired on something it should not have.

There is no un-resolve. Each records who closed it, when, and an optional note.

Seen versus open

Opening the full record marks it seen. First reader wins; the timestamp never moves after that. The list page does not mark anything.

The red circle on the sidebar counts unviewed open violations, not open ones — a count that never goes down is a count nobody reads. It polls every 20 seconds and shows 99+ above 99.

On the workspace's violations page, an unviewed open row is tinted red and badged "new — nobody has looked at this."

In the attention queue

Severity	Disposition	Urgency
critical	intervene	92
anything else	decide	75

A critical policy is a line somebody drew on purpose. Crossing it is an intervention; anything else is a decision.

The queue offers four actions: See the change, Fixed — resolve, Accept this once, and False positive. Accepting requires a note, because anything that permanently loosens a rule does.

What the agent is told

A critical open violation is the one thing that produces HARD_STOP:

{policy} was violated by {matched}. {detail} This is a critical control: stop, and do not work around it.

A high severity violation is serious and produces a remediation the agent can act on. critical is the category your organization defined as "never, under any circumstances", and an agent that works around one is worse than one that stops.

It is also the one thing that turns the madebook/supervised check red on a pull request a session did report:

Supervised by Agent 04 (session #212), but a critical control fired: {reason}

Who is emailed

Organization → Governance → Settings → Who is emailed about violations.

Nobody is emailed yet. Violations still land in the queue and the audit log.

A recipient is either a member of the organization or a plain email address — the second is badged address. Adding one takes a picker with a Custom email address… option; several addresses at once can be separated by commas.

Each recipient has a severity floor:

Option	Gets
every violation	everything
medium and up	medium, high, critical
high and critical	high, critical
critical only	critical

The email's subject is "{severity} policy violation: {policy}", with the workspace on a second line, and a link straight to the record. A failed notification never blocks anything — it is logged and dropped.

Adding a member who is not in the organization: "That person is not a member of this organization."

Exporting the record

Organization → Governance → Settings → Export the record downloads everything as JSON: sessions with their events, briefs, runs and health; change sets with their files, symbols, dependencies, risk and evidence; violations, deviations, decisions, policies, constitutions, missions with their clauses and verifications and versions, capsules, attention items, AI runs and the audit log.

Exported 214 sessions, 389 change sets, 1,102 runs

The empty state

An empty violations page means one of two things, and the page says both:

Your policies are being respected — every reported change stayed inside the rules.

Or there is nothing to break yet: no active policies, or no agent sessions reporting in. Write policies under Governance, and connect coding tools with keys from Tokens.

Related

• Policies
• Providers, models and clients
• The attention queue