# NeutronOS: Federated Retrieval-Augmented Generation for Nuclear Facility Knowledge Management

**Draft — 2026-04-09**

## Abstract

We present NeutronOS, a federated retrieval-augmented generation (RAG) platform designed for nuclear facility knowledge management. Built on the Axiom framework, NeutronOS combines semantic document chunking informed by knowledge graph extraction with a generational blue/green upgrade mechanism that enables zero-downtime corpus improvements across a peer-to-peer federation of research nodes. We demonstrate a 30.5% improvement in full-text retrieval relevance scores when transitioning from fixed-size character splitting to graph-informed semantic chunking on a corpus of 435,457 embedded chunks spanning molten salt reactor literature, NRC regulations, IAEA standards, and facility-specific operational documents. The platform includes CURI-O, an autonomous quality optimization agent that uses statistical significance testing (paired t-test, p < 0.05) to decide when to promote new corpus generations, ensuring that every upgrade is measurably better than the current state.

## 1. Introduction

Nuclear facilities generate vast quantities of technical documentation — regulatory filings, safety analyses, operating procedures, research reports, experiment logs, and simulation results. This knowledge is critical for safe operations, regulatory compliance, and research advancement, yet it is typically scattered across file systems, version control repositories, shared drives, and institutional databases with no unified retrieval mechanism.

Large language models (LLMs) can synthesize and reason over this knowledge, but they suffer from two fundamental limitations: (1) they hallucinate when asked about domain-specific details not in their training data, and (2) they cannot access facility-specific or restricted documents. Retrieval-augmented generation (RAG) addresses both limitations by grounding LLM responses in retrieved document context, but existing RAG implementations face their own challenges in the nuclear domain:

- **Chunking quality**: Fixed-size character splitting destroys document structure — tables, cross-references, regulatory section boundaries, and code blocks are arbitrarily fragmented.
- **Knowledge evolution**: Corpora must be updatable without downtime, with provable quality improvement at each step.
- **Access control**: Nuclear documents span public, restricted, and export-controlled tiers that must be enforced at every retrieval boundary.
- **Federation**: Research facilities need to share public knowledge while protecting restricted and export-controlled content — requiring peer-to-peer corpus synchronization with tier-aware filtering.

NeutronOS addresses these challenges through four architectural innovations:

1. **Graph-informed semantic chunking** — A knowledge graph extraction pipeline (deterministic + LLM-assisted) identifies document structure, entities, and relationships, then exports semantic boundaries to the chunker, producing chunks aligned to tables, sections, procedures, and code blocks rather than arbitrary character offsets.

2. **Generational blue/green upgrades** — Each corpus tier (community, facility, personal) maintains independent generation numbers. New generations are built alongside existing ones, evaluated by the CURI-O quality agent via statistical A/B testing, and promoted only when measurably better. Rollback is instantaneous.

3. **Federated RAG with peer-assisted distribution** — Nodes in the federation advertise their active corpus generations and serve search requests to peers. Pack distribution uses a peer-assisted protocol where nodes that have downloaded a new pack can serve it to other requesting peers, preventing bottlenecks.

4. **CURI-O optimization loop** — An autonomous agent that continuously monitors retrieval quality, proposes chunking parameter experiments, evaluates candidate generations, and promotes or discards based on statistical evidence. Benchmark queries are explicitly excluded from the learning loop to prevent overfitting.

## 2. System Architecture

### 2.1 Corpus Model

NeutronOS uses a three-tier corpus model:

| Tier | Scope | Content | Example |
|------|-------|---------|---------|
| Community (`rag-community`) | Public | Shared knowledge across all facilities | NRC regulations, IAEA standards, published research |
| Organization (`rag-org`) | Facility | Facility-specific restricted content | Operating procedures, internal analyses, experiment data |
| Personal (`rag-internal`) | Individual | User workspace index | Notes, sessions, draft documents |

Each tier manages corpus generations independently. A generation represents a complete rebuild of the corpus with potentially different source data, chunking strategy, embedding model, and knowledge graph.

### 2.2 Ingest Pipeline

The ingest pipeline operates on **full source documents**, not pre-chunked fragments:

