Ledger, sync, offline and hardware requirements
Analog timing layer
Least mature component.
How to read status labels: In the pilot (v0.2.0, synthetic data) Simulated in the pilot Coming (Wave 2, rolling out) Designed, not yet built Open decision Not offered / no claim made Planned partner integration
C0970Is the analog timing layer part of the pilot?
No. The specification describes it, but the pilot does not include it. REQ-3501 says the analog timing layer, if built, must be a separate optional module confined to one shielded room or booth with dual-key refreshing codes, delay paths and a home node. Its acceptance check: module can be absent without affecting other requirements.
C0971How are out-of-schedule signals from the analog layer handled?
REQ-3502 is a lower-priority requirement for the large tier only: out-of-schedule signals must be flagged to all nodes. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says injected out-of-schedule signal produces ALERT token.
C0972Would the analog layer ever be the only lock?
The analog timing layer part of the specification (REQ-3503) says the layer must never be the only lock, must tolerate clock drift with configured windows, must provide emergency break-glass, and must use redundant home nodes. Designed, not built: there is no code for this in the pilot. Acceptance check: home node failure leaves care and non-analog approvals functional.
C0973How well does the analog layer work?
How would it be tested? The specification says doc contains (still an open decision) markers; no claim. That is the check for REQ-3504: construction, refresh interval and delay values are (still an open decision); hardware is untested and no security claim must be made about it. This is on the design side of the line. Nothing in v0.2.0 does it. Parts of it are explicitly marked as open in the specification.