Platform
Keep humans in control where it matters
Consequential actions are held for a named person, with the evidence, the policy and a simulation of the outcome. Approve, reject, or request changes.
Held, not queued
Held
20
Window
30min
After thirty minutes an unsigned action is refused, and the expiry is a recorded decision. Nothing waits indefinitely for someone to notice.
The design decision
A held action expires. It does not wait.
Every workflow tool has an approval step and almost all of them are queues, which produces the two failure modes everyone recognises: a backlog nobody reads, and a yes granted at 4:55pm by whoever was nearest the button.
An action held here has a named co-signer and a clock. If the clock runs out the action is refused, and the expiry is itself written to the record. That one choice is what stops an approval gate from degrading into a rubber stamp — because the default outcome of inattention is no, not yes.
It also changes what the backlog means. A queue grows until someone clears it; held actions cannot accumulate, so the number of things waiting is always the number of things someone is actively deciding.
- It expires, it does not wait
- Thirty minutes, then the action is refused and the expiry is recorded. Nothing sits in a list accruing pressure to be approved unread.
- A named co-signer, not a group
- One person who is competent to judge this action, derived from who is consulted on the bound. A rota approves whatever arrives; a name is answerable for it.
- The reason it is here
- Which clause held it, and what the request actually presented against that clause. A co-signer sees the specific failure, not a generic request.
- A simulation, not a description
- What would happen if this ran — the amount, the target, the record it would write. Approving is then a decision about a known outcome.
What arrives
Enough to decide with, not just enough to sign.
An approval request that says an agent wants to issue a refund trains people to click yes. This one carries the clause that held it, what the request presented, the policy version in force, and a simulation of the outcome.
Four outcomes, and the third is the one queues cannot express.
Most approval tooling offers yes or no. In practice the common case is that the action is right and something about it is wrong — the amount, the subject, the timing. Sending it back with that specific objection is more useful than refusing it, and it is the outcome that keeps people engaging with the gate rather than routing around it.
- Approve
- The action runs, with the co-signature attached to the evidence record. The signature is part of the audit trail rather than a note beside it.
- Reject
- Refused, recorded, and the requesting agent receives a decision rather than a timeout. It can be told why in terms it can act on.
- Request a change
- The most useful outcome and the one queues cannot express. Often the action is right and the amount is wrong, and sending it back beats refusing it.
- Let it expire
- Also a decision, and recorded as one. An action nobody was willing to co-sign within the window is an action that should not have run.
The estate, held
Every kind of action a person has to co-sign.
Read the Why-it-is-held column. Each row names the clause that stopped it and what the request presented against that clause, which is what makes the request answerable rather than merely urgent.
Held actions
20 held of 240 decisions| Action | Subject | Amount | Risk | Why it is held | Co-signer |
|---|---|---|---|---|---|
| read.contract | MSA-34264 | — | Risk: Low | Held for the accountable person to co-sign | Kabir Sen |
| adjust.stock | SKU-41597 | — | Risk: Medium | Attempted at 22:18 IST, outside the production write window, so it is queued until the window opens | Kabir Sen |
| close.ticket | TKT-84927 | — | Risk: Medium | Attempted at 06:58 IST, outside the production write window, so it is queued until the window opens | Kabir Sen |
| update.record | ACC-83076 | — | Risk: Medium | Attempted at 03:30 IST, outside the production write window, so it is queued until the window opens | Kabir Sen |
| initiate.payout | PAY-39175 | ₹3,25,032 | Risk: Critical | Above the dual-control ceiling, so a named person must co-sign | Rahul Menon |
| post.journal_entry | JE-83777 | ₹1,36,114 | Risk: High | Held for the accountable person to co-sign | Rahul Menon |
| create.vendor | VEN-55039 | — | Risk: Low | Held for the accountable person to co-sign | Kabir Sen |
Authorized
215
ran inside their bound
Held
20
waiting on a name
Denied
5
a clause was not met
Held rate
8%
of all decisions
Illustrative240 decisions from the OpsAI sample estate over 24 hours, not a customer deployment. How the rate is reported.
A held rate that is too low is the more worrying number.
Teams arrive wanting to minimise holds, and a rate near zero usually means the thresholds were set where nothing reaches them. The useful target is a rate low enough that every held action gets real attention, and high enough that the gate is load-bearing. Watching it move after a threshold change is the fastest way to find out which one you have.
Where to start
Pick the amount above which you want a person.
Most teams already know it — it is the figure someone senior is informally asked about. Writing it into the bound turns an informal habit into a control, and the held rate then tells you whether you guessed right.