Overview

@disclosureos/instruments answers the sixth question the standard asks: what hardware produced the data?

It defines the Sensor Manifest — the standard's first standalone document type besides Observation. An organization that operates detection hardware publishes one manifest cataloging every sensor it runs: modality, timing provenance, measurement units and uncertainty, raw-data locators, and calibration status. Case records cite manifest entries from their sensor readings via SensorReading.sensorRef ("<org-slug>:<sensor-id>").

npm install @disclosureos/instruments

A standalone document, not an extension slot

Unlike observables and origins, this package does not add a slot to Observation. A manifest is published once per organization and cited from many records:

import { createSensorEntry, createSensorManifest, validateSensorManifest } from '@disclosureos/instruments';
import { createSensorReading } from '@disclosureos/records/factories';
import { sensorRef } from '@disclosureos/records/shared';

const spy1 = createSensorEntry('princeton-spy1', 'AN/SPY-1B Passive Phased Array Radar', 'radio_frequency', {
  timing: { timeSource: 'gps_disciplined' },
  calibration: { status: 'documented', currentMethod: 'Navy maintenance and alignment program', referenceInUse: true },
});
const manifest = createSensorManifest('US Navy', 'us-navy', [spy1]);
validateSensorManifest(manifest); // [] — no issues

// In a record, the reading points at the entry:
const radar = createSensorReading('shipborne_radar', 'radar_phased_array', {
  id: 'princeton-spy1-radar',
  sensorRef: sensorRef(manifest.orgSlug, spy1.id), // "us-navy:princeton-spy1"
});

What each sensor declares

Design commitments

• Honest nulls are first-class. Declaring "no calibration" or "uncertainty not yet characterized" is itself information a data consumer needs. Gaps stay visible and comparable across operators.
• Spec-level disclosure, not sourcing-level. Publishers may withhold specific make/model identities and publish class descriptors instead ("dual GM-tube counter" rather than a product name).
• Proposed vocabulary is flagged, not smuggled. A recordsMapping value outside the records enums must carry a proposedSensorType / proposedDetectionMethod flag — the validator enforces it.
• Metadata-first. rawData.format and locatorPattern let manifests circulate widely while raw data is pulled on demand.

Validate from the CLI

disclosureos manifest validate ./my-org-sensors.json

Checks manifest structure, unique kebab-case sensor ids, and that every records-enum mapping either exists in the enums or carries its proposed flag.

Provenance

The Sensor Manifest was proposed by ELDÆON, the standard's first external contributor, and promoted into the framework as this package. Their manifest is the worked example in the repository, alongside the community registry of published manifests.