You may have arrived here from the Mode A page. Mode A is the one integration path built, verified and offered today, and it asks you for a single value: a hash. Everything below goes further than that — first two adjunct tiers that tell us a little more while still sending no content, then three modes that do send content — and none of it is a product you can buy yet.

Read this to understand where the platform is going, and what adopting a deeper mode would cost your engineering team — not as a menu to choose from this quarter. All three modes have their core mechanisms built and verified end to end against a real running chain. All three are reference implementations your own team adapts, not packaged, install-and-go products. No customer has been onboarded through any of them.

_____________________

The one difference that matters before any detail

At Mode A we receive a digest and never the thing digested. That is not a limitation of Mode A; it is the property Mode A exists to provide, and it is why there is no custody question to negotiate — there is nothing in our custody to argue about.

At B, C and D, content crosses. Row data in Mode B, the request body in Mode C, an explicit payload in Mode D. Whatever else differs between them, that single fact changes the conversation: you would be asking us to hold something, rather than to hold a fingerprint of something. Every requirement below follows from it, and so does every question your risk function will raise.

So the honest order of questions is this. Does “this record existed, unaltered, at this time, under this verified tenant” satisfy your audit requirement? If it does, Mode A is not a stripped-down option — it is the right one, and it is the only one with no custody exposure at all.

_____________________

Two adjunct tiers that do not cross that line

Between Mode A and the three modes below sit two optional tiers that disclose slightly more than a digest and still disclose no content at all. They are adjuncts to Mode A, not deeper modes: your own commit path still does the sending, no component of ours enters your estate, and the custody position above is unchanged. What varies is only how much the Mode A call tells us.

Tier	What you add to the Mode A call	What it buys you
Adjunct: Lifecycle	Three booleans: whether the transaction executed, whether it committed, and whether it aborted.	Cross-checks that cannot run at Mode A at all — a committed transaction with no corresponding execution result, and a failed transaction that nevertheless carries a success signal. The abort flag unblocks opcode-logic and compensation checking in addition, once we carry it.
Adjunct: Lifecycle + Magnitudes	The three booleans, plus amounts as int64 mantissas with int32 exponents.	The above, plus totals-consistency checking across a block: that committed and aborted totals agree when counted from two independent stores.

Status: design only. Neither adjunct tier has a mechanism built, and neither is a product you can buy. The fields exist in our schema — the abort flag was restored to it on 2026-10-04 — but nothing on the integration path populates the booleans or the amounts today, and the abort flag is not yet carried into the trace record our cross-checks read. The checks above are what these tiers would unlock, not what they deliver now. No customer has been onboarded through either.

Three things worth knowing before costing either one. Your tenant identity is not among the values you send — it never was, at any mode: it is stamped from your verified credential, and a call carrying a zero tenant boundary is refused outright. The hash is the same hash as Mode A, computed over your own record under the published canonical form, and not our own internal transaction hash. And the abort flag’s missing half is ours rather than yours — it has been present on the message you submit all along, so sending it asks nothing new of your systems.

Disclosing amounts is a separate question from how those amounts are then protected. The privacy ladder’s Rung 2 encrypts them under a platform key while preserving the constancy cross-check, so a Magnitudes customer would ordinarily want Rung 2 applied to them. Disclosure and protection stay independent axes, deliberately.

What the adjunct tiers do NOT buy: the voice of the person the record is about. The cross-checks above are structural — they test what you tell us about a transaction’s lifecycle against itself, and against totals counted from independent stores. They cannot detect a record that is internally coherent and false: a job never done, recorded as done at every step, with amounts that reconcile perfectly. No amount of additional lifecycle detail changes that, because the inconsistency is not there to find.

Closing that loop means letting the person a record is actually about — the tenant, client, patient or customer — confirm or dispute it under their own identity, separately from whoever submitted it. That requires us to RECEIVE the record, which is Modes B, C and D. At Mode A and its adjuncts we never do, by construction. So the honest division is: process-shaped inconsistency is detectable here; content-shaped falsehood is not, and the only mechanism that narrows it lives on the content-receiving side.

_____________________

Whose province a process belongs to

A process belongs wholly to one province — yours or ours. It is never half-run by each. Where a crossing is genuinely needed it happens at one named point and nowhere else, and everything on either side of that point has a single owner.

This governs every requirement further down, because each of the three deeper modes is a small bridge with exactly two connections: one into your systems, one to us. You deploy and operate that bridge, inside your own estate. It reads what you have decided it may read and makes one call outward. We never reach back the other way — not into your database, not into your backend, not into your outbox.

	Mode A	Mode B	Mode C	Mode D
