Keep the whole promise.
A final capacity band hides what passengers receive while work is happening. The model carries the service curve as well as the endpoint.
START WITH A COUNTEREXAMPLE
Can this design be delivered?
Choose a case, then change the constraints. Every retained option includes a construction path.
CALCULATED RESULT
Calculating…
THE RESOURCE ANTICHAIN
Different ways to meet the same brief
Less cost, earlier completion, fewer access units: each retained point has a trade-off. Select one to inspect its path.
FROM CHOICE TO CONSTRUCTION
Walk the selected path
Filled bars: service during work. Dark line: commissioned capacity at slot end. Dashed line: minimum operating service.
Read the full construction trace
| Slot | Work | Service during work | Installed bands after work | Cost | Access |
|---|
Compose before reducing.
Signalling readiness, grid continuity, crews and access restrict the set of admissible paths. Temporary works earn their place through this interface.
Retain the alternatives.
Only then reduce resource tuples to their Pareto antichain. An empty frontier is a result about this finite catalogue and this brief.
Experiment receipt
Reload this URL to reopen the brief. Path selection and replay are temporary. Export creates a local JSON file; no works or commitments are authorised.
END → WAY → CONSTRUCTION
A path can be an implementation.
The advance is to change what a design choice contains. The finished system alone is too small an object for the staged-delivery question.
Implementation set IAll legal finite action histories
→Functionality exec(i)Operating-service curve + commissioned-capacity curve
+Resources eval(i)Cost, finish slot, peak access
What the original foray asks
Use monotone co-design to tackle rail project trade-offs without avoiding the difficult part: aligning platform, signalling and power expansion across staged delivery constraints. Explain the result at project-director level.
What is constructed here
For each path, permanent capacity only increases. A separate service measure records what is available during each work slot. These are different quantities: installing a bigger asset does not by itself guarantee uninterrupted operation. This app queries a constant operating floor and one end-of-slot commissioning requirement, and solves again for every new brief.
The engine composes a finite action catalogue with signalling guards, power continuity and shared crew/access limits. It queries the resulting implementation space for the minimal resource tuples that meet the service and milestone requirements. It returns an actual trace for every retained tuple.
h(f) = Min { eval(i) : i ∈ I, f ≤ exec(i) }
The order on service curves is pointwise. The order on resource tuples compares each coordinate separately. “Minimal” allows several incomparable answers; there need not be one least or best plan.
Requirements may change. Commitments are another choice.
Monotonicity relates ordered requirements to feasible resource choices: asking more cannot make an inadequate implementation adequate. It does not mean that an exploratory slider may never be lowered. This model separately assumes that commissioned permanent tiers cannot decrease; temporary equipment can be installed and returned, and service during work can vary. Those are explicit transition rules, not consequences of the word “monotone”.
Explore the introductory coupling explanation · See exactly where categorical co-design is used
The counterexample concerns a missing interface
Projecting a path onto final capacity erases continuity. Under that projection, the cheap direct grid method can dominate the temporary-bridge method. Once continuity is required, the cheap path can disappear and the enabling method becomes useful. Pareto reduction remains correct for the problem it was given. The endpoint-only problem omitted part of the promise.
What this does and does not establish
This gives a constructive positive result for a bounded version of the foray: staged rail co-design can produce feasible paths and a resource antichain when the action catalogue, constraints and temporal interface are explicit. It also locates the extra modelling work: co-design does not invent engineering methods, permissions or stakeholder preferences from a final capacity target.
Capacity bands, costs, slot lengths, cutovers and guards are fictional. Access units are a declared scarce planning resource, not a railway rule. There is no uncertainty model, calibration, negotiation or claim of engineering safety. Stakeholder concerns are represented only by the specified hard service, milestone and access constraints; this does not solve equitable negotiation.
Inspect the declared catalogue
Algorithm and evidence
All admissible finite choices are represented by the solver; the independent checker enumerates histories on smaller cases and compares feasible resource frontiers. Verification establishes the declared calculations, not usefulness to a human or a validated transport plan.
SOURCE IDEAS, MODEL CHOICES, TESTED RESULTS
Where the construction comes from.
A constructive step in the rail co-design foray, with its sources, surviving companion essays and recorded antecedents.
01
Design problems with implementation
Gioele Zardini, Co-Design of Complex Systems (2023), §§3.1–3.5, printed pp39–50. Supplies the functionality / implementation / resource separation and composition by admissible implementation tuples. This app chooses finite stage paths as those implementations.
Thesis at ETH Zürich ↗02
Minimal resource antichains
Andrea Censi, A Mathematical Theory of Co-Design (2015; revised 2016), with the MCDP manual’s catalogue examples and Monotone Co-Design Problems; or, everything is the same. Supplies the partial-order view of functionality and resource trade-offs. The JavaScript finite solver is independently written; it does not reproduce the general library or claim to implement its feedback solver.
Censi’s paper ↗ · Author’s papers & talks ↗03
Companion essays and preserved ideas
The programme studio compares compatible finished packages and four supplied staging strategies. Its coupling primer preserves the best explanations from the retired rail apps, correcting their request and monotonicity claims. The wildlife essay makes component composition explicit in another setting.
04
Temporal co-design already has antecedents
Corentin Briat’s 2026 codesign-mcdp library includes sequential and temporal extensions. Its current manual labels those extensions as work in preparation, not peer reviewed. Its carried-state implementation and regression example reinforce the need to preserve future resource consequences before projecting onto cost. This app uses its own finite solver.
Library paper ↗ · Reviewed sequential implementation ↗Contribution and boundary
The contribution is an executable end–way test for this foray, not a claim that temporal co-design or constrained planning is a new field. Each resource point is supported by a trace. Each infeasibility claim is restricted to the declared finite catalogue, time horizon and brief.
Inspect the app source ↗ · Model, source use and verification