Initiative

Program

OESIS is an open program for parcel-first environmental sensing and inference. It combines modular hardware, explicit uncertainty, and governance that keeps parcel operators in control of parcel-linked data unless they choose to share it. Long-term direction includes preparedness, disaster relief, and climate- and infrastructure-resilience intelligence. For version labels and release scope, see How we ship and the open release packet. For a plain-language overview, start with Why it matters and How it works. This page focuses on scope, shipping labels, and technical lineage.

Why it matters How it works

Program scope

Open Environmental Sensing and Inference System (OESIS) is a parcel-first environmental sensing and inference program. It combines sensing, parcel inference, governance, neighborhood intelligence, and pilot deployment while keeping parcel-linked data private by default. Long term, it aims to support predictive software for local climate-related conditions and hazards using local observations, parcel context, public data, and optional neighborhood evidence. The parcel remains the anchor for decisions as the program grows. Outputs are meant to complement official alerts and emergency authorities, not replace them.

Modular hardware and software that scale from one parcel to networks
Explicit governance: private by default, shared by choice
Long-term path from field pilots to broader shared intelligence

Current build scope

The runtime covers indoor, outdoor, and flood sensing at one parcel, with multi-node evidence composition, trust scoring, and governance enforcement. All acceptance tests pass through v1.0. The next focus is field pilot deployment, hardware verification, and product surfaces.

v0.1–v1.0 acceptance-gated: six runtime lanes with structural and value-level tests
Trust-scored parcel state with five-factor quality model
Governance enforcement: consent, revocation, retention, and export at API level

Shipping and releases

How we ship

This website explains the project, the current scope, and where to verify deeper details.

Active engineering lanes span v0.1 through v0.5: from reference pipeline through trust scoring and governance enforcement. Packet status is tracked separately and may still be partial or deferred for some lanes.

Implementers should treat the open release packet and linked contracts as the canonical publication boundary.

Formal phase and version language lives in program-specs. The website uses simpler labels first, then points to the canonical docs.

The program is intentionally staged: narrow slices now, broader capabilities later, with pilots and field learning in between.

Label	In plain terms	For implementers	Verify
Project site	Narrative pages that explain the project and point to deeper docs.	Use for orientation, then verify schemas, guides, and runtime boundaries in the canonical repos.	Open release
Home snapshot label	The small card on the home page names the product slice we are emphasizing right now.	It aligns with the current pilot-facing slice and its published contracts, not the entire long-term roadmap at once.	—
Public release packet	The first published open-release boundary: what is licensed, reviewed, and ready to cite.	Start from the v1.0 summary and publication matrix, then follow links into contracts, software, and hardware guides.	Open source v1 summary (repo)
Version arc and phases	Formal slices and capability stages describe how the product grows over time.	See Program for the version model and Roadmap for the public phase narrative.	Roadmap

Next milestone

Where the product is headed vs where it is today

v0.1 through v1.0 are complete — six acceptance-gated runtime lanes covering indoor, outdoor, and flood sensing with trust scoring, governance enforcement, and extended support objects. The next build target is v1.5: bridging from measurement to intervention by adding indoor-response and outage-aware support surfaces.

Concept mockup: one parcel with bench-air indoor node and mast-lite outdoor reference, beside a parcel-view web UI with readiness cards, evidence, history, nodes, and sharing or export.

v1.5 target. The system links hazard context to building state, actions taken, and measured outcomes — connecting the pipeline to real indoor-response verification. This is an illustrative target — not everything shown is live yet. See Roadmap for phasing.

Technical diagram: bench-air node to local ingest API, inference API, parcel platform API, and JSON outputs such as parcel state and evidence summary.

Implementation today (v1.0). Six runtime lanes pass acceptance tests: sensor data flows through ingest, inference, and parcel APIs, producing structured outputs with trust scoring, governance enforcement, and contrastive explanations. See Open release for the full implementation status.

Why this structure

Parcel-first, local, community-aligned

Parcel-first, not only regional

Forecasts and regional indices miss site-specific risk. Parcel-first systems anchor decisions to what your site actually experiences.

Local & community-controlled

Networks can grow from real places and real stewardship instead of only top-down dashboards—still bounded by opt-in sharing and clear policies.

Modular and incremental

Small nodes and clear contracts let pilots start narrow and expand without rewriting the ownership model.

Explore

For the full phased roadmap, systems overview, and governance policies, see the dedicated pages.

Roadmap Systems Governance