Diagrams

Public-safe diagrams for the project site.

TL;DR

Picture how sensors, software, and sharing rules connect—without digging into implementation secrets. Open the full article for wording aimed at reviewers; open each gallery card for metadata, spec links, and the live diagram.

These diagrams explain the system, the product surface, and the privacy boundary without exposing implementation-enabling detail.

New here? Start with the Program overview—scope, governance links, and how current work relates to longer-term direction.

Governance and privacy summarizes ownership, sharing, and claims boundaries.

Public-safe overview of the diagram categories on this site: parcel view, governance lanes, and release path. Not a complete live architecture map. — This hub image is intentionally modest: it shows the kinds of diagrams available here, not a claim that the full system stack is already live end to end. Open each gallery card for the live diagram and spec cross-links.

The diagrams below stay public-safe and high level. They are meant to explain how the system fits together, not to disclose implementation-enabling detail.

In this phase, the most important diagrams are the ones that show:

parcel metadata as a prior layer, not just admin context
local observations compared against public baseline context
a parcel result alongside the public-only foil result

That framing makes the diagrams more honest: the value of local sensing is not just "more data," but whether it changes what a parcel-specific conclusion should be.

TL;DR

Diagram gallery

Each card summarizes the idea in plain language. Expand for reviewer metadata, spec links, and the rendered diagram.

System context

Shows how parcel nodes, public context, parcel context, inference, parcel views, and policy-gated shared outputs fit together.

Takeaway: The parcel view is primary; shared outputs are downstream and policy-gated.

Technical: metadata, links, and diagram sourceExpand

Audience: Public overview
Version relevance: v0.1 through later networked versions
Purpose: Explain the full system shape without exposing implementation detail.

Related released specs

flowchart LR
    A["Purpose-built parcel nodes"] --> B["Ingest and normalization"]
    P["Public context"] --> B
    C["Parcel context and node registry"] --> D["Parcel inference"]
    B --> D
    D --> E["Parcel operator parcel view"]
    D --> F["Policy-gated shared map"]
    D --> G["Exports, rights, and governance flows"]

Recommended first integrated prototype

Explains the current public-safe recommended parcel prototype and how modular nodes converge into one parcel experience.

Takeaway: The first useful release already behaves like one coherent parcel system, not a collection of disconnected devices.

Technical: metadata, links, and diagram sourceExpand

Audience: Current release framing
Version relevance: Program-phase v0.1 now, v0.2 next
Purpose: Show what the first integrated release looks like in practice.

Related released specs

flowchart TB
    subgraph oneParcel["One parcel"]
        A["Bench-Air Node\nindoor reference"]
        B["Mast-Lite\nsheltered outdoor reference"]
        C["Flood Node\noptional low-point module"]
    end

    R["Parcel identity\nnode registry\nsharing settings"] --> I["Single ingest path"]
    A --> I
    B --> I
    C --> I
    P["Public weather and smoke context"] --> E["Single inference engine"]
    I --> E
    R --> E
    E --> V["Single dwelling parcel view"]
    E --> S["Optional shared-map aggregation"]

Data-rights and visibility boundary

Shows how private parcel data, user-selected sharing, and public context remain distinct lanes in the system.

Takeaway: Open release does not erase privacy boundaries or turn real parcel-linked data into open data.

Technical: metadata, links, and diagram sourceExpand

Audience: Governance and privacy
Version relevance: All versions
Purpose: Explain ownership and visibility rules visually.

Related released specs

flowchart TB
    A["Private parcel data"] --> B["Parcel platform"]
    C["User-selected shared contributions"] --> D["Shared neighborhood signals"]
    E["Public external data"] --> F["Public context lane"]

    B --> G["Parcel operator controls\nconsent\nrights requests"]
    D --> H["Coarse shared-map outputs"]
    F --> B
    D --> B

    X["No public parcel-resolution map\nfor real contributed data"]

Parcel view surface

Anchors the public parcel experience around a single parcel view rather than around separate device dashboards.

Takeaway: The dwelling-facing unit is the parcel, not the device dashboard.

Technical: metadata, links, and diagram sourceExpand

Audience: Parcel UX overview
Version relevance: v0.1 and later
Purpose: Show how the parcel view stays the primary surface for status and evidence.

Related released specs

flowchart TB
    A["Parcel home screen"] --> B["Readiness cards"]
    A --> C["Event timeline"]
    A --> D["Evidence view"]
    A --> E["Node health and freshness"]
    A --> F["Sharing and rights controls"]

    B --> B1["smoke (sensor-backed)"]
    B --> B2["heat (sensor-backed)"]
    B --> B3["flood (sensor-backed)"]
    B --> B4["shelter (derived)"]
    B --> B5["asset risk (derived)"]
    B --> B6["reentry (derived)"]

Public-safe diagrams for the project site.

Diagram gallery

System context

Recommended first integrated prototype

Data-rights and visibility boundary

Parcel view surface

Read next