Project Architecture Gaps and Deferred Decisions

1. Security and Trust Boundaries (ADR-001)

Problem: The node and central server communicate over IP (likely not encrypted in initial deployment). The system must define mutual authentication, encryption, and key management strategy.

Current state: HTTPS is mentioned as an option, but TLS mutual authentication is not required in MVP.

Issues:

• Can a compromised node inject false telemetry? Current design assumes node is trusted.
• Can an attacker intercept or replay telemetry frames?
• What is the API key management strategy? Where are secrets stored?

Deferred decision:

• Require mutual TLS for all node-to-central communication?
• Use API key + bearer token pattern, or certificate-based auth?
• How to rotate credentials in the field?

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

See also: ADR-001-TLS-Mutual-Auth

---

2. Schema Governance and Compatibility Policy (ADR-002)

Problem: Payload field schemas (parameter definitions) are runtime configurable. As missions evolve and parameters change, the system needs a strategy for schema versioning and backward compatibility.

Current state: Schema versions are mentioned as "immutable once deployed," but there's no formal versioning scheme or upgrade path.

Issues:

• Can a node support multiple schema versions simultaneously?
• What happens if central sends a frame definition that a node doesn't support?
• How are old schemas archived and replayed?

Deferred decision:

• Adopt semantic versioning (major.minor.patch) for schemas?
• Can a payload type have multiple active schema versions, or must upgrade happen atomically?
• Deprecation policy: how long to support old schemas after new ones are released?

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

See also: ADR-002-Schema-Governance

---

3. Time Synchronization and Clock Authority (ADR-003)

Problem: Telemetry events are timestamped using GNSS PPS at the node, but the central server also embeds timestamps. In multi-node scenarios, timestamps from different nodes may drift.

Current state: The node computes PPS-derived absolute time; central receives it. No reconciliation strategy is defined.

Issues:

• Which timestamp is source of truth: node time or central receive time?
• What's the acceptable clock drift between nodes (for multi-asset scenarios)?
• How does the system behave during GNSS outage or loss of fix?

Deferred decision:

• Central server to apply NTP or external time correction?
• Accept node timestamps as-is, or use central receive time as authority?
• Fallback strategy during GNSS degradation (dead-reckoning, TCO discipline, other)?

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

See also: ADR-003-Clock-Authority

---

4. Failure Domain and Degraded-Mode Policy (ADR-004)

Problem: What happens when the central server is unreachable, or when a node loses lock, or when GNSS fails? The system needs explicit fallback and error-recovery rules.

Current state: Graceful degradation is mentioned conceptually, but there's no formal policy for which operations degrade, which fail, and what the operator sees.

Issues:

• If central is down, does node continue telemetry streaming (to local storage only)?
• If node loses GNSS, does beam tracking fail, or does it fall back to dead-reckoning?
• What's the maximum allowed telemetry gap before operator is alerted?

Deferred decision:

• Node-side failover: cache mission plan and continue DSP?
• Operator alert thresholds: how long without lock before "LOCK LOST" alert?
• Telemetry buffering policy: how much can node buffer before overwriting old data?

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

See also: ADR-004-Degraded-Mode-Policy

---

5. Per-Target Binding Fallback and Resolution (ADR-005)

Problem: The frontend displays decoded parameters using binding rules supplied by the central server. But if the binding is stale, incorrect, or missing, the frontend needs a strategy for what to display.

Current state: Fallback scopes are defined (exact → payload-type default → global), but the frontend UI behavior when a binding is not found is not specified.

Issues:

• Should unmapped parameters be visible in the UI at all?
• Should the frontend warn or alert if a binding is missing?
• Can the operator override or disable a binding at runtime?

Deferred decision:

• Render unmapped parameters in a separate "unbound telemetry" panel?
• Alert the operator if a parameter that was bound becomes unbound (e.g., stale binding)?
• Support operator-side binding override or only centrally-staged bindings?

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

See also: ADR-005-PerTarget-Binding

---

Summary

Five system-wide ADRs (all status: Proposed)

---

Next: See ADR-INDEX for the master ADR registry, or return to Docs Home for navigation by audience.