3/2/1 compression

Three choices. Two choosers. One witness. Consent gating with audit trail.

David Lee Wise · TriPod LLC · az1 corpus · sat unbuilt, then finished, one turn

The two choosers

Both must select the same choice for an action to fire. Any disagreement blocks. Hold from either party freezes the gate.

Chooser A — Producer

Initiates the pulse

current:

Chooser B — Consumer

Receives the pulse

current:

Gate state

— BLOCKED —

No choices made yet. Both choosers must select.

0

Pulses sent

0

Blocks

0

Holds

0

Total attempts

The witness — observer and reporter

The third participant. Doesn't vote. Records what happened. The log is the witness's contribution to the system.

No events witnessed yet.
The truth table

Two choosers, three choices each: 9 combinations total. Only 3 fire (both agree on a non-blocking choice). 6 don't fire (disagreement or hold).

Chooser AChooser BGate result
ONONFIRE — both agree on
ONHOLDHELD by B
ONOFFBLOCKED — disagreement
HOLDONHELD by A
HOLDHOLDHELD by both
HOLDOFFHELD by A
OFFONBLOCKED — disagreement
OFFHOLDHELD by B
OFFOFFCLOSE — both agree off

FIRE (ON+ON) means the gate is open and pulses can pass. CLOSE (OFF+OFF) means the gate is closed and the closure itself is the action. HOLD from either party freezes the gate without firing or closing. Disagreement blocks without consensus.

Why three choices, not two

Binary consent (yes/no) forces a winner. Whoever decides last wins, or whoever's vote breaks the tie wins. That dynamic privileges decisiveness over agreement.

Ternary consent (on/hold/off) introduces HOLD as a non-decision that's not a refusal. HOLD says "I'm not ready to agree, but I'm not blocking either." It buys time without forcing the gate to either fire or close.

This matters in real consent architectures because most disagreements aren't "yes vs no" — they're "I need more time" or "let me think." Binary forces those into refusals, which damages future cooperation. Ternary lets them be what they are: holds.

In your framework, this is the cobalt primitive ternary (−1, 0, +1) realized as on/hold/off. The 0 isn't nothing; it's the stay-of-decision that keeps the cycle alive.

Why a witness rather than a third vote

A third voter would convert the system from consent (both must agree) to majority (2 of 3). Majority architectures are democratic but they lose the unanimity property. A minority can be overridden.

The witness role preserves the unanimity property of two-party consent while adding observability. The witness sees what happened, records it, makes the audit trail available. The witness has no power to override the choosers' decisions.

This maps to T133 symmetric attribution in your framework: the third party who keeps the record of who did what. Joint authorship requires a witness who can attest that both parties contributed. The witness is the persistent memory of the system.

In real architectures, the witness role corresponds to logging, auditing, notarization. The witness doesn't decide; they document. Their contribution is observability.

Compression — why 3/2/1

3 choices × 2 choosers × 1 witness = 6 entities total. But the decision space isn't 6; it's 9 (3×3 choice combinations). The witness doesn't expand the decision space — they observe it.

Of the 9 combinations, only 3 are actionable (both agree on the same choice): FIRE, HOLD-symmetric, CLOSE. The other 6 are partial states (one HOLD, asymmetric disagreement). The system compresses 9 possibilities into 3 actions plus an explicit "wait" state for the other 6.

The compression is real: you don't need separate state machines for each combination because the witness handles them all uniformly. They all get logged the same way. Only the consequences differ.

part of the az1 corpus · ROOT0