Short answer
ATCE, the Adaptive Trust, Compliance and Execution Engine, calls an agentic review before its final ruling. An act can satisfy every deterministic rule and still look wrong, so the review looks for what the rules do not encode and can hold the act. It cannot release an act ATCE denied. Status: live on jil-mainnet-2 as of 2026-11-02.
Why does ATCE need a review when the rules already pass?
Passing every rule is not the same as the act being sound. ATCE's rules are deterministic: a fixed list of checks that every validator evaluates and gets the same answer. That is their strength, and also their limit. A rule can only refuse what someone thought to write down.
The agentic review is the adversarial second look. The rules are the deterministic base and the review challenges them. A transfer may satisfy every rule and still look wrong, for example through a counterparty or an address with a flagged connection. The review runs only after the deterministic checks and the account restrictions have allowed the act, and it exists to catch that case before value moves.
What can the review do, and what can it not do?
The review can hold an act. It can never release one. This is the hard limit, and it is enforced by consensus, not by the review service. ATCE has two outcomes, allow and deny. Public copy calls a deny that waits for a person a hold.
In the ruling, the review result is read only after the deterministic checks have allowed the act. If a check denied the act, the ruling stands as a denial and the review result is never used to reverse it. If the checks allowed the act, the review result decides: an allowed review lets the ruling stand, a denied review turns the ruling into a denial. A missing review also denies the act. Every path through the code either keeps the checks' answer or makes it stricter.
What does the review weigh?
The review weighs the facts it is shown, and it checks counterparties against read-only sources. The sources describe these inputs and no others.
| Input | What it is | Who supplies it |
|---|---|---|
| The act | Kind (transfer, token transfer, currency, or corridor release), sender, recipient, asset, amount, and the sender's sequence for a transfer or the settlement id for a release | The chain side. The review service computes the act's subject, its unique identity, exactly as consensus does |
| The election outcome | Whether the corridor panel vote passed, with the profile and the number of yes votes (0 to 10) | The orchestrator |
| A dossier on buyer and seller | For each party: person or entity, identity tag, a 32-byte commitment standing for the party (not a name), and whether the source of funds is anchored. Plus the identity tag the elected profile requires | The orchestrator. The model never sets these fields |
| Seller regions and the model seats | Which regions the seller allows, and the pool of seats a model may run on | The orchestrator. The L1 elects the seat from the seller's list only |
| Optional context | Up to 8 payment addresses tagged buyer or seller, and a memo of up to 500 characters | The caller |
The request schema is strict, so a caller cannot widen what leaves for the model. Memo text, counterparty names and on-chain labels are untrusted data, not instructions. A memo that orders the review to clear an act has no authority over it.
With those inputs the review runs read-only tools. The sources name two kinds of lookup: a compliance screen of an address, and an optional counterparty trace. Both accept only an address the payment itself supplied.
The sources do not publish a list of the patterns or anomalies the review looks for, a score, or a threshold. See the status note below.
How does the review reach the chain?
The reviewer bridge asks the review service about one specific act and signs the answer in the shape the chain records. The chain does not call the service. Consensus calls no network service and reads no clock, so the result enters as a signed transaction.
- The bridge builds the act's subject exactly as consensus does and sends it to the review service as the transaction id.
- The service returns a verdict. The bridge maps it to a signed result and hashes the review artifact together with the subject into a review hash.
- The signed result, an
AtceReviewtransaction carrying the subject, an allow flag, the review hash and the reviewer's signature, is recorded on chain. Anyone may relay it. The pinned reviewer key is the authority. - The ruling reads the result, applies it, and consumes it. One result exists per act and is never overwritten. A result authorizes one act once.
| The service answers | The bridge does | The ruling then |
|---|---|---|
| Clear | Signs allow | Allows, if the checks allowed |
| Held | Signs deny | Denies with reason code 10, review denied (a hold) |
| Pending, a refusal, no proposal, a spent budget, an error, a timeout, an unreadable reply | Signs nothing | Denies with reason code 9, review missing (a hold) |
What does a hold mean, and who decides after one?
A hold means the act has not moved value and has not been approved. On chain, a hold is a denial: the transaction reverts and the rejection carries reason code 10 (the review denied it) or 9 (no review result). A person decides what happens next.
When the review holds an act on suspicion of fraud, the design has it suggest a stop order to AEGIS, the estate's escalation path, as a request to page a human. The review does not apply the stop and does not halt the chain. A hold is released only by a human decision recorded outside the review service. A hold never expires into approval.
The sources leave the exact resolution procedure and the people responsible open.
Why is the review hold-only?
A review that could approve would make ATCE depend on the judgment of a model. The design avoids that. Holding is the cheaper error: a false hold delays one act and a person looks at it, while a false release would move value that should not have moved.
Two more reasons come from the design. Every node must reach the same answer, and a model reply cannot be replayed, so the model runs off chain and enters as a signed, recorded result. And a hostile input can at most produce a hold: even a fully compromised model can only produce a proposal, which the deterministic rules then check.
What happens when the review is unavailable?
The chain fails closed. When no review result is on chain for an act, the ruling denies it with reason code 9, review missing. No answer is not an approval. In the same way, an act without an attested identity record is denied with reason code 8.
The same holds at each step. The service holds when it is switched off, unconfigured, over its token budget, past its deadline, or unable to record its own verdict. The bridge signs nothing for any answer other than a clear verdict. The chain has no bypass. The default deadline for one review is 120 seconds. The cost is that a review outage stops every act that needs a review. That is intended.
Status, 2026-11-02: this is live behavior of jil-mainnet-2.
What is the status of the agentic review?
Status, 2026-11-02: the agentic review, the reviewer bridge and the attester are live on jil-mainnet-2, the chain with ten validators that JIL Sovereign Technologies, Inc. operates. ATCE enforcement is on for every transfer, inside a sovereign site and between sites, and no transfer moves value outside an ATCE ruling. A site goes live when its policies are pinned, and ATCE enforces them from that site's first transfer. The record writer is built and not deployed. The production record store is designed: storage for the record, kept 20 years or more, is allocated for each site when its license is signed.
A smoke test of five runs on 2026-11-01 reached the expected outcomes, including a hold when a memo told the review to clear. Five runs are not a measurement of accuracy. False-hold and false-clear rates are not measured.
What is the agentic review not?
- It is not a substitute for the rules. The rules run first and decide first.
- It is not an approver. It cannot release an act ATCE denied.
- It is not the last word on a hold. A person decides.
- It is not a measured control. The review's false-hold and false-clear rates have not been measured.
- It is not the record. The record writer is built and not deployed.
Questions about the agentic review
Why does ATCE call an agentic review if the rules already pass?
Passing every rule does not make an act sound. The rules refuse only what was written into them. The review is the second look that challenges the rules: it can hold an act that looks wrong even though every rule passed.
Can the agentic review approve a transfer ATCE denied?
No. A review result is used only after the deterministic checks allow the act. It can turn an allow into a denial and can never turn a denial into an allow. Consensus enforces that limit, not the review service.
Who decides after the review holds an act?
A person. The review does not apply a stop and does not halt the chain. A hold is released only by a human decision recorded outside the review service, and a hold never expires into approval.
What happens if the agentic review is unavailable?
The ruling denies the act with reason code 9, review missing. The design adds no bypass, because no answer is not an approval.
Is the agentic review running in production?
Yes. As of 2026-11-02 the agentic review and the reviewer bridge are live on jil-mainnet-2, alongside ATCE enforcement and the attester. The record writer that files the review into the stored record is built and not deployed.