Rebuild a Greenhouse Event from Four Records
Run a small Python example with two temperature readings and two spatial-capture references. Follow the timeline and inspect why the records cannot be fused as one synchronized capture.
Streamline Farms · neighborhood food infrastructure
Four records are enough to expose a reconstruction problem: two air-temperature readings, two spatial captures, different times, and different scanner frames. Put them on one timeline without losing those differences, then ask which relationships the records actually support.
This is a synthetic, runnable exercise in handling records. It does not diagnose a crop or reconstruct Streamline's field dataset.
Download the example
Use the synthetic CSV and the Python example. Run python reconstruction-demo.py reconstruction-events.csv with Python 3. The script uses only the standard library and prints JSON.
The fixture contains two air-temperature observations and two spatial-capture references. It supplies metadata rather than a point cloud. No actual LiDAR geometry or registration is performed.
| Record | Capture time | Context | Value or frame | Calibration |
|---|---|---|---|---|
| air-a | 09:00 UTC | Demo greenhouse, Bed A | 24 °C air | current |
| air-b | 09:05 UTC | Demo greenhouse, Bed A | 25 °C air | current |
| scene-a | 09:00 UTC | Demo greenhouse, Bed A | scanner-A frame | current |
| scene-b | 09:10 UTC | Demo greenhouse, Bed A | scanner-B frame | unknown |
Preserve before deriving
The script retains source file and record identity, capture and receipt times, location, measurement type, units or frame, and calibration state. The sorted timeline is a derived representation. The source fields remain attached.
Matching bed labels allow a joint inspection. They do not establish simultaneity or a qualified spatial transformation. scanner-A and scanner-B remain separate frames.
A refusal that still produces something useful
The example attempts only a deliberately strict synchronized-fusion check. It refuses because the capture times differ, the frames differ without a supplied transform, and one calibration state is unknown. It lists those reasons and keeps all observations available.
An expected output contains fusion_allowed: false, the rejection reasons, the four-record timeline, and a temperature summary explicitly labeled as air observations. This is not a universal time-tolerance rule. A different analysis may intentionally compare observations captured at different times.
What a production reconstruction adds
Real use needs device identity and clock evidence, integrity checks, full measurement metadata, geometry, qualified coordinate transforms, capture duration, uncertainty, and a question-specific relationship rule. Those inputs are absent from the demonstration.
Streamline's engineering has reconstructed one recorded greenhouse interval. This downloadable fixture lets someone inspect the underlying record-handling principle; it does not publish the private source data or demonstrate independent replications.
Using a replay for food planning adds a different relationship: from the represented crop area to a harvest lot accepted into inventory. The timeline here has no harvest quantities, kitchen stock, or delivery reservations. Those records are required before anyone can use it to answer which ingredients are available for a meal.
Sensor provenance explains how those fields change a conclusion. The buyer test asks whether the result saves useful investigation work.
Download the example script and synthetic observations to run the four-record check yourself.
Keep exploring.
Read the evidence, try the available tools, or help build the first neighborhood.