Who operates the moving part	You call us. There is no component of ours in your estate, and none of yours in ours.	YOU run the observer, in your estate.	YOU run the gateway, in your estate.	YOU run the relay, in your estate.
Which province owns the process	Split cleanly at the call: everything before it is yours, everything after is ours.	Yours, entirely, up to the call.	Yours, entirely, up to the call.	Yours, entirely, up to the call.
The one place a crossing happens	The call carrying your digest.	The call. Your database is never reached from our side.	The call. Your backend is never reached from our side.	The call. Your outbox is never reached from our side.
What this rules out, explicitly	Nothing to rule out.	ITOTCCA holding a replication slot on your database. If our observer stalled, your disk would grow — a fault in our province spending your resource.	ITOTCCA operating a component inline in your request path, able to stop your traffic during our own outage.	ITOTCCA polling your database directly.

The last row is the one worth reading twice. Mode B is why this is stated rather than assumed: a replication slot holds WAL on your server until the reader acknowledges it. Were we to operate that reader, a stall on our side would consume disk on yours. You operating it keeps the consequence where the control is.

_____________________

The five values you send, and where each comes from

All four modes reach us through one call, and that call carries five values. That is the entire surface. Mode B, Mode C and Mode D each build the same five-value request and differ only in where they get the values from — which is why there is no field-mapping programme at any mode, and why the metadata record is assembled by us in every case.

The call carries	Mode A	Mode B	Mode C	Mode D
the action’s name	fixed — hash attestation	the table→action mapping you author	the action named on the matched route	the outbox row’s own column
a business-process reference	not sent — Mode A dispatches directly	not sent	the matched route’s entry, if set	the outbox row’s column, if set
the payload	YOUR CONTENT HASH — a digest, and nothing digested. No rung of the ladder applies, because there is nothing to seal and no key exists.	the changed row, as JSON — CONTENT. This is the one value the ladder protects: held at rest under our key, or sealed under yours.	the request body verbatim — CONTENT. Same ladder position as Mode B.	the outbox row’s payload — CONTENT. Same ladder position as Mode B.
a request type	not set	the write operation: INSERT / UPDATE / DELETE	the route’s declared type, resolved when the gateway starts	the outbox row’s column — the only mode carrying REVERSAL, CORRECTION and RESTATEMENT
an idempotency key	yours to choose, or we mint one	derived from the change’s own position in your log, not authored	your Idempotency-Key header, if sent	the outbox row’s own id
Which of these does the ladder cover?	None, and none is needed: only a digest crosses.	The payload, and only the payload. The other four are labels and references you choose — an action name, a process reference, a request type. The idempotency key never becomes part of the record at all: it is consumed into the derived transaction id and is not retained, which matters at Mode B where you would otherwise be sending us your table name and a primary key.

Read the payload row twice. It is the only row here that changes what is in our custody, and the only row any rung of the ladder applies to.

That last row is worth stating rather than leaving to be inferred. A ladder that protects content says nothing about the values travelling beside it, and a reader who assumes otherwise would be assuming protection we have not claimed. Four of the five values cross as you wrote them; the fifth, the idempotency key, is hashed into the transaction id and kept nowhere.

_____________________

Mode B — change-data-capture observer

What it does. We read your database’s logical replication stream and turn committed row changes into the same underlay records Mode A builds from a hash. Your application is not modified at all: no SDK, no call to add, no screen change.

What we would ask of your systems — all of it database-side:

Requirement	Why, and what it costs you
wal_level = logical	Logical decoding is how the stream exists at all. A PostgreSQL server setting, and on most estates a restart to apply.
A named publication	It defines exactly which tables we may observe. You choose its contents, and nothing outside it is visible to us — this is your primary control, not ours.
A named replication slot	It holds our read position, so a restart resumes rather than re-reads or skips. It also means your server RETAINS WAL for us: if our observer stops, your disk grows. That is a real operational coupling and you should size for it.
REPLICA IDENTITY FULL, on some tables	Only where the recorded payload must contain the whole row. Without it PostgreSQL sends the primary key and changed columns only. Set it per table, deliberately, and only where the audit value justifies the extra WAL.

What Mode B cannot do, and this is structural rather than unfinished. It is forensic by construction. Your own write has already committed by the time the stream carries it, so nothing can be refused, rejected or held. If you need something stopped before it happens, Mode B is the wrong mode and no amount of configuration changes that.

_____________________

Mode C — gateway-mediated

