The Standard · Part 6 of 6 — The instrument layer
Organizations publish what their sensors are, how they keep time, and how they are calibrated — so data from different arrays can be compared honestly, and well-documented instruments earn the trust they deserve.
Everything so far in the standard lives inside one case record. The sensor manifest is different: it is the standard’s first standalone document. An organization that operates detection hardware — a research group, a vendor, an institution — publishes one manifest describing every sensor it runs. Case records then point at manifest entries from their sensor readings, so the full hardware story is written once and cited everywhere.
Community contribution
The sensor manifest was proposed by ELDÆON, the standard’s first external contributor, and promoted into the framework as @disclosureos/instruments. Their published manifest is the worked example below.
schemaVersionstringrequiredVersion of the sensor-manifest schema this instance targets (SemVer).
orgstringrequiredPublishing organization, display form (e.g. "ELDÆON").
orgSlugstringrequiredStable lowercase slug for the publisher (e.g. "eldaeon"); the org half of a `sensorRef`.
orgUrlstringURL for the publishing organization.
generatedAtstringISO date the manifest was generated.
sensorsSensorEntry[]requiredOne sensor: its class, spec, timing, raw-data locator, measurements, and calibration provenance.
futureUpgradesFutureUpgrade[]Planned hardware declared ahead of deployment so data consumers can anticipate new streams. Not part of the live sensor array.
A case record says a radar tracked something. A manifest entry says what that radar is: the kind of instrument, the clock that timestamps its data, the units and error bars of what it measures, where its raw files live, and how — or whether — it is calibrated.
Sensors are organized across 6 modalities: Audio, Electro-Optical, Radio Frequency, Quantum, Environmental, Biometric.
recordsMappingsensorTypedetectionMethodproposedSensorTypeproposedDetectionMethodtimingtimeSourcetimeUncertaintyNsrawDataformatlocatorPatternsampleRateHzbitDepthmeasurementsnameunituncertaintycalibrationstatuscalibratedcurrentMethodtraceableReferencereferenceInUsecadenceuncertaintyBudgetnotesA timestamp is only as good as the clock behind it. Timing error of even a few seconds confounds any attempt to correlate two stations’ data, so the clock source is declared, never assumed.
atomic_clockgps_disciplinedntpsystemunknownMost datasets reduce calibration to a yes/no box. The manifest records it as a maturity gradient instead, and “no calibration is performed” is a valid declared state rather than a blank. Stating where each instrument sits makes calibration comparable across organizations and gives every operator a defined path from one rung to the next.
noneNo calibration is performed. Declared honestly, this is itself useful information.
candidate_identifiedA traceable reference has been named but is not yet part of practice.
in_practiceA real calibration method is performed today, but no full uncertainty budget exists.
documentedThe calibration method and its uncertainty budget are published.
The multipliers on the right are where this feeds back into scoring: a claim backed by an instrument with published calibration provenance earns additional weight in the consensus score. The defaults are deliberately conservative — a sensor without a manifest entry keeps the ×1.00 baseline, and no rung of the gradient ever weighs less than that baseline. Publishing provenance can only add weight.
Everything in this section comes straight from ELDÆON’s published manifest — 28 sensors across 6 modalities, plus 3 declared future upgrades. The page renders the document itself, so as the manifest evolves, this section follows.
Sensors by modality
Calibration status across the array
Most of the array sits mid-gradient, working toward documented calibration, and the manifest states exactly where each instrument stands — which is precisely what the format is designed to capture.
eldaeon:dionysus-infrasonic-mic
eldaeon:dionysus-passive-radar
eldaeon:dionysus-fluxgate-magnetometer
Each organization hosts its own manifest; a small shared registry maps organization slugs to published manifest locations, so a sensorRef like eldaeon:dionysus-passive-radar can always be resolved. Adding your organization is a pull request.
eldaeonView manifestOperate sensors? Publish a manifest and validate it with disclosureos manifest validate.