§ 1
In brief
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
- Variants, not edits
- The accepted logic is not edited in place. A change is a new variant with its own version.
- Agreed scenarios
- Each variant must pass the scenarios agreed for it, including what must never happen.
- People accept
- AI writes the variant; a person with the right accepts it. AI never accepts its own work.
- Assemblies are data
- A retail group and a payment provider run on the same code and differ only in their data.
§ 2
In detail
2.1
Variants beside, never edits
Nothing in use is edited. A change is a new variant — a set of rules with its own version — beside the accepted one, which keeps running until the new one is accepted. A rule carried over unchanged keeps what it has proven; a changed rule is checked from the start. A variant that was rejected stays on record with the reason.
Demo scene 1
The group’s settings, entry by entry
Each setting is an entry with its value, its mode, its date and the role that set it; a change adds an entry and keeps the old one.
| Setting | Value | Mode | Date | Set by |
|---|---|---|---|---|
| How an acquirer is chosen | on-us first | may be changed below | 26 Sept 2026 | payments manager: routing and costs |
| Who holds the money | banks settle to the merchant directly | enforced | 1 Jun 2026 | hierarchy administrator |
| Payout schedule | next day (T+1) | may be changed below | 1 Jun 2026 | hierarchy administrator |
| Allowed instruments | Card, Apple Pay, Google Pay, QR transfer (NBU), Pay by bank, Bank transfer, Pay in parts, Bonus points | may be changed below | 1 Jun 2026 | hierarchy administrator |
| Maximum for one payment | ₴200,000.00 | may be changed below | 1 Jun 2026 | hierarchy administrator |
| Refunds allowed for | 14 days | may be changed below | 1 Jun 2026 | hierarchy administrator |
| Agents at work | Sentinel, Navigator, Reconciler, Collector, Analyst, Dispute clerk, Integration copilot | may be changed below | 1 Jun 2026 | hierarchy administrator |
| What agents may do alone | propose only | may be changed below | 1 Jun 2026 | hierarchy administrator |
| Approval threshold for routing | 90 % | may be changed below | 10 Jan 2025 | payments manager: routing and costs |
| Blocked countries | RU, BY, KP, IR, SY | enforced | 10 Jan 2025 | risk and fraud |
2.2
How a variant is checked
- The agreed scenarios run first, including everything that must never happen.
- A failure is traced to the first step where the result went wrong, and the fix is chosen from known kinds of change rather than guessed.
- The same facts in another order, split or repeated, must give the same charge, the same final fact and the same state.
- Past payments are replayed through the variant before it is used.
- Once, at acceptance, the variant meets cases its author never saw.
2.3
People accept
AI writes the variants. A person challenges them with corner cases and with conditions that must stop a payment, and accepts the result. AI never accepts its own work, and the accepted logic is not touched again.
2.4
Assemblies are data
What the platform is for a company — its units, roles, agreements, acquiring terms, policies and connected providers — is a stand: data the runtime loads, with the same shape for a retail group and for a payment provider. A new company is a new stand, and a new rule for one company is a new variant for its stand; nothing of the engine or of the other companies changes.
Demo scene 2
Two assemblies, one code
What each demo stand is made of. The code that runs them is the same.
| Retail group | Payment provider | |
|---|---|---|
| Units | 31 | 29 |
| Roles in use | 9 | 8 |
| Settings | 23 | 57 |
| Risk rules | 3 | 7 |
| Connected providers | 7 | 11 |
| Acquiring terms | 10 | 0 |
§ 3