A claim needs a definition of done

The run completes. The agent reports success, the funds move, and the task closes.

Two weeks later, the supplier says the wrong thing arrived, or the customer says the work they paid for was not the work they asked for.

Everyone goes back to the same run. The logs are complete, but the argument goes nowhere because the record shows that the agent decided it was finished and nobody had written down what finished meant.

Acceptance was never determined by the party doing the work #

In finance operations, nobody has ever been allowed to declare their own work complete. A purchase order states what was ordered. A delivery note states what arrived, signed by whoever received it rather than whoever sent it. The goods receipt is entered by a different team, and all three have to agree before an invoice is paid.

None of it looks like a control on its own. Together, it says one thing: a supplier can send an invoice, but it cannot approve one. That is segregation of duties applied to the work rather than to the payment. Most companies stopped noticing it was there.

What the agent collapses #

Your agent does the work and reports the result. Those used to be two roles, and they are now one process.

The agent is not being dishonest. It is answering the question it was given, and that question is exactly what is in dispute. The task was ambiguous. The agent decided what it meant, did the work, and reported that the work was done. Nobody else was there for any of it.

There is a second gap underneath it. An agent can tell you a payment was sent. It cannot tell you the payment was owed. The first is a fact about its own behaviour. The second is a fact about the world, and it is the one the other party is asking about.

A human reviewer used to close that gap. Removing them was the point of the deployment.

Where a missing definition shows up #

An undefined success condition costs nothing while everything works. Then it appears in three places at once.

• The dispute. The counterparty says the obligation was not met. You say it was. Neither of you agreed to a test beforehand, so the loss stays wherever it landed.
• The incident review. People argue about whether the agent exceeded its mandate or performed a loose mandate correctly. Those are different failures with different fixes, and there is no stated condition to tell them apart.
• The payout. You wrote failure terms. Capital is committed to the task. And nobody can say whether the failure occurred.

The last one undoes everything else. Committed capital does not settle an argument about what was promised. It funds one.

What a usable success condition looks like #

A success condition is not a description of the work. It is the fact that decides whether the obligation was met.

• A fact, not a judgement. An invoice matched to a purchase order and a receipt is a fact. “Supplier paid correctly” is a judgement, and a judgement is exactly what you are trying to avoid needing.
• Checkable by someone who was not there. If confirming it requires your own system to be believed, you have written a claim rather than a condition.
• Half-finished states, described in advance. Most runs do not fail cleanly. Half the batch went out. The order was placed at the wrong price and delivered anyway. Nearly every real dispute lives in the middle, and the middle is what people leave undefined.
• A named decider for what remains. Something will still be ambiguous. Choosing who resolves it before the run is a control. Choosing afterwards is a negotiation about who has the stronger position.

It also has to sit on the task rather than on the agent. What counts as done for a supplier payment is not what counts as done for a payroll run.

The same logic as capital #

We have written before that capital found after a failure is a negotiation, while capital committed before the run is a control. A success condition works the same way. The party that failed is never the right party to define failure, and neither is the party that lost money. Both will define it honestly. They will still define it differently because, by then, each is looking at the same run from the wrong end of a loss.

So both have to be fixed at the same time. Capital committed in advance is what makes a remedy real. A condition fixed in advance is what makes it payable.

What your customer is actually buying #

Your customer is not buying a record or capital on its own. They are buying one sentence: if this goes wrong in this specific way, this is what I receive, and I do not have to persuade you of it.

The weight of that sentence sits in the middle, in the part that names the specific way things went wrong. Without that, the capital sits behind an obligation nobody agreed to define, and what you handed your customer is not a claim. It is a better-documented argument.

Where Reineira sits #

Reineira is an accountability layer for financial agents. It sits before the run, at the point where a task is defined and backed.

You set the mandate, controls, and success conditions for each run. You choose the backing: your own capital committed to the task, or capacity from a risk partner under separate terms when ready. You define the failure terms and the payout path.

Reineira is software. It does not provide or arrange insurance, recommend capital, custody funds, or act as counterparty to an operator’s clients. Production capital and risk transfer come under separate terms from the operator or an appropriately authorised partner.

Reineira is in private beta and runs in a sandbox.

The short version #

Finance never let the party doing the work decide that the work was done. The purchase order, delivery note, and sign-off exist to keep those two roles apart.

An agent puts those two roles back together. It decides what the task meant, then tells you it completed the task. You can commit capital to a run like that and still settle nothing. A payout needs a failure, and a failure needs a definition of done that was fixed before anyone had a reason to argue about it.

Before an agent runs a task, someone should be able to finish this sentence: if this goes wrong, here is the fact that shows it, and here is what my customer receives. If the only party that can finish that sentence is the agent, your customer does not have a claim.