Payouts need 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: the record shows the agent decided it was finished, and nobody had written down what finished meant.

Acceptance was never determined by the party doing the work #

Nobody in finance 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 the payment, and 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; they are now one process.

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

A second gap sits underneath. An agent can tell you a payment was sent, not that it 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 asks about. A human reviewer used to close that gap, and removing them was the point.

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 one correctly. Different failures, different fixes, and 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 judgement is what you are trying to avoid needing.
• Checkable by someone who was not there. If confirming it requires believing your own system, you have written an assertion, not a condition.
• Half-finished states, described in advance. Most runs do not fail cleanly. Half the batch went out, or 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 sits on the task, not 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. Neither the party that failed nor the party that lost money can define failure: both will define it honestly, and still differently, each looking at the same run from the wrong end of a loss.

So both have to be fixed at once. Capital committed in advance makes a remedy real. A condition fixed in advance 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 sits in the middle, in the part that names the specific way things went wrong. Without it, the capital stands behind an obligation nobody agreed to define, and what you handed your customer is no remedy. 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 funded.

You set the mandate, controls, and success conditions for each run. You choose the funding: your own capital committed to the task, or a funding provider’s under separate terms, once formed. 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. A remedy is the operator’s own promise to its client, funded by the operator or a funding provider under separate terms.

Reineira is in preview and runs in a sandbox.

The short version #

Finance never let the party doing the work decide it was done. The purchase order, delivery note and sign-off keep those roles apart. An agent puts them back together: it decides what the task meant, then tells you it finished.

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 fixed before anyone had 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 who can finish it is the agent, your customer has no remedy.