Inontime Protocol
A governed event, hashing and propagation standard for multi-organisation project delivery.
Governed Events
Structured events for progress, change, baselines and funding, with clear metadata and governance rules.
Hashing
Events are serialised into canonical JSON and hashed (SHA‑256) so any change is detectable across organisations.
Propagation
Events move between organisations in propagation envelopes. Each side verifies the hash and replays the event locally.
Baselines & Audit
Baseline lineage links snapshots via integrity values and audit chains link all events processed by each organisation.
THE INONTIME PROTOCOL
What the protocol actually is:
The Inontime Protocol is a governed event and baseline protocol for multi-organisation delivery. It defines the rules for turning real-world delivery events (progress updates, changes, instructions) into stable, verifiable objects; how those objects move between organisations; and how they update a shared view of scope, schedule, estimate and risk without forcing everyone onto the same tool.
Instead of each party maintaining its own private truth in separate systems, the protocol gives everyone a consistent way to express “who agreed what, when, and how it changed the work” and to replay that history when they need to.
What the protocol standardises:
Governed delivery events.
A common envelope for progress updates, early warnings, changes and instructions: who raised it, who received it, what part of the work it touches, and the intended impact on scope, time, cost and risk.
Stable representation and integrity.
A predictable machine-readable structure (for example JSON) and integrity checks (for example hashing) so the same event always serialises the same way. Any tampering or re-editing becomes detectable.
Propagation between organisations.
Rules for packaging events into propagation messages, sending them between organisational workspaces, and replaying them independently – without shared logins, databases or vendor lock-in.
Baselines as verifiable snapshots.
A baseline is treated as a governed snapshot of the SSER model at a point in time. The protocol defines how new baseline versions are derived from events, how lineage is recorded (V1 → V2 → V3…), and how those versions can be reconstructed and compared.
Node identities and the delivery graph.
A consistent way to identify organisations, contracts, packages, scope items, activities, risks, valuations and evidence. Events carry references to these nodes, so each party can replay the same changes onto the same underlying graph, even in different systems.
Assurance and funding signals.
Conventions for deriving valuation / funding outputs from the governed history: what was delivered, what was agreed, what changed, and when with the option to anchor key states externally where stronger assurance is required.
What this enables in practice
By fixing these rules at the protocol level, Inontime turns delivery governance from a patchwork of licenced systems, spreadsheets, emails and siloed tools into a repeatable, verifiable process that can span any number of organisations. Different platforms can implement the protocol, but they all speak the same language for events, baselines and identities.
The current InOnTime platform ships with a thin Slice One implementation: governed delivery events are created, hashed, propagated and independently verified between two organisations, and an NEC-style change management engine runs on top of that protocol.
Subsequent slices extend this core into full baseline history, richer node types (projects, contracts, risks, funding flows) and funding-assurance outputs, all anchored in the same delivery-identity graph.

CONTACT
To collaborate, discuss, pilot the protocol, or find out more please contact us below.
