The deer need a usable route; the project needs a crossing, guiding fences and a way to observe what happens. Those choices bring land, cost, construction and power obligations. Four essais explore different parts of that one promise, using explicit toy assumptions.
Can we deliver the whole promise, including the journey to it?
A foray into coupled project choices
Design the whole promise.
A green bridge is a start. Guidance, observation and delivery must fit it—and each other. Follow those obligations through four different co-design methods.
ONE SCENARIO · FOUR QUESTIONSThe connections do the work
The bridge is only part of the promise. Connections expose work and resources that an isolated choice can hide. The arrows here guide the investigation; each essai defines its own mathematical interfaces.
Co-design keeps the requirements and resource trade-offs of connected systems in the same decision.
ONE INVESTIGATION SEVERAL WAYS IN
Start with the question you have
Four ways to explore.
Start with a complete crossing. Then ask how to deliver it, which programme assumptions matter, and how to support remote observation. Each essai keeps its own units and declared model.
01 · Connect a habitat
What makes a crossing work?
A bridge is one part of the answer. Compose bridge, fencing and monitoring choices; inspect the complete alternatives and the trade-offs they leave between resources.
Wildlife-crossing co-design. A finite component model with explicit interfaces and implementation witnesses.
Require declared corridor readiness, shared crews, restricted access or an intermediate milestone. Find feasible action sequences and inspect every step behind the resource trade-offs.
Staged path co-design. Exact finite construction with independently checked witnesses.
Compare crossing, guiding-fence and monitoring packages, governance assumptions and four supplied staging strategies. See how interface mismatch and an illustrative approvals loop affect the alternatives.
Programme co-design studio. A broader comparison, with an introductory explanation of coupled requirements.
Remote cameras and sensors need power. Battery packs bring cooling allowances; cooling and conversion need power too. Follow the cycle until a complete monitoring installation emerges.
Monitoring-power co-design. Recorded Python MCDP calculations, with independently checked whole-unit implementations.
Specify what the system must provide. Keep combinations whose parts satisfy each other’s requirements. Then compare the resources those complete implementations need.
The crossing, staged-path, programme and monitoring-power models use this common structure at different levels. Their method notes show the actual interfaces and the limits of the construction.
These experiments draw on monotone co-design: represent what connected parts must provide, then retain the resource choices that remain incomparable. The method notes connect the actual constructions to Zardini and Censi, and distinguish model assumptions from checked results.
All are illustrative project models. Their different assumptions belong to each experiment; their results are not interchangeable forecasts. “Model crossings/day” is an invented capability proxy, not a prediction of animal behaviour. Staged readiness is a separate management condition.