What it does. A gateway sits inline, in front of your backend. Requests pass through it, attribution is derived from the verified caller identity rather than from anything the payload claims, and the record is written before the request continues.

What we would ask of your systems — chiefly a routing change and a route table:

Requirement	Why, and what it costs you
Route traffic through the gateway	It must be in the path to act on it. A network and deployment change, and it puts a component of ours ON YOUR CRITICAL PATH. That is the significant consequence of this mode and should be weighed as you would weigh any other inline dependency.
A route table	Per route: HTTP method, a path prefix, and the atom it maps to. Optionally a business-process id and a request type. You author it, and it is how you decide what is recorded and what simply passes through untouched.
Request types resolved at startup	Named types in that table are resolved when the gateway loads, so a typo fails at startup rather than on the first matching request. Misconfiguration is loud and early by design.

What Mode C uniquely can do. It is the only one of the three that is preventative: it can refuse a request before your backend ever sees it, and it fails closed. That capability is also the source of its weight — a component in the request path is a component that can stop traffic.

_____________________

Mode D — SDK / dual-write relay

What it does. Your application writes a record of its intent into an outbox table, inside the same database transaction as the business write. A relay reads that outbox and forwards it. Because both writes commit or neither does, the record cannot disagree with the business fact it describes.

What we would ask of your systems: an outbox table, and an application change to write to it. The worked example ships as a schema you may apply verbatim, and its shape is a starting point rather than a mandate — your own table in your own schema can serve instead, provided it offers the same operations.

Column	Purpose
atom_name	Which business action this record describes
business_process_id	Which process instance it belongs to, where applicable
payload_json	The content. This is the field that makes Mode D a content-receiving mode.
req_type	Semantic intent, including REVERSAL, CORRECTION and RESTATEMENT
status, tx_id, attempts, last_error	Relay bookkeeping. PENDING until forwarded, then the resulting transaction id; attempts and the last error make a stuck row visible rather than silent.
created_at, sent_at	When your system recorded it, and when it was relayed

Two qualifications we would rather state than have found. It is called dual-write but it is not literally atomic — it is the outbox pattern, so your write and the relay’s forwarding are separate steps with a durable record in between. And the shipped relay assumes one relay instance per outbox; running several against one table would need row-level claiming the worked example does not include.

What Mode D uniquely gives. Explicit semantic intent. No other mode can distinguish a reversal from a correction from a restatement, because no other mode is told: Mode B sees a row change and Mode C sees a request, and neither carries the meaning your application already knows. Retry safety comes from an idempotency key, so a repeated submission is recognised rather than duplicated.

_____________________

Two things a deeper mode does NOT buy you

Read this before choosing a mode on the strength of content delivery.

Independent content re-verification is not unlocked by any of them. It is natural to assume that once we receive content we can independently confirm it is correct. We cannot, and nor can anyone else. Checking a claim requires a second, independent claim about the same event — which is what a bilateral settlement predicate between two counterparties provides. For a single submitter there is no independent fact to check against. That is closed by design rather than open by omission, and no deeper mode fixes it. Any vendor telling you otherwise for a single submitter is selling something that cannot exist.

Encryption of received content is designed and built, and not yet armed anywhere. The data-visibility ladder — platform-key, customer-key and partner-key encryption of content — exists in code, and its schema exists in the database. No record has been sealed in any running deployment. That is consistent rather than alarming: nothing is arriving to be sealed, because no customer is onboarded through a content-receiving mode. But it is the first thing to settle before one is, and you should hear it here rather than discover it in a security review.

_____________________

Keys, and the data-visibility ladder

The custody question raised above deserves its answer on the same page rather than in a separate document. Once content crosses, what protects it? That is the ladder. But the row that matters most is the first one, not the encryption rows.

A ladder invites you to read Mode A as its bottom rung. Mode A is not on the ladder at all: it involves no key anywhere — not ours, not yours. A digest needs none. Every rung below is a key-management obligation, and Mode A is the only option that never creates one.

	Mode A	Modes B, C and D
