Local to Global
Essay 01 · reviewed working prototype
Essay 01 · Formal Inspiration Applied

Scope coherence
from local claims to a global view

Four teams can each have a plausible scope register and still disagree about the same work. Explore the fictional Pennine Viaduct Renewal Programme: inspect the interface rules, resolve a drainage dispute, and see what still prevents a coherent global view.

Interactive teaching example · fictional UK infrastructure programme. Choices change this page only and reset on reload; no project record, approval or file is created. Start with the problem, inspect a rule in the checker, then compare the resolved examples.

THE HIDDEN CONTRADICTION

The Pennine Viaduct Renewal Programme has four major work packages. Each package maintains its own scope register. Explore each package — then run the conflict detector to see what lurks in the overlaps.

4
Work Packages
?
Conflicting interfaces
?
Interfaces needing clarification
WHAT IS A SHEAF MODEL?

Sheaf theory offers rigorous language for asking whether local data can compose into a consistent global picture. This page implements a finite comparison on declared interfaces; it does not prove that a complete project sheaf has been constructed.

The Project Graph

Use a graph of work packages and shared interfaces: physical space, deliverables or resources. The comparison maps run from each package to its interface; the line between two packages does not imply one controls the other.

G = (V, E)
V = {WP1, WP2, WP3, WP4}
E = {(WP1,WP2), (WP1,WP3), (WP2,WP4), ...}

This toy makes interfaces first-class so that contradictions can be located rather than left dispersed across package records.

Local Sections

Each work package carries local data: its own view of scope items, quantities, cost, and responsibility. This is the "local section" over that node.

xWP2 ∈ F(WP2)
xWP2 = {drainage_installer: "WP2",
  containment_width_mm: 150}

Here, “local sections” are the package facts declared for the overlapping zone. Their independent truth is not established by the checker.

The Sheaf Consistency Condition — click nodes to explore
A four-package interface graph. The detailed checker below provides the same status information in text.
👆
Click any node or edge on the diagram above to explore the sheaf structure. Nodes represent work packages; edges represent interfaces where consistency must hold.

The Restriction Map

For each edge (interface), a restriction map projects each work package's local data down to the shared interface zone.

ρWP1→WP1∩WP2 : F(WP1) → F(WP1∩WP2)
ρWP2→WP1∩WP2 : F(WP2) → F(WP1∩WP2)

The comparison rule requires the projected values to be equal or compatible within a declared tolerance. If not → a located incoherence.

Gluing: Building Global Scope

Collect the four local accounts into one tuple. This finite model calls that tuple a compatible candidate only when all six selected interface rules pass. A missing value keeps the result undecided.

x = (xWP1, xWP2, xWP3, xWP4)
test ρv→e(xv) ~e ρw→e(xw) for every e = {v,w}

If gluing fails, these selected accounts cannot form one coherent view until the mismatch is investigated. Other unmodelled project facts remain outside the result.

A restriction map in ordinary language

Keep the whole package register locally. For the drainage overlap, extract just the field installation owner. WP1 says WP1; WP2 says WP2. Those values fail the same-owner rule. The £420k and £380k estimates explain why the dispute matters, but unequal estimates alone do not establish duplicate scope.

The containment rule asks a different question: is the provided width at least the required width? The symbol ~e means the declared rule for that interface. Inequalities and missing-data states here are an applied compatibility model; they are not a proof of the existence or uniqueness axioms of a sheaf.

The cover is a choice. These four packages and six overlaps leave out other suppliers, time periods and constraints. Green means this declared slice agrees. It cannot establish completeness, engineering adequacy or whole-project approval.

SHEAF CONSISTENCY CHECKER

Select a work package, then an interface to inspect the two projected values and their comparison rule. Green = passes the selected rule. Amber = information missing. Red = fails the selected rule.

Work Packages
Programme Stats
Total Interfaces6
Coherent0
Incoherent0
Ambiguous0
Select a work package →

Choose a work package from the list to inspect its interfaces and consistency status.

RESOLVING INCOHERENCE

