Slice Three – Baselines & Stage Framework on the Protocol

Having proven cross-organisation change control on the InOnTime protocol, the next slice turns baselines and stage gates into governed, hash-verifiable objects as well.

In conventional projects, “the baseline” is scattered across schedules, estimates and registers, with different versions living in different systems and email threads. Slice Three replaces that with explicit Baseline Snapshots: structured, write-once records of scope, time, cost and risk at a point in time, each with a canonical payload and a SHA-256 hash. Every approved change event from the Slice Two engine is attached to a specific baseline version, and when a new baseline is agreed the system records a baseline transition (e.g. Award → Post-CE-07), linking the old and new snapshots by hash.

On top of this, Slice Three introduces a Delivery Stage Framework (Feasibility, Concept, Scheme, Detailed, Delivery, etc.). Each baseline and key change decision is anchored to a stage gate under that framework, so you can always answer: “What did we think the project looked like at this gate, and which governed events have moved us from that view to today?”

Technically, it is the same protocol as before: baselines and stage-gate decisions are just additional governed event types, with canonical JSON, hashes and optional cross-organisation propagation. Practically, it gives owners, funders and delivery teams a traceable baseline history: every shift in programme, cost or risk is tied back to a verifiable chain of early warnings, compensation events, PMIs and agreed baseline changes. This is the foundation for later slices that compute funding-assurance outputs and long-term delivery-identity signals from protocol-native data.