Director brief
Compare the minimal alternatives
Feasible candidates
0
All plans surviving the hard ceilings.
Pareto-minimal plans
0
The antichain under <capex, months, risk, possessions>.
Highlighted plan
—
Selected using the current recommendation lens.
Least relative headroom
—
Computed from the selected service plan.
Set the task and press Recompute frontier. The model will choose train length, headway, subsystem packages, governance, and stage strategy, then filter for minimal resource bundles.
Start here: a request, a compatible design, and its trade-offs
Functionality is the promise.
Here it is passengers per hour in the peak direction. A design is a particular service plan and package tuple. Resources are what that implementation requires: capex, duration, programme risk and possessions. Green dashed diagram edges show provided capabilities; red solid edges show resource requirements.
One choice can require a co-move.
In this fictional catalogue, a longer planned train requires a larger platform envelope and may raise the minimum signalling and power capability. For example, a 10-car plan at 18 tph still requires 21-tph signalling. These are declared compatibility rules, not universal engineering or safety laws.
Monotone does not mean irreversible.
Holding the catalogues and assumptions fixed, asking for more throughput can only remove feasible implementations. It does not force the user to keep the highest target ever tried. A signed commitment or an irreversible construction step is an additional project rule and needs its own model. You can freely explore a lower request here.
Several minimal choices can be useful.
A cheaper plan may take longer or use more possessions. Pareto dominance means no worse in every resource and strictly better in at least one. The remaining alternatives form a discussion object: compare the extra resource needed for a gain, without forcing everyone’s objectives into one score. Balanced is only an illustrative initial highlight; a hypothetical risk ceiling is not stakeholder consent.
This primer preserves and corrects the useful explanation from the earlier rail-transit, incremental-upgrade and rail-simulator essays. For legal work sequences and service during construction, open the staged-path experiment.
Executive reading
Select a retained implementation to inspect its functionality, compatible subsystem tuple and resource consequences.
Task decomposition
Increase corridor throughput
meet the declared capacity request
meet the declared capacity request
Accommodate longer trains
station and platform envelope
station and platform envelope
Provide the required train frequency
headway, interlocking, regulation
headway, interlocking, regulation
Feed extra traction power
substations, feeders, resilience
substations, feeders, resilience
Keep the programme governable
claims, approvals, stakeholder tolerance
claims, approvals, stakeholder tolerance
Programme algebra
Capex
Package costs are summed, then context, governance and declared premiums apply.
Package costs are summed, then context, governance and declared premiums apply.
Schedule
Parallel work uses a max-like critical-path logic, then adds interface / approval delay.
Parallel work uses a max-like critical-path logic, then adds interface / approval delay.
Risk
Mismatch, possessions, and governance discipline are merged, then optionally fed back into schedule.
Mismatch, possessions, and governance discipline are merged, then optionally fed back into schedule.
The selected implementation: actual component joins
The same three provided ≥ required checks select this tuple in the engine. This is an endpoint capability check; it does not certify intermediate operating service.
Select a plan to inspect its component joins.
What the highlighted plan is really saying
Once solved, this panel explains the highlighted plan in programme language: what it buys, what it forces elsewhere, and which declared assumptions drive its programme penalties.
Data flow vs logical dependency
Following the documentation, the co-design diagram is about dependencies, not operational signal flow.
On a narrow screen, scroll the diagram sideways to read its labels.
Stage alignment diagnosis
Select a plan to inspect normalized subsystem readiness in its base construction pattern. The separate clock breakdown accounts for programme-level delay; neither display certifies operating service.
Method in six moves. Define the task, identify the implementing components, join their provided and required capabilities, retain compatible alternatives, evaluate their resources, and query the minimal tuples. The feedback panel is a separate affine resource calculation; it is not a general solver for cyclic co-design diagrams.
1 · Define the task
The task here is not “buy some rail assets”. It is: deliver corridor peak throughput under explicit ceilings on budget, time, and programme risk. The page treats this as the top-level function and keeps implementation choices separate from it.
2 · Functional decomposition
The external function is throughput. A service plan specifies cars and frequency; the three package catalogues provide the capabilities required by that plan. A works implementation also includes a governance choice and a supplied staging pattern. The no-project implementation uses compatible baseline assets.
3 · From decomposition to co-design diagram
The actual joins are explicit: platform cars ≥ service-plan cars; signalling tph ≥ max(planned tph, the train-length requirement); power index ≥ the declared load requirement. The selected tuple’s checks are shown in the Brief. Diagram arrows illustrate these dependencies; they are not simulated operating signals.
4 · Populate implementations
The implementation set is the compatible subset of the Cartesian product of the finite catalogues, with the service plan and programme alternatives retained. Flat enumeration computes these joins directly. The catalogue relation is discrete; readiness sampling and risk assumptions remain approximations of the chosen scenario.
5 · Solve by querying minimal resources
For the requested throughput, the solver retains all compatible implementations that meet the declared ceilings, then finds the minimal resource tuples across them. Raising only the throughput request removes implementations; it never changes a fixed implementation’s cost or risk.
6 · Treat loops explicitly
For a fixed implementation, the supplied affine map is r = B + 0.72q + 0.222P + 0.42αr. Every supplied α gives slope below one, so the exact solution is r = (B + 0.72q + 0.222P)/(1 − 0.42α). The trace illustrates iteration; the resource evaluation uses this exact result.
Stylised modelling choices in this scenario
Packages, durations, governance effects and penalties are illustrative. Capacity requirement maps are non-decreasing; resource bundles are Pareto-filtered. Sequencing is restricted to four supplied strategies. Readiness is linearly interpolated within work stages and mismatch is sampled at 120 intervals; it is not certified operating service. The feedback calculation is a synthetic scalar evaluator, not a general MCDP loop solver. Resource ceilings of zero are unconstrained; there are no hidden duration or risk cutoffs. The no-project option has zero incremental resources only when the baseline packages are compatible and meet the task.
Pareto frontier
x = capex, y = schedule, bubble = risk, outline = Pareto-minimal. Click a row below to inspect a plan.
feasible plan
minimal plan
Dominance reading
The green-outlined points form an antichain: no distinct retained resource tuple dominates another across all four dimensions. Dominance also compares possessions, which this two-axis projection does not fully display. The table retains all four resource coordinates.
Feasibility split
The bar chart decomposes feasible candidates by stage strategy and governance mode, showing where the antichain comes from institutionally.
Minimal plans table
The recommendation lens only highlights a row. The antichain itself remains the correct decision object.
Why this loop exists. This model assumes that mismatched subsystem delivery increases an illustrative approvals burden, which lengthens the programme and feeds back into its risk index. Those relationships are declared scenario assumptions, not identified causal effects or empirical claims about railway failure.
Iteration trace
The trace shows risk ↗ approvals delay ↗ schedule ↗ risk from zero. The final row is the exact affine solution used by the resource query, not a tolerance-limited estimate.
Loop read-out
Solve the frontier and select a plan to see its fixed-point trace.
This is one declared scalar resource evaluator. A general MCDP feedback operator over design relations is a different construction and is not implemented here. With feedback off, the model uses the stated nonrecursive base, mismatch and possession terms.
Explanatory model notation
This sketch is not executed or validated MCDPL syntax. The actual finite JavaScript relation checks the component joins shown in the Brief and enumerates their compatible tuples. Inspect the model note for the implemented equations.
Glossary
Functionality = what a subsystem provides.
Resources = what it requires.
Catalogue = arbitrary discrete implementation relation.
Choose = retain one explicit programme alternative.
Antichain = mutually non-dominating minimal plans.
Scalar feedback here = an affine schedule/risk evaluator with an exact fixed point.
Resources = what it requires.
Catalogue = arbitrary discrete implementation relation.
Choose = retain one explicit programme alternative.
Antichain = mutually non-dominating minimal plans.
Scalar feedback here = an affine schedule/risk evaluator with an exact fixed point.
Interpretive note
The point of the exercise is not to make rail projects look like a single spreadsheet optimisation. It is to formalise the fact that every local improvement pushes on a wider dependency structure, and that management choices about packaging and pacing are themselves part of the design space.