Replay synthetic telemetry. Explain every alert.

1 · Open the contract

Start with observation.schema.json and one line of fixtures/telemetry.ndjson. Each record declares schema version, synthetic status, device, boot, sequence, UTC observation time, demo metric, unit and value. The runtime enforces this contract directly; the companion JSON Schema is documentation.

Checkpoint: Explain why a plausible number with the wrong unit must still be rejected.

2 · Run the tests

Extract the ZIP and open a terminal in the extracted folder. With Node.js available, run the command below. This uses the built-in test runner and needs no npm install.

node --test test/pipeline.test.mjs

Observed: 29 tests passed, none failed or skipped, on 20 October 2026. Passing these tests establishes the stated offline behavior; it is not a production-readiness certification.

3 · Replay the fixed fixture

Use the command below with the supplied fixture and explicit clock. The clock is part of the experiment: replacing it with today’s time changes freshness. The CLI prints JSON to the terminal and creates no server or output file itself.

node run.mjs fixtures/telemetry.ndjson --as-of 2026-10-20T09:00:45.000Z

Observed: 16 input lines: 7 accepted, 8 rejected and 1 duplicate. One accepted observation is stale. Four demo state-transition events are emitted.

4 · Trace a rejected or stale record

Read the line-number audit in expected-report.json. Wrong units, malformed JSON, future observations and backward time do not overwrite accepted state. An identical accepted identity is a duplicate; a changed payload under that identity is a conflict. A rejected record does not reserve a sequence identity.

Checkpoint: Trace the stale high fan value to an accepted-stale record and explain why it emits no fresh exception.

5 · Change one rule or observation

Change a copy of the fixture, predict the resulting counts and replay it with the same clock. Fresh demo values above 50 enter review, 45 or below clear it, and values between hold the previous state. More than 60 seconds old is stale. These are arbitrary teaching values, unrelated to a real machine or sensor specification.

Checkpoint: Explain why an in-between value does not repeatedly emit a new alert, and test the exact freshness boundary.

6 · State the deployment gaps

Write down what a live system would add: approved source/session identity, trusted time, real measurement validation, durable storage, restart recovery, authenticated transport, review routing and accountable response. This project supports one demonstration boot; it does not solve session rotation or distributed delivery.

Checkpoint: Keep observed software results separate from untested sensor accuracy, broker/network behavior, notification delivery, operator response and financial outcomes.