ZIFFER home

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 policyZIFFER answers
The resourceHighest tier
The reversibility of the actionIrreversible
A risk function for the actionRefused

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 required

Distinct 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 ran

Nothing 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

On this page