Coherence Change Orchestrator

One place to run every kind of change.

Model change and run it.

Every initiative runs through both, in order.

The transformation mapModel the change

What runs today, what you are going to, and every finding the difference between them raises.

A verdict on the map charters an initiative
The initiative acceleratorRun the programme

What a decision on the map becomes: a charter, a blueprint, the mappings, and the work packages that land it.

The initiative types.

Every type models an as-is and a to-be, and the delta between them is what becomes work.

Regulation change

A new or amended rule lands. The to-be is the landscape that satisfies it; the gaps are the controls that do not exist yet.

Compliance audit

The obligations read against what actually enforces them. The gaps are the rules with nothing behind them.

System sunset

Retire something. The to-be is the landscape without it; the gaps are what it was carrying that nobody has picked up.

Migration

Replace one system with another. This is the type that ends in a cutover.

New product or service

The to-be is the business that can sell and service it; the gaps are the capabilities and systems it still needs.

New development or feature

A change inside what you already run, scoped against everything it touches before it is committed.

The transformation map.

Where the change gets modelled, before any of it becomes a programme. A projection holds a bounded set of findings, in the dozens.

See what is wrongThe findings that matter, ordered from the business outcome at the top down to the evidence underneath, each one naming the role accountable for it.
Computed for the readerThe same model projects differently per question, per role and per intent. An auditor and a CTO get different maps because different checks run for each. It is not the same list re-sorted.
A standing checkYou do not have to ask. Findings are raised into a feed as they are found, graded, each with its next action attached: investigate, simulate, accept or defer.
Trace to sourceDrill from any finding to the paragraph, the schema line or the function in the code that proves it. Where the evidence runs out, the map says so.
Test the changeRun the consequences through the model to see what it would touch, and branch a named what-if that collects them as you go. The live record is untouched, and the result names the roles whose targets the change would move.
Model the to-beDraw the state you are going to on the same model: what the landscape looks like after the regulation lands, after the system is retired, after the product ships. The as-is and the to-be sit side by side, and the delta between them is computed.
Record the verdictThe verdict comes from a fixed menu of seven: fix the model, build it, link what already exists, retain, decommission, remediate, or rule it out of scope. Out of scope stops it resurfacing, and build opens a work package.
The transformation map answering one question: 54 findings across seven sectors, a feed of graded findings each carrying its next action, and the evidence panel alongside
the transformation map · one question, 54 findings, each with its next actionclick to enlarge ⤢

The initiative accelerator.

A verdict on the map charters an initiative, and the initiative produces four things in order. Each one is derived from the model, so none of them starts from a blank page.

CharterWhat was decided, frozen and signed. The initiative stays bound to the version of the transformation map it came from, so what the change was for cannot be quietly re-argued later.
BlueprintWhat has to be built or changed to get from the as-is to the to-be. Derived from the two states on the map.
MappingsWhat on one side answers to what on the other, each one graded: one-to-one, lossy, needs reconciliation, net new, or orphaned.
Work packagesEvery gap gets one decision, from build, migrate, retain, decommission or remediate, and a gap with its decision made becomes a work package: scoped, owned, tracked.

A work package goes to whoever does the work: one of your team, or an agent with write access to the system it touches: your ERP, your codebase. Neither authorises itself. The gate sits upstream of the work, and it is held by two named people on your side.

The governance controls.

What runs from the first sentence to the deployment.

One sentence starts itAn initiative begins as a sentence in plain language. The platform reads it, pulls the relevant findings from the map, and drafts the charter. Your experts accept it, correct it or reject it.
The preview is the gateBefore you ask to advance a phase, the platform lists exactly what the gate will check. Preview and gate run the same computation, so nothing new appears at the gate.
Quorum on every phaseA phase is exited by named approvers and a minimum count, and the person asking is never counted among the signatures. Moving a programme backwards requires a stricter quorum than moving it forwards.
Nothing writes on the first pressA governed action first shows what it would touch. It commits on a second, deliberate press.
A receipt for every decisionWhat was done, who did it, who authorised it, the evidence it rested on, and the pointer that undoes it. Sealed records are tamper-evident: alter one and the seal breaks.
Risk is accepted by peopleA machine can never accept a risk, at any severity, through any path. Only a named person on your side can.
Dependencies are acknowledgedInitiatives declare dependencies on each other, and both sides must acknowledge. A phase cannot advance past an unfinished dependency.

The SAP IBP implementation.

One initiative, chartered on the map and executed in waves through the two gates.

Down to the columnThe mappings behind a cutover go to column level: which source column becomes which target column, and the transformation that converts it. A confirmed map is sealed. Change the map or its reconciliation afterwards and the seal breaks.
The cutoverAn ordered plan: freeze the data, migrate, smoke-test, go live, post-check. A destructive step is refused unless it carries a rollback procedure, and the risk checks are re-run at the moment of go-live.
01 · CharterThe implementation, chartered on the transformation map

SAP IBP replaces demand planning run on spreadsheets, macros and scheduled jobs. Every step knows what it touches before anything moves.

promo calendar · Exceldemand model macroweekly sales history jobtouches 7 integrations · 3 reports · 1 controlcharter frozen, and signed
Gate one · the domain is published. A named person signs.
02 · Execute in wavesEvery step, with its computed impact

Integrations re-pointed and the demand model rebuilt with every figure anchored. The undocumented +14% planning uplift is surfaced as a named line with an owner.

wave 1 · interfaces: touches 7, breaks 2, owners namedwave 2 · demand model: every figure anchoredevery gap gets one decision: migrate · build · retain · decommission · remediate+14% override: undocumented, now on the record
Gate two · into reality. Two signatures, and the AI never signs.
03 · Parallel runOld against new, on live weeks

The signed forecast is produced by both systems and reconciled. Every delta is explained, with the receipt attached. Nothing irreversible happens without a signature.

deltas explained · receipts attachedevery match proven, and re-checked when it is read
Cutover · gated, and auditable while it runs.
The proofOne signed number, traced to its three sources.

Old against new, checked figure by figure. Signed and time-stamped, then re-checked against live data. If the systems drift afterwards, the proof flags as no longer valid.

signed · countersigned · on the register, receipt attached
Gate one · publishing the domain

A domain goes live when its named owner publishes it, and it cannot go live while the work is unfinished.

Gate two · into reality

Nothing changes a live system without a second signature. An AI can never sign its own work.

When a work package deploys, the model updates in the same step. There is no separate documentation task, and the model cannot drift behind the work.

The other three products.

All four read and write the same model. See the whole platform.

Coherence Ontology Studio

You scope the domains. The platform reads your material and proposes what it found, and what your experts confirm is the model.

Coherence Explorer

Ask it, and the answer names its sources. Test a change and see what it touches before you commit.

Coherence Compute Engine

The compute under the other three. Nobody opens it directly, and it is what makes the same material give the same answer every time.

See a worked example.

Three are open to explore, or start your own first domain with five documents.

This site uses cookies

We use essential cookies for the site to function and analytics cookies (Google Analytics) to understand how you use it. Analytics cookies are only activated with your consent. We do not track you across other websites. Your data is stored in the EU and processed in accordance with GDPR. Read our Privacy Policy