From evidence to a parcel view—honestly bounded.

What happens to the data

OESIS combines four evidence lanes into one parcel view:

1. Parcel priors — Site facts and operator-provided context that shape the starting expectation.
2. Local evidence — Readings from parcel-operated nodes.
3. Optional nearby evidence — Coarse shared signals from nearby participants who opt in.
4. Public context — Regional weather, smoke, hydrology, and related public feeds.

The goal is a parcel-facing result with confidence and reasons, not a single opaque score.

What makes it parcel-first

A parcel-first system asks more than “what does the regional map say?” It also asks:

• does this parcel diverge from the regional baseline?
• did parcel context change the interpretation?
• what changed once local evidence was added?

In practice, the view should preserve three cues: priors (starting assumptions), divergence (local differences), and contrast (public-only result versus fused result).

What the evidence modes mean

These modes explain where a conclusion comes from, not how severe it is:

• local_only — grounded in direct parcel evidence from local nodes.
• local_plus_public — parcel evidence fused with broader public context (weather, smoke layers, hydrology feeds).
• insufficient — not enough evidence to produce a reliable estimate.

The system also generates contrastive explanations showing what public data alone would conclude versus what the fused parcel inference says — so you can see whether local sensing changed the picture.

What is implemented today

Active development spans five runtime lanes (v0.1 through v0.5), each with its own acceptance tests:

• v0.1 — Reference pipeline: one bench-air indoor node through ingest and inference to a parcel view with evidence modes and reasons.
• v0.2 — Adds mast-lite outdoor node for two-node parcel operation.
• v0.3 — Adds flood-node, covering three hazard tracks (smoke, heat, flood) with derived shelter and asset-risk statuses.
• v0.4 — Node registry binding multiple sensors to one parcel, plus trust gates (freshness, confidence, cross-source disagreement).
• v0.5 — Governance enforcement: consent, revocation, retention cleanup, and export bundles in the runtime.

See Systems for module maturity and Open release for implementation-level guides.

Reference bench-air wiring (v0.1). Build and firmware specifics live in the Open release documentation.

Reference model: one parcel, one bench-air lineage, one ingest path, one inference path, and one parcel-facing output. Later lanes add mast-lite, flood-node, trust scoring, and governance.

Trust boundary

Outputs are advisory guidance for household judgment. They do not replace official alerts, emergency authority, or on-scene decisions. Wider sharing remains optional and policy-gated.