§ 1
In brief
Rules as records
Decide what happens next
drafted with AI, accepted by people
In
Orders, payers, the company’s systems
The record
Every fact of every payment
only appended, never rewritten
Read from the record
Views for people and agents
- orders
- invoices
- payments
- settlements
- ledger
Outside
Banks and providers
a request goes out once; the answer comes back as a fact
In
Orders, payers, the company’s systems
Rules as records
Decide what happens next
drafted with AI, accepted by people
The record
Every fact of every payment
only appended, never rewritten
Outside
Banks and providers
a request goes out once; the answer comes back as a fact
Read from the record
Views for people and agents
- orders
- invoices
- payments
- settlements
- ledger
- One record, only appended
- Orders, payers, banks and rules add facts; nothing is changed or deleted. A correction is a new fact.
- Rules as data
- Each rule is a short record that answers one question. Rules have versions; AI drafts them and people accept them.
- One boundary to the outside
- Each request to a bank goes out once. The answer comes back as a fact; a duplicate is recorded and changes nothing.
- Views are readings
- Orders, invoices, payments, settlements and the ledger are computed from the record and can be rebuilt at any time.
§ 2
In detail
2.1
One record, only appended
A payment is not a procedure. It is a set of facts that arrive from different parties at different times — the order, the invoice, the payer’s instrument, the customer’s confirmation, a screening, a route, the bank’s answer, the money — and points at which enough is known to go on. The engine’s only memory is a record of such facts, one for each attempt, that is only ever appended to.
The record grows in steps: first the facts that arrived, then every decision they allow, then the requests those decisions make, then the answers that come back. A fact that comes in a later step sees everything an earlier step produced, which is why the charge waits for the customer’s confirmation.
2.2
Rules as records
What a payment does is a set of rules the engine reads. One kind of rule watches for a moment — has enough become known? — and another acts on it: records a fact, or asks a bank once. Every rule states its question in plain words, and the set is loaded only when every reference resolves. The company’s policies are the same kind of data, set on its structure and inherited down it.
2.3
One boundary to the outside
The engine never calls a bank from inside a decision. A rule writes an intention; a connector carries it to an acquiring bank, a 3-D Secure server or a person who reviews, and the answer comes back as a fact linked to the request. A late answer — a webhook, a settlement file — is the same kind of fact.
Each request goes out once. Late facts, such as an invoice after the charge or a duplicate webhook, are recorded and change nothing.
#1Order receivedshop
#2Card attachedpayer
a token and its brand; no card number
#3Ready to chargerule
an order and a card, no payment yet
#4Charge requested, oncerule
#5Answer: capturedbank
#6A duplicate request arrives lateshop
#7Recorded; no second chargerule
An example. Every entry stays in the record; the late duplicate changes nothing.
2.4
Views are readings
Nothing a person sees is stored as such. The views of orders, invoices, attempts, payments, settlement batches and the ledger are computed from the facts; a table in a cabinet is a reading of the views with the columns of a role; an export carries the source of every row. All of them can be rebuilt at any moment and come out the same, because the record is the same.
2.5
How a change comes in
First come the agreed scenarios: what must never happen, and what must work. AI writes a variant, a new set of rules beside the old one; it is checked against the scenarios, against the same facts in other orders, and against past payments; then a person accepts it. The accepted logic is not touched again.
In use
The accepted logic
runs unchanged; it is never edited in place
New variant
A bank, a rule or an instrument
written with AI
Check
Agreed scenarios
and past payments
Decision
Accepted by a person
Result
Runs beside the accepted logic
2.6
What this gives
- Audited — every step carries what caused it, and the record can be replayed.
- Analysed — any question about any payment is a reading of the same record — a strategy tried on past payments, a fee checked line by line, one period compared with another — without a second system.
- Extended — a new rule, bank or instrument is a variant beside what works, checked before it is used.
§ 3
The core module
At the core is NestVM by CoAgnes: the engine that keeps the record and runs the rules. It is an external module, included under separate agreements, and it is not part of these repositories.
Around it River builds what a payments platform needs: the vocabulary of facts and the five records of a payment; the structure with its policies and access; agreements and acquiring terms; screening, instruments and the division of money; the ledger, routing, the pay page, integration and the agents; and the views of every cabinet.
The demo stand of this site runs the same structure on the platform’s own runtime in memory: a record of facts for each attempt, views read from it, and agents that only read.