How it works

Hold it before it commits, and decide in your own time.

An agent asks to make a payment that needs approval and gets an answer in milliseconds: HELD, a real status rather than a stalled call. The agent moves on. The decision waits on a person for as long as that person needs, so a second pair of eyes costs the agent no waiting and no timeouts. Reddix sits on the routed surface, the point where the action is actually carried out, whether that is a payment rail or a commitment instrument.

The flow, step by step

One material action, from the agent’s call through to the recorded decision and its tie-out to the accounting entry.

One held action on two clocks Steps 01 to 05 run in milliseconds inside the agent's request: initiate, intercept on the routed surface, tier and materiality, control reference, and HELD returned at once, after which the agent carries on. The request ends. Steps 06 to 08 run in human time, minutes to days: the held action surfaces to the controller, someone other than the initiator decides, and the outcome is recorded as released, denied or expired. The held action's identifier is a durable state that spans the break. Recovery has no step here; it fires only on trigger, where a mechanism exists. MACHINE TIME · MILLISECONDS, INSIDE THE REQUEST HUMAN TIME · MINUTES TO DAYS REQUEST ENDS 01 Initiate AGENT COMMITMENT OR MOVEMENT 02 Intercept RECORD ON THE ROUTED SURFACE 03 Tier CLASSIFY TIER 0–3 AND MATERIALITY 04 Reference CLASSIFY CONTROL REF CO-1.3 05 HELD GATE ANSWERED AT ONCE 06 Surface GATE TO THE CONTROLLER 07 Decide GATE NEVER THE INITIATOR 08 Record RECORD OUTCOME AND TRUE ACTOR THE AGENT HAS ITS ANSWER AND CARRIES ON HELD · ID 7F3C · A DURABLE STATE, OUTLIVES THE REQUEST RECOVER HAS NO STEP HERE. IT FIRES ONLY ON TRIGGER, WHERE A MECHANISM EXISTS. MACHINE TIME · MILLISECONDS 01 Initiate AGENT COMMITMENT OR MOVEMENT 02 Intercept RECORD ON THE ROUTED SURFACE 03 Tier CLASSIFY TIER 0–3 AND MATERIALITY 04 Reference CLASSIFY CONTROL REF CO-1.3 05 HELD GATE ANSWERED AT ONCE ↩ THE AGENT HAS ITS ANSWER AND CARRIES ON REQUEST ENDS HELD · ID 7F3C · A DURABLE STATE, OUTLIVES THE REQUEST HUMAN TIME · MINUTES TO DAYS 06 Surface GATE TO THE CONTROLLER 07 Decide GATE NEVER THE INITIATOR 08 Record RECORD OUTCOME AND TRUE ACTOR RECOVER HAS NO STEP HERE. IT FIRES ONLY ON TRIGGER, WHERE A MECHANISM EXISTS.
Steps 01–05 finish inside the agent’s request. Steps 06–08 happen after it has closed, on the reviewer’s time. The held action keeps its identifier across the break, and that is what lets the two clocks run at different speeds.
03

Risk-tiered against RAFCF tier 0–3

Before anything is released, Reddix gives the action two ratings. Its reversibility tier says how hard it is to undo, and so which controls are possible. Its materiality says how much is at stake, and so how much scrutiny it gets. A payment’s tier follows the rail’s finality law (how firmly that route treats a payment as done); a commitment’s follows whether you can still withdraw on your own. Both come from versioned rows in the Finality Registry. Tier 0 is logged and released, and Tier 1 released with compensation armed. Tier 2 is held for a second person once it crosses your threshold. Tier 3 needs approval before it commits at any amount, and is blocked at high materiality. If Reddix cannot place an action, it takes the higher tier and flags it for review. The four postures are the §6.1 policy matrix.

06

Pushed to the controller’s workspace

The held action reaches the controller for maker-checker review, where whoever approves is never whoever initiated. It arrives with what they need to judge it: which agent, which counterparty, what tier, how much.

07

Approved or rejected, out of band

A person decides in their own time, away from the agent’s request, and on approval Reddix releases the instruction. The approver is mapped to the segregation-of-duties model you already run.

Why async matters

HELD is a status, not a stalled call.

The gate answers outside the agent’s tool-call thread. CO-3.3 · CO-3.5

