Implementation Readiness Roll-Up
1. Status Snapshot
| Metric | Count |
|---|---|
| Pages with open questions | 14 |
| Total open questions logged | ~166 |
| Blocking for MVP implementation | ~86 |
| Recommended cluster-wide ADRs | 8 |
| Page-scoped ADRs flagged | ~110 |
2. Cross-Cutting ADRs (Highest Priority)
The same decision shows up on multiple pages. Resolving these once unblocks many entries downstream. Each should be drafted as a single ADR with cluster-wide scope.
| # | ADR Title | Why It Spans the Cluster | Owners | Pages Affected |
|---|---|---|---|---|
| CC-1 | Signed-Object Serialization and Canonicalization (CBOR/COSE vs JSON/JWS, primary on wire) | Manifest, capsule, endorsement, telemetry packet all need one wire format that’s stable, compact, and signable | Engineering + Security | authorization-package, disconnected-operations, system-design, pki |
| CC-2 | Signature Algorithm Suite and Post-Quantum Migration Path | ECDSA P-256 baseline locked, but Ed25519 timing, hybrid PQ trigger, and per-artifact alg selection are open | Engineering + Security | pki, authorization-package, aircraft-hardware-identity |
| CC-3 | HSM Vendor Selection, FIPS Posture, and Key Ceremony Runbook | All signing roots (ATOMx Root, OEM intermediates, authority endorsement) depend on a consistent HSM stance | Security + Legal | pki, onboarding-manufacturers, threat-model |
| CC-4 | Audit-Ledger Backing Technology and Tamper-Evidence Mechanism | Hash-chained Postgres vs Merkle DAG vs managed-ledger vs immutable cold storage — touches every signing event, disclosure, and reconciliation | Engineering + Security | system-design, threat-model, authorization-package |
| CC-5 | Identity-Proofing Vendor and IdP Topology (login.gov primary, FIDO2/PIV/VC integration) | The “Strongly Verified” tier and federation contract reach into every authorization | Engineering + Product + Legal | pilot-identity, onboarding-operators-and-pilots, system-design |
| CC-6 | Multi-Tenancy Isolation Strength (logical-only vs partitioned vs FedRAMP single-tenant) | Determines feasible deployment models for federal vs commercial customers | Engineering + Security + Product | system-design, onboarding-authorities |
| CC-7 | FedRAMP Boundary, Authorized Cloud Services, and Classified-Jurisdiction Posture | Drives which GCP / Azure-Gov / IL5 services are admissible and how classified deployments are partitioned | Security + Product + Legal | system-design, onboarding-authorities, threat-model |
| CC-8 | Remote ID Standards-Compatibility Analysis — does the ATOMx extension fit inside optional fields of F3411 / Part 89 / F3586 / F3548? | Resolved Outcome: fits inside optional fields, no rule change required. F3411 §5.4.5.11 explicitly blesses private AuthTypes A–F; Part 89 specifies a floor (mandatory messages + ≥1 Hz periodicity) not a ceiling; F3586 is silent on the Authentication Message; F3548 §1.6 covers value-added capabilities. Three caveats apply (9-msg-per-pack cap, no normative “ignore-unknown-AuthType” clause, no central AuthType registry); one recommended lightweight registrar action with ASTM F38. No FAA petition. Full analysis → Remote ID Standards Compatibility. | Product + Legal + Standards-External | remote-id-standards-compatibility, disconnected-operations §5.1, origins-and-decisions §3.2 |
Drafting these 8 cluster-wide ADRs first will collapse a meaningful portion of the ~110 page-scoped ADRs into “follows from CC-N.” CC-8 resolved 2026-05-11 — see Remote ID Standards Compatibility. Field deployment is no longer regulatory-blocked, subject to the three implementation caveats documented in that analysis.
3. Owner Distribution
A coarse breakdown of who needs to be at the table to resolve the open questions. Many entries have shared ownership; counts below tally any-touched.
| Primary Owner | Approximate # of Questions Touching Them |
|---|---|
| Engineering | ~110 |
| Security | ~80 |
| Product | ~55 |
| Legal | ~30 |
| External (FAA, OEMs, standards bodies, agencies) | ~25 |
| SRE / Platform | ~15 |
The Engineering + Security overlap is structural — most cryptographic and protocol decisions need both. PM-led decisions (purpose-code catalogs, role permissions, tier semantics) cluster around the onboarding pages and the disclosure policy.
4. Per-Page Open-Questions Index
Each page owns its open-questions section. Click through to read the canonical entries.
| Page | Cluster Weight | Questions | Blocking | ADRs Proposed | Source Section |
|---|---|---|---|---|---|
| Trust Model | 10 | 11 | 7 | 9 | § Open Questions |
| Trust Ladder | 20 | 10 | 6 | 7 | § Open Questions |
| PKI and Chains of Trust | 30 | 15 | 8 | 13 | § Open Questions |
| Pilot Identity | 40 | 12 | ~6 | ~9 | § Open Questions |
| Aircraft Hardware Identity | 50 | 13 | 6 | ~10 | § Open Questions |
| Authorization Package | 60 | 12 | 7 | 10 | § Open Questions |
| Flight Lifecycle | 70 | 10 | 6 | ~8 | § Open Questions |
| Disconnected Operations | 80 | 5 | 2 | ~3 | § Open Questions |
| Local Broadcast & Messaging | 82 | 9 | 3 | ~7 | § Open Questions |
| Remote ID Standards Compatibility | 85 | — | — | — | resolves CC-8; no open-questions section |
| Threat Model | 90 | 12 | 6 | 9 | § Open Questions |
| System Design | 100 | 14 | 8 | ~10 | § Open Questions |
| Onboarding Manufacturers | 110 | 10 | 7 | 7 | § Open Questions |
| Onboarding Aircraft | 120 | 11 | 6 | ~8 | § Open Questions |
| Onboarding Operators and Pilots | 130 | 10 | 5 | ~7 | § Open Questions |
| Onboarding Authorities | 140 | 13 | 9 | ~11 | § Open Questions |
(_index.md and Origins and Decisions intentionally have no open-questions section — origins §9 already enumerates research gaps from a different angle.)
5. Suggested Drafting Order
A tractable sequence that respects dependencies — earlier ADRs unlock later ones:
CC-8 Remote ID Standards-Compatibility Analysis— Resolved 2026-05-11. Outcome: fits inside optional fields; no rule change required. See Remote ID Standards Compatibility.- CC-3 HSM Vendor and Ceremony — pure procurement and security-architecture; runs in parallel with CC-8
- CC-2 Signature Algorithm Suite — unblocks most signed-object work; benefits from CC-3 being underway
- CC-1 Serialization and Canonicalization — needs CC-2 settled; partly shaped by CC-8 (Remote ID payload constraints may force CBOR)
- CC-7 FedRAMP Boundary — gates cloud-service selection for CC-4 and CC-6
- CC-4 Audit Ledger Backing — needs CC-7 to scope acceptable technologies
- CC-6 Multi-Tenancy Isolation — needs CC-7 for federal-customer constraints
- CC-5 Identity Proofing and IdP Topology — partner-dependent; can run in parallel with the others
After the eight cluster-wide ADRs, page-scoped ADRs can be drafted in parallel by domain owners. The blocking count (~86) gives a realistic MVP-readiness backlog.
6. ADR Storage and Format
ADRs for this cluster live in content/docs/ATOMx/ADR/ (existing convention; see Talos-21-Trust-Model.md for the format precedent). Suggested naming:
- Cluster-wide:
ATOMX-CC-NN-<short-title>.md - Page-scoped:
ATOMX-<page-slug>-NN-<short-title>.md
Each ADR should include: Context, Decision, Status, Consequences, Alternatives Considered, Page References. A template lives in the ADR archetype if the docs site has one configured.
7. Maintenance
This roll-up is not auto-generated. When a page’s open-questions list changes, update this page’s counts manually. When an ADR is drafted, strike or annotate the corresponding entry on the source page and update this roll-up to point at the ADR. When all entries on a page have been resolved, remove that page’s open-questions section entirely and bump its status from Draft to In Review.
8. Cross-References
- Origins and Decisions §9 — Open Questions and Research Gaps — narrative-style open questions from meeting research (different angle, complementary)
- ATOMx Overview — return to cluster landing page