Implementers
Everything you need to build or evaluate OESIS: sensor hardware specs, software service guides, data contracts, and architecture indexes for the current release. If you want to see how the pieces connect visually, start with the Diagrams page.
New here? Start with the Program overview for an overview of the initiative, or Governance and privacy for ownership, sharing, and data boundaries.
Specification links open the public GitHub program-specs repository in a new tab.
Implementers
Run one slice end to end—bench-air-class hardware through published software contracts—before branching to other modules.
Start from the released indoor / sheltered air node on the hub.
Ingest, inference, and parcel platform contracts linked from the hub.
Architecture flow diagrams before you open implementation-heavy repos.
Honest status table—opens the public repo in a new tab.
Trust boundary
Release packet
Release-scoped public packet and publication boundary for the project site; canonical markdown roots under release/v1.0/.
TL;DR
Open hardware modules cover indoor air, sheltered outdoor reference, optional flood points, and a privacy-minded thermal option. Each has build and firmware docs for makers.
Indoor or sheltered air reference and the quickest way to get real readings through the full stack.
Produces the first repeatable indoor or sheltered parcel evidence and exercises the full ingest-to-parcel-view path.
Why it matters: It is the fastest hardware route from concept to trustworthy parcel evidence.
Relevant diagrams: System context, Recommended first integrated prototype
Sheltered outdoor reference for weather and air at the edge of the parcel.
Adds sheltered outdoor parcel context without waiting for the richer mast build.
Why it matters: It is the simplest outdoor step that turns a single-structure slice into a fuller parcel kit.
Relevant diagrams: Recommended first integrated prototype, Parcel view surface
Optional low-point runoff evidence where parcel context makes it operationally relevant.
Measures low-point runoff evidence while staying explicit that one point is not the whole parcel story.
Why it matters: It adds flood-specific evidence without pretending a single sensor point is parcel-wide truth.
Relevant diagrams: Recommended first integrated prototype, Data-rights and visibility boundary
Second-wave outdoor mast for richer particulate and weather context at parcel edge.
Extends outdoor evidence beyond mast-lite by adding a weather-plus-particulate hardware path with dedicated build and firmware docs.
Why it matters: It is the upgrade path when teams need stronger outdoor PM and weather evidence than the first sheltered-outdoor step.
Relevant diagrams: System context, Parcel view surface
v1.5 bridge hardware for read-side equipment-state evidence from CT-clamp current signals.
Captures HVAC and sump-adjacent equipment state as an explicit evidence stream, including cycle and confidence metadata.
Why it matters: It supports the hazard-to-response bridge by adding measured equipment behavior without implying full controls automation.
Relevant diagrams: System context, Data-rights and visibility boundary
Research-gated derived thermal scene metrics without raw imagery persistence.
Provides area-level thermal context through privacy-safe derived metrics rather than stored frames.
Why it matters: It opens a path to scene sensing while preserving the project’s privacy posture.
Relevant diagrams: Parcel view surface, Data-rights and visibility boundary
TL;DR
Software pieces cover the parcel app, ingestion, inference, and optional neighborhood map outputs—each documented for implementers.
The dwelling-facing app and API surface for parcel status, evidence, and freshness.
Turns parcel-state outputs and evidence summaries into a usable parcel view without hiding uncertainty.
Why it matters: It is the main product surface where parcel awareness becomes usable rather than buried inside pipeline internals.
Relevant diagrams: System context, Parcel view surface
Validates device packets and external feeds, then normalizes them into canonical observations.
Creates the evidence boundary that turns raw packets into the parcel-first information model.
Why it matters: It is the place where raw measurements become consistent, inspectable evidence for the rest of the system.
Relevant diagrams: System context, Recommended first integrated prototype
Combines observations and context into parcel-state outputs with explicit uncertainty.
Turns normalized evidence into parcel-state guidance while keeping reasons, freshness, and confidence visible.
Why it matters: It is where parcel evidence becomes parcel-state guidance without pretending sparse evidence is certainty.
Relevant diagrams: System context, Data-rights and visibility boundary
Optional coarse neighborhood outputs built from policy-gated shared signals.
Creates a neighborhood condition layer that remains downstream of parcel ownership and sharing controls.
Why it matters: It is the part of the stack where network effects become visible without exposing raw parcel data.
Relevant diagrams: System context, Data-rights and visibility boundary
TL;DR
Indexes for architecture, data contracts, and build guides—jump in here if you are implementing against the open release.
How hardware, software, identity, and governance fit together across versions.
Formal definitions for parcels, nodes, observations, and sharing behavior.
Cross-subsystem references for building, procuring, and installing the parcel kit.
Current technical architecture guidance that explains how hardware, software, parcel identity, governance, and future architecture debate fit together.
Canonical parcel, node, observation, and sharing definitions for the released system surface.
BOMs, procurement checklists, installation guidance, and node-specific build references for the current released kit.
