Sheaf Models Unify Local Data Into Global Scope

Problem: Fragmented WBS views create hidden contradictions

Different work-package managers carry “local truths” that cannot be simultaneously true when you stitch them into one programme-wide scope narrative. Contradictions hide in interfaces: dates, assumptions, inventory baselines, MEWP access, utility availability, temporary works ownership, and what counts as “done”.

• Symptom: risk register grows faster than scope certainty.
• Director red flag: the word “interface” appears often but has no measurable constraints attached.
• Why it costs: incoherence forces scope rework or dispute resolution after commitment, when changes are most expensive.

Method: Model scope as a sheaf over the project graph

A sheaf encodes local data on nodes and enforces “agreement” on overlap edges. The project graph is the map of overlaps: packages sharing assets, locations, milestones, or authority.

• Nodes: WBS packages (Civils, Systems, Utilities, Traffic Management, etc.)
• Edges: overlaps/interfaces (shared corridor, shared crane, shared safety boundary)
• Stalks (sheaf-speak): the structured data each node carries (scope items, dates, quantities, constraints, ownership).

Mechanism: Enforce consistency across overlapping work packages

Each overlap edge restricts both sides to a common “view” (boundary conditions). If two packages disagree on any overlap attribute, the sheaf consistency check flags it as incoherent.

Result: Detect incoherence before cost commitment

Directors get an earlier, more objective signal than “gut feel” or “someone thought of it.” Incoherence becomes visible as a graph: you can rank which overlaps generate most contradictions and commission targeted integration work.

• Outputs: incoherence list, heatmap by interface, and “who owns resolution”.
• Near-miss capture: turns “we’ll sort it out later” into a quantified scope risk.

Next step: Prototype on live PMO data

Start small with a single corridor or station section; the goal is not perfection but a proof that the method finds contradictions that humans miss. If it finds nothing, great—if it finds something, you’ve bought programme resilience cheaply.

Project graph: the constraint map

The graph is your interface register made precise: edges are the “gluing conditions” (shared constraints). Many issues on large UK programmes are basically graph topology problems: too many edges per node without a single owner.

• Good topology: limited overlap degree, explicit ownership.
• Bad topology: one node overlapped by many, vague constraints (“as required”), no reconciliation mechanism.

Sheaf intuition: gluing local stories into one coherent narrative

Think of each package as an “essay” about the project and overlaps as the footnotes they must share. If two essays share footnotes that disagree, they can’t be combined into a single publication.

A sheaf is the rulebook that says: the global story exists if and only if all shared footnotes match.

Benefits vs. traditional WBS

WBS is great for accountability but poor at constraints because interfaces live in unstructured documents. Sheaf modelling upgrades interfaces to first-class, checkable objects.

• Less reliance on hero integration managers and more on machine-checkable consistency.
• Supports assurance: repeatable checks, audit trails, “why this was flagged”.

Governance: minimum policies you need

Directors don’t need to become category theorists; you need policy about what constitutes an overlap and who provides/approves the boundary data.

• Rule 1: Every overlap has a declared owner (even if it’s shared).
• Rule 2: Overlap data is structured (not paragraphs in a PDF).
• Rule 3: Each gate includes an incoherence check: “Can we glue these packages?”

Prototype plan: week-by-week

Engagement: how to sell it to a project director

Frame it as assurance + decision quality: a way to stop surprises, not an academic exercise. The language to use is “interface discipline” and “early detection”, not “category theory”.

FAQ (director-ready)