Build from the showcase

The Meridian showcase is an application over a fixed, entirely fictional case. Its instrument values, accounts, editions, laboratory results and assessments come from the downloadable example bundle.

The original record renderer uses an application view derived from standard documents. That view is not an additional DisclosureOS contract. You can use the same documents in a different interface. The expanded mixed workspace adds separately authored recordings with their own standard acquisition, measurement and source-selection documents.

Explore the mixed recordings

The default workspace has four panels: a visible clip, a numerical thermal field, an RF waterfall and weather from two meters. All five instruments are fictional. Focus a panel, move the shared playhead, select a thermal pixel or radio bin, and open its source inspector. Each source retains its own cadence. Thermal and RF samples occur every two seconds; weather every ten seconds. The display holds the most recent sample and reports its sample time. Visible video has twelve frames per second.

The recording manifest declares source hashes, byte lengths, array layout, units, models and limitations. Thermal values come from little-endian float32 arrays, never from image colors. The RF array contains power per bin, not spectral density. Environmental CSV rows retain both meter identities. The visible clip is synthetic, lossy H.264 imagery with a separate frame/time/pointing table.

The viewer verifies numerical source bytes against the manifest before displaying them. It loads one 192 KB thermal chunk at a time. Inspect a pixel to obtain its zero-based frame, row, column and byte offset; inspect a radio bin for its frequency edges and exact array offset. The selected-pixel trace covers the current twenty-second chunk. Video inspection identifies the requested frame interval; use a decoder for exact frame extraction rather than treating browser playback as a scientific decoder guarantee.

The bundle includes recordings-v1/build.mjs, its scenario input and a source guide. Regenerate these sources with node build.mjs --write from that directory, using Node 22 and ffmpeg with libx264. Numerical outputs are deterministic; encoded MP4 bytes may vary across ffmpeg builds, so the manifest records the encoder version and arguments.

Validation scope: the eight-check receipt below covers the original record packet and scalar readings. The mixed recordings now have a separate canonical record packet and source-selection evaluation, described below. The historical recording manifest retains its original wording and bytes. The original artifacts retain their original bytes. No scientific calibration, thermal/visible registration or common physical cause is established by this simulation.

Source-selection contract

The mixed record packet uses the standard's observation, acquisition-context, acquisition-bindings, measurement-bindings and new product-source-selection 0.1.0 contracts. Five instruments connect to sixteen raw logical products and one derived viewing video. All 120 weather values have canonical measurements and capture-time bindings.

The source-selection document describes array encoding, axes, byte order, CSV row partitions and exact rational frame timing. Select layout:thermal-04 with array_element indices [5,20,33] to read the pixel at 90 seconds: byte offset 102532, value 23.93558120727539 Cel. Select layout:spectrum with indices [45,64] for the RF bin at the same time. These are canonical selectors, rather than viewer-specific addressing conventions.

Both environmental meters share one CSV file. Each has a separate product layout with an exact instrument partition. Selecting the wrong meter's row fails the profile. The video remains a derived product with generator, scenario and frame-table inputs; it is not relabeled as raw sensor imagery.

The mixed verification receipt checks 366 source selections: all weather measurements, a thermal pixel and RF bin across every sample, and first/middle/final video and metadata frames. Its source-selection checks pass. Full acquisition and measurement profiles remain incomplete because physical calibration and measured clock uncertainty are absent. No zero uncertainty is invented to obtain a pass. A video check validates bytes and the declared frame interval; media decoding remains not_checked.

The viewer consumes a projection of these canonical layouts and a byte-for-byte copy of the standard's dependency-free reader. index.json only maps product references to local filenames. Panel layout, colors and the held-sample playback policy stay in the application. The download includes the reader, JSON Schema, documents and verifier. This source-candidate addition is not yet on npm; use the exact canonical commit in the packet README and run:

node /path/to/meridian/recording-bindings-v1/verify.mjs /path/to/disclosureos

This first profile supports contiguous numerical arrays, UTF-8 CSV records and constant-rate video declarations. Compressed scientific containers, variable-frame-rate video, strides and custom missing-value encodings require later profiles.

Run the viewer

The bundle includes a standalone Next.js app in viewer/, with the actual showcase components, adapter and shared plot dependencies under the MIT license. No access to the portal repository is required. Using Node 22, run:

cd meridian/viewer
npm install
npm run dev

Open the local viewer. Source downloads are served locally; Standard, Docs and partner links lead to the public portal. The small app shell uses system fonts. To produce a production build, run npm run build, then npm start.

Rendering the included fixed example does not require unpublished DisclosureOS packages. The next section reproduces its standard validation independently.

Run the example

Unzip the bundle. Use Node 22 and the exact source commit below. This example includes material and laboratory contracts newer than npm 2.0.0-beta.3; installing that npm beta alone will not reproduce the full example.

git clone https://github.com/disclosurefoundation/disclosureos.git
cd disclosureos
git checkout c894a086e8326f048ba1806e7ba9d07556f16489
corepack pnpm install --frozen-lockfile
corepack pnpm build
cd ..
node /path/to/meridian/verify.mjs /path/to/disclosureos

The verifier reads the downloaded files, checks them against the authored fixture, runs eight V2 checks, and compares CSV timestamps, units and values to their measurements. A missing, altered or truncated source file fails verification. The included validation.json records the expected outcomes.

Follow a reading

