Governance / Guard
What the firewall refuses, with a name and a remedy.
Guard decides what an agent is allowed to write into the ledger, and what a reader is allowed to treat as settled. The policy engine is shipped; scope is fixed before the operation; abstention is a real retrieval outcome; contradictions stay readable on both sides. A new claim is confirmed by a human, not by the process that proposed it.
T3 judgement is deferred. A budgeted AI judge that would resolve disputed claims automatically is not implemented and does not run. The decision to defer it was made on the platform ledger under ADR-Z-07: it is not required for the shipped firewall to refuse, abstain, and hold contradictions. Confirmation of a new claim remains a human act.
What happens to a write between being proposed and being trusted.
A write is bound to scope, evaluated against policy, refused with a named reason when it fails, preserved alongside its contradictions when it disagrees, withheld when the evidence is insufficient, and confirmed by a human before it becomes a settled claim.
01 - Bind
Every connection is bound to one installation, project, repository, and worktree before its first tool call. Scope is immutable for the life of the connection.
02 - Evaluate
A proposed write is checked against the ADR-Z-08 policy engine. The check is explicit: a rule either clears the rule set or names the rule it failed.
03 - Refuse
A capture that fails a rule is refused with the rule named and a concrete remedy. The refusal is not a downgrade — the write did not enter the ledger.
04 - Preserve
When a claim contradicts a reviewed one, both claims stay readable. Neither side is silently deleted to keep the graph tidy.
05 - Abstain
When the evidence is insufficient, recall returns a structured abstention that names what is missing — not a plausible guess assembled from fragments.
06 - Confirm
A new claim is not confirmed by the same process that proposed it. Confirmation is a human act — the agent proposes, a person decides.
illustrative example — not live data
Scope is fixed before the operation.
Every connection is bound to one installation, project, repository, and worktree before its first tool call. Scope is immutable for the life of the connection. Widening scope is not a retry or a fallback — it requires a new admission, so a tool that asks for more than it was admitted to is refused rather than quietly accommodated.
zephr statusOne command shows the connection and its bound scope — what Guard admitted it to.
- Admitted
- An agent bound to apps/web reads a belief anchored in apps/web. The check runs at the transport, so no tool can opt out of it.
- Refused
- The same agent asks for a belief anchored in packages/billing. That scope is not an ancestor of the one it was admitted to.
scope_violation: connection admitted to apps/web; packages/billing is outside the bound worktree
illustrative scope — not live data
One refusal, named and remediable.
An illustrative capture that the firewall refused. The rule is named, the missing evidence is named, and the remedy is concrete — so the refusal is a direction, not a dead end.
Capture blocked
A proposed credential-related claim was refused because it had no evidence source and no human confirmation. The refusal is not a downgrade — the write did not enter the ledger.
failed rule
adr-z-08 - evidence-required
what is missing
no evidence source attached - no human confirmation on record
remedy
attach the incident report as evidence, then submit the claim for human review
Illustrative example — not live data
Both claims stay readable. Neither side is silently resolved.
When a new claim contradicts a reviewed one, the contradiction is surfaced — not hidden, not auto-resolved, not deleted. Both sides remain readable until a human verdict settles which one holds.
reviewed claim
Session tokens are validated in the edge middleware, never in route handlers.
contradictory claim
Tokens may also be validated in route handlers when the middleware is skipped.
open - awaiting human verdict
illustrative claims — not live data
Policy, scope, abstention, contradictions, confirmation.
Each capability below carries its own status. Six are shipped and one — T3 judgement — is deliberately deferred under ADR-Z-07. A capability list that hid the deferred one would be exactly the kind of confident blur this product exists to replace.
Trust Firewall policy engine
ShippedA proposed write is checked against the ADR-Z-08 policy engine before it reaches the ledger. A rule either clears the rule set or names the rule it failed.
ADR-Z-08
Scope binding
ShippedEvery connection is bound to one installation, project, repository, and worktree before its first tool call. Widening scope requires a new admission, not a retry.
ADR-Z-09
Refusal with a named remedy
ShippedA capture that fails a rule is refused with the rule named and a concrete remedy. The refusal is not a downgrade; the write did not enter the ledger.
policy engine - ADR-Z-08
Abstention as a first-class result
ShippedWhen evidence is insufficient, recall returns a structured abstention naming the gap. Abstention is a first-class result, not an empty array or a guess.
retrieval contract - ADR-016
Contradictions kept readable
ShippedA contradictory claim does not delete the reviewed one. Both claims stay readable, with the contradiction surfaced rather than silently resolved.
memory graph - ADR-029
Human-only confirmation
ShippedA new claim is proposed by an agent and confirmed by a human. The same process that proposes a claim does not confirm it; confirmation is a separate, human act.
review engine - ADR-023
T3 judgement
Planned - deferred under ADR-Z-07A budgeted AI judge that would resolve disputed claims automatically. It is deferred under ADR-Z-07 and does not run; disputed claims stay open for a human verdict.
ADR-Z-07
What Guard checks before a tool call is allowed.
A tool call is not a weighted score across checks. It is a fixed sequence — scope, deny-list, evidence, confirmation — and the sequence short-circuits at the first failure. The matrix below shows illustrative checks and their verdicts for different tool calls.
| Tool | Scope | Deny-list | Evidence | Confirmation |
|---|---|---|---|---|
| zephr_memory_write | clear | clear | clear | clear |
| zephr_memory_read | clear | clear | pending | pending |
| credential claim | clear | refused | refused | pending |
- 01Scope
Is the tool call within the bound installation, project, repository, and worktree scope?
- 02Deny-list
Does the tool call match any rule in the deny-list (e.g. credential-related claims without evidence)?
- 03Evidence
Is there an evidence source attached to the proposed write? A claim without evidence is refused.
- 04Confirmation
Has a human confirmed the new claim? The same process that proposes does not confirm.
See what it refuses before you trust what it accepts.
Guard is easiest to judge from its failures. Read the trust semantics, then walk the golden path and inspect a refusal for yourself.