The execution layer for separations and integrations
MeridianCogent models how a carve-out actually works — what a business depends on, what has to be untangled, in what order, and what it costs when that slips. Currently in development.
Most tools track tasks. This one tracks consequence.
A separation is not a list of work. It is a chain of dependencies where each link determines the next, and where the cost of a missed link compounds rather than accumulates.
A shared system has to be untangled before a transitional service can end. That service has to end before the business is genuinely standalone. Whether it will end on time is knowable months ahead of the date — but only if the dependency between the two is modelled rather than assumed.
MeridianCogent models that chain explicitly:
Systems register
What the business runs on, and what it shares with the parent.
Decommission sequencing
What has to be separated, untangled or stood up, and in what order.
TSA exit dependencies
Which transitional services cannot end until that work completes.
Exit risk
Where the modelled completion date falls after the contractual exit date.
Day 1 readiness
What is actually blocking Day 1, derived from the chain rather than typed into a status field.
Five stages, each depending on the one before: Systems register, Decommission sequencing, TSA exit dependencies, Exit risk, .
Systems register
What the business runs on, and what it shares with the parent.
Decommission sequencing
What has to be separated, untangled or stood up, and in what order.
TSA exit dependencies
Which transitional services cannot end until that work completes.
Exit risk
Where the modelled completion date falls after the contractual exit date.
Day 1 readiness
What is actually blocking Day 1, derived from the chain rather than typed into a status field.
Every stage reads from the one before it. Nothing in this chain is a status someone updates by hand.
Gates that actually block
Most platforms have gates that record disapproval. A gate is marked red, and the work continues anyway, because nothing in the system can stop it.
Here, a gate is a real constraint on the schedule. Work downstream of an unsatisfied gate cannot be scheduled as though the gate will clear. Conditions precedent block closing rather than annotating it. The critical path reflects what is genuinely possible, not what the plan assumed in January.
This is the difference between a system that reports on a programme and a system that governs one.
Every number has a named human behind it
The platform does not source legal requirements, costs, valuations or jurisdictional rules. Every material figure is entered by a customer or their advisor, and formally adopted by a named person before it can affect a plan.
When it is adopted, the platform takes a snapshot of exactly what was adopted and when. If the underlying figure later changes, the adoption is marked stale rather than silently updating — the original decision remains visible, along with who made it and on what basis.
Corrections are made by superseding a record, never by overwriting one. The history of what was believed, and when, survives intact.
This constraint is deliberate and it is not negotiable. A platform that asserts what a jurisdiction requires has taken on a liability it cannot discharge and a claim it cannot stand behind.
Transitional services, modelled as exposure
A TSA is not a document to be stored. It is a live cost with an end date that may or may not hold.
The platform holds the service catalogue across multiple currencies, models exposure and overrun including step-up pricing, and — critically — connects each service to the separation work that has to finish before it can end. Where the modelled completion of that work falls after the contractual exit date, that is surfaced as exit risk, months before it becomes an invoice.
The point is not to record what the TSA costs. It is to know, in March, that the September exit will not happen.
What happens if this slips?
It is one thing to know a transitional service exits in September. It is another to know what a two-week delay on a single cutover does to that date — and to the invoice that follows it.
MeridianCogent is being built to answer that directly: take the current schedule, move one date, and see which transitional services can no longer end when they were meant to, and what that costs.
The question a CFO actually asks is not what the plan says. It is what the plan costs when it does not hold.
Numbers that mean what they say
A synergy ledger that lets one row mean an annual run rate and the next mean a cumulative figure, then adds them together, produces an authoritative total that is simply wrong.
Every amount in the platform states what it represents before it can be stored. Quantities on different bases are never summed. Independently reported figures are shown side by side rather than netted into a single number that implies a precision nobody has.
Built for deals that are not public
Access is scoped to the programme, not the organisation — being an employee of the customer does not grant visibility of a deal. Advisors and vendors hold time-bounded, logged access to only what they need.
Programmes can run under code names. Exports are watermarked to the person who generated them. Unusual access patterns are detected and surfaced rather than sitting in a log nobody reads.
These are not enterprise add-ons sold separately. They are how the platform works by default, because a separation involves people who should not see each other's information and a deal that is not announced yet.
What else the platform covers
Alongside the execution chain, MeridianCogent is being built to hold the artifacts every transaction actually runs on:
- Obligations and conditions precedent — what must be done, and what gates closing
- The consent register — change-of-control consents and where they stand
- Contract novation — the full population of contracts to be re-papered, assigned or novated
- The perimeter register — what transfers, what is retained, and what remains disputed
- Risk register — assessed on two dimensions, never reduced to a score
- Integration budget and cost-to-complete — what the capture is costing
- Stranded costs — the overhead that does not leave when the business does
- Delay scenarios — what a slipped date does to exit timing and cost
- Cutover runbook and hypercare — the hours around Day 1, and the weeks after
- The communications plan — what gets said, to whom, when
- Playbooks — Day 1 readiness, first hundred days, and carve-out separation, as starting structure rather than an empty list
- Bulk import — because a real carve-out arrives as a spreadsheet
Some of these are live today and some are in build. MeridianCogent is not commercially available yet.
Early access
MeridianCogent is in development. Join the list for updates as we open access.