```
Source Document (PDF, DOCX, MD)
    │
    ├─→ Knowledge Graph Extraction (full doc, structure-preserving)
    │     Stage 1: Deterministic (regex cross-refs, heading structure, tables)
    │     Stage 2: LLM-assisted (entity recognition, relationship extraction)
    │     Stage 3: Entity resolution (fuzzy matching + embedding similarity)
    │     → Entities, relationships, semantic boundaries
    │
    └─→ Semantic Chunker (informed by extraction output)
          → Chunks aligned to semantic units (sections, tables, code blocks)
          → Each chunk tagged with entity_ids[] from knowledge graph
          → Embeddings generated (nomic-embed-text, 768-dim)
          → Stored in PostgreSQL with pgvector
```

### 2.3 Generational Blue/Green

```sql
-- Every chunk belongs to a corpus + generation
chunks.corpus_generation INTEGER  -- 1, 2, 3, ...
chunks.chunking_tier TEXT         -- 'fixed', 'semantic', 'graph_informed'

-- Node-level config per corpus tier
rag_generation_config.active_generation INTEGER     -- blue (serving)
rag_generation_config.candidate_generation INTEGER  -- green (evaluating)
```

Promotion: `UPDATE rag_generation_config SET active_generation = 2`
Rollback: `UPDATE rag_generation_config SET active_generation = 1`

No data deletion. No downtime. Instant switchover.

### 2.4 Knowledge Graph

Apache AGE on PostgreSQL provides Cypher query capabilities alongside pgvector. The graph stores:

- **8 core entity types** (domain-agnostic): Document, Component, Procedure, Person, Code, Material, Concept, Fact
- **14 nuclear-domain entity types** (NeutronOS extension): Reactor, FuelElement, FuelSalt, Isotope, SimulationCode, etc.
- **10 core + 8 domain relationship types**: REFERENCES, DESCRIBES, GOVERNS, FUELED_BY, etc.

