Back to app index

Category Theory Toolkit for Construction Systems Engineering

Start with Poset, Set, and Rel to model precedence, data, and traceability; then add Cat to treat whole artefacts as composable “systems”. The big wins in projects come from functors that translate between semantics (requirements ⇄ design ⇄ cost ⇄ schedule ⇄ as-built), and from sheaf-style “local-to-global” consistency checks across disciplines and site zones.

Tip: pick a use case → see recommended categories & functors

Use-case lens

Highlights relevant nodes () and functors.
Active selection (node/edge)
Recommended for selected use case

Map (use case → categories → functors)

Semantic translation map

Click a node to see PM and technical explainers. Use “Show only recommended” to declutter.

Pick a use case or click a node

—

A useful “engineering” stance: treat every artefact as a morphism between states (e.g., “Design v3” → “Issued for Construction”), then make translations between artefacts explicit as functors; what breaks under composition is usually where scope, interface, or accountability breaks.

Categories to start from (ranked)

These are the “most likely to pay rent” categories in construction systems engineering; click to focus, or use PM explainer.

Functor patterns (translation between semantics)

Most project pain is not inside a model; it’s in the translation between models. These functor “shapes” are practical: you can name them, assign owners, and test them.

Forgetful functor (drop structure)

BIM → attribute tables → reporting

PM: “Extract what we can measure/report, without dragging the whole geometric model around.”

Watch: If you forget too much, you can’t reconstruct accountability (classic reporting drift).

Valuation functor (assign costs/risks)

Design/options → £, time, carbon, risk

PM: Make your pricing/risk model a named map with explicit inputs; then change-control is just “did the functor’s inputs change?”

Academic aside: Many estimators implicitly enrich categories over a cost monoid; naming that clarifies “what adds” vs “what multiplies”.

Adjunction (abstraction ⇄ refinement)

Scope/WBS ⇄ detailed design packages

PM: “Roll-up” and “drill-down” are rarely inverses; adjunction formalizes the best-possible approximation in each direction.

Use: Detects where summaries are misleading (no left adjoint) or detail cannot be consistently aggregated (no right adjoint).

Natural transformation (change request)

Two interpretations of the same spec

PM: A CR is a controlled “switch” from one pipeline to another (e.g., pricing old spec vs new spec), component by component.

Practical: If you can’t write the components, you can’t cost the change coherently.

A contrarian but useful lens

Instead of “one master model”, aim for a category of models with explicit functors between them; the goal is not a single truth but coherent composition across contractual and disciplinary boundaries (a construction-flavoured version of “many-sorted semantics”).

Tangent to explore later: “How sheaf gluing conditions resemble Last Planner / constraint removal on site.”