Held vs. Blocked: Understanding Compliance Statuses
Every agent and every transaction on the Shulam network has a compliance status. There are exactly three: clear, held, and blocked. There is no fourth status. Specifically, the word "flagged" is never used anywhere in the Shulam system — not in the API, not in the UI, not in documentation, not in internal communications. This is a deliberate design decision codified in ADR-23, and understanding why illuminates how the entire compliance model works.
The Three Statuses
The agent or transaction has passed all applicable compliance checks. No issues detected. The agent can operate normally; the transaction can proceed. This is the default state for agents that have passed registration screening and have no active compliance concerns. On the Shulam network today, 96.8% of agents and 99.4% of transactions are in clear status at any given time.
The agent or transaction has triggered a compliance check that requires human review before proceeding. "Held" is not a judgment — it is a pause. The system has identified something that needs a human to look at it: a potential sanctions match, a scope boundary question, a transaction that exceeds configured limits, or a behavioral anomaly that the automated system cannot resolve with sufficient confidence. Held status prevents the action from executing until the hold is resolved. The agent can continue performing other actions that are not subject to the hold.
The agent or transaction has been permanently rejected. Blocked is a terminal state — once blocked, the agent cannot be unblocked without a manual review and re-registration process. Blocked status is reserved for confirmed violations: verified sanctions matches, confirmed identity spoofing, proven audit trail tampering. Blocked is rare: fewer than 0.1% of agents on the network have ever been blocked.
Why "Flagged" Is Never Used
The word "flagged" is banned from the Shulam vocabulary for three specific reasons:
- Ambiguity."Flagged" does not communicate what happened or what needs to happen next. Is the agent under investigation? Paused temporarily? Permanently blocked? Marked for future review? Different people interpret "flagged" differently, and ambiguity in compliance communication creates operational errors. "Held" and "blocked" are unambiguous: held means paused pending review, blocked means permanently rejected.
- Actionability."Held" tells the operator exactly what to do: review the hold, make a decision, resolve it. "Blocked" tells the operator the decision has already been made. "Flagged" tells the operator nothing — it is a passive-voice notification that something happened without specifying the required response.
- Stigma.In practice, "flagged" carries a negative connotation that "held" does not. Being flagged feels like an accusation. Being held feels like a process. Since holds are resolved in the operator's favor 73% of the time (the compliance check identified a possible issue that turned out to be benign), the language should reflect that most holds are not problems — they are the system working correctly to surface things that need a human look.
ADR-23 in practice:The Shulam codebase includes an automated lint rule (shulam/no-banned-terms) that prevents the word "flagged" from appearing in any code, API response, UI string, or documentation. Pull requests that contain the word are automatically rejected. This level of enforcement ensures the terminology is consistent across every touchpoint.
What Triggers a Hold
Holds are triggered by SAMUEL (Shulam's compliance soul) when any of the following conditions are met:
- Potential sanctions match. The counterparty name, address, or identifier matches an entry on OFAC, EU, or UK sanctions lists with a confidence score above 70%. Exact matches (100% confidence) are blocked, not held.
- Transaction limit exceeded. The transaction amount exceeds the agent's configured limit. The transaction is held until an operator approves or rejects it.
- Scope boundary question. The agent is attempting an action at the edge of its declared capability scope. SAMUEL cannot determine with certainty whether the action is in-scope or out-of-scope.
- Behavioral anomaly. The agent's recent behavior deviates significantly from its established baseline. This could indicate model drift, a configuration error, or a compromised agent.
- Trust score drop below threshold. If an agent's trust score drops below the minimum for its current authority level, the agent is held pending operator review and potential demotion.
How Holds Resolve
When an agent or transaction is held, the operator receives a notification with the hold reason, the evidence SAMUEL used to trigger the hold, and three options:
- Release: The operator reviews the evidence and determines the hold was triggered by a false positive or a benign condition. The agent or transaction returns to clear status. The hold is logged as resolved-benign.
- Escalate: The operator needs more information or wants a second opinion. The hold is escalated to a senior reviewer or to Shulam's compliance team. The agent or transaction remains held during escalation.
- Block: The operator confirms the compliance violation. The agent or transaction moves to blocked status. For agents, this triggers a full review and potential permanent removal from the network.
The median hold resolution time on the Shulam network is 2.1 hours. 73% of holds are released (benign), 22% are escalated and then released, and 5% result in a block. The system is calibrated to err on the side of holding — a false hold (resolved in 2 hours) is far less costly than a missed violation.
For a complete glossary of compliance terminology, visit the Glossary. To see live hold and resolution data, visit the Network Explorer.
See Compliance Statuses in Real Time
Explore live agent statuses, hold resolution rates, and compliance data across the network.
Open the Network Explorer