1. Open Instruments, choose Original scalar readings, select Optical elevation, and move the cursor to 21:01:30 UTC.
2. Select the displayed 39.92° reading. Its source is optical.csv, row 11 including the header.
3. The same value appears as optical-9 in observation.json. Its unit is deg and its declared standard uncertainty is 0.2 deg.
4. measurements.json connects it to the optical channel and UTC timestamp. bindings.json connects the data product to an acquisition described in acquisition.json.

The view shows actual samples at ten-second intervals. Lines join them without smoothing. The three channel scales are independent, and a common timestamp does not establish a common physical source. Calibration declarations are fictional and unreviewed.

Trace the other relationships

The research claim history and instrument evaluator use distinct history contracts. instrument-history.json is an explicit, empty history for the instrument checks; both histories reference the same observation snapshot. It does not discard or convert the research assessments.

The field report text uses form-feed characters to delimit pages. Review citations bind to an exact edition, artifact digest and page. Laboratory results bind to portion A; the viewer must not transfer those results to the retained portion B.

How the viewer is built

The download includes fixture.mjs, which authors the example data, and project.mjs, which derives the application view after verification. The viewer/ folder contains the renderer source, so its implementation is available independently of the portal's internal repository.

• viewer/src/lib/showcase/meridian.generated.json supplies the visible data. view.json is the same projection outside the app.
• viewer/src/lib/showcase/model.ts adapts the three channels to the shared mission viewer's stream model and validates URL selection state.
• viewer/src/components/showcase/ renders the case and source inspector. The instrument plots are included in viewer/src/mission/; they are the same implementation used by the portal.
• viewer/scripts/prepare.mjs makes the bundle's adjacent source files available for download from the local app.
• recordings-v1/ supplies the new mixed sources. mixed-instruments.tsx, recording-data.ts, recording-hooks.ts and recording-plot.tsx use canonical source layouts and the shared reference reader. recording-bindings-v1/ supplies the new standard documents and their own verification receipt.

To change the example, edit fixture.mjs or project.mjs, then run this from the unzipped meridian/ folder after building the pinned canonical checkout:

node regenerate.mjs /path/to/disclosureos

The script validates the authored inputs, rewrites the source files and standard documents, and updates the viewer data. Restart the viewer to refresh its source downloads. Keep normative records as the source of displayed values. Adapt the projection for your own use case; do not maintain a second, disconnected set of readings in the UI.

What this demonstrates

Meridian connects instrument measurements, reported context, accounts, editions, material lineage, laboratory results and assessment history. It is a worked application of selected capabilities, not coverage of every optional field or contract.

Structural and reference checks establish consistency within this authored example. They do not establish scientific validity, source authenticity, witness independence or a relationship between the sample and the recorded light. External checks that did not run remain not_checked in the receipt.

The fixture contains only authored public example data. The renderer is not a general intake, redaction or publication service. For real material, follow the contribution workflow and preserve the publication decisions alongside the sources.

Data and fictional text are CC0-1.0. Example code follows the repository MIT license.

Spatial context

The Sky & surroundings workspace uses the additive spatial packet. Canonical observation, acquisition bindings and product-source selections connect four source instruments/references and three derived products. The selection document addresses every pointing, track, station and clock row plus the first and final all-sky frame. Validation passes 1,511 selections while physical acquisition profiles remain incomplete.

The 640×640 all-sky clip runs at six frames per second. Its pointing table and clip are derived products of the retained optical frame metadata, not independent observations. Its ideal equidistant projection shares the authored optical light trajectory; the lens model declares synthetic bearing and field-of-view assumptions. Neither image gives a distance.

Aircraft reports retain an independent relative clock and Cartesian frame. The source message IDs survive normalization to CSV; the 100–120-second gap is never interpolated. No geographical transform or alignment to the field clock is supplied, so the viewer has a separate aircraft scrubber and does not overlay the track on the sky. The association review explains this boundary. These are fictional normalized reports, not a native ADS-B decoder.

Station positions retain the sourcebook's local frame: North (0,0,0), South (80,-120,0) metres. No GNSS fix is claimed. The timing review distinguishes the clock-offset model from unknown physical uncertainty; it applies no correction.

Shared links preserve workspace=spatial, spatialPanel, cursor, aircraftSecond, skyAz and skyEl. The same workspace and source packet ship in the downloadable viewer.

Field signals

The Field signals workspace adds pressure waveform and acoustic spectrum, magnetic components and derived magnitude, and passive-radar map inspection. It uses the same source-selection contract and reader as the other workspaces.

• Source guide
• Generation and processing methods
• Observation and derivations
• Acquisition context
• Measurement bindings
• Source selections
• Validation receipt

The acoustic periodogram is calculated from the retained pressure samples using 800-sample periodic Hann windows at 100 Hz with a 400-sample hop. Exact inspected values remain in Pa²/Hz; the heatmap applies a logarithmic display scale. Magnetic magnitude is derived from the three retained components. Every magnetic component has its own canonical measurement and capture-time binding.

Radar maps are authored in Doppler Hz and bistatic excess path length km. No transmitter/receiver geometry, range/speed conversion or geographic track is inferred. Map maxima use a declared selection rule, not a probabilistic detector. The bounded IQ reference has an independent relative clock and is not an input to these maps. This example supplies synthetic float32 products, not a decoder for a provider's NDJSON, compressed or SDR formats.

Shared URLs retain workspace=signals, cursor, signalPanel, acousticBin, magneticAxis, delayBin, dopplerBin and the independent iqSample. The field cursor can select the final 100 Hz pressure sample at 239.99 seconds. Source selection validates exact bytes and values; incomplete physical calibration and clock characterization remain explicit in the acquisition checks.