Back to app index

Galois Adjoints as a Requirement ↔ Commitment “Translator” (Rail Upgrade Example)

We model two posets: Requirements (capacity tiers) and Commitments (platform/signalling/power/approvals + budget + schedule). The left adjoint f maps a requirement to the weakest commitment package that guarantees it. The right adjoint g maps your current commitments to the strongest requirement tier you can safely claim.

1) Choose a requirement (what stakeholders ask for)

Left adjoint f(requirement)

“Weakest commitment package that still guarantees this tier.”

Closure g(f(requirement))

“If you package the minimum commitments, what tier do you effectively land on?”
Why this helps a project director
If a requirement changes by one notch, f propagates a monotone (non-decreasing) uplift into every commitment dimension. That makes scope-control legible: you can show exactly which subsystems, approvals, and budgets must move together to stay coherent. The closure highlights “step changes” (e.g., once you ask for tighter headway, signalling jumps to a new regime).

2) Choose commitments (what you’re actually funding/scheduling/procuring)

What you’re seeing (the adjunction law)

3) Director view: a single coherent “so what?”

Strongest tier you can safely claim under your commitments:
Interior f(g(commitment)) strips slack: “smallest commitment that still justifies your current claim.”
How to use this in governance:
  • Change control: when a tier changes, show Δf as the “must move” list across modules.
  • Stage-gates: freeze commitments at f(tier) before promising that tier externally.
  • Negotiation: if commitments are capped, g(commitment) is your defensible counter-offer.
  • Co-design alignment: the monotonicity enforces “no subsystem left behind”.
Note: if time-vs-money trade-offs create multiple incomparable “minimum” options, you won’t get a single weakest package; you’ll get a Pareto set (antichain). That’s exactly where monotone co-design uses set-valued solutions rather than single points.