Entity extraction is deterministic first (regex patterns for document cross-references, heading structure, metadata) and LLM-assisted second (structured prompts to the facility's local LLM).

### 2.5 Federation

Nodes advertise their capabilities via `/.well-known/axiom-manifest.json`:

```json
{
  "node_id": "rascal",
  "axiom_version": "0.8.0",
  "active_generations": {"rag-community": 2, "rag-org": 1},
  "compatible_format_versions": ["1.0.0", "2.0.0"]
}
```

Federation search fans out to peers in parallel with configurable timeout. Results are merged by score with provenance tagging (which node served each result).

## 3. Experimental Setup

### 3.1 Corpus

| Source | Documents | Chunks | Tier |
|--------|-----------|--------|------|
| MSR Knowledge Bundle (Ondrej Chvala, curated OCR'd ORNL reports) | 1,425 | 35,439 | Community |
| NRC Regulations (10 CFR Parts 20, 50, 52, 70, 100) | ~50 | ~10,000 | Community |
| IAEA Standards (SSR-3) | ~10 | ~500 | Community |
| OpenMC Documentation | ~20 | ~500 | Community |
| Box Shared Documents (procedures, publications, proposals) | 473 | 252 | Organization |
| NETL TRIGA Data | 144 | ~800 | Organization |
| Digital Twin Repositories | 40 | 70 | Organization |
| NeutronOS Platform Documentation | 105 | 1,232 | Organization |
| **Total** | **~11,955** | **435,457** | |

All chunks embedded with nomic-embed-text (768-dim). Knowledge graph: 1,538 entities, 24,971 edges (deterministic extraction).

### 3.2 Models

- **LLM**: Qwen 3.5-122B (MoE, ~10B active parameters), quantized Q4_K_M, running on Rascal (UT Austin, NVIDIA GPU)
- **Embeddings**: nomic-embed-text (137M parameters, 768-dim), Ollama local
- **Database**: PostgreSQL 16 with pgvector + Apache AGE 1.5.0, running in K3D

### 3.3 Evaluation Methodology

**Two conditions compared:**
1. **Baseline (Raw Qwen)**: Qwen 3.5-122B with no retrieval context
2. **NeutronOS (Qwen + RAG)**: Same Qwen 3.5-122B with community + organization RAG context injected via system prompt

**Scoring**: LLM-as-judge (self-evaluation) — a second Qwen call evaluates each answer against a gold standard on two dimensions:
- **Accuracy**: Does the answer contain the correct factual claim? (yes/partial/no)
- **Citation**: Does the answer cite a specific source document? (yes/no)

**Benchmark isolation**: Benchmark queries are explicitly excluded from CURI-O's interaction log to prevent the optimization loop from overfitting to evaluation questions.

### 3.4 Question Design

[**TODO**: Replace with domain-expert-authored questions from NE colleagues]

Questions are divided into two categories:
1. **General nuclear engineering** (10 questions) — answerable from public knowledge that may be in the LLM's training data
2. **Facility/corpus-specific** (10 questions) — answerable only from documents in the corpus (ORNL report numbers, specific author attributions, unpublished operational details)

## 4. Results

### 4.1 Retrieval Quality: Fixed vs Semantic Chunking

| Metric | Gen 1 (Fixed, 800-char) | Gen 2 (Semantic) | Improvement |
|--------|-------------------------|-------------------|-------------|
| Average FTS relevance score | 0.603 | 0.787 | **+30.5%** |
| Full-text recall (10 queries) | 30% | 100% | **+70 pp** |
| Vector search recall (10 queries) | 100% | 100% | — |

The semantic chunker's alignment to heading, table, and section boundaries produces dramatically better full-text search results because queries match complete semantic units rather than arbitrary text fragments.

### 4.2 LLM Response Quality: Raw Qwen vs NeutronOS

[**TODO**: Replace with results from domain-expert questions]

Preliminary results with 20 auto-generated questions (LLM-judge scoring):

| Category | Raw Qwen Accuracy | NeutronOS Accuracy | Δ |
|----------|-------------------|---------------------|---|
| General (10 questions) | 90% | 70% | -20% |
| Corpus-specific (10 questions) | 90% | 90% | 0% |
| Overall | 90% | 80% | -10% |

**Key finding**: Qwen 3.5-122B (122B parameters) already knows most published nuclear engineering facts from training data. The current benchmark questions do not adequately test RAG's value because they ask about publicly available knowledge. The real value of RAG emerges for:

1. **Unpublished facility-specific data** — operating procedures, experiment measurements, internal analyses
2. **Temporal queries** — changes between document revisions, recent additions to the corpus
3. **Cross-document synthesis** — connecting facts from multiple documents that the LLM has not seen together
4. **Source traceability** — providing citable document references for regulatory and safety contexts

### 4.3 Federation Performance

| Metric | Value |
|--------|-------|
| Cross-node search latency (VPN) | < 2 seconds |
| Mixed-generation federation | Functional (v1 + v2 nodes interoperate) |
| Generation rollback time | < 1 second |

## 5. Discussion

### 5.1 Context Distraction

We observe that RAG context can occasionally *reduce* accuracy on questions the LLM already knows correctly. When the retrieved context is related but not precisely on-topic, the LLM follows the context rather than its parametric knowledge. This "context distraction" effect suggests that RAG systems need confidence-aware context injection — only inject context when retrieval confidence exceeds a threshold.

### 5.2 The Benchmark Problem

General-purpose LLMs increasingly absorb domain literature into their training data, making it difficult to design fair RAG benchmarks. The most compelling evaluation requires questions that are (a) factually grounded in specific documents, (b) not answerable from training data alone, and (c) authored by domain experts who know what practitioners actually need to look up. We plan to collaborate with nuclear engineering colleagues to develop such a benchmark.

### 5.3 Generational Upgrades as Scientific Method

The blue/green generational model treats every corpus change as a hypothesis: "generation N+1 is better than generation N." CURI-O's statistical significance testing (p < 0.05) ensures that only provably better generations are promoted. This mirrors the scientific method — conjecture, experiment, measure, accept or reject — applied to knowledge base engineering.

## 6. Related Work

[TODO: Compare with LangChain, LlamaIndex, Haystack, Ragas, GraphRAG (Microsoft), etc.]

## 7. Conclusion

NeutronOS demonstrates that domain-specific RAG systems benefit more from structural improvements (semantic chunking, knowledge graph extraction) than from simply adding more text. The 30.5% retrieval improvement from semantic chunking validates the graph-informed approach. The generational blue/green upgrade mechanism provides a production-safe path for continuous improvement, and federation enables cross-facility knowledge sharing with tier-aware access control.

The primary limitation is benchmarking: current auto-generated questions do not adequately test RAG's value for domain experts. Future work will focus on expert-authored benchmarks, dynamic LLM parameter tuning per query intent, and full knowledge graph integration into the query path (hybrid RAG + Cypher traversal).

## Acknowledgments

Ondrej Chvala (UT Austin) for the curated MSR knowledge bundle and hybrid OCR pipeline.
Kevin Clarno (UT Austin) for the computational nuclear engineering research group infrastructure.

## References

[TODO]