Walk through an illustrative drainage decision. Advancing the example changes the declared owner in this browser and rechecks the interfaces. Resolving one dispute does not resolve every overlap.

Original accounts. No simulated ownership decision has been applied.

Starting conflict: Deck Drainage Ownership
WP1 (Civils): drainage installation = £420k "in scope"
≠ INCOHERENT
WP2 (M&E): drainage installation = £380k "in scope"
💷
Both fictional packages claim the same installation work. The example estimates are £420k and £380k; the checker does not calculate a loss or saving. Package leads must agree the boundary, responsible party and any commercial adjustment.
Resolution Protocol
Step 01 · Detected
Two installation owners found
Automated checker identifies restriction map mismatch on WP1 ∩ WP2 interface.
Step 02 · In Progress
Interface Meeting Called
Illustrative response: package leads compare their scope definitions with the design authority. No actual meeting or approval is recorded by this demo.
Step 03 · Pending
Agree WP1 as installation owner
Both toy accounts now name WP1 for deck installation. WP2 retains outfall connections; real scope and commercial changes would need their normal authority.
Step 04 · Pending
Recheck all six interfaces
After a drainage-only agreement, containment still fails and two interfaces still need information. The overall slice remains unresolved.
Illustrative comparison to test empirically
DOCUMENT REVIEW ALONE
DetectionDepends on reviewer and timing
Cost evidenceNot measured in this prototype
Schedule evidenceNot measured in this prototype
TraceabilityOften narrative and dispersed
WITH DECLARED OVERLAP RULES
DetectionRepeatable on selected fields
Cost evidenceRequires a retrospective test
Schedule evidenceRequires a retrospective test
TraceabilityMismatch tied to interface and field
PMO VALUE HYPOTHESIS

Explicit overlap rules could add a repeatable compatibility check to PMO review. Whether that improves detection, cost or schedule outcomes is an empirical question, not a result of this prototype.

Not measured
Conflict cost avoided
requires evidence
Rule-set
Detection is limited to
declared overlaps
Case-dependent
Timing benefit
requires validation
Candidate validation sequence
Phase 01 · Toy
Concept & Toy Example
Demonstrate selected compatibility rules on the fictional Pennine Viaduct scenario. No leadership acceptance or field trial is implied.
Phase 02 · Retrospective
Test on a closed data slice
Model a bounded WBS and interface register, then compare checker findings with known historical issues.
Phase 03 · Shadow use
Run beside existing assurance
Compare false positives, missed conflicts and reviewer effort without changing a formal gate.
Phase 04 · Decision
Keep, revise or stop
Only expand the method if the bounded tests show useful signal and acceptable modelling cost.

Why infrastructure is a plausible test

Infrastructure programmes often distribute scope across packages, contracts, models and authorities. That makes their interfaces a plausible place to test explicit compatibility rules—but neither contract form nor gate process guarantees that the chosen cover is useful.

The Digital PMO Angle

Federated models and interface registers may supply structured local facts. A useful checker would still need carefully governed mappings, units, tolerances and authority—not merely an automated graph conversion.

How a PMO could use the result
  1. Define one review slice. Agree which packages, revision dates and shared interfaces are in scope. Record important omissions.
  2. Agree the data contract. Name each field, its units, source revision and responsible owner. Declare equality, capacity or tolerance rules before judging the result.
  3. Review at an existing cadence. Run comparisons before the interface meeting and after an approved package change. Missing information goes back to its owner; contradictions go to the relevant package leads.
  4. Resolve through existing authority. A checker locates disagreement. Design and commercial authorities decide whether to change a package, clarify a mapping or revise a rule.
  5. Recheck and retain the evidence. In a pilot, keep the before/after values, rule version, decision owner and residual issues with the normal interface register. This teaching page creates none of those project records.
  6. Evaluate the extra work. Compare missed issues, false alarms and reviewer effort against the existing process before expanding its use. A passing slice adds evidence to a gate; it does not approve the gate.
🎯
Potential validation test: use a closed programme slice with a known interface history. Compare the declared-rule checker with the historical record, including misses and false positives, before considering live use.