Diagrams

How the pieces fit together.

TL;DR

Visual overview of how sensors, software, and sharing rules connect. Open each gallery card for metadata, spec links, and the rendered diagram.

These diagrams show the system architecture, product surface, and privacy boundaries at a high level.

Overview of diagram categories: parcel view, governance lanes, and release path. — Diagram categories on this site. Open each gallery card for the full diagram and spec cross-links.

The diagrams below show how the system fits together at a high level. The most important ones illustrate:

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

The value of local sensing is not just "more data" — it is whether local evidence 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 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"]

Builder tech inventory (released and staged)

Lists the hardware families builders will encounter, separated into current first-path parcel kit versus staged bridge and R&D modules.

Takeaway: The project is modular: not every documented hardware family is part of the first integrated parcel kit path.

Technical: metadata, links, and diagram sourceExpand

Audience: Builders and integrators
Version relevance: v0.1 through v1.5 bridge staging
Purpose: Make hardware coverage explicit without implying equal deployment maturity.

Related released specs

flowchart TB
    subgraph currentPath["Current first-path parcel kit"]
      BA["Bench-Air Node\n(released path)"]
      ML["Mast-Lite\n(next outdoor step)"]
      FN["Flood Node\n(optional low-point)"]
    end

    subgraph stagedPath["Staged bridge and R&D modules"]
      WPM["Weather + PM Mast\n(second-wave outdoor)"]
      CM["Circuit Monitor\n(v1.5 bridge)"]
      TP["Thermal Pod\n(research / privacy-gated)"]
    end

    currentPath --> ING["Single ingest path"]
    stagedPath --> ING
    ING --> INF["Inference and parcel-state"]
    INF --> PV["Parcel view + policy-gated sharing"]

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)"]

How the pieces fit together.

Diagram gallery

System context

Recommended first integrated prototype

Builder tech inventory (released and staged)

Data-rights and visibility boundary

Parcel view surface

Read next