# P4 local arithmetic lab · p4-toy-1

Educational authored parameters, version p4-toy-1, dated 2026-10-12. This is a static arithmetic model, not an aircraft, detector, network receiver or flight simulator. Every numerical input (including limits and reserve) is fictional. Limits here are parser bounds, not operating limits.

## Keep the four source files together

Download [calculator.py](calculator.py), [fixture.json](fixture.json), [expected.csv](expected.csv) and this [readme.md](readme.md). The author's [raw results](raw-results.json) and [host verification record](host-results.json) document all 17 cases matching expected results, identical replay and three matching rollback pairs. Expected results are independently authored; the calculator never reads expected.csv. Author host results never fill a learner record: learner=NOT_RUN until the learner's own work is recorded. Hardware, flight and RF evidence remains NOT_RUN.

1. Read the script and all case test plans before execution. Use Python 3.9 or newer with standard library only in an appropriate local environment.
2. Preserve source files as baseline; record SHA-256 of script, fixture and expected CSV, Python version, command, date/time and exit code. Hashes identify bytes; they do not authenticate an author.
3. Run `python calculator.py` from the folder. Optional `python calculator.py --fixture local-copy.json` accepts one local regular JSON file of at most 65,536 bytes. It has no output-path option; the caller may capture stdout to its own evidence folder. No network, subprocess, eval, device interaction or file writes exist in the calculator.
4. Only exit 0 JSON is an actual host calculation. Compare every disposition and metric with expected.csv, including nulls and booleans. Invalid input exits 2, sends a short error to stderr and produces no result JSON. Do not label a rejected fixture as a passing case.
5. Run the same source and input twice and compare output bytes. Compare CAM05/CAM01, DATA07/DATA01, PAY05/PAY01 ignoring case_id; all other fields must match. These are authored baseline restoration scenarios. For a learner edit, additionally restore the saved fixture copy, verify its hash and rerun; log evidence separately.
6. Record changes in the case change-record.md under the same outcome ID (v0 then v1), expected-before-run, actual, discrepancies, reviewer feedback and retest. Never edit expected.csv merely to match a wrong actual result.
7. Keep physical, flight, RF and learner evidence NOT_RUN and permissions/receiver NOT_CONFIRMED until separately evidenced. A numeric_fit does not clear these gates.

## Exact schema and bounds

Top-level keys: schema_version exactly "p4-toy-1"; evidence_basis exactly "authored_teaching_parameters"; cases exactly 17 entries in the supplied order CAM01–CAM05, DATA01–DATA07, PAY01–PAY05. Each case has exactly case_id, model and parameters. Model is camera, data or payload according to its prefix. Unknown/missing fields, duplicate JSON keys, nonfinite constants, booleans as numbers, wrong types, malformed JSON and wrong ordered IDs are rejected. The entire fixture is validated before any calculations are output.

JSON numeric lexemes are at most 32 characters; exponent magnitude at most 12 before Decimal conversion. Positive quantities must be greater than zero. Integer fields cannot be fractional.

| Model | Exact parameter keys and parser bounds |
|---|---|
| camera | target_mm, gsd_mm_per_px, min_samples: (0,10000]; image_count: integer (0,10000]; bytes_per_image and capacity_bytes: integer (0,1e9] |
| data | age_s: [0,1e6]; payload_bytes: integer (0,1e9]; bitrate_bps, deadline_age_s, ttl_s: (0,1e6]; connected: boolean; plan_version: PLAN0 or PLAN1 |
| payload | components: exactly FRAME, BATTERY, PAYLOAD in that order, each with id, mass_kg (0,10000], x_m [-1000,1000]; mass_limit_kg (0,10000]; cg_limit_m (0,1000]; capacity_wh, required_wh (0,1e6]; reserve_fraction [0,1) |

Only camera gsd_mm_per_px, data bitrate_bps, and PAYLOAD component mass_kg allow null. Null means unknown, never zero. All other numeric parameters are mandatory and known. Totals include all components; no partial mass is presented as total.

## Formula and output contract

- Camera: samples = target_mm / gsd_mm_per_px; total_bytes = image_count × bytes_per_image. Sampling passes >= min_samples and storage passes <= capacity. Unknown sampling still retains known storage metrics.
- Data: serialization_s = payload_bytes × 8 / bitrate_bps; arrival_age_s = age_s + serialization_s. This ideal serialization excludes protocol overhead, queuing, retries and receiver processing. Metrics remain nominal even offline. Disposition precedence: unknown → offline_hold → stale_plan (expected PLAN1) → expired (arrival >= ttl) → deadline_missed (arrival > deadline) → numeric_fit. Equality at deadline passes only if no earlier condition holds; equality at TTL expires.
- Payload: total_mass_kg = sum masses; cg_m = sum(mass × signed x) / total mass; usable_wh = capacity_wh × (1 − reserve_fraction). Fit requires total <= mass limit, abs(CG) <= CG limit and required <= usable. Unknown mass makes total, CG and their flags null; independent energy remains known. One-dimensional static coordinates are fictional, not physical placement instructions.

Exact Fraction arithmetic determines all comparisons before rounding. Display numbers round to nine decimal places, half up; integer results have no fractional part. The JSON object has schema_version, evidence_level "host_calculation", results array and physical/learner "NOT_RUN". Each result has case_id, model, disposition and metrics. Camera metric keys: samples, sampling_ok, total_bytes, storage_ok. Data: serialization_s, arrival_age_s. Payload: total_mass_kg, cg_m, mass_ok, cg_ok, usable_wh, energy_ok.

## Scope and open gates

A host calculation can support the P4 document/simulation gate after comparison, replay and restoration evidence. It does not prove camera visibility, geometric accuracy, meaningful search detail, receiver acceptance, compatibility, mechanical strength, dynamics, vibration, thermal behavior or endurance. Hardware/flight/field tests are separate NOT_RUN; specialist not_assigned and P3 pending_field_review. P5 has no real learners and remains preparation only. CLO/PLO are blank, pending_design.