03Method
Written while the work happens, not after it.
The three stages are the same on every engagement. Each closes at the moment its work can still be honest: the map before the build, the reasoning at the point the call is made, and the handover tested before the engagement ends.
Why the order is fixed
The map comes before the build, every time
Entry looks like delay. It is the stage that stops the other two costing twice as much. A build that starts before the disagreement is mapped encodes one reading of a contested term into a system, and the argument that was going to happen anyway now happens against working software with a change budget attached.
Where a client is certain the definitions are settled, entry is the stage that proves it, and it is short. It has never yet found nothing.
The three stages
What happens in each
None of the three carries a fixed length. How long a stage runs follows the circumstance, and a number published here would be either a guess or a floor nobody intends to hold to. You get a real estimate after entry, when there is something to estimate against.
01Entry
Read the systems that disagree, and talk to the people who own them. The disagreement is rarely where anybody expects, because each system is internally consistent and each owner is correct within it. The output is a written map of where the definitions already differ, and a brief naming what the work will deliberately leave alone.
ProducesA written map of where your definitions already disagree, and a brief naming what the work will leave alone.
Naming what is out of scope is what stops an engagement growing quietly. It is the shortest part of the brief and the part that gets read twice.
Hands overThe brief, before any build starts.
02Delivery
Build the thing, and write the record of what changed and why as it happens. Written at the point the call is made, beside the work, rather than assembled at the end from memory and a chat log. A reconstructed record reads like a reconstruction, and it is trusted accordingly.
ProducesThe system, and the record of what changed and why, written as it happens.
The record is handed over during the stage rather than at the end of it, so nothing about the reasoning is a surprise at handover.
Hands overThe decision record as it grows.
03Handover
Package the three artefacts, then run the test that ends the engagement: your engineers answer a real question about the system using only the record, with nobody from Koinon in the room. A question they cannot answer is a gap in the record, and closing it is part of the stage rather than a variation to it.
ProducesThe three artefacts, written up as a package your team owns.
Koinon is not built to stay. An engagement that ends with a dependency has failed its last stage, whatever it shipped.
Hands overYour engineers answering a question using only the record, with nobody from Koinon in the room.
The three artefacts
- 01Definition register
- 02Lineage map
- 03Decision record
The three artefacts
What every engagement leaves behind
These three do not change with the discipline. A pipeline, a dashboard, a service, and an agent each produce the same set, because each one encodes a definition and each one will outlive the person who built it.
The three fragments below follow one term through all three artefacts. Illustrative of the pattern, not a record of one organisation.
- 01
Definition register
Names what a contested term means, who owns it, and the date the wording was agreed. One place a disagreement gets settled, rather than five reinterpretations downstream. Contested terms only: a register of every term is a register nobody maintains, and an unmaintained register is worse than none, because people trust it.
The testTwo people reading the entry reach the same number.
Specimen 01, one register entry - Term
- Revenue, quarterly
- Owner
- Group financial controller
- Agreed
- 12 March 2026
- Wording
- Revenue recognised in the quarter on the accounting standard, net of credit notes raised after close. Not invoiced value, and not closed-won.
- 02
Lineage map
Shows which systems use that definition, and every hop a number takes to reach a report. Traceable to source, not to two transformations back. The map covers the terms in the register rather than every column in the warehouse, which is what keeps it accurate enough to rely on.
The testA figure in a report can be traced to the system that first recorded it.
Specimen 02, four hops of that figure BillingInvoiced value, before credit notes
Finance ledgerRecognised value, on the accounting standard
Group consolidationRecognised value, after intercompany elimination
Board packThe consolidated figure, sourced from the ledger
The register entry governs hop two. Every hop after it inherits that wording.
- 03
Decision record
Shows when a definition changed and why, written at the point the call was made rather than reconstructed from a chat log six months later. It records the reasoning and the alternatives, because the next team needs to know what was considered and rejected, not only what was chosen.
The testA new engineer can tell whether a behaviour is deliberate.
Specimen 03, one decision record entry Entry 0712 March 2026
- Changed
- Quarterly revenue moved from invoiced value to recognised value.
- Why
- Billing and the ledger disagreed by the credit notes raised after close, and the board pack took whichever figure arrived first.
- Rejected
- Invoiced value, which matched the CRM and overstated the quarter by the credit notes.
- Supersedes
- Everything marked closed-won in the period
03Commission the work
A system that can answer for itself.
A 30-minute diagnostic, not a sales call. Bring the disagreement and the deadline that made it matter.
Book a 30-minute diagnostic, opens cal.com in a new tabSheet 04, other ways to reach us