Keys — who holds what	NOBODY HOLDS A KEY, because there is no key. Nothing to escrow, rotate, split, recover or lose, and no key-custody clause to negotiate.	A key exists, and from the customer-key rung onward it is YOURS to manage. Only the at-rest rung uses a platform-held key.
If content crosses, what can we read?	Nothing — and not because of a key. There is no plaintext in our custody to read, now or later.	As sent, at the at-rest rung: that protects the stored bytes against theft of the storage, not against us, because we hold that key.
Sealed under YOUR key	Nothing to seal.	AES-256-GCM, your key, never sent to us. We commit the hash of the CIPHERTEXT, which still proves this exact content existed unaltered at this time. Permanently opaque to us unless you choose to share the key.
Sharing with a named partner	Nothing to share.	An anonymous envelope: a holder finds their own slot, so the recipient list is not itself readable. A list of recipients in the clear is a sharing graph, and would disclose who a record was shared with even while the content stayed sealed. Revocable — “permanent” was deliberately withdrawn as a choice, because nobody can meaningfully consent to irreversibility at the moment of sharing.
Is encryption optional?	There is nothing to encrypt, so the question does not arise.	NO. A content-receiving mode with no encryption switched on is a risk-laden system, so encryption is part of the mode rather than a setting you select. The association or regulator that holds the auditors requires it at every such mode, for the same reason.

The consequence, stated in the open. Read that last row together with the status note below. B, C and D are not merely available-but-unproven today: onboarding anyone through a mode that receives content, while the protection built for it is switched on nowhere, would be selling a risk-laden system with no protection actually in force. So arming it comes first. That is a sequencing fact about us rather than a condition on you, and it is a further reason Mode A is what we recommend today.

_____________________

Which shared levels each mode can use — and what the ladder costs you

The network has three shared levels above the member’s own estate. Which of them a transaction can actually use is decided by the MODE, because they need different things from you, and the answer is not the same for all three.

Shared level	What it has to do	What that needs	Usable at
Level 1 — the registry	Who is a member, in which federation, with what standing	An identity, established at REGISTRATION and not per transaction	Every mode, Mode A included. Mode A already carries a verified tenant identity; that is what the registry is for. It is a prerequisite, not something a transaction consumes.
Level 2 — gov-reg and gov-comm	What may cross, under which regime, and the record that it did	The parties, and the nature of the transaction	Mode B or deeper. A hash cannot be regime-checked. At Mode A there is nothing for Level 2 to evaluate, by construction and not by omission.
Level 0 — cross-border	The same question across jurisdictions	As Level 2	Mode B or deeper — and designed rather than built.

So Mode A is not shut out of the network; it is shut out of REGULATION. Attestation and membership are one thing, and deciding what may cross is another. A Mode A member is a member, provable and in good standing, whose transactions no shared tier evaluates — because none of them has been shown anything to evaluate.

Now the part that cuts the other way, and that nothing else on this site says. Level 2 must READ a transaction to apply a regime to it. The ladder exists to stop that reading. The two are therefore in direct tension, and the tension lands exactly where a bank would choose secrecy:

Rung	Who can read the payload	What Level 2 can still do
Rungs 1 and 2 — plaintext, or the platform’s own key	The platform can	Everything. Regime evaluated, crossing recorded.
Rungs 3 and 4 — your key, or a named partner’s	The platform cannot	It can record THAT something crossed. It cannot evaluate WHAT crossed. The regime function degrades to bookkeeping.

This is the same trade the audit tier already faces — Rung 1 gives full cross-checking, Rung 3 gives genuine secrecy and costs you the cross-checking — and it extends to Level 2 without anyone having said so before now.

What would resolve it, and why that is not an answer yet. Keyed commitments: a key-holder proves a value matches what was committed without revealing the value, so Level 2 could verify a claim about a transaction — that it falls in a permitted category, say — without seeing the transaction. Verification would stop falling as privacy rises. The commitment layer is implemented across the relevant tiers and is switched on in none of them. No commitments have been written in any running deployment.

The constraint, stated plainly, because discovering it late is expensive. Today you can have the upper rungs of the ladder, or you can have Level 2 doing its job. Not both. The mechanism that would give you both is built and armed nowhere. If secrecy from us is the requirement, Rung 2 or 3 at Mode B/C/D would be the position and Level 2 becomes a recorder rather than a regulator — which may be exactly what you want, but it should be a choice you made rather than one you inherited.

_____________________

Choosing between them

If you need…	Then
Proof a record existed, unaltered, at a given time, under a verified tenant	Mode A. Built, and the only mode we offer for onboarding. One hash. No content crosses, so no custody question arises.
A record of what your database actually did, with no application change	Mode B. Forensic only — it can never refuse anything.
Something refused before it reaches your backend	Mode C. The only preventative option, and the only one putting a component of ours in your request path.
Reversal, correction and restatement told apart	Mode D. The only mode your application can tell what it meant.

If the first row satisfies your requirement, stop there. The deeper modes are a real and deliberate direction for the platform, and they are described here at the level of detail your engineers would need to evaluate them — but Mode A is what is finished, and recommending otherwise today would not be honest.

_____________________

---

Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.