A pilot answers one question: does a shared ledger solve our problem with real partners and real data? It should be small, fast and honest. This is the shape we use with a group of three organizations.
Weeks 1 to 2: define one process
- Pick one process that crosses company lines, such as a hand-off, an approval or a shared count.
- Write down which records each party creates and who must be able to see them.
- Agree on what success means. For example: disputes about this process drop, or reconciliation time halves.
Weeks 3 to 4: design the network
- Each organization gets one node. With proof of authority, each node also holds a signing key, and the nodes take turns adding blocks.
- We decide what goes on the ledger: often only a fingerprint (hash) of a document, with the document itself kept private.
- We write a threat model: what happens if one partner's key is stolen, a node goes offline, or a partner leaves.
Weeks 5 to 8: build and test
- Stand up the three nodes in the cloud, one per organization or one shared account to start.
- Connect the ledger to the systems that create the records, usually through a small API.
- Write tests for every rule, including attack tests: a partner trying to rewrite a record, a forged signature, a node sending junk.
Weeks 9 to 10: run it with real data
Each partner uses the pilot alongside its normal process. We watch the numbers agreed in week one, and we record every problem. Then we write a short report: what worked, what did not, what a production network would cost to run, and whether to go ahead.
What makes pilots fail
- Too many processes at once. Start with one.
- No partner willing to run a node. Confirm this in week one.
- Putting sensitive data on the ledger. Put fingerprints on the ledger and keep the data where it is.
The same building blocks, including proof of authority and record anchoring, are public in our open-source node, PlainChain. Axieo now focuses on audits; see how we audit.