Package exploration 7 September 2026; monitoring adaptation 27 September 2026 · Monitoring-power app · Foray home

The useful addition is executable feedback between components. We can declare the capabilities that each component must provide, wire the demands they create for one another, and let the package find the least consistent resource requirements. The monitoring essay uses that capability to size an off-grid wildlife monitoring supply, including the power needed by its own cooling and conversion equipment.

This review used the actual source and an isolated installation of Corentin Briat’s codesign-mcdp 0.2.1 at commit 97d6446. It is the separate public implementation identified in the previous audit, not original PyMCDP returning. We inspected the package API, manual and selected examples, then ran bounded probes of the core solver before building the app.

Capabilities and promising project questions

Package capability What it could add Disposition in this experiment
Module, System, solve and feedback trace Size an enabling resource whose own overhead creates further demand; expose which component causes the next increase. Used directly for battery, cooling and converter sizing.
Series/parallel composition and resource antichains Build a larger model from reusable component relations, preserving several incomparable answers. The component system is explicit; eight fixed equipment-family combinations preserve named implementations and are compared by capital and cabinet volume.
Lower/upper design problems and monotone parameter boxes Ask which wildlife crossing or monitoring configuration remains adequate under an established range of assumptions. Useful next extension, but the bracket and common adverse corner must be justified. The app currently has two explicit, separately solved equipment envelopes.
Online candidate evaluation with valid optimistic bounds Decide which expensive engineering model to evaluate next, while preserving the remaining unknown candidates. Potentially useful when inner calculations are expensive. It is a computational search question, not automatically an ecological survey or a field-learning policy.
Temporal, sequential and receding-horizon extensions Explore changing systems and choices over time. Not used here. Their semantics and stated research status need their own audit before replacing the existing staged-path result.

A particularly promising later wildlife question is one design committed before a survey versus a policy that keeps a later choice open. A robust installed design must be the same physical implementation in every possible scenario. Reoptimising separately after seeing each scenario answers a different question. A survey-contingent policy would need explicit shared first-stage actions, observation branches and resource accounting; the package’s uncertainty wrapper does not supply those policy rules automatically.

The current essay applies the inspected static composition machinery to off-grid monitoring at a wildlife crossing: batteries supply cameras, sensors and a data link, and must also power their own support equipment. This adapts the historical rail experiment with W/Wh units, capital coefficients divided by 1,000 and a newly declared additive cabinet-volume resource. All 784 calculations are regenerated with the pinned package. The sizing question remains separate from crossing performance and installation sequencing.

Findings that changed the implementation

The package is useful, but its convenience APIs are not mathematical certificates for arbitrary supplied models. These source-pinned findings affected our design:

  1. Convergence is required. A bounded runtime probe returned feasible=True while status="max_iter"; the intermediate resource point did not yet meet the full requirements. The solver exposes these separately. The atlas build rejects every unfinished calculation.
  2. Cold starts preserve the least-solution question. Reusing a larger solved point for a relaxed request produced false infeasibility in a probe, while a cold solve found the smaller answer. Every atlas calculation starts from zero.
  3. Catalogue availability is checked explicitly. An empty capped component inside System produced a partly infinite internal state and diverged. We instead solve the monotone integer sizing system, verify its least point, and compare that point with the stated availability bounds. The proof and exhaustive check establish when exceeding a bound rules out an available design.
  4. Implementation names are kept outside the numeric frontier. CatalogDP.h returns resource dictionaries rather than catalogue names. Each equipment-family combination is therefore solved and recorded with its own identity, counts and complete interface checks; equal-resource alternatives remain recoverable.
  5. Units and monotonicity belong to the model contract. Unit strings are descriptive metadata. The package checks wiring targets and coverage, but does not prove physical dimensional consistency or monotonicity of arbitrary Python functions. The three inequalities, integer arithmetic and non-negative coefficients are independently checked here.

The uncertainty layer needs separate care. In this version an undeclared Box direction uses a summed-resource heuristic; an actual system probe selected the favourable endpoint as its reported worst case. Declaring the proven adverse direction produced the expected endpoint in that probe. The Ellipsoid direction shortcut is not a general worst-case oracle, and stochastic convenience summaries pool resource coordinates across feasible frontier points. Those coordinates need not describe one design committed before uncertainty resolves. The new app does not use these shortcuts. Inspected uncertainty implementation.

The same pinned uncertainty entry point does not forward trace=True or on_iteration: the retained probe produced no trace and no callbacks. An uncertainty extension that needs an explanatory iteration trace should solve each explicitly justified endpoint through ordinary solve(trace=True) and compare with the uncertainty API. A missing trace is not an empty or completed calculation. The current monitoring app uses ordinary static solves and is unaffected. This is a source-pinned extension caveat, not a general claim about newer versions.

There are also two different online layers: candidate-evaluation search and a myopic sense/solve/act loop. A budget-exhausted search is incomplete; a partially successful control run is not a completed programme. These distinctions would need explicit treatment in an app using them.

Publication architecture

The core package has no mandatory runtime dependencies beyond Python’s standard library. It can therefore be run reproducibly during generation without adding a heavy runtime to the public page. All supported briefs are calculated with the pinned Python package, and the recorded atlas is embedded in the standalone HTML.

The page supports exactly the displayed power, duration and condition choices. Its ceilings filter complete recorded designs; it does not interpolate a result for an uncomputed request. The Python model, generator, contract, package pin and independent oracle make a new atlas reproducible. The build checks source hashes and complete results, rather than trusting a screenshot or just a frontier count.

Running the Python package in a browser worker through Pyodide is a candidate future architecture if freely editable component parameters become useful; browser compatibility was not tested in this experiment. It would add runtime loading, cancellation, failure and browser/native-equivalence work. It is not necessary for the complete finite experiment published here.

Source and scope

The framework remains Censi’s mathematical theory and Zardini’s co-design definitions. The package’s manual distinguishes the established static machinery from its author’s newer temporal and sequential extensions, which it describes as not yet peer reviewed. The app uses the static core and our declared finite engineering model, with an independent oracle; it makes no general correctness claim about every package module or a real monitoring installation.