How OwnCharter works
One action, end to end: the intent, the Gate that denies it before execution, the signed capability behind it, and the record that answers for it afterward.
One action, end to end
INTENT export customer table to external endpoint GATE no capability: denied before execution INTENT update CRM record: mark invoice 1042 paid GATE capability granted: crm.write RESULT done. hash-chained to the permanent record.
The first thing the Gate does on this page is refuse. The export intent held no granted capability, so it was denied before execution. Not caught in a review. Not flagged in a dashboard the morning after the customer table had already left the building.
Every action an agent takes passes through this one chokepoint, and the chokepoint fails closed. Not granted means denied. Not verified means denied. Errored means denied. Prevention, not detection.
The allowed action follows the same path: intent, checked capability, execution, permanent record. That is the tactical layer behind the strategic claim.
The gate is not writable by the thing it gates
The grant moves in one direction only. An agent cannot grant itself a capability, cannot widen one it already holds, and cannot reach the mechanism that decides, because the gate is not writable by the thing it gates.
A tool that watches agents and reports afterward is selling you a description of the incident. A description is not a gate in front of it. The director sent to break this should start here: find the path that lets the actor change the rule. There is none.
Who grants, and what a grant is
crm.write did not come from nowhere, and it did not come from the agent. Only the operator grants capability, and that is a human decision every time.
Operator names a seat, not a job title. Which human holds it is yours to decide. The grant lands on the record next to the action it authorized.
Capabilities ship as signed packs, and they are verified against a pinned root before the Gate will honor them. Unsigned, unverified, or tampered with gets the same fail-closed answer as everything else. A signature on its own is a badge you accept on faith. A signature checked at a fail-closed gate is a control.
The permanent record
Both decisions in that transcript, the allow and the deny alike, landed in the same place: a permanent record, written after the Gate ruled and never before. Authorized before, recorded after.
The record is hash-chained. Each entry folds the hash of the entry before it into its own, so it is tamper-evident by construction. Rewrite one entry and its hash stops matching, and every entry after it inherits the break.
Try to break it
Rewrite one entry. Watch the chain tell on you.
Below is a slice of the record: four Gate decisions, each entry's hash folded into the next. This time you are not the operator, you are the intruder. Rewrite an entry, the way an agent covering its tracks would, and watch every hash downstream of the edit fail verification.
A slice of the record
Tap any entry to rewrite it.
Do not accept a claim of tamper evidence. Rewrite an entry. The hashes downstream must fail verification or the record is not evidence.
What this costs you
The invariants hold today: the Gate fails closed, capability comes only from the operator, packs verify against a pinned root, and the record is hash-chained. I run my own governed agent operation on that construction while I build it.
The fleet-scale Control Information Center is not built yet. It is being built in the open, heading for early alpha. The cost of assessing it is the time to read the record and try to break the rules. I have left both in the open.
Start with the writing.
One operating problem at a time, taken apart in long form. For people who see the whole puzzle and have to answer for it. No pitch attached.