# OptiCold website and calculation interfaces

Website release: opticold-web-2026-10-19.6-en. Calculation implementation: opticold-weather-economics-2026-10-19.1.

## Reading and interaction

The English homepage, index.html, presents the solution, representative results, the connected service model, accessibility, resilience, implementation inputs, Jharkhand cases, and model evidence. The interactive workspace is weather.html. legacy.html and capabilities.html retain historical demonstrations; their old results are not mixed into the current homepage.

The homepage reads 21 case/scenario entries and 63 policy summaries from homepage-data/catalog.json. Its manifest binds the summary SHA-256. Each entry binds the exact weather-data result and economics-data receipt. Case and scenario changes update service, household burden, route summaries, cost, audit/search status and evidence links together. Near and remote groups retain their own demand denominators. Planned doses are not observed vaccinations.

## All three cases accept custom inputs

Edit row-level demand, near/remote splits, session windows, known ambient temperature and the declared remote acceptance limit. Near + remote must equal each row’s dose demand. This workspace accepts up to 500 original obligations with windows between 08:00 and 17:00. Fixed-plan, simple-rule and optimized results share the current request and existing resource pool.

Switching saved cases reads audited results. Computing launches the local browser Python engine and independent audit, then prices actual activity quantities in INR estimates. Editing inputs or switching cases terminates stale calculations and clears old charts and export. Loading disables editing and import. Accepted results must match the request case and condition. Import re-audits against current inputs and rejects stale or invalid-input records.

The original JSON numeric types are retained. Display formatting does not rebuild execution ledgers. Worker studyMode supports compare, improve and recover. withEconomics:true returns opticold-core-and-economics/1 containing core and economics. imported: exportedText re-audits the core and recalculates costs. requestFromRecord:true extracts a recovery record’s original request inside Python.

## Runtime and publication scope

Serve the entire public-capabilities directory over HTTP(S). The included vendor/pyodide runtime, Python bundle and economics module require no external solving service. Update compute/runtime-manifest.json and engine-bundle.zip together, and economics-manifest.json and economics-bundle.zip together.

The public runtime retains byte-identical V3 Python sources, reviewed_data/merged_data.json and parameter_records.json. All seven original source-snapshot files were verified locally. The public runtime snapshot explicitly covers only the two required parameter JSON files and records the original snapshot hash. Source workbooks, internal notes and full source archives remain local. Packaging does not rewrite the algorithm. The English presentation and evidence guide do not alter audited source records; English parameter explanations preserve all numeric bands, units, sources and statuses.

## Limits and cost scope

All main cases are synthetic. Weather inputs represent declared or known operating conditions, not automatic weather forecasts. Pre-dispatch replanning and in-transit recovery are separate workflows; the recovery replay is not a field execution record. Missing evidence remains unassessed. Valid zero-service results retain unmet original demand. Incomplete search is not a global-optimum proof. When the fixed plan retains more service, it remains explicitly available for comparison.

The core budget uses DEMO_UNITS. Costing is post-solve INR_ESTIMATE accounting, not route optimization under a rupee budget. Run cash, first-year cash, subsequent steady-year cash and economic cost remain separate. The 48-round annual workload, disruption mix and some prices are frozen assumptions; custom demand or temperature edits do not recalculate annual results. Separate deployment budgets must not be added mechanically. Loss sensitivities are not achieved savings, and unknown full costs are not zero.

Field data, equipment performance, actual acceptance, operational responsibility and implementation procedures still need verification. Website and model checks do not establish vaccine efficacy, reduced discard or realized service improvements.


## Extending to another village

The three cases are structured feasibility demonstrations, not a training dataset or predictions for other locations. C1 tests single-village delivery and a preconfigured alternative road; C2 tests household travel rules alongside delivery; C3 tests shared multi-village resources under disruption. Audited feasibility applies to the declared inputs and constraints.

The generic planning core accepts configured data and tasks. The current browser adapter explicitly accepts only the registered C1/C2/C3 fixtures. Its input controls vary demand, group splits, session windows and declared conditions within those fixtures. Roads, inventory, vehicles, staff and equipment are not replaced by renaming a village.

For a new location, choose the closest planning structure, supply and verify a complete local demand/network/resource/household configuration, establish a comparable reference, and run a fresh model calculation and audit. Integration must register and bind the new configuration rather than bypass the fixture check. Check runtime and search limits for larger instances; validate local execution before claiming comparable field results. The existing generic model interface and field-data gate support this integration workflow; this website does not yet provide an arbitrary new-village configuration importer.


Preset identity correction on 19 October 2026: the workspace now checks the exact WEATHER_ condition ID. This distinguishes heat from heat-plus-delay and accepts registered closure and supply-failure presets. Existing calculation inputs, Python sources, numeric results and cost receipts are unchanged. Historical result/catalog and browser-check records retain their original release identity. New selection checks cover all 21 presets and 168 mismatched case/preset combinations; they do not rerun the upstream 518 checks.