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.

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 current reference slice is narrow: one parcel, one bench-air lineage, one parcel context, one ingest path, one inference path, and one parcel view. The next planned step is a two-node indoor and sheltered-outdoor kit built from bench-air plus mast-lite. In parallel, the team is focused on the first field pilot, monitoring, documentation, and partnerships.

  • v0.1 reference path from bench-air ingest to a parcel view
  • Single-structure and small-site parcel awareness with explicit uncertainty
  • Partnerships and docs that make deployment repeatable

Shipping and releases

How we ship

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

Active development spans v0.1 through v0.5: from reference pipeline through trust scoring and governance enforcement. It is not a claim that every future phase is already shipped.

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.

LabelIn plain termsFor implementersVerify
Project siteNarrative 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 labelThe 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 packetThe 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 phasesFormal 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

Program-phase v0.2 next promotion

Target experience vs reference stack today

In program-specs, v0.2 is the next accepted parcel-kit promotion—for example indoor bench-air plus sheltered-outdoor mast-lite, stronger trust and history, and more parcel-operator surfaces—without jumping to the v1.5 measurement-to-intervention bridge or a full route/block engine. The open-release packet also treats several product surfaces as partial or planned relative to that target. These are different pictures of product maturity: current narrow truth, next promotion target, and later bridge work.

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.

Program-phase v0.2 target (next promotion). Illustrative north star for a parcel kit and operator experience: two reference nodes on one parcel and a parcel-facing surface with readiness-style summaries, evidence legibility, history, node health, and basic sharing or export—not a guarantee that every element is live in the reference runtime, and not v1.5 automation, intervention ranking, public parcel-resolution maps, or full governance guarantees. See phasing and Roadmap for how this relates to later work.

Technical diagram: bench-air node to local ingest API, inference API, parcel platform API, and JSON outputs such as parcel state and evidence summary; mast-lite shown as partial or staged.

Reference implementation today. The stressed path is a narrow, verifiable pipeline — local ingest, inference, and parcel APIs — producing contract-shaped JSON (for example parcel state, parcel view, evidence summary). Active development spans v0.1 through v0.5; many consumer-grade surfaces remain partial or docs-only. Start from Open release and the program-specs scope doc for the honest status table.

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

Related pages

Systems and components, the phased roadmap, and governance are split out so this page stays narrative.

Technical lineage

Version arc & capability phases

You are here: useful awareness for one site. Next steps tighten the kit, then add careful sharing between nearby sites, neighborhoods, and eventually larger federated networks—without giving up local control.

The public nine-phase roadmap lives on Roadmap. Below is the engineering-style version path and intermediate capability model for implementers.

  1. Reference pipeline through governance enforcementFive active runtime lanes: reference pipeline, indoor+outdoor sensing, flood coverage, trust scoring, and governance enforcement.Active development

    Bench-air + mast-lite + flood-node, node registry, trust gates, consent/revocation/retention/export enforcement.

  2. Measurement-to-intervention bridgeAdds the minimum bridge from hazard sensing to house-state, action, and measured outcome reasoning.Next build target

    Introduces response and verification support surfaces without implying full automation or mature controls compatibility.

  3. Block intelligenceFirst sparse shared intelligence across nearby parcels.Future direction

    Introduces block-scale derived intelligence without abandoning parcel ownership rules or the parcel-first operating model.

  4. Neighborhood networkNeighborhood coordination becomes a first-class product layer.Future direction

    Extends from block-scale inference to broader neighborhood coordination, richer shared signals, and clearer network behavior.

  5. City federationFederated local systems connect at city scale.Long-range direction

    Connects larger areas without collapsing local control, parcel ownership, or neighborhood-level governance.

TechnicalCapability phases between major releasesExpand

Practical product steps between major releases—from an instrumented parcel to interior response, sparse shared inference, and federated local systems.

Between 1.0 and 1.5

From parcel intelligence to response bridge

The product begins measuring whether actions help by connecting hazard context, house response, and outcome verification.

  1. 1.1
    Evidence quality and confidence layer

    Observed vs inferred parcel state becomes clearer, with stronger confidence framing and reason codes for the parcel view.

  2. 1.2
    Hazard-specific parcel workflows

    Smoke, flood / runoff, and heat move from one generic status model toward clearer parcel workflows and more truthful readiness framing.

  3. 1.6
    Interior response awareness

    The product begins relating outdoor forcing to indoor response and critical-room conditions instead of treating the parcel as exterior-only.

  4. 1.7
    Bounded action and verification loop

    Manual guidance and limited soft integrations are judged by did-it-help verification rather than assumed success.

Between 1.5 and 2.0

From response bridge to sparse local intelligence

Shared awareness begins, but it still grows from parcel-first evidence rather than replacing it.

  1. 2.1
    Sparse shared inference

    A partially instrumented local area can support shared signals without requiring every house to look identical or participate at the same depth.

  2. 2.x
    Route, drainage, and edge dependency modeling

    Parcels are understood in relation to route vulnerability, low points, drainage edges, and other block-level dependencies.

Between 2.0 and 3.0

From block signals to neighborhood coordination

The system matures from local inference into a broader shared layer that can support neighborhood-scale coordination.

  1. 2.5
    Shared neighborhood priors

    Block-scale evidence starts informing parcel priors, neighborhood context, and broader situational framing even where adoption is uneven.

  2. 2.8
    Operational neighborhood layer

    Neighborhood coordination becomes a distinct product concern instead of a loose extension of block intelligence.

Between 3.0 and 4.0

From neighborhood network to city federation

The network scales outward by federation and interoperability rather than by collapsing local control into one central system.

  1. 3.5
    Federated interoperability and governance

    Independent local systems learn how to exchange signals, policies, and coarse status layers while preserving local ownership and governance boundaries.

Top