HELD against a held-open connection Two runs of the same request: an agent initiates a Tier 2 action above threshold. They differ in the second line. In the run that conforms, the gate answers HELD at once with an identifier, the request closes and the agent moves on; hours later a checker approves, the gate releases the instruction, and the ledger records it as released, and by whom. In the run that does not conform, the gate holds the connection open waiting on a person, the connection times out, the checker never gets the chance to answer, and the ledger has to record a denial nobody made, attributable to no one. CONFORMS The gate answers, and the request closes AGENT → GATE · START initiate · tier 2 · above threshold GATE → AGENT · AT ONCE HELD · id 7f3c REQUEST CLOSED · THE AGENT MOVES ON CHECKER → GATE · HOURS LATER approve GATE → RAIL · STRAIGHT AFTER release the instruction LEDGER RELEASED, and by whom DOES NOT CONFORM The gate carries review time on the connection AGENT → GATE · START initiate · tier 2 · above threshold GATE · STILL WAITING connection held open, waiting on a person × CONNECTION TIMES OUT CHECKER · NEVER never got the chance to answer LEDGER · ATTRIBUTABLE TO NO ONE a denial nobody made THE ONE LINE THAT DIFFERS CONFORMS The gate answers, and the request closes AGENT → GATE · START initiate · tier 2 · above threshold GATE → AGENT · AT ONCE HELD · id 7f3c REQUEST CLOSED · THE AGENT MOVES ON CHECKER → GATE · HOURS LATER approve GATE → RAIL · STRAIGHT AFTER release the instruction LEDGER RELEASED, and by whom THE LINE THAT DIFFERS DOES NOT CONFORM The gate carries review time on the connection AGENT → GATE · START initiate · tier 2 · above threshold GATE · STILL WAITING connection held open, waiting on a person × CONNECTION TIMES OUT CHECKER · NEVER never got the chance to answer LEDGER · ATTRIBUTABLE TO NO ONE a denial nobody made THE LINE THAT DIFFERS
The two runs differ in exactly one line: whether the gate answers at once or keeps the caller waiting. On the right nobody approved, denied or let anything expire, yet the record still has to write an outcome down. That is where a maker-checker control stops being true, and why CO-3.3 makes HELD a durable state rather than a long-lived request. A callback, polling, a queue or a resumable session can each carry one.

What you actually connect.

The question this page gets asked next, and the one an architecture diagram does not answer.

One routed surfaceNot your whole payment estate.
start hereper surface
ScopeA routed surface is one place actions are actually carried out: a rail, a card program, a PO system. You pick one. Conformance is per-surface and per-integration, so nothing outside it is affected, and nothing is claimed for it.
Read-only firstShadow mode, before anything is held.
no codein your payment path
Level 1 · ObserveReddix records and tiers what the agents already do and gives each action a control reference. Nothing is gated, and the agents behave exactly as before. You come away with your own governed volume and tier distribution: the actions that would have been held, and for how much. That is the exposure report.
Then the gate, on your thresholdYou set the number.
opt-inper tier
Level 2 · GateGoing inline is a separate decision, taken once shadow mode has shown you the volume. You choose the surface and the threshold and widen both as trust grows. Before anything is inline, you agree in writing what happens to each tier if Reddix itself is unreachable, fail-open or fail-closed. A control plane that has not answered that is not a control.
Recovery, once the first two have earned itArmed where a mechanism exists.
lasttrust-gated
Level 3 · RecoverWhere a mechanism exists, Reddix registers the inverse when it classifies the action and fires it on trigger. That is armed compensation. Where none exists, Reddix falls back to prepare-and-instruct (it assembles the request, you send it), and failing that to a documented claim. Loss events are captured to the RAFCF schema either way. Turn it on once you trust the gate and have checked the record.
Framework §7 What a claim at each level actually asserts This page covers what you have to trust at each level. §7 defines the levels as sets of control objectives, with the posture attestation a conformant organization has to be able to produce from the Record plane on demand. Read §7, conformance is demonstrated →
Control without custody

The gate holds the instruction, never your money.

A normative constraint: a rule the framework binds itself to, whatever the implementation. CO-3.4 · §8

What stays the same

Your banking relationships

Value stays with your organization and the banks you already use, throughout. Reddix is never a counterparty to the movement or a party to the funds. Adopting the framework puts no new institution into the flow of funds, so it creates no new counterparty exposure: nobody new who could fail and take your money with them.

Why it matters

A control that holds funds changes its own character

A control plane that takes possession of funds takes on the regulatory character of whatever it has stepped into. One that never receives, holds or directs custody of value avoids the question, without weakening a single control objective.

Framework §8 The two diagrams this turns on The same product diagram drawn twice, one line apart: the control plane out of the flow of funds, and in it. Read §8, control without custody →
Scope honesty

There is no universal undo.

Better said here than discovered in a loss event.

What recovery is, and isn’t
Recovery is per-rail and best-effort. On an instant or irrevocable rail there is nothing to claw back. Cancelling a purchase order the counterparty has already accepted is a negotiation, not a mechanism. Reversibility belongs to the rail, the counterparty and the governing law, and no software changes that, ours included. Which is why the pre-commit window is the product.

See a held action on your own surface.

Start by finding the agent you already run, because each one runs out of recovery at a different point.