What you leave with

What we measure

Before the work starts we agree the two or three numbers that matter for this transaction. These might be: the days between paying out and being paid, the hours a week spent chasing and reconciling, how often something goes wrong and what it costs when it does, how much of a credit line sits tied up, and how many more of these you could handle without hiring. By the end of stage one you have a view on whether there is a case worth taking further.

Stage 1. Map the transaction

Transaction map

Shows the real end-to-end sequence: parties, systems, documents, physical events, decisions and hand-offs. It becomes a common reference for operations, finance, legal and technology.

Participant-view matrix

Shows what each party sees, needs, controls and cannot see. This exposes where teams are waiting on incomplete information or making decisions from assumptions.

Who acts, and on whose say-so

Identifies who can instruct, approve, release, block, override or merely observe each material action. This is often the most immediately useful risk and governance output.

Evidence and dependency register

Lists the facts that matter, the evidence that supports them, who issues it, who relies on it, how long it remains valid, and which external systems or documents feed the process.

Bad-day playbook

Maps at least the normal path and two credible failure paths: late evidence, conflicting instruction, quantity mismatch, failed payment, expired mandate, lost custody control, dispute. This is where hidden weaknesses become visible.

Value and issue register

A ranked list of delays, duplicated work, trapped cash, loss exposure, capacity constraints and avoidable technology spend, with an initial hypothesis of what each is costing or preventing.

Stage 2. Define authority and control

State, action and control specification

Defines permitted states, actions, preconditions, deadlines, finality and the rules that must never be broken. This is the spine for any workflow, integration or smart contract.

Authority and evidence policy

The approval, delegation, evidence, reliance, disclosure and exception rules in a form that operations, risk and legal can review.

Exception, dispute and enforcement design

What happens when the normal path fails: who decides, what is frozen, which notice is required, how reconciliation works, and how a case reaches resolution.

Where the model and the operation diverge

The points at which the model does not yet describe how the transaction is actually run: a role it assumes that nobody holds, a field no system can produce, a step that rests on one person being available, a term you could not ask a counterparty for. Each set out with what the model would have to account for, so the distance between the two is explicit now rather than discovered during an implementation.

Business case and success measures

For each change you are considering: the intended benefit, the assumptions behind it, where it starts from, who would own it, and which of the agreed numbers would move if it worked.

What each change would need

The changes you named, sorted by what they depend on: those you could make with the systems you already have, those needing a process or policy decision, and those that would need technology investment or a prototype. Sorting rather than ranking; the order is yours to set.

What each implementation route would require

Four routes side by side: no new technology, improving the existing workflow, integrating systems, or building a controlled prototype. For each, what it would take, what it would not solve, what it depends on, and what would make the case for it fail. The choice is yours.

Stage 3. Prove the control design

Multi-party working transaction

The agreed normal transaction run across separate participant views: instruction, evidence, approval, state change, release, payment or settlement marker. It turns a paper design into something your team can challenge.

Role-specific sandbox

Operations, finance, risk, legal and technology can enter the transaction from their own position. This reveals whether the design works for the people who must use it, rather than only for its authors.

Critical-scenario suite

The normal path plus the few failures that matter: stale evidence, conflicting instruction, delayed payment, expired mandate, quantity mismatch, loss event, default or disputed claim. This proves what becomes blocked, who is notified and who can resolve it.

Control-evidence log

A readable record of every material act: who acted, under which authority, which evidence was used, what state changed and which control was checked. It lets risk, audit and legal assess the design without reading code.

Reconciliation and finality demonstration

Shows whether the record can be reconstructed from events, how it relates to source systems, and the difference between requested, acknowledged, legally effective and physically irreversible actions.

Architecture fit assessment

Explains why that particular environment was chosen for this transaction: privacy, participant control, event history, finality, interoperability, cost and operational ownership. It is not a generic blockchain comparison.

Production-readiness gap register

A precise list of what remains before a live implementation: legal agreements, integration work, identity and access model, data ownership, evidence controls, security review, governance, operating procedures and support.

Build-or-stop analysis

What proceeding, redesigning selected controls, running a limited pilot or stopping would each require, set against what the prototype proved. It states the evidence, the dependencies, the case for and against each, and the next sensible spend. The investment decision is yours.

What a prototype gets built to answer

In a custody, financing or physical-goods transaction, the questions worth testing might include these.

• Can a warehouse release be blocked while a lender's control interest is active?
• Can a bank rely on a specific inspection record without seeing commercially irrelevant terms?
• Can an expired authority prevent a valid-looking instruction from being acted upon?
• Can a quantity be prevented from being allocated twice?
• Can every party reconstruct the sequence relevant to them without gaining access to everyone else's records?
• Can a dispute or exception freeze the right thing, while the rest of the operation continues?

These are business questions, not technical ones. A ledger is a test instrument before it is a system. “The right person approves.” “The certificate must be current.” “The goods cannot be released while finance is outstanding.”

A ledger will not run on an approximation. Every rule of that kind has to become exact, or nothing happens. Stage three does not deploy the model. It puts the model somewhere that cannot quietly fill a gap with interpretation, and sees what breaks.

A ledger is not a requirement. Enforceable control is.

The prototype is not production software and does not replace your legal agreements, systems or operating controls. It is a decision tool: a working proof of what can be enforced, and what still depends on people or on external evidence.

Back to advisa.tech