Two questions, and what each one decides
What has to be true
Two questions decide whether this work is possible and whether it is finished. What has to exist before a transaction can be written down at all, and what has to be settled before any of it could be enforced by a shared record.
They are not the same question, and the distance between them is most of the work.
What has to exist before a transaction can be written down.
A transaction does not have to be orderly to be modelled. The valuable ones usually are not, and a process nobody has documented is the normal starting point rather than an obstacle.
What it does need is enough substance to answer five questions. If all five hold, the transaction can be written down whatever state it is in today.
The five, and what each one means
| What has to exist | Which means |
|---|---|
| A consequential subject | Identifiable goods, a shipment, a warehouse position, a payment, a right, an account, a claim or a case. Something a party can point at and mean the same thing by. |
| More than one party who can affect it | Someone instructs, another verifies, another holds custody, another finances, insures, accepts or regulates. |
| Actions that change a position | Release, delivery, inspection, acceptance, payment, substitution, allocation, claim or cancellation. |
| Conditions the actions depend on | Authority, evidence, quantity, quality, time, location, a hold, a payment condition or a previous event. If every action is negotiated fresh, you have a negotiation rather than a transaction, and there is nothing to write down. |
| A process that can be observed | Not perfectly documented. Reconstructible, through people, documents, systems, physical hand-offs and the exceptions everybody remembers. |
Nothing on that list asks the client to arrive with rules already written. The work is to find where the rules are absent, in conflict, or carried silently by experienced people.
A transaction can be written down long before it could be enforced.
These are two different states and most transactions are in the first. Reaching the second is not a technical step. It is a set of agreements between organisations that do not currently have them.
The two states, side by side
| A transaction is mappable when | It is ledger-ready when |
|---|---|
| You can reconstruct what happens, and why | The parties can agree what counts as a valid state change |
| You can identify the subjects, roles, evidence and hand-offs | Each material action can be attributed to an authorised party |
| You can expose the gaps and the ambiguity | The necessary evidence can be issued, versioned, shared and relied upon |
| You can state the controls you want | Those controls can be checked before the action is accepted |
| You can describe the exceptions | There is an agreed response when physical reality, evidence and instructions conflict |
This is why the model comes first. A ledger cannot resolve an unclear transaction. It can only make an unclear process run faster, and permanently.
Every transaction is made of the same classes. Where the weight falls is what makes yours different.
Every organisation describes its own process in its own words, which is why no two descriptions can be held against each other, and why the same question gets asked six times and answered six ways. We work from a fixed list of classes, so that a coffee trade and a copper trade can be compared at all, and so that nothing gets left out because nobody thought to ask.
A class is one kind of thing a transaction has to settle.
Six of them, in plain words
| Class | What it settles |
|---|---|
| Subject | The thing itself. Which parcel, which batch, which cargo, identified so two parties cannot mean different things by it. |
| Interest | Who has a claim on it, and whose claim comes first. |
| Fact | What is asserted to be true, by whom, and from when. |
| Obligation | What someone owes, to whom, and by when. |
| Invariant | What must never be true, whatever else happens. |
| Disclosure | Who may see what, and who may not. |
Which classes matter most, by trade
| What you trade | Which classes matter most | The question it turns on |
|---|---|---|
| Softs and agri | Fact, Invariant | Whether the figure that governs is the one everyone is acting on |
| Metals under finance | Subject, Interest | Whether anyone else has a claim on the same goods |
| Energy in transit | Obligation, Fact | Whether “released” means the same thing to the carrier, the terminal and the bank |
| Chemicals in distribution | Disclosure, Obligation | Which declared fact binds, and who it binds downstream |
Two parties to the same transaction fill in the same list differently. Where they differ is what we are looking for.
When your control must be trusted by someone else.
Your internal controls do not stop mattering when a transaction crosses into custody, finance, insurance, regulation or a new counterparty. They become the basis on which another organisation decides whether to release goods, advance funds, insure risk, accept a declaration or continue the relationship.
Advisa maps the point where internal operating control becomes externally relied-upon evidence: what the other party needs to know, which facts they can rely on, who is authorised to provide them, and what must happen when they change.
Four moments when somebody outside has to decide whether to rely on it
| When it gets asked | What the external party needs to rely on | What the transaction model establishes |
|---|---|---|
| Before a facility is renewed, extended or increased | Whether financed goods are identified, eligible, not subject to an undisclosed competing claim, and released only through the agreed control process. | The relationship between custody, stock position, lender control, release authority, evidence currency and enforcement state. |
| Before a due-diligence statement or regulated declaration is signed | Which facts are established by suppliers, inspectors, warehouses or other parties; what evidence supports them; and how later correction or supersession is handled. | A source-to-declaration evidence chain, accountable roles, effective dates, dependency record and exception path. |
| Before a new warehouse, custodian or counterparty joins | What authority, evidence, access, control risk and operational dependency the new participant introduces. | A before-and-after control map: what changes, which permissions are new, which evidence is now relied upon, and what controls need adjustment. |
| After a release, claim, discrepancy or control failure | Whether the same weakness exists elsewhere, who could have acted, what they knew at the time, and what control should now prevent recurrence. | A replayable event, authority and evidence view that supports root-cause analysis and a targeted remediation plan. |
Control ends at the boundary. Accountability does not.