# Axiom Platform Execution Plan — 2026

> **Living document.** Single source of truth for what gets built in Axiom, in what order, and why. PRDs remain authoritative for *what* to build; this document governs *when* and *in what order*. Domain consumers (e.g., NeutronOS) maintain their own execution plans for domain-specific work that layers on top.

**Last Updated:** 2026-04-01
**Tracks:** Axiom platform capabilities only (domain-agnostic)
**First consumer:** NeutronOS (nuclear facilities) — see [NOS Execution Plan](https://github.com/…/Neutron_OS/docs/working/execution-plan-2026.md)
**Deployment progression:** Local workstation → Private server (VPN) → HPC cluster

---

## Current State of Play

| Capability | Spec | Code | Status |
|---|---|---|---|
| **CLI framework (`axi`)** | ✅ | ✅ 17 registered nouns | signal, mo, pub, doc, chat, code, rag, connect, db, log, mirror, status, test, update, install, note, serve |
| **Extension system** | ✅ | ✅ | 3-tier discovery, `axiom-extension.toml` manifests, 20+ builtin extensions |
| **Provider identity (ADR-012)** | ✅ | ✅ | `provider_base.py` (359 lines) — ProviderBase, ProviderIdentityMixin |
| **LLM Gateway/Routing** | ✅ | ✅ | `gateway.py` (1537 lines), `router.py` (457 lines) — tier routing, keyword + SLM classification, VPN check, audit logging |
| **RAG** | ✅ | ✅ | store (423 lines), ingest (229), chunker (123), embeddings (255), sanitizer (151), personal (259), watcher (166), CLI (349) |
| **EVE Agent (signals)** | ✅ | ✅ | 69 files — ingestion, extraction, synthesis, correction review, media library, briefing, voice ID, echo suppression |
| **M-O Agent (steward)** | ✅ | ✅ | 18 files — node health, retention, log steward, repo hygiene, network |
| **PRT Agent (publisher)** | ✅ | ✅ | 51 files — DOCX/OneDrive/Box, publish engine, state, validation |
| **WALL-E Agent (chat/loop)** | ✅ | ✅ | 31 files / 10k lines — chat, code assistance, REPL loop |
| **DFIB Agent (diagnostics)** | ✅ | ✅ | 5 files — platform health checks |
| **Prompt Registry** | ✅ | ✅ | `infra/prompt_registry.py` (266 lines) |
| **Data Platform** | ✅ | 🟡 Schema sketched | Iceberg/dbt/Dagster not wired to runtime |
| **FAIR / DMP** | ✅ (new PRD) | ❌ 0% | Jurisdiction-agnostic; provider pattern |
| **Federation** | ✅ (ADR-016) | ❌ 0% | A2A protocol adopted; zero code shipped |

---

## Dependency Graph

#### Critical Path (P0–P2)

```mermaid
flowchart TB
    subgraph P0["P0: Foundation"]
        direction TB
        PB["provider_base.py (ADR-012)"]
        PB --> GW["gateway.py — + QueryRouter"]
        DB["PostgreSQL — migrations"]
        S3["SeaweedFS/S3 storage"]
    end

    subgraph P1["P1: Routing + RAG"]
        direction TB
        KW["Keyword classifier"]
        KW --> SLM["Ollama SLM classifier"]
        SLM --> VPN["VPN reachability check"]
        VPN --> QR["QueryRouter full"]
        RAG_S["RAG pgvector schema"]
        RAG_S --> RAG_E["Embedding pipeline"]
        RAG_E --> RAG_R["Retrieval + — tier filtering"]
        QR --> CHAT["axi chat — end-to-end"]
        RAG_R --> CHAT
    end

    subgraph P2["P2: Multi-Store RAG"]
        direction TB
        DUAL["Dual-store — fan-out"]
        DUAL --> MERGE["Result merge — + re-rank"]
        MERGE --> E2E["E2E: local + — remote RAG"]
    end

    GW --> KW
    DB --> RAG_S
    S3 --> RAG_E
    CHAT --> DUAL

    style P0 fill:#ffcdd2,color:#000000
    style P1 fill:#c8e6c9,color:#000000
    style P2 fill:#bbdefb,color:#000000
    style PB fill:#ef9a9a,color:#000000
    style GW fill:#ef9a9a,color:#000000
    style DB fill:#ef9a9a,color:#000000
    style S3 fill:#ef9a9a,color:#000000
    style KW fill:#a5d6a7,color:#000000
    style SLM fill:#a5d6a7,color:#000000
    style VPN fill:#a5d6a7,color:#000000
    style QR fill:#a5d6a7,color:#000000
    style RAG_S fill:#a5d6a7,color:#000000
    style RAG_E fill:#a5d6a7,color:#000000
    style RAG_R fill:#a5d6a7,color:#000000
    style CHAT fill:#a5d6a7,color:#000000
    style DUAL fill:#90caf9,color:#000000
    style MERGE fill:#90caf9,color:#000000
    style E2E fill:#90caf9,color:#000000
    linkStyle default stroke:#777777,stroke-width:2px
```

#### Deployment Stages (P2–P5)

```mermaid
flowchart TB
    P1_REF["P0+P1: — Single node ✅"]

    subgraph P2["P2: Second Node"]
        direction TB
        MANIFEST["Node manifest — + identity"]
        MANIFEST --> DISC["mDNS discovery"]
        DISC --> TRUST["Trust + invite — model"]
        TRUST --> DUAL["Dual-store — RAG fan-out"]
        DUAL --> RES["Resource — sharing (LLM)"]
        RES --> PACK["RAG data — packs"]
        PACK --> E2E["Two-node — E2E"]
    end

    subgraph P3["P3: Live Ops"]
        direction TB
        HB["Heartbeat daemon"]
        HB --> UPGRADE["Node upgrade protocol"]
        UPGRADE --> A2A["A2A Agent — Cards"]
        A2A --> SYNC["Knowledge sync v1"]
        SYNC --> FEED["Feedback + — maturity scoring"]
        FEED --> PROMO["Promotion pipeline"]
    end

    subgraph P4["P4: FAIR + DMP"]
        direction TB
        META["Core metadata schema"]
        META --> PID["PID Provider (DOI/ARK/Handle)"]
        PID --> EMB["Embargo lifecycle"]
        EMB --> DMP["DMP Template Engine"]
        DMP --> RPT["Reporting — Providers"]
        RPT --> DASH["Compliance dashboard"]
    end

    subgraph P5["P5: Scale"]
        direction TB
        HPC["Third+ node (HPC)"]
        HPC --> TRI["Three-store — RAG fan-out"]
        TRI --> FED_DASH["Federation dashboard"]
        FED_DASH --> DECOM["Node decommission"]
        DECOM --> EXT_FED["External partner federation"]
    end

    P1_REF --> MANIFEST
    E2E --> HB
    E2E --> META
    PROMO --> SYNC
    DASH --> FED_DASH
    A2A --> EXT_FED

    style P2 fill:#bbdefb,color:#000000
    style P3 fill:#ffe0b2,color:#000000
    style P4 fill:#e1bee7,color:#000000
    style P5 fill:#b2dfdb,color:#000000
    style P1_REF fill:#a5d6a7,color:#000000
    style MANIFEST fill:#90caf9,color:#000000
    style DISC fill:#90caf9,color:#000000
    style TRUST fill:#90caf9,color:#000000
    style DUAL fill:#90caf9,color:#000000
    style RES fill:#90caf9,color:#000000
    style PACK fill:#90caf9,color:#000000
    style E2E fill:#90caf9,color:#000000
    style HB fill:#ffcc80,color:#000000
    style UPGRADE fill:#ffcc80,color:#000000
    style A2A fill:#ffcc80,color:#000000
    style SYNC fill:#ffcc80,color:#000000
    style FEED fill:#ffcc80,color:#000000
    style PROMO fill:#ffcc80,color:#000000
    style META fill:#ce93d8,color:#000000
    style PID fill:#ce93d8,color:#000000
    style EMB fill:#ce93d8,color:#000000
    style DMP fill:#ce93d8,color:#000000
    style RPT fill:#ce93d8,color:#000000
    style DASH fill:#ce93d8,color:#000000
    style HPC fill:#80cbc4,color:#000000
    style TRI fill:#80cbc4,color:#000000
    style FED_DASH fill:#80cbc4,color:#000000
    style DECOM fill:#80cbc4,color:#000000
    style EXT_FED fill:#80cbc4,color:#000000
    linkStyle default stroke:#777777,stroke-width:2px
```

---

## P0: Platform Foundation

**Goal:** Shared infrastructure that every downstream feature needs.
**Deployment:** Local workstation
**Status:** Largely complete.

| # | Work Item | Status | Notes |
|---|-----------|---|---|
| 0.1 | `provider_base.py` — ProviderBase, ProviderIdentityMixin (ADR-012) | ✅ Done | 359 lines |
| 0.2 | `gateway.py` — provider registry, tier routing, audit logging | ✅ Done | 1537 lines |
| 0.3 | `router.py` — KeywordClassifier, SLM classifier, VPN check, QueryRouter | ✅ Done | 457 lines |
| 0.4 | PostgreSQL + Alembic migration framework | ✅ Done | EVE schema migration exists |
| 0.5 | RAG schema — pgvector store, documents, chunks, embeddings | ✅ Done | `rag/store.py` (423 lines) |
| 0.6 | S3-compatible object storage abstraction | ❌ Remaining | Needed for Model Corral and artifact storage |

---

## P1: Intelligent Routing + RAG

**Goal:** `axi chat` routes queries to the right LLM tier, grounded in searchable knowledge corpus.
**Deployment:** Local workstation (single-store, public tier)
**Status:** Complete.

| # | Work Item | Status | Notes |
|---|-----------|---|---|
| 1.1 | KeywordClassifier — keyword list → tier routing | ✅ Done | In `router.py` |
| 1.2 | Ollama SLM classifier — local semantic classification, 2s timeout | ✅ Done | Graceful fallback to keyword-only |
| 1.3 | VPN reachability check — TCP connect, 1s timeout | ✅ Done | In routing pipeline |
| 1.4 | QueryRouter — combines classifiers + session mode + CLI overrides | ✅ Done | Full implementation |
| 1.5 | Embedding pipeline — Ollama local → pgvector | ✅ Done | `rag/embeddings.py` (255 lines), `rag/ingest.py` (229 lines) |
| 1.6 | RAG retrieval — similarity search + access tier filtering | ✅ Done | `rag/store.py` (423 lines) |
| 1.7 | Personal workspace indexing (`axi rag index .`) | ✅ Done | `rag/personal.py` (259 lines), `rag/watcher.py` (166 lines) |
| 1.8 | RAG wired into `axi chat` — context injection | ✅ Done | WALL-E agent (Neut) integrates RAG retrieval |
| 1.9 | Interaction logging | ✅ Done | Audit logging in gateway + routing_audit |
| 1.10 | `axi rag` CLI (`index`, `search`, `status`) | ✅ Done | `rag/cli.py` (349 lines) |

---

## P2: Second Node — Federation Primitives + Multi-Store RAG

**Goal:** Stand up a second Axiom node. Two nodes discover each other, share LLM resources and RAG corpora, and serve RAG data packs. Ben and Ondrej can both use `axi chat` with grounded, multi-node responses.
**Deployment:** Local workstation + private server (behind VPN)
**Timeline:** Weeks 3–7
**Key insight:** The deployment progression IS federation. Every new node needs discovery, trust, and resource sharing from day one.

| # | Work Item | Depends On | Acceptance Criteria |
|---|-----------|---|---|
| 2.1 | **Node manifest + identity** — JSON describing node_id (Ed25519 key-derived), capabilities, resources, owner, profile (Leaf/Standard/Provider) | 0.6 | Every Axiom node generates and serves its manifest at startup |
| 2.2 | **mDNS node discovery** — nodes on same network find each other automatically | 2.1 | Second node appears in `axi federation list` within 30s |
| 2.3 | **Invitation + trust model** — token exchange, human approval for joins, trust_level assignment | 2.1, 2.2 | Node join requires bilateral approval; trust level configurable |
| 2.4 | **Resource advertisement** — nodes publish available LLM providers, RAG corpora, storage with capability scores | 2.1 | `axi federation resources` shows resources from both nodes |
| 2.5 | **Resource selection** — configurable strategies (best-of, fan-out, pinned) for federated LLM access | 2.4 | Chat query routes to best available LLM across both nodes |
| 2.6 | **Dual-store RAG retrieval** — fan-out query to local postgres + remote postgres, merge results, re-rank | 1.6, 2.3 | Query hits both stores; results merged respecting trust + tier |
| 2.7 | **Restricted-tier embedding on remote** — embeddings generated on the remote node, never shipped to cloud | 1.5, 2.3 | Restricted docs embedded on remote only |
| 2.8 | **RAG data packs** — portable corpus bundles (`.axiompack`) that can be distributed between nodes | 2.6 | Pack created on one node, loaded on another; chunks searchable |
| 2.9 | **`axi rag sync`** — synchronize corpus metadata between nodes | 2.6 | Local node knows what remote has |
| 2.10 | **Node deployment playbook** — documented steps to stand up a new Axiom node | 2.6 | Reproducible by a new operator in <2 hours |
| 2.11 | **Two-node E2E validation** — `axi chat` with fan-out, grounded responses from both nodes | 2.5, 2.6 | Both users get grounded responses citing sources from both nodes |

---

## P3: Live Operations — Node Lifecycle + Intelligence

**Goal:** Nodes can be upgraded, monitored, and managed without downtime. Knowledge flows between nodes. Agent-to-agent communication works across nodes.
**Deployment:** Two+ live nodes under active use
**Timeline:** Weeks 7–12

| # | Work Item | Depends On | Acceptance Criteria |
|---|-----------|---|---|
| 3.1 | **Heartbeat daemon** — periodic liveness checks between nodes | 2.1 | Stale nodes detected within 2× heartbeat interval |
| 3.2 | **Node upgrade protocol** — rolling upgrade: new version deployed to one node, validated, propagated | 3.1 | Upgrade one node without disrupting the other; rollback on failure |
| 3.3 | **A2A Agent Cards** — each agent publishes `/.well-known/agent-card.json` per ADR-016 | 2.1 | Agent capabilities discoverable across nodes via standard HTTP |
| 3.4 | **Cross-node agent delegation** — agent on Node A can delegate a task to agent on Node B via A2A | 3.3 | EVE on local delegates compute-heavy extraction to EVE on GPU server |
| 3.5 | **Knowledge sync v1** — bilateral: promoted community facts pulled between nodes | 2.3, 4.11 | Facts approved at Node A appear at Node B within sync interval |
| 3.6 | **Sync conflict resolution** — last-writer-wins with human review for conflicts | 3.5 | Conflicting facts surfaced for review; no silent overwrites |
| 3.7 | **Feedback signal capture** — thumbs up/down in `axi chat`, explicit corrections | — | Feedback stored; queryable by session; informs maturity scoring |
| 3.8 | **Knowledge maturity scoring** — GREEN/YELLOW/RED trust gradient on RAG chunks | 3.7 | Score updated on access + feedback |
| 3.9 | **EVE crystallization → community facts pipeline** | 3.8 | Crystallization produces facts; wired to promotion |
| 3.10 | **M-O knowledge maturity sweep** — weekly sweeps | 3.8 | GREEN/YELLOW/RED scoring operational |
| 3.11 | **Promotion pipeline** — personal → facility → community with human review gate | 3.8, 3.9 | `axi rag review` CLI; promoted facts sync to peers via 3.5 |
| 3.12 | **Knowledge graph layer (Phase 0.1)** — Apache AGE on PG, deterministic entity extraction, `axi graph` CLI | 3.7 | Entities/relationships extracted from indexed docs; Cypher queries functional. See `spec-knowledge-graph.md`, `prd-knowledge-graph.md` |
| 3.13 | **Knowledge graph hybrid retrieval (Phase 0.2)** — RAG+graph merged results, MCP tool, LLM extraction | 3.12 | Structural queries routed to graph; `axiom_graph_query` MCP tool exposed |
| 3.14 | **PG session store** — `sessions` + `session_messages` tables in shared PG, multi-client access, LISTEN/NOTIFY | 0.4 (PG) | `axi chat --resume` works from any client connected to same PG. See [spec-session-store.md](../tech-specs/spec-session-store.md) |
| 3.15 | **Session delegation** — agents join human sessions, RACI ownership model | 3.14 | EVE writes to a session started by a human; delegation visible in `axi chat --list` |
| 3.16 | **Interaction log** — SQL view over `session_messages`, per-session cost aggregation | 3.14 | `interaction_log` view queryable; OKR O7 KR-1 satisfied |
| 3.17 | **Chat UX improvements** — token budget ceiling, tool subset modes, cost display, structured output, configurable compaction | 3.14 | `axi chat --simple`, `--budget`, `--json` all functional |

**Already implemented (agents + infra):**
- Prompt Template Registry ✅ (266 lines)
- EVE agent ✅ (69 files), M-O agent ✅ (18 files), PRT agent ✅ (51 files), WALL-E agent (chat/loop) ✅ (31 files), DFIB agent ✅ (5 files)
- SECUR-T retired — security functions absorbed by D-FIB
- Remaining work is wiring maturity/promotion/sync and cross-node agent communication

---

## P4: FAIR Data Management + DMP Framework

**Goal:** Jurisdiction-agnostic FAIR metadata, PIDs, embargo lifecycle, DMP template engine. Any domain consumer can satisfy its funder's data management requirements.
**Deployment:** All active nodes
**Timeline:** Weeks 10–14

| # | Work Item | Depends On | Acceptance Criteria |
|---|-----------|---|---|
| 4.1 | Core metadata schema — DataCite-aligned fields on all data objects | — | Schema migration applied; metadata assignable via API and CLI |
| 4.2 | PID Provider ABC + concrete providers (DataCite DOI, ARK, Handle) | 4.1 | Can mint PIDs via any configured provider; offline minting queued |
| 4.3 | Creator Identity Provider ABC + concrete providers (ORCID, LDAP, local) | 4.1 | Creator resolution chain works |
| 4.4 | Dataset access lifecycle engine (draft → embargoed → published → archived → tombstone) — extends PRT StorageProvider | 4.1 | State transitions enforced; embargo auto-expires |
| 4.5 | License metadata on all objects (SPDX identifiers) | 4.1 | License required on publish transition |
| 4.6 | DMP Template Provider ABC (U.S. DOE DMSP, EU Horizon Europe DMP, generic) | 4.1 | `axi dmp generate` produces jurisdiction-compliant draft |
| 4.7 | Reporting Provider ABC (U.S. OSTI, EU OpenAIRE, disabled) | 4.2 | Published datasets auto-reported to configured endpoint |
| 4.8 | Repository registry with NSTC qualification metadata | 4.2 | Domain consumers can pre-populate with domain-specific repos |
| 4.9 | DMP compliance dashboard | 4.1–4.7 | Audit-ready view scoped to active jurisdiction's rules |
| 4.10 | Metadata export (DataCite XML, Dublin Core, JSON-LD) | 4.1 | Machine-readable metadata harvestable by external catalogs |

---

## P5: Scale — Third+ Node, HPC, External Partners

**Goal:** Expand federation beyond two nodes. HPC tier for export-controlled workloads. External partner federation (cross-organization).
**Deployment:** Local + private server + HPC cluster + external partners
**Timeline:** Weeks 14+

| # | Work Item | Depends On | Acceptance Criteria |
|---|-----------|---|---|
| 5.1 | **Third node onboarding** (HPC cluster) — same playbook as P2, validates at scale | 2.10 | HPC node joins federation; resources advertised |
| 5.2 | **Three-store RAG fan-out** — query fans to local + private server + HPC | 2.6, 5.1 | Tier-appropriate results from all three stores |
| 5.3 | **Export-controlled workloads on HPC** — EC-only embedding, storage, retrieval on authorized system | 5.1 | EC docs never leave HPC; accessible only from authorized nodes |
| 5.4 | **Federation dashboard** — node health, sync status, resource utilization, trust graph | 3.1 | Operator sees full federation state at a glance |
| 5.5 | **Node decommission** — graceful leave: knowledge migrated, resources de-advertised, federation notified | 3.1 | `axi federation leave` cleanly removes node |
| 5.6 | **External partner federation** — cross-organization trust (different VPNs, bilateral DSAs) | 2.3, 3.3 | Two organizations' Axiom federations exchange community knowledge |
| 5.7 | **Federation-wide DMP compliance** — compliance dashboard aggregates across all federated nodes | 4.9, 5.4 | Cross-node compliance view for multi-site funded projects |

---

## P6: Canary Nodes — Federated Release Promotion

**Goal:** Every release starts as "edge." Canary nodes auto-upgrade in a sandbox, smoke-test, and push signed attestations. Fleet nodes only upgrade after diverse canaries attest green. Silence is failure. Any node can opt into canary duty.
**Deployment:** All nodes (canaries push outbound — works behind firewalls)
**Timeline:** Phases across v1.2–v2.0+
**Key insight:** Push-based, not pull-based. Canaries never need inbound connections. They poll PyPI (outbound), test locally, and push signed attestations (outbound). Works behind VPNs, NATs, and air gaps.

| # | Work Item | Depends On | Acceptance Criteria |
|---|-----------|---|---|
| 6.1 | **Release channels (edge/stable)** — every tag publishes as edge; stable = canary-validated | — | `axi release channel` shows current channel |
| 6.2 | **Canary agent** — BURN-E extension: detect → sandbox → smoke → attest → rollback | 3.1 (heartbeat) | `axi release canary-run` completes full cycle |
| 6.3 | **Smoke test registry** — tiered tests (Tier 1-4) registered by capability | — | Tier 1 tests pass on any install; higher tiers require infra |
| 6.4 | **Attestation signing** — Ed25519-signed attestation with platform profile | 2.1 (identity) | Attestation verifiable by any node with the canary's public key |
| 6.5 | **Attestation sinks (gossip)** — push attestation to local federation state for peer propagation | 2.2 (discovery) | Attestation written locally, propagated to peers on sync |
| 6.6 | **Attestation sinks (pack server, GitHub)** — push to HTTP endpoints | — | Attestation readable by fleet nodes via HTTP GET |
| 6.7 | **Promotion evaluator** — local policy: quorum, OS diversity, silence timeout, profile matching | 6.4 | Node evaluates attestations against policy and decides locally |
| 6.8 | **Fleet upgrade service** — auto-upgrade when promotion criteria met | 6.7 | Fleet node upgrades only after stable promotion |
| 6.9 | **Rascal as first canary** — configure Rascal with canary role, Tier 4 smoke, cron | 6.2, 6.3 | Rascal detects edge release, smokes, attests within 15 min |
| 6.10 | **Commercial canary opt-in** — license flag, pricing incentive, telemetry dashboard | 6.7, 6.8 | Any node can opt in/out; canary fleet diversity visible |

**Related:** [Canary Nodes PRD](prd-canary-nodes.md) · [Canary Nodes Tech Spec](../tech-specs/spec-canary-nodes.md)

---

## Critical Path

P0 and P1 are complete. The critical path is now:

```
0.6 (S3 storage) ─┐
                   ├→ P2 (second node: discovery + trust + dual-store RAG + packs)
P1 (RAG ✅) ───────┘
                       ↓
                   P3 (live ops: upgrade protocol + A2A + knowledge sync + maturity)
                       ↓               ↓
                   P4 (FAIR/DMP)    P6 (canary nodes — release promotion)
                       ↓               ↓
                   P5 (third node, HPC, external partners, commercial canary program)
```

**P2 is the immediate priority** — it brings the minimum federation primitives needed for two nodes to talk. Everything after P2 assumes live nodes exist that need managing (P3), compliance (P4), and scaling (P5). P6 (canary nodes) runs in parallel with P4 once P3's heartbeat daemon is operational — it provides the upgrade safety net that a growing federation requires.

---

## Domain Consumer Integration Points

Axiom provides infrastructure; domain consumers configure and extend it. The table below shows where domain products plug in:

| Axiom Capability | What Domain Consumers Provide | Example (NeutronOS) |
|---|---|---|
| **Extension system** | Domain-specific agents, tools, CLI nouns | `neut model`, `neut signal`, reactor-specific agents |
| **RAG corpus** | Domain knowledge content, community packs | Nuclear domain pack (~33k chunks: NRC regs, MCNP docs, reactor physics) |
| **LLM routing tiers** | Keyword lists, classification training data | Nuclear export control keywords (10 CFR 810 terms) |
| **Metadata schema** | Domain extension fields | reactor_type, core_position, isotope, neutron_flux |
| **DMP Template Provider** | Jurisdiction-specific template | U.S. DOE DMSP template with 5 mandatory sections |
| **Reporting Provider** | Jurisdiction-specific endpoint | OSTI E-Link 2.0 for DOE-funded datasets |
| **Repository registry** | Domain-specific repository targets | NNDC, ESS-DIVE, Materials Data Facility |
| **Retention policies** | Regulatory-specific tier configuration | NRC: 2yr warm, 7yr cold, permanent for safety basis |
| **Federation** | Node topology, trust relationships | UT NETL ↔ OSU TRIGA ↔ INL NRAD bilateral trust |

---

## Relationship to Domain Execution Plans

This plan defines Axiom platform milestones. Domain consumers maintain their own plans for domain-specific work:

- **NeutronOS:** [execution-plan-2026.md](https://github.com/…/Neutron_OS/docs/working/execution-plan-2026.md) — references Axiom milestones as M0 (→ P0), M2 (→ P1/P2), M4 (→ P3), M5 (→ P4), M6 (→ P5)

When Axiom milestones slip, domain consumers' dependent milestones slip proportionally. This plan is the upstream dependency.

---

## Deployment Target Progression

Axiom is designed for incremental deployment. Each tier adds capability without requiring the prior tier to be decommissioned:

| Tier | Role | Network | Typical Hardware | Federation Profile |
|---|---|---|---|---|
| **Local workstation** | Development, personal RAG, public-tier LLM | Internet | Laptop/desktop | Leaf |
| **Private server** | Shared LLM (GPU), restricted-tier RAG, team resources | VPN | GPU server (e.g., A100) | Standard or Provider |
| **HPC cluster** | Export-controlled workloads, batch compute, large model training | Institutional VPN | Multi-node cluster | Provider |
| **Coordinator** | Federation management, resource directory, knowledge sync hub | VPN or public | Modest server | Coordinator |

Nodes at any tier can join or leave the federation independently. The federation is resilient to individual node outages — nodes cache last-known-good state and resume sync on reconnection.
