Concepts
Proposal, grant, quorum, receipt, anchor - the five objects ZIFFER moves, and what each one is not.
Five objects. Each definition ends with what the object is not, because most of the ways this goes wrong are a reader assuming one of them is the other.
Proposal
A request from an agent for one action: what to do, to which resource, with which arguments.
A proposal carries facts about the world. It does not carry the values the decision depends on: the risk grade, the reversibility class, who owns the resource. Those are recomputed from signed policy on the deciding side.
A compromised agent writes the whole proposal. So the proposal is treated as what an untrusted party said, and every value that decides anything is derived somewhere else.
A proposal is not a permission. Holding one grants nothing.
Grant
The decision that an action may run, produced by grading the proposal against signed policy and comparing the grade to a floor.
Three defaults fail closed:
| Missing from policy | ZIFFER answers |
|---|---|
| The resource | Highest tier |
| The reversibility of the action | Irreversible |
| A risk function for the action | Refused |
A default that changes no outcome is documentation, not a control. Each of these three is read by a branch that can stop an action.
A grant is not an execution. ZIFFER never performs the action.
Quorum
The rule for a held action: how many distinct approvers must confirm before a grant is issued.
held - quorum 2-of-2 requiredDistinct means distinct signing identities. Two confirmations from one approver are one approver, and the check is on the identity that signed, not on the name in the message. If the quorum is not met before the hold expires:
quorum not met - nothing ranNothing ran is stronger than nothing persisted. The executor never started, because it had no receipt to start on.
A quorum is not an approval workflow. It is a condition on a signature count, and it is checked at the executor, not at the button.
Receipt
The signed record of a grant: the proposal it answers, the grade, the quorum that met, the identities that signed it, and when.
It is signed with two independent signature algorithms, and verification requires both. One algorithm breaking does not make a receipt forgeable.
The executor verifies the receipt before acting. That is the load-bearing step: a receipt that is transmitted but never checked is a claim, and a claim is what an attacker sends.
A receipt is not a log line. A log records what a system says happened. A receipt is checkable by someone who was not there and does not trust you.
Anchor
A commitment to the receipt chain, published where more than one party can see it.
Receipts are appended to a chain, so a receipt cannot be removed later without breaking every receipt after it. The anchor makes that chain checkable by someone outside the system that wrote it.
An anchor is not a backup. A record only you hold is a record only you can edit. The point of anchoring is the second party.
How they connect
agent ──proposal──▶ ZIFFER
│ grade against signed policy
│ compare to the floor
├── below floor ──▶ grant ──▶ receipt
└── at or above ──▶ held ──▶ quorum met ──▶ receipt
└── not met ──▶ nothing ran
receipt ──▶ executor verifies, then acts
└──▶ chain ──▶ anchor