System overview
From evidence to a parcel view—honestly bounded.
TL;DR
OESIS fuses parcel context, local readings, optional nearby signals, and public feeds into one parcel view with confidence and reasons. Outputs are advisory and do not replace official alerts.
This page explains the product flow in everyday language. For visuals, see Diagrams; for contracts and build guides, see the open release hub.
What happens to the data
OESIS combines four evidence lanes into one parcel view:
- Parcel priors — Site facts and operator-provided context that shape the starting expectation.
- Local evidence — Readings from parcel-operated nodes.
- Optional nearby evidence — Coarse shared signals from nearby participants who opt in.
- 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).
OESIS compared to common approaches
| Approach | What it does well | What it misses | What OESIS adds |
|---|---|---|---|
| Regional maps and alerts | Broad situational awareness across large areas | Site-level interpretation and indoor relevance for one location | Parcel-level interpretation with local divergence and confidence shown |
| Standalone consumer sensors | Direct local measurements | Cross-signal synthesis and clear reasoning across sources | Fused parcel view with observed vs inferred framing and evidence modes |
| Smart-home automation tools | Device control and convenience | Hazard interpretation and uncertainty-aware environmental reasoning | Hazard-aware, advisory-first parcel-state outputs before bounded controls |
| Institutional dashboards | Program-level monitoring and reporting | Site-scale ownership, opt-in sharing, and parcel stewardship | Private-by-default parcel model with policy-gated sharing and clear claim boundaries |
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).
- public_only — derived from public context without fresh local evidence (sensors may be stale or absent).
- 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
Engineering work is organized into six runtime lanes (v0.1 through v1.0), all of which pass 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.
- v1.0 — Extended support objects: house state and capability as inference inputs, intervention event tracking with verification windows, five-factor trust scoring, and contrastive explanations with divergence analysis.
Use Open release and Program for current module-level status.
Architecture boundary
The runtime is organized into five modules: ingest, context, inference, parcel platform, and checks.
oesis-program-specsdefines contracts, architecture, and release/status boundaries.oesis-runtimecontains executable module implementation.oesis-hardwarecontains sensor node specs, build guides, and firmware.
This page stays high-level; use Systems and Open release for module-level links.
What is staged next
The v1.5 bridge stage adds indoor-response and outage-aware support surfaces so the system can link hazard context to building state, actions taken, and measured outcomes — without implying full automation or controls integration.
Freeze-node and weather-PM mast remain geography-gated or staged surfaces unless explicitly marked as current in the published docs.
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 occupant judgment. They do not replace official alerts, emergency authority, or on-scene decisions. Wider sharing remains optional and policy-gated.