What ZIFFER is

An agent asks for something. ZIFFER decides whether it may have it, and writes down what it decided. Nothing runs on a decision that cannot be shown afterwards.

That is the whole product. The rest of this page is the five steps it takes.

Propose

The agent sends a proposal: one action, its arguments, the resources it touches. It does not send a risk level, a reversibility class or an approval. Those are values ZIFFER derives; a value the decision depends on is never read from the party being decided about.

A proposal is a request. It is not a permission, and holding one grants nothing.

Grant

ZIFFER grades the proposal against signed policy: what the action costs, what it touches, whether it can be undone. The grade meets a floor, and the floor decides what has to happen before the action may run.

Below the floor, the answer is a grant. At or above it, the action is held and needs people.

Three defaults are fixed and fail closed:

• a resource with no entry in policy is graded at the highest tier, never the lowest;
• an action with no reversibility entry is treated as irreversible;
• an action with no risk function is refused, not graded down.

Unknown is never low.

Execute

A held action needs a quorum. Two named approvers, two separate confirmations, two distinct signing identities:

held - quorum 2-of-2 required
  approver 1  confirmed
  approver 2  pending

One approver confirming twice is one approver. If the second confirmation does not arrive, the hold expires:

quorum not met - nothing ran

Nothing ran. Not "was rolled back", not "was reversed". The action never started, because the executor checks the grant before it acts rather than after.

Prove

Every grant produces a receipt: the proposal, the grade, the quorum that met, the identities that signed, the time. The receipt is signed with two independent signature algorithms at once, and verification requires both. One broken algorithm does not make a receipt forgeable.

A receipt is checkable by someone who was not there and does not trust you. That is the point of writing it.

Distribute

Receipts go into an append-only chain, and the chain is anchored where more than one party can see it. An anchor nobody but you can read is a log; an anchor two parties hold is evidence.

What ZIFFER does not hold

ZIFFER does not run your action. It does not hold your credentials, your data or your keys. It grants, and it proves the grant. The executor stays on your side, and it is the executor that refuses to act without a valid receipt.

That boundary is deliberate. A grant layer that also executes is a single component that can both authorise and perform, and there is then nothing left to check it.