Slice 2 takes the core Inontime protocol from a simple “hash and propagate one event” demo into a working two-party change management engine.

At contract level, Slice 2 introduces an NEC-style change workflow between a client organisation and a delivery organisation. Early warnings, compensation events, notifiable compensation events (NCEs) and Project Manager’s Instructions (PMIs) are all treated as first-class governed events rather than ad-hoc emails or spreadsheet entries. Each change is represented as a ChangeCase with a clear outcome (CE / NCE / PMI) and a lifecycle (for CEs: Notified → Quoted → Decided → Implemented). For every step in that lifecycle, Inontime records the structured details of the change – including scope, cost, time and risk impacts – in a canonical JSON payload, computes a SHA-256 hash, and appends a new GovernedEvent into the originating organisation’s audit chain.

On top of this change engine, Slice 2 activates the propagation engine between the two parties. Whenever a governed event represents a formal notice or decision that must be shared – for example an early warning, an NCE notification, a CE notification, a quotation, a PM decision or a PMI – the system wraps the canonical payload and its hash into a PropagationEnvelope addressed from the source organisation to the counterparty. The receiving side does not simply “trust the message”: it independently recomputes the hash from the payload, verifies integrity, and then either accepts the event (creating a matching GovernedEvent with the same hash in its own workspace) or rejects it with a recorded reason. Accepted events therefore exist as bit-for-bit identical, hash-verified records in both organisations’ ledgers, giving a shared, tamper-evident history of how each change was raised, priced, decided and implemented.

In effect, Slice 2 turns NEC-style change control into a protocol:

• every meaningful action in the change process becomes a governed event;
• every cross-organisation notice flows through the propagation engine with explicit direction (client → delivery or delivery → client); and
• every change that affects time and cost carries structured links back to scope, estimate, schedule and risk.

This gives you a live, cross-party change register that is both operationally useful (people can actually run the contract on it) and cryptographically robust (events are canonicalised, hashed, propagated and independently verified under the same InOnTime protocol that underpins later slices for baselines, funding assurance and the delivery-identity graph