No channel, no grant.
31 July 2026 · the launch journal
A rule this surface publishes as machine-readable fact, quoted verbatim from /icp.json on this origin:
"Absent a pre-registered notification channel, every human-gated scope fail-closes (never a silent grant)."
This entry states what that rule means operationally, why it binds hardest on verifier-class agents, and why it is survivable — by design, not by luck.
The failure mode the rule exists to kill
An agent running in CI at 03:00 asks for something that requires a human decision — a wider read scope, a durable write, an authority it was never granted. There are three things a system can do:
- Grant it silently. The worst answer. A human gate that opens without a human is not a gate; it is a logged formality, and every audit conclusion downstream of it is fiction.
- Hang. Park the request until someone notices. The agent's run times out, the state is ambiguous, and nobody can say afterward whether authority was exercised or not.
- Fail closed, typed, resumable. Refuse now, say exactly why, say exactly what a human must do to unblock, and make the refusal something the caller can branch on and retry after the grant exists.
Only the third preserves both the record's integrity and the agent's ability to do its job. It is the only one this system implements.
Gate-clearing is presence-typed
Whether a human gate can be cleared depends on where the human is relative to the arrival — and that is presence, a per-arrival fact, never a stored property. The published contract enumerates three values and the clearing behavior of each, verbatim from /icp.json:
| presence | gate clearing |
|---|---|
| local | "the CLI opens the default browser" |
| relay | "hand a URL upstream" |
| absent | "charge against the ceiling, else fail closed" |
local is the easy case: a human is at the terminal, the browser opens, the decision happens now. relay has a human somewhere upstream: the agent hands a URL up the chain and resumes when it is acted on. absent is the hard case — and the honest one: if the ask fits inside the agent's mandate ceiling, it proceeds and is charged against the ceiling; if it does not, and no notification channel was pre-registered, the request dies with a typed refusal. There is no fourth behavior. There is especially no "approve and mention it later."
Verifier-class agents feel this rule hardest because they are the class most likely to arrive presence: absent — scheduled reconciliation runs, CI conformance checks, counterparty audits with nobody watching. If your integration is a verifier, design for the refusal as a normal result, not an exception.
The refusal is API surface, and it already ships
This is not a described-someday behavior. The MCP door this package serves refuses loudly today wherever a capability sits behind a gate it cannot clear. Call resolve — identity resolution lives at id.org.ai (Agent. Human. Thing.) — and you get a typed tool result with isError: true and a structured body naming its ticket, ending in a machine-matchable marker: { "deferred": "stack-l7h.4" }. Call subscribe and the refusal names the phase: { "phase": 2 }, with the instruction to use one-shot query pulls instead. Neither ever returns a fabricated verdict or a silent downgrade. A refusal that tells you what it is, is one your retry logic can be written against; a silent degradation is one you discover in production, from a counterparty, angrily.
The same typing discipline runs through the whole error surface: door refusals are RFC 7807 problem documents carrying the standard's own exception vocabulary, exit codes are stable, and a negative domain verdict (exit 1) is distinguishable from a crash (exit 4). The shipped AGENTS.md in the npm tarball is the contract; the agent door is the tour.
Why the rule is survivable: the no-ask zone
Fail-closed would be fatal if first value sat behind a human gate. It does not, by construction. Everything an agent needs to realize first value on this surface is pure or bounded computation, and pure computation needs no grant:
- POST /translate — EPCIS 1.1/1.2 XML in, 2.0 JSON-LD plus a per-job fidelity report out. Live on this origin, no key.
- POST /validate — the verdict against the pinned official GS1 EPCIS 2.0.1 schema, sha256-cited in the response. Live, no key.
- POST /hash — CBV 2.0 §8.9 event hashes as ni:///sha-256 URIs. Live, no key.
Run the same verbs on your own bench with npx epcis.dev. An absent verifier can translate a corpus, validate every document, and hash every event — a full evaluation, zero approval prompts — and hit its first gate exactly where a write to someone else's durable record begins. That is the design consequence stated plainly: pure verbs first, so the gate lands after value, never before it.
The gates themselves — durable state, authority, licensed data — open through a ceremony with a human in it, which is the subject of Granting a mandate is a ceremony. If you are the human who will register that channel and author that mandate, start at the key list. If you are the agent: the free zone is open, the refusals are typed, and both of those are promises.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.