Skip to main content

Sensor Intake

Sensor Intake is the platform's eyes and ears: the governed path a raw sensor reading takes to become a typed, classified, provenance-bearing observation. Its distinguishing property is that governance travels with the capture, the provenance and the classification are attached where the sensor lives, not asserted afterwards in a central pipeline.

What is reachable​

Signed capture bundles​

A sensor reading is packaged as a signed capture bundle with a tamper-evident capture hash chain, so a capture cannot be silently altered between the sensor and the store. On the device itself, the edge agent carries the sensing stack rather than shipping raw feeds home:

  • On-board host drivers, hardware monitors, industrial I/O, satellite positioning.
  • Hardware drivers for audio and video capture (V4L2 / ALSA. See the capture-backend boundary in the ceiling above).
  • On-edge speech-to-text, so audio becomes text at the sensor.
  • Capture-provenance verification, every capture is authenticated against its signing certificate at ingest.

The enrollment and lifecycle plane​

Around the captures sits the plane that governs the sensors themselves:

  • Sensor enrollment and lifecycle, bringing a sensor into the estate as a governed thing with an identity.
  • Clock synchronization across sensors, without a shared clock, multi-sensor fusion is guesswork; this makes cross-sensor timing trustworthy.
  • A cognition policy, governing what may be inferred from a given sensor, which is a stronger and different control than governing who may read it. It is the difference between "who can see this feed" and "what conclusions the platform is permitted to draw from it."

On the core side: REST, webhook and database connectors, an ingest gate, perception model packs, and time-difference-of-arrival aperture synthesis across distributed receivers.

Afferent fusion: many sensors into one provenanced observation​

The end state this plane builds toward is afferent fusion: many sensor readings resolved into a single provenanced observation that the executive engine can reason over, the afferent (sensory) front of the sense→decide→act loop. The fusion and signing machinery is built and parity-pinned across the core and the edge, so the same fused, signed observation is produced on either runtime.

Fusion activates on a sensor and model binding

The fusion machinery is built; it activates when live sensors and a model-serving embedder are bound to it, a planned hardware / model boundary, not a shipping feed. Until that binding, the executive engine decides on the inputs it already has (an entity's trajectory and its enclosing scope) and degrades the absent fusion signal to an honest neutral rather than inventing one. Describe fusion as built and parity-pinned, awaiting activation, not as a live sensor feed.

The perception funnel: decode, extract, classify, route​

Every arriving capture passes through a four-stage funnel that turns bytes into a governed, typed observation, carrying its provenance and classification at each hop:

  • Decode: parse the arriving format into structured content.
  • Extract, pull out entities, coordinates, feature vectors, and other typed fields.
  • Classify, assign a content type and, critically, a sensitivity (for example PII/PHI or a protected classification).
  • Route, send each observation to the right store by its classification: sensitive content to the sensitive store, embeddings to the vector store, anomalies to the anomaly store, and failures to a dead-letter path.

The funnel, hop by hop​

*Figure: Sensor Intake, from a signed capture to a governed store. A capture is verified at ingest, then flows through decode → extract → classify → route, carrying its provenance and classification the whole way.

Table equivalent

StageStateReachable?What it does
Signed capture bundleverifiedYesSensor reading packaged with a tamper-evident capture hash chain
Capture-provenance verificationverifiedYesAuthenticates each capture against its signing certificate at ingest
Decodefunnel hopYesParses the arriving format into structured content
Extractfunnel hopYesPulls out entities, coordinates and feature vectors
Classifyfunnel hopYesAssigns content type and sensitivity (e.g. PII/PHI, protected classification)
Routefunnel hopYesSends each observation to the store its classification requires
Governed store + recordverifiedYesThe typed observation lands governed, on the tamper-evident chain
Content signing of outboundbuilt, held apartNoImplemented but does not execute in production, so it is not claimed

Why the pairing matters​

The eyes and ears are at the edge; the governance travels with what they capture; and the inference policy is enforced where the sensor lives. That combination, capture provenance verified at ingest, classification stamped in the funnel, and a cognition policy over what may be inferred, is what separates a governed observation system from an IoT ingest pipeline. Sensor Intake feeds the Surveillance sensor-to-decision chain, and lands its output as governed data like any other.

Across the deployment matrix​

The sensing stack runs on the edge agent on the device itself, so it holds in the sovereign, air-gapped corner by construction: captures are bundled, hashed and verified locally, and only governed observations move. It works single-cell and, where cells can reach each other, multi-cell, but a disconnected device still produces verifiable, classified captures with no coordinator to reach.