Why the Inontime Protocol is needed
Projects, teams and organisations need a governed truth. These are the problems we’re fixing first.
Inontime isn’t another dashboard. It’s a governed baseline and event layer that keeps scope, schedule, cost and risk in sync across organisations.
On this page we show five concrete ways that, through the use of propagation, changes on the ground turn into verifiable decisions that Owners, Contractors, Funders and the full Engineering and Construction Supply Chain can all trust.
Use Cases
Below are five concrete ways that changes on the ground turn into verifiable decisions that owners, contractors and funders can all trust.
Use Case 01 — Change Once, Align Everywhere.
Today, the same change can live in five different versions across client and contractor systems.
Inontime turns each approved change into a governed event that updates scope, schedule, cost and risk for both sides. Owner and contractor stay on the same page instead of drifting apart.
Use Case 02 — Field to Boardroom
A site engineer hits an underground obstruction and snaps a photo. In most projects, that evidence dies in WhatsApp.
Inontime turns it into a governed event, a baseline change and a funding decision the board can replay – one continuous chain from field reality to executive sign-off.
Use Case 03 — Procurement & Award
Tender packs, clarifications and award decisions are usually scattered across emails and spreadsheets.
With Inontime, they become a governed chain that creates Baseline V1 for both client and contractor, so delivery starts from a shared, verifiable understanding of scope, price and risk.
Use Case 04 — Make baselines and stage gates first-class protocol objects: write-once snapshots of scope, time, cost and risk at each delivery stage (Feasibility, Concept, Scheme, Detailed, Delivery), each with a hash and a clear link to the governed events that changed them.
“Show me the Award baseline vs today, and which approved changes moved us from one to the other.”
“At the end of Scheme Design, what did we believe the cost and programme were, and what’s changed since?”
“For this gate pack, generate a verifiable baseline history driven only by governed events.”
Use Case 05 — Turn verified governed events into funding instructions and drawdown signals, so payments can be tied directly to independently-checked delivery history.
“Only release this milestone payment when the corresponding change events and baseline updates are verified by both parties.”
“Produce an audit-ready funding trail that links each drawdown to specific, hash-verified delivery events.”
“Flag funding risk when changes are implemented on site but not yet agreed or baselined.”
Use Case 6 - Make baselines and stage gates first-class protocol objects: write-once snapshots of scope, time, cost and risk at each delivery stage (Feasibility, Concept, Scheme, Detailed, Delivery), each with a hash and a clear link to the governed events that changed them.
“Show me how this contractor has performed on change control across all their projects (disputes, late quotations, baseline churn).”
“Rank bidders by on-time implementation of agreed changes and stage-gate performance, not just by price.”
“Surface early warning signals when a BU or supplier’s governed events start to show deteriorating behaviour.”
See how this could work on your project.
These are just the initial use cases highlighted to demonstrate the potential power of the protocol.
If you would like to trial the change management engine on a live project, get in touch.