Node-Scoped Gaps and Deferred Decisions

This section identifies architectural decisions that are specific to the antenna node and currently proposed but not yet formally decided.

---

1. Schema Validation Strictness Policy (N-ADR-001)

Problem: The node receives frame definitions and payload schemas via API. How strict should validation be?

Issues:

• Should the node reject out-of-range field offsets (overlapping fields)?
• What if a field_schema declares more bytes than the max_payload_bytes?
• Should the node validate that all payload bits are covered by field definitions?

Deferred decision:

• Strict validation: reject problematic schemas at POST time?
• Lenient validation: accept all, log warnings, skip undecodable fields at runtime?

Impact: Lenient mode is faster to deploy; strict mode catches operator errors earlier.

Owner: Assigned TBD
Target decision date: 2026-04-03

See also: N-ADR-001-SchemaValidation

---

2. Decoder Failure Behavior and Backpressure (N-ADR-002)

Problem: If the DSP pipeline decodes a frame but the telemetry router fails to parse it (e.g., schema mismatch), what happens?

Issues:

• Should the router drop the frame, log it, or buffer it?
• If buffering, how much memory is allowed before discarding old frames?
• Should router backpressure propagate back to DSP (pause frame generation)?

Deferred decision:

• Ring buffer approach: keep last N frames, discard oldest if full?
• Drop approach: discard frames that can't be decoded, increment error counter?
• Backpressure approach: DSP pauses if router buffer full (blocks frame flow)?

Impact: Buffer approach wastes memory but preserves data; drop approach is lean but loses telemetry.

Owner: Assigned TBD
Target decision date: 2026-04-05

See also: N-ADR-002-Decoder-Backpressure

---

3. Timestamp Authority During GNSS Degradation (N-ADR-003)

Problem: Telemetry events are timestamped using GNSS PPS at the node. When GNSS loses fix or PPS signal drops out, which timestamp should the node use?

Issues:

• Should node switch to local crystal oscillator?
• How long to wait before declaring GNSS lost? (1 second? 5 seconds?)
• Should telemetry events include GNSS_VALID flag so central knows timestamps might drift?

Deferred decision:

• Keep using GNSS time even if fix degraded (trust long-term accuracy)?
• Switch to local TCXO clock and mark timestamps as degraded?
• Continue outputting frames timestamped by FPGA clock until GNSS recovers?

Impact: GNSS fallback ensures continuity but timestamps may drift; switching to TCXO makes drift explicit but may confuse operators.

Owner: Assigned TBD
Target decision date: 2026-04-10

See also: N-ADR-003-GNSS-Degradation

---

Summary

Four node-scoped ADRs (all status: Proposed)

---

Next: See ADR-INDEX for the master ADR registry across both system and node.