DisclosureOS documentation · v2 Beta
Instruments overview
Describe how data was captured, then connect a measured value to its source.
The Instruments area covers equipment, recording sessions and the links from an observation to captured data. Your application retains the original files. The standard describes those files and the conditions under which they were produced.
Start with one capture
Choose one instrument, the configuration it used and one recording. Describe them in an acquisition context: a document that identifies equipment, channels, capture times, calibration declarations and output files.
You can describe several instruments in the same context. Start small so you can check identifiers, units and timing before adding more channels.
Describe equipment and a capture →
Need the record itself? Start with the Observation guide.
Connect a reading to its capture
An observation stores the measured value and its source history. Acquisition context describes how the source data was collected. Bindings connect the two using explicit identifiers. They do not rely on matching filenames or labels in a chart.
Its quantity, unit, source product and processing history.
The source instrument, captured product, channel and measurement time.
Equipment, configuration, timing, calibration and output files.
There are two binding documents. Acquisition bindings connect the observation's instrument source and raw product to the equipment and captured product. Measurement bindings connect a measured value to that product, one captured channel and an explicit time. The current measurement check supports one instrument raw product and one channel per measurement; showing several sensors together does not validate a fused measurement.
Assemble the links
Read the mapping rules, timing requirements and limits before connecting measurements in your application.
Run a complete example
Download a synthetic measurement, its four JSON documents and three source artifacts. Run the checks with matching, missing and altered bytes.
The Field reference under Equipment and captures covers all three documents: acquisition context, acquisition bindings and measurement bindings. Use it for exact fields and constraints. The runnable example also appears under Build & contribute because it brings Records, Instruments and the shared evaluator together.
Choose a sensor profile when needed
A sensor profile adds declarations for a particular kind of source data, such as radar returns or a satellite raster. Use one when you need its specific relationships and checks. You do not need a dedicated profile to describe an instrument and its captures.
These profiles combine an observation, acquisition context and source selection with sensor-specific declarations. They do not require the scalar measurement-binding example first. Choose the profile that matches your source data; the five guides are alternatives, not a sequence you must complete.
All five profiles are published in Beta 4. Each guide shows the package API, a complete synthetic example and optional source-reproduction steps.
| Profile | What it describes |
|---|---|
| Radar | Scan or dwell timing, returns, detection decisions and track estimates. Scenarios include moving platforms and cooperative replies. |
| Active sonar | Transmitted pings, echo samples, receive availability and the assumption used to convert delay to distance. |
| Passive sonar | Pressure samples and the input windows used to calculate spectra, including unavailable samples. |
| Lidar point clouds | A pulse register, spatial returns, coordinate frames and retained no-return or unavailable states. |
| Satellite rasters | Spectral bands, quality flags, scaling and grid coordinates tied to retained raster cells. |
The viewer supports more recording families than this list of profiles. Cameras, scalar readings, waveforms and other examples may use the shared acquisition documents and format readers. A visualization does not imply a dedicated sensor profile or support for every native file format. Check renderers and format support for those boundaries.
Understand what a check establishes
The result depends on the API you run. Keep its individual check statuses alongside success.
| Check | What a passing result establishes |
|---|---|
| Parse an acquisition context | The document has the expected structure and its local references resolve. Source files and physical calibration remain unchecked. |
| Evaluate measurement bindings | The declared observation, capture, channel and time agree. The profile also requires matching artifact bytes. It does not inspect their numerical content or recalculate the measured value. |
| Evaluate a sensor profile | The supplied source files, layouts and relationships satisfy that profile's rules. Some profiles also reproduce a calculation, such as the passive sonar spectrum. Read the guide's result stages and limits. |
Missing files have different result statuses. In the measurement-binding example, missing required bytes leave profile: not_checked. In the five sensor-profile examples, a missing required source fails the sources stage and prevents later content checks. Both return success: false. Do not convert either result into a negative observation or an empty measurement.
The evaluators use files supplied by your application; they do not fetch remote URLs. A successful check does not authenticate a sensor, approve its calibration or establish a physical explanation. Keep those review outcomes separate from capture declarations and numerical checks.
Availability and next steps
The acquisition context, two binding contracts and sensor profiles are all available in 2.0.0-beta.4. Use that exact package version; document and profile versions remain separate. See installation and release details.
For an interactive introduction, visit the Instruments standard page. To inspect the example case's connected recordings, open its research desk.