∮

Sheaf Models for Scope Coherence

Interactive explainer for a UK public-sector project director

Project director mode • board language first

From fragmented WBS views to coherent scope

A sheaf model treats each work package as a local view of the project and asks whether those views agree where they overlap. The point is not mathematical ornament; it is early detection of scope incoherence before design, procurement, or cost approval hardens incompatible assumptions into spend.

Hidden contradictions across packages Interface rules made explicit Better readiness for approval gates Pilot on live PMO data
Problem

Fragmented WBS views create contradictions nobody owns

Package plans can each look sensible while the combined scope still contradicts itself at interfaces.

Method

Model scope as a sheaf over the project graph

Attach local data to packages and define what must match on the overlaps between them.

Mechanism

Enforce agreement where packages overlap

If Civils and Utilities share a corridor, the corridor facts must reconcile rather than merely coexist in separate files.

Result

Detect incoherence before cost commitment

The output is a contradiction heatmap: where the current baseline cannot all be true at once.

Next step

Prototype on one live, interface-rich PMO slice

Start narrow: one station box, corridor segment, reservoir zone, or package cluster with real interface pressure.

1 • Interactive scope-coherence simulator

See how hidden contradictions emerge in the overlaps

Select a scenario. The graph shows a stylised public-sector infrastructure slice: packages are local views; the lines are overlaps where consistency should hold. Click any package or any overlap line for detail.

coherent overlap watch / immature contradiction

Scenario detail

Choose a scenario or click a package / interface in the graph.

What the sheaf check flags

These are not vague “risks”. They are direct contradictions or unstable shared facts in the current scope slice.

2 • Translation layer

Turn the mathematics into delivery language

The audience does not need category theory. They need a disciplined way to ask whether package views can be stitched into one spendable baseline.

Sheaf = disciplined stitching of local scope views

Each team can keep its own detailed view. The model asks whether those views agree when projected onto shared interfaces.

Overlap = shared boundary where truth must match

The overlap is where two packages refer to the same corridor, asset, handover, readiness condition, or quantity.

Consistency rule = what each package must agree on

Dates, quantities, retained assets, consent conditions, and readiness prerequisites are typical early rules.

Global section = a scope picture you can commit against

If all local claims agree on the checked overlaps, you have the closest mathematical analogue of a coherent scope baseline.

Contradiction heatmap = where to intervene first

The output shows where incompatible claims sit, who owns them, and which cost gates they threaten.

Board language = scope coherence, not mathematical theatre

Lead with “hidden contradictions across interfaces” and only reveal the formalism underneath when useful.

Formal version, stripped down:

For each work package Pᵢ attach data F(Pᵢ)
  e.g. boundary, dates, quantities, design assumptions, asset states.

For each overlap Pᵢ ∩ Pⱼ define shared fields and restriction maps.
A coherent baseline is a family of local sections sᵢ such that
  rᵢⱼ(sᵢ) = rⱼᵢ(sⱼ)
on every overlap.

In plain English:
all package views tell the same story where they touch.
3 • UK public-sector lifecycle fit

Where does this help in a real infrastructure programme?

Use the tabs to retune the framing. The same logic can support option development, business-case confidence, procurement interface clarity, live delivery control, and assurance.

4 • Pilot blueprint on live PMO data

Prototype this without creating a giant digital-theory programme

The fastest credible route is one interface-rich slice with real PMO artefacts. The model needs just enough structure to reveal contradictions that existing governance is not surfacing early enough.

WBS and package list

Useful for defining nodes, owners, and decomposition — but not sufficient on its own for truth at overlaps.

Interface register

Usually the best starting point. Each interface becomes an overlap candidate with named owners and shared facts to test.

Master schedule and key dates

Dates are often the quickest contradictions to surface because different packages silently rely on different readiness assumptions.

Assumptions log and design basis

Assumptions are local truths until the model forces them onto shared interfaces.

Cost plan / estimate basis

Link costed items back to the same overlap facts so the output becomes decision-relevant rather than conceptually interesting.

Asset / GIS / BIM / drawing boundaries

Spatial or asset definitions help when the contradiction is literally a boundary or retained-asset problem.

Pick a slice with pain, not a showcase

Choose 8–12 packages around one interface-rich area where the PMO already suspects coordination friction.

Extract the local truths each team already uses

Dates, quantities, assumptions, boundaries, access rules, and readiness conditions usually exist already — just scattered.

Define 10–20 overlap rules with commercial bite

Start with same corridor release date, same retained asset owner, same quantity tolerance, same consent window, or same readiness prerequisite.

Run a contradiction review before the next commitment gate

The pilot succeeds if it changes a real decision: interface clarity, estimate assumption, stage-gate confidence, or escalation sequence.

5 • Limits and honest positioning

What to say so this does not sound like mathematical theatre

The credibility move is restraint. Present this as a scope-coherence engine that sharpens interface discipline and approval confidence, not as an all-purpose prediction machine.

It does not replace project governance

It helps governance by making contradictions explicit. Someone still needs to decide, reconcile, own, and approve the resulting changes.

It only checks the rules you encode

A poor rule set gives false comfort. Start with a few commercially material overlaps rather than trying to encode the universe badly.

It is not a digital twin by itself

The model checks coherence of declared scope facts; it does not by itself simulate physical behaviour or operational performance.

It should start narrow and prove value fast

A modest pilot on one difficult interface zone is more persuasive than a grand architecture that never touches a live decision.

UK public-sector framing: this explainer uses the language of business cases, assurance, major-project readiness, and PMO data because the aim is to make the method legible inside a real UK infrastructure decision process, not merely inside a mathematical seminar.