Your agents can ask. They cannot pay.

The rule is written down. Nothing can evaluate it.

Your policy sits in a manual, a circular, a set of clauses nobody has made machine-evaluable. Every rules platform on the market assumes you arrive with your rules already modelled. Most institutions do not.

An institution has a written rule. It is approved, it is in force, and it exists as prose in an operating document: a claims manual, a dispute procedure, an underwriting guideline, a circular from the regulator. Prose cannot be evaluated, cited by clause, or replayed against past cases. A decisioning platform can evaluate a rule only once someone has modelled it, and for this rule nobody has. So a person reads it and applies it. What they decided is recorded; which clause they applied, and whether the text settles the case, is not.

Every rules platform assumes that work is already done: that someone has turned the prose into conditions a machine can test. That is a property of the category, not of any one product, and for most institutions the assumption is false. The conversion is the work, and it is usually the work nobody has done. Putting agents in front of an unconverted rule does not close that gap. It hides it behind a model.

The system that decides records what was decided. The system that pays records what was paid. Neither records what was authorised in a form anyone outside your walls can check, and neither can stop the other. A decisioning tool can flag a case it dislikes; it cannot prevent the disbursement. A payments platform can execute; it has no view of the authority the payment was made under.

What is left is the question the arrangement was never designed to answer: which clause did this determination rest on, and was the payment that followed it authorised?

Convert, train and simulate, deploy

Step one is what makes step two possible. Step two is what makes step three safe to say yes to.

Sections 02 to 05 describe the product being delivered. The status section states what is built today, and where the two differ, the status section is right.

Enforcement and the record are properties of step 03. They are not steps.

Mechanical clauses are settled by the engine. Only judgment reaches an agent.

The register says which is which, clause by clause, before anything runs.

A clause is classified once, at conversion. A mechanical clause sets a test the records answer, and the engine settles it deterministically: the same facts, the same result. A router dispatches each clause by that classification, so only a clause that genuinely requires judgment reaches an agent or a person. The routing key is the clause's disposition, fixed at conversion, not a confidence score guessed at runtime.

Where a clause is ambiguous, where the text permits more than one reading, the ambiguity is registered rather than silently resolved. The readings are stated, the choice is the institution's, and a determination that rests on a chosen reading says so in its result. A result the engine decided, one an agent assessed, and one a person decided are visibly different in the record.

A determinate clause decided by a model is a model risk problem the institution did not need to take on. An ambiguous clause resolved silently is a finding waiting to happen.

A deadline, a required field, a code from a list: these have a right answer, and a model deciding them can only add error. And the first examiner to read an ambiguous clause both ways will ask which reading you applied, and since when. The register is that answer, written down before the question is asked.

The mandate, the enforcement point, and what a refusal leaves behind

Step three in detail.

Where authority is exercised on someone else's behalf

Wherever three parties exist, our controls have something to bind. Where only two do, they mostly do not.

Our controls matter where three parties exist: who granted the authority, who exercised it, and who may later have to be satisfied that it was exercised inside the grant.

• 01Card issuers and dispute platforms
• 02Post-trade operations
• 03Third-party claims administrators
• 04Benefits and warranty administrators
• 05Fund administrators
• 06Managing general agents
• 07Escrow agents
• 08Outsourced accounts payable

Anywhere authority to decide or to disburse is delegated, written down, and audited. Agents, on this page, are AI systems in the software sense, not insurance agents.

The same three parties appear on the asset side: a fund or its general partner, an administrator processing capital calls, distributions and fee payments on its behalf, and a depositary or auditor obliged to verify. Mandate is the word that world already uses.

Each of those three can verify offline, against a published key: the party that granted the authority, the party that exercised it, and the auditor or regulator who has to be satisfied, and none has to trust the other two or involve us.

The questions that decide whether this gets forwarded internally

Answered as they would be answered in diligence, including where the answer is not yet.

Who does the conversion work, and what do we have to supply?

We do, by hand, with our own harness. You supply the written policy as you operate it today, the regulation it implements if you can name it, and a person who can answer for the institution when the text leaves a reading open. Every conversion so far has been of public regulation, plus one rehearsal on a provider manual from a US state Medicaid managed care programme. There is no self-serve conversion tool, and we would rather say so.

What happens when our policy changes?

The register is versioned. A change to the rule is a new register version, never an edit to the old one, and every determination cites the version it was decided under. Re-simulating against the new version before it goes live is step two, run again. What is not built is noticing that your document changed: today you tell us, and the change is a conversion pass.

What happens to a term our own document uses but never defines?

It is recorded as ungrounded: a term the document decides outcomes with and supplies no meaning for. Nothing guesses at it. A clause that turns on it waits until the institution supplies the meaning, and a determination that rests on a supplied meaning says so in its result, not only in its provenance. A term defined elsewhere and cited is recorded differently from one with no pointer at all.

How do we know the encoded rule matches the rule as written?

By measurement, not assurance. The encoded register and the rule as written are evaluated over the same generated fact sets, and every disagreement is counted and classified by cause. That divergence report is the deliverable of step one, and it carries its own denominators. One such measurement is published: the conversion finding on Illinois Medicaid managed care.

Can we revoke an agent's authority immediately?

Yes, with two limits we would rather state than have you find. Revoking sets an entry in a published status list, and verification refuses a credential whose entry is set. It refuses just as firmly when the list cannot be fetched or decoded, which is the part most implementations get backwards. First limit: the status list's own signature is not yet checked on that path, so the guarantee is currently as strong as control of the address serving the list, and no stronger. Second limit: suspension, as distinct from revocation, is not evaluated yet. A suspended credential still verifies. Both limits are in the status section.

Can we pause all disbursement without a deploy?

Revoking the mandate is the lever, and it now does what the question above describes. What we have not done is rehearse it as a drill, end to end, from revocation through to a payment being refused, so we would want to run that with you rather than assert it here.

Can we require human approval above a threshold, and is that approval evidenced?

The threshold is a field in the mandate, and the approval is itself a signed artifact that names what it authorised. It authorises one payment, never a widened future authority. The enforcement logic is built; the approval interface a person would use is not. See the status section.

Can we restrict payments to an approved vendor panel?

Not as an allowlist, and we would rather say so than imply otherwise. The binding counterparty control today is a cumulative cap per counterparty, which limits concentration rather than membership. The allowlist-shaped field in an earlier schema version was advisory, meaning an evaluator could ignore it, and it has been withdrawn rather than left in place looking binding.

Can we require a decision record before a payment, not just check one when it is there?

Not yet, and the difference is worth being precise about. A citation that is present is verified before anything moves, on every routing decision rather than only when a human is involved, and the result is derived from the document rather than from what the requesting system claims about it. What does not exist is a way for the mandate to demand a citation is enforcement of it: delegation v2.7 carries that field, and our enforcement point does not yet honour it, so a payment citing nothing is not refused for it. A published schema is not a verifier.

What happens to a request the mandate does not authorise?

No payment is constructed. Not a warning, not a flag, not a queue for someone to review. The service holds the credential, so there is nothing for the agent to route around.

Does a denied claim produce a record?

Yes, and that is deliberate. A decision that moves no money still produces a signed record, so the denials are evidenced as well as the approvals.

Can one mandate cover multiple agents and roles?

Yes. A mandate is scoped to the authority, not to a single process, and the same authority can name a deciding agent and a paying agent as distinct subjects.

What if an agent tries to bypass the service?

This is the case we tested hardest, because it is the one that matters. The service holds the credential, so the refusal happens where the signature would be produced, which is why the bypass has nothing to bypass. The one demonstration of this on a live network, and its limits, are in the status section.

Where does our data go? Does the vendor see it?

The service runs in your infrastructure. Your claim files, your policy documents and your adjudication inputs stay there. What travels to a verifier is a credential and a record, not the data behind a decision.

What security artifacts are available, and when?

No SOC 2 report today, and we are not yet in an observation window. We are not going to put a date on it here. The enforcement path is self-hosted and holds your keys, so our internal controls are not the control there. Yours are. The one place we sit in the chain today is mandate issuance: our service signs the authority that every enforcement decision is then evaluated against. That is exactly why principal-as-issuer is specified, and why it is named on this page as unbuilt rather than left for you to discover. In the meantime a design partner gets a source-available enforcement engine they can read, permanent published schemas, and contractual commitments.

How does this sit alongside our claims platform and our payment processor?

We do not connect to any of them, and there is no connector to any of them on our roadmap. Your agents call our tool instead of calling a payment API directly, and that substitution is the entire integration surface.

Three words this page uses precisely

Each of these has a loose everyday meaning and a narrow one here. The narrow one is meant.

Mandate

The delegated authority itself, expressed as a signed credential rather than a document. It carries the limits, the thresholds and the conditions a payment is checked against.

Attestation, or decision record

A signed statement that a decision was made: what was decided, under which policy version, on which inputs, by which system. It is evidence a third party can check, not a log line.

Enforcement point

The place where a refusal actually stops a payment, rather than reporting on one. Here it is the boundary that holds the credential, because a refusal anywhere an agent can route around it is advice.

Do not take our word for any of this

The specification, the schemas and the enforcement engine are public and permanent. An engineer can check this page without talking to us.

These are usable on their own, not only as evidence. The engine is MIT licensed and installable from npm as @observer-protocol/policy-engine, and the credential model is a published schema at a permanent URL, so an implementer can adopt either without adopting us.