I Made LLMs Read a 500-Page Specification With 100% Accuracy — Without Fine-Tuning

Large language models fail on large specifications. Not because they lack intelligence — because they lack navigation. I tested this. I built a 500-page (+200 pages of AST-Grammars) proprietary language specification, gave it to frontier models, and measured what happened. The result: even with the entire document loaded into a 200k-token context window, models failed to answer 28% of questions — explicitly admitting they couldn't find the information. For cross-referential questions requiring connections between non-adjacent sections, the failure rate climbed to 53%. These aren't obscure trick questions; they're the kind of queries a domain expert answers in five seconds by knowing where to look. 28% of questions 53% The models weren't stupid. They were lost. I spent three months trying to fix this with better prompts. Longer system instructions, chain-of-thought scaffolding, explicit section references. Nothing moved the needle past ~85%. The model would find the definition but miss the constraint in a different chapter. Or find the constraint but miss that an annex overrides it. Then I stopped trying to make the model navigate and built a navigation system instead — 14 pre-compiled indices that encode the expert's mental map of the document. The same models that failed 28% of queries now achieved 100% accuracy on the same questions. No fine-tuning. No retraining. No embedding database. Just structured tooling that tells the model exactly what to read. 100% accuracy What does 100% accuracy mean here? Every answer preserves the full semantic meaning of the source text, every claim is traceable to a specific section via chain address, and every cross-reference is resolved — with zero gaps and zero hallucinations. Not "close enough" — complete, citable, and verifiable. This article describes that system: how it works, what it costs, and why it matters for anyone building AI over structured documents. The full research paper — "Skill Without Training: Deterministic Knowledge Navigation for Large Language Models over Structured Documents" (Chudinov, 2026; DOI: 10.5281/zenodo.18944351) — is available on Zenodo with all indices, benchmark questions, evaluation artifacts, and the open-source MCP server. "Skill Without Training: Deterministic Knowledge Navigation for Large Language Models over Structured Documents" 10.5281/zenodo.18944351 The Cost of Being Lost Every time an LLM answers a question about a document, it incurs three costs: Cost(answer) = navigation_cost + reading_cost + reasoning_cost Cost(answer) = navigation_cost + reading_cost + reasoning_cost For a domain expert, navigation cost is near zero. You know where definitions live. You know which annex contains the admissibility matrix. You know that §2.7.4 cross-references §7.0 for enforcement rules. You don't re-read the entire document for each question — you go straight to the right page. For an LLM without navigation aids, navigation dominates. In my measurements, a typical agentic baseline (Claude Sonnet + grep + read_file tools) spent ~40% of tokens on navigation overhead: searching for the right section, reading wrong fragments, backtracking, re-reading. Fifteen to twenty tool calls per question, 25–35 seconds of wall time, 25–30k tokens consumed — most of it wasted on figuring out where to look rather than understanding what was found. ~40% of tokens where to look understanding what was found Metric Naive Agent With Index System Tool calls per question 15–20 1–2 Wall time 25–35s ~3s Tokens consumed 25–30k ~2–4k Navigation overhead ~40% ~0% Accuracy (hard-36 subset) 72% 100% Metric Naive Agent With Index System Tool calls per question 15–20 1–2 Wall time 25–35s ~3s Tokens consumed 25–30k ~2–4k Navigation overhead ~40% ~0% Accuracy (hard-36 subset) 72% 100% Metric Naive Agent With Index System Metric Metric Naive Agent Naive Agent With Index System With Index System Tool calls per question 15–20 1–2 Tool calls per question Tool calls per question 15–20 15–20 1–2 1–2 Wall time 25–35s ~3s Wall time Wall time 25–35s 25–35s ~3s ~3s Tokens consumed 25–30k ~2–4k Tokens consumed Tokens consumed 25–30k 25–30k ~2–4k ~2–4k Navigation overhead ~40% ~0% Navigation overhead Navigation overhead ~40% ~40% ~0% ~0% Accuracy (hard-36 subset) 72% 100% Accuracy (hard-36 subset) Accuracy (hard-36 subset) 72% 72% 100% 100% 100% The index system doesn't make the model smarter. It eliminates the thing the model is worst at — finding where to look — so all its capacity goes to the thing it's actually good at: reading and reasoning. What the System Actually Does The architecture has three layers. Each does what it does best. Layer Responsibility Implemented By Knowledge encoding Capturing human expertise in stable form Domain experts writing specifications Navigation Finding the right fragments for a query Index compiler + MCP server Inference Reading and reasoning over fragments LLM (unmodified) Layer Responsibility Implemented By Knowledge encoding Capturing human expertise in stable form Domain experts writing specifications Navigation Finding the right fragments for a query Index compiler + MCP server Inference Reading and reasoning over fragments LLM (unmodified) Layer Responsibility Implemented By Layer Layer Responsibility Responsibility Implemented By Implemented By Knowledge encoding Capturing human expertise in stable form Domain experts writing specifications Knowledge encoding Knowledge encoding Capturing human expertise in stable form Capturing human expertise in stable form Domain experts writing specifications Domain experts writing specifications Navigation Finding the right fragments for a query Index compiler + MCP server Navigation Navigation Finding the right fragments for a query Finding the right fragments for a query Index compiler + MCP server Index compiler + MCP server Inference Reading and reasoning over fragments LLM (unmodified) Inference Inference Reading and reasoning over fragments Reading and reasoning over fragments LLM (unmodified) LLM (unmodified) Humans are good at defining meaning, bad at memorizing 500-page documents. Algorithms are good at indexing and retrieval, bad at reasoning. LLMs are good at reading and synthesizing, bad at navigating large spaces without drift. The system respects these asymmetries. The 3-Pass Compiler A compilation pipeline ingests the raw specification and produces machine-readable indices: Pass Input Output When 1 — Structure Raw markdown (~500 pages) Chain addresses, section graph, cross-references, vocabulary Build time 2 — Semantics Structured sections 14 aspect indices, ontological roles, keyword maps, Terms & Definitions Build time 3 — Normative Semantic units MUST/SHOULD/MAY extraction, enforcement graph, admissibility rules Query time Pass Input Output When 1 — Structure Raw markdown (~500 pages) Chain addresses, section graph, cross-references, vocabulary Build time 2 — Semantics Structured sections 14 aspect indices, ontological roles, keyword maps, Terms & Definitions Build time 3 — Normative Semantic units MUST/SHOULD/MAY extraction, enforcement graph, admissibility rules Query time Pass Input Output When Pass Pass Input Input Output Output When When 1 — Structure Raw markdown (~500 pages) Chain addresses, section graph, cross-references, vocabulary Build time 1 — Structure 1 — Structure 1 — Structure Raw markdown (~500 pages) Raw markdown (~500 pages) Chain addresses, section graph, cross-references, vocabulary Chain addresses, section graph, cross-references, vocabulary Build time Build time 2 — Semantics Structured sections 14 aspect indices, ontological roles, keyword maps, Terms & Definitions Build time 2 — Semantics 2 — Semantics 2 — Semantics Structured sections Structured sections 14 aspect indices, ontological roles, keyword maps, Terms & Definitions 14 aspect indices, ontological roles, keyword maps, Terms & Definitions Build time Build time 3 — Normative Semantic units MUST/SHOULD/MAY extraction, enforcement graph, admissibility rules Query time 3 — Normative 3 — Normative 3 — Normative Semantic units Semantic units MUST/SHOULD/MAY extraction, enforcement graph, admissibility rules MUST/SHOULD/MAY extraction, enforcement graph, admissibility rules Query time Query time Passes 1–2 run once at build time (~2–3 minutes on commodity hardware). Pass 3 runs at query time inside the MCP server, scoring retrieved fragments by normative weight. Chain Addresses: A Coordinate System for Knowledge ISO-grade documents already contain a latent coordinate system: deep hierarchical numbering, lettered paragraphs, tables, explicit cross-references. I operationalized it into what I call chain addresses: chain addresses 2.5.3 — section heading + first paragraph 2.5.3/A. — a specific lettered paragraph 2.5.3/(A)-(F) — a paragraph range 2.5.3/all — full subtree extraction 2.5.3/table-1 — a structured table 2.5.3 — section heading + first paragraph 2.5.3 2.5.3/A. — a specific lettered paragraph 2.5.3/A. 2.5.3/(A)-(F) — a paragraph range 2.5.3/(A)-(F) 2.5.3/all — full subtree extraction 2.5.3/all 2.5.3/table-1 — a structured table 2.5.3/table-1 A chain address resolves through the linear backbone into (file, line-span, node-type), enabling single-pass extraction. Every piece of retrieved content has a stable coordinate — no embedding drift, no chunk boundary ambiguity. (file, line-span, node-type) 14 Index Artifacts The compiler produces 14 indices grouped into four architectures: Architecture Indices What it solves Unit-based 11 Concept routing: "what to read for this concept?" Graph-based 1 Discovery: "what else is linked to this section?" Linear / inverted 1 Physical resolution + reverse lookup + vocabulary Structural 1 Admissibility: "what is allowed/forbidden where?" Architecture Indices What it solves Unit-based 11 Concept routing: "what to read for this concept?" Graph-based 1 Discovery: "what else is linked to this section?" Linear / inverted 1 Physical resolution + reverse lookup + vocabulary Structural 1 Admissibility: "what is allowed/forbidden where?" Architecture Indices What it solves Architecture Architecture Indices Indices What it solves What it solves Unit-based 11 Concept routing: "what to read for this concept?" Unit-based Unit-based Unit-based 11 11 Concept routing: "what to read for this concept?" Concept routing: "what to read for this concept?" Graph-based 1 Discovery: "what else is linked to this section?" Graph-based Graph-based Graph-based 1 1 Discovery: "what else is linked to this section?" Discovery: "what else is linked to this section?" Linear / inverted 1 Physical resolution + reverse lookup + vocabulary Linear / inverted Linear / inverted Linear / inverted 1 1 Physical resolution + reverse lookup + vocabulary Physical resolution + reverse lookup + vocabulary Structural 1 Admissibility: "what is allowed/forbidden where?" Structural Structural Structural 1 1 Admissibility: "what is allowed/forbidden where?" Admissibility: "what is allowed/forbidden where?" The 11 unit-based indices encode different aspects of the document: physical types, semantic layers, design rationale, grammar, behavioral rules, philosophical foundations, terminology, and ontological routing. Seven are manually curated by a domain expert; six are auto-generated from document structure. aspects Combined, the indices contain 396 units — each a reading program that tells the MCP server exactly what to extract and in what order. 396 units The Ontological Trick This is the part that separates the system from keyword search. The same word means different things depending on what you're asking. "Rule" in a programming language specification could mean: WHAT: the type definition of a rule construct HOW: the grammar and body syntax for declaring rules WHY: the design rationale — why rules exist as a distinct type WHEN: the conditions and triggers — when rules fire or apply WHERE: the constraint matrices — where rules are admissible WHAT: the type definition of a rule construct WHAT HOW: the grammar and body syntax for declaring rules HOW WHY: the design rationale — why rules exist as a distinct type WHY WHEN: the conditions and triggers — when rules fire or apply WHEN WHERE: the constraint matrices — where rules are admissible WHERE A keyword search for "rule" returns all of these, forcing the model to sift through pages of mixed-relevance content. The ontological funnel routes the same keyword to different reading plans depending on the question type: different reading plans Query intent Ontological role Prioritized indices What gets retrieved "What is a rule?" WHAT onma, phya, sema Definition sections, type classification "How to declare a rule?" HOW bsyn, grma, bhva Grammar rules, body syntax, examples "Why do rules exist?" WHY ont, desa, phla Design rationale, philosophical foundations "When does a rule fire?" WHEN bhva, desa Trigger conditions, execution semantics "Where are rules admissible?" WHERE grix, onma Admissibility matrices, placement constraints Query intent Ontological role Prioritized indices What gets retrieved "What is a rule?" WHAT onma, phya, sema Definition sections, type classification "How to declare a rule?" HOW bsyn, grma, bhva Grammar rules, body syntax, examples "Why do rules exist?" WHY ont, desa, phla Design rationale, philosophical foundations "When does a rule fire?" WHEN bhva, desa Trigger conditions, execution semantics "Where are rules admissible?" WHERE grix, onma Admissibility matrices, placement constraints Query intent Ontological role Prioritized indices What gets retrieved Query intent Query intent Ontological role Ontological role Prioritized indices Prioritized indices What gets retrieved What gets retrieved "What is a rule?" WHAT onma, phya, sema Definition sections, type classification "What is a rule?" "What is a rule?" WHAT WHAT onma, phya, sema onma, phya, sema onma phya sema Definition sections, type classification Definition sections, type classification "How to declare a rule?" HOW bsyn, grma, bhva Grammar rules, body syntax, examples "How to declare a rule?" "How to declare a rule?" HOW HOW bsyn, grma, bhva bsyn, grma, bhva bsyn grma bhva Grammar rules, body syntax, examples Grammar rules, body syntax, examples "Why do rules exist?" WHY ont, desa, phla Design rationale, philosophical foundations "Why do rules exist?" "Why do rules exist?" WHY WHY ont, desa, phla ont, desa, phla ont desa phla Design rationale, philosophical foundations Design rationale, philosophical foundations "When does a rule fire?" WHEN bhva, desa Trigger conditions, execution semantics "When does a rule fire?" "When does a rule fire?" WHEN WHEN bhva, desa bhva, desa bhva desa Trigger conditions, execution semantics Trigger conditions, execution semantics "Where are rules admissible?" WHERE grix, onma Admissibility matrices, placement constraints "Where are rules admissible?" "Where are rules admissible?" WHERE WHERE grix, onma grix, onma grix onma Admissibility matrices, placement constraints Admissibility matrices, placement constraints The ontological role index (onma) contains 69 units across 22 constructs, each named _ — for example, rule_what, rule_how, rule_why. One keyword, five completely different navigation paths. onma 69 units _ rule_what rule_how rule_why The system classifies each query into one of five roles (WHAT / WHY / HOW / WHEN / WHERE) and uses this classification as a routing signal, not just a filter. Chains whose ontological intent matches the query receive a priority boost; mismatched chains are demoted. The result: the model receives focused, role-specific content rather than everything that mentions the keyword. routing signal Reading Programs, Not Keyword Matches A unit in the index is not just a pointer. It's a reading program — an explicit recipe for how an expert would consume the relevant content, encoded as an ordered sequence of chain addresses: reading program { "delegate": { "keywords": ["delegate", "boundary", "cross-border", "trust"], "seq": [ {"Order": 1, "Tier": 1, "chain": ["2.7.4"], "Note": "Definition"}, {"Order": 2, "Tier": 2, "chain": ["2.7.4.3/all"], "Note": "Constraints"}, {"Order": 3, "Tier": 3, "chain": ["A.7"], "Note": "Registry entry"} ] } } { "delegate": { "keywords": ["delegate", "boundary", "cross-border", "trust"], "seq": [ {"Order": 1, "Tier": 1, "chain": ["2.7.4"], "Note": "Definition"}, {"Order": 2, "Tier": 2, "chain": ["2.7.4.3/all"], "Note": "Constraints"}, {"Order": 3, "Tier": 3, "chain": ["A.7"], "Note": "Registry entry"} ] } } The important fields: Order: strict reading priority — definition first, constraints second, registry last. Tier (1–4): what to drop under budget pressure. Tier 4 goes first; Tier 1 (definitions) is protected always. Chain: the stable coordinate pointing to the exact text. Order: strict reading priority — definition first, constraints second, registry last. Order Tier (1–4): what to drop under budget pressure. Tier 4 goes first; Tier 1 (definitions) is protected always. Tier Chain: the stable coordinate pointing to the exact text. Chain When a query matches multiple units, the system builds a weighted reading plan: all candidate chains are scored, deduplicated, subsumed (if a parent section covers a child), grouped by file, and extracted in a single pass. The ranking formula: weighted reading plan effectivePriority = metaWeight × 30 + order × 10 − ontoMatch × 15 + demotions effectivePriority = metaWeight × 30 + order × 10 − ontoMatch × 15 + demotions This is not similarity search. It's a compiled reading plan — the kind of plan a domain expert builds mentally in two seconds and an LLM cannot build at all. The Keyword Enrichment Pipeline User vocabulary rarely matches spec vocabulary. The system bridges this gap with a three-phase enrichment pipeline: T&D expansion: Look up each input keyword in the specification's Terms & Definitions tables. Extract backtick-quoted terms and bold phrases from definition text. These become candidate expansions. Co-occurrence: Find index units that match ≥2 input keywords. Extract all other keywords from those units. These become co-occurrence candidates. Waterfall confirmation: Run a second pass. Keep only candidates that actually appear in units matching ≥2 of the expanded keyword set. This eliminates noise. T&D expansion: Look up each input keyword in the specification's Terms & Definitions tables. Extract backtick-quoted terms and bold phrases from definition text. These become candidate expansions. T&D expansion Co-occurrence: Find index units that match ≥2 input keywords. Extract all other keywords from those units. These become co-occurrence candidates. Co-occurrence Waterfall confirmation: Run a second pass. Keep only candidates that actually appear in units matching ≥2 of the expanded keyword set. This eliminates noise. Waterfall confirmation Example: query record immutability. The word "immutability" doesn't appear in any heading. Phase 1 enriches record → block type, derived type. Phase 2 finds co-occurring metadata, flags, constraints. Phase 3 confirms all candidates. The system reaches record → derived type → metadata flags → immutability rule in Annex A — a four-hop navigation chain that no keyword search would find. record immutability record block type derived type metadata flags constraints record → derived type → metadata flags → immutability rule in Annex A The Normative-Driven Pipeline (NDP) Normative specifications speak in RFC 2119: MUST, SHALL, SHOULD, MAY, MUST NOT. These aren't style choices — they're machine-readable signals: Keyword NDP treatment Priority MUST / SHALL Enrich + elevate High SHOULD Enrich, medium weight Medium MAY Conditional, include when explicitly relevant Low MUST NOT / SHALL NOT Filter + elevate as prohibition High Keyword NDP treatment Priority MUST / SHALL Enrich + elevate High SHOULD Enrich, medium weight Medium MAY Conditional, include when explicitly relevant Low MUST NOT / SHALL NOT Filter + elevate as prohibition High Keyword NDP treatment Priority Keyword Keyword NDP treatment NDP treatment Priority Priority MUST / SHALL Enrich + elevate High MUST / SHALL MUST / SHALL Enrich + elevate Enrich + elevate High High SHOULD Enrich, medium weight Medium SHOULD SHOULD Enrich, medium weight Enrich, medium weight Medium Medium MAY Conditional, include when explicitly relevant Low MAY MAY Conditional, include when explicitly relevant Conditional, include when explicitly relevant Low Low MUST NOT / SHALL NOT Filter + elevate as prohibition High MUST NOT / SHALL NOT MUST NOT / SHALL NOT Filter + elevate as prohibition Filter + elevate as prohibition High High When the user asks "what rules govern X?" — paragraphs containing MUST get promoted above paragraphs containing MAY. Under tight token budgets, low-normative paragraphs are dropped first. The result: the model receives the most authoritative content first, always. For non-RFC documents (GDPR, corporate policies), NDP extends with a fallback cue layer: deontic verbs (required, prohibited, ensure), constraint templates (only if, unless, no later than), and structural priors (headings like Requirements, Controls, Exceptions). required, prohibited, ensure only if, unless, no later than Requirements, Controls, Exceptions Results Accuracy Progression The system was built incrementally. Each component's contribution was measured against a fixed 10-question benchmark: Stage Component Added Accuracy Tokens per Query Pre-index Grep + read_file baseline ~70% ~24k Run #1 Aspect indices + chain addressing ~87% ~10k Run #4 Cross-reference graph expansion ~95% ~6k Run #13 Tier-weighted scoring model 100% ~3.8k Final NDP + line-level filter 100% ~2k Stage Component Added Accuracy Tokens per Query Pre-index Grep + read_file baseline ~70% ~24k Run #1 Aspect indices + chain addressing ~87% ~10k Run #4 Cross-reference graph expansion ~95% ~6k Run #13 Tier-weighted scoring model 100% ~3.8k Final NDP + line-level filter 100% ~2k Stage Component Added Accuracy Tokens per Query Stage Stage Component Added Component Added Accuracy Accuracy Tokens per Query Tokens per Query Pre-index Grep + read_file baseline ~70% ~24k Pre-index Pre-index Grep + read_file baseline Grep + read_file baseline ~70% ~70% ~24k ~24k Run #1 Aspect indices + chain addressing ~87% ~10k Run #1 Run #1 Aspect indices + chain addressing Aspect indices + chain addressing ~87% ~87% ~10k ~10k Run #4 Cross-reference graph expansion ~95% ~6k Run #4 Run #4 Cross-reference graph expansion Cross-reference graph expansion ~95% ~95% ~6k ~6k Run #13 Tier-weighted scoring model 100% ~3.8k Run #13 Run #13 Tier-weighted scoring model Tier-weighted scoring model 100% 100% 100% ~3.8k ~3.8k Final NDP + line-level filter 100% ~2k Final Final NDP + line-level filter NDP + line-level filter 100% 100% 100% ~2k ~2k 100% accuracy was reached at Run #13 and maintained through all subsequent runs. Later components improved precision (upgrading inferred matches to direct matches) without affecting accuracy. precision Full Benchmark: 246 Questions × 5 Runs Each Category Questions MCP Accuracy Naive Full-Context Failure A — Factual 82 100% 27% B — Cross-referential 74 100% 53% C — Abstract/Philosophical 45 100% 0% D — Normative 45 100% 43% Total 246 100% 30% Category Questions MCP Accuracy Naive Full-Context Failure A — Factual 82 100% 27% B — Cross-referential 74 100% 53% C — Abstract/Philosophical 45 100% 0% D — Normative 45 100% 43% Total 246 100% 30% Category Questions MCP Accuracy Naive Full-Context Failure Category Category Questions Questions MCP Accuracy MCP Accuracy Naive Full-Context Failure Naive Full-Context Failure A — Factual 82 100% 27% A — Factual A — Factual 82 82 100% 100% 27% 27% B — Cross-referential 74 100% 53% B — Cross-referential B — Cross-referential 74 74 100% 100% 53% 53% 53% C — Abstract/Philosophical 45 100% 0% C — Abstract/Philosophical C — Abstract/Philosophical 45 45 100% 100% 0% 0% D — Normative 45 100% 43% D — Normative D — Normative 45 45 100% 100% 43% 43% 43% Total 246 100% 30% Total Total Total 246 246 246 100% 100% 100% 30% 30% 30% The naive baseline had access to the entire specification (~178k tokens in a 200k context window) and still failed 30% of the time. Category B (cross-referential) was worst: questions requiring connections between non-adjacent sections hit 53% failure rate. The model could not reliably cross-reference by scanning alone — it needed deterministic navigation. Cost Comparison Metric MCP (full system) Agentic Baseline Full-Context Baseline Accuracy (hard-36) 100% 72% 72% Spec tokens per query ~2–4k 25–30k 178k Token reduction factor — 7× 15× Tool calls 1–2 15–20 0 Wall time ~3s 25–35s varies Metric MCP (full system) Agentic Baseline Full-Context Baseline Accuracy (hard-36) 100% 72% 72% Spec tokens per query ~2–4k 25–30k 178k Token reduction factor — 7× 15× Tool calls 1–2 15–20 0 Wall time ~3s 25–35s varies Metric MCP (full system) Agentic Baseline Full-Context Baseline Metric Metric MCP (full system) MCP (full system) Agentic Baseline Agentic Baseline Full-Context Baseline Full-Context Baseline Accuracy (hard-36) 100% 72% 72% Accuracy (hard-36) Accuracy (hard-36) 100% 100% 100% 72% 72% 72% 72% Spec tokens per query ~2–4k 25–30k 178k Spec tokens per query Spec tokens per query ~2–4k ~2–4k 25–30k 25–30k 178k 178k Token reduction factor — 7× 15× Token reduction factor Token reduction factor — — 7× 7× 7× 15× 15× 15× Tool calls 1–2 15–20 0 Tool calls Tool calls 1–2 1–2 15–20 15–20 0 0 Wall time ~3s 25–35s varies Wall time Wall time ~3s ~3s 25–35s 25–35s varies varies Two baselines, two ratios. Against the agentic baseline (grep + read_file loop): 7× fewer tokens. Against the full-context baseline (entire spec cached): 15× fewer tokens. Both confirm the same thing — structural indices eliminate the dominant cost factor. Multi-Model Validation Model Benchmark Accuracy Claude Sonnet 4 Hard-36 (Naive) 72% Claude Sonnet 4 246-question full (Naive) ~70% Claude Opus 4.6 Hard-36 (MCP) 100% Claude Opus 4.6 Conceptual-10 (MCP) 100% (quality: 0.967) Claude Haiku 4.5 Hard-36 (MCP, with prompt patches) 100% Model Benchmark Accuracy Claude Sonnet 4 Hard-36 (Naive) 72% Claude Sonnet 4 246-question full (Naive) ~70% Claude Opus 4.6 Hard-36 (MCP) 100% Claude Opus 4.6 Conceptual-10 (MCP) 100% (quality: 0.967) Claude Haiku 4.5 Hard-36 (MCP, with prompt patches) 100% Model Benchmark Accuracy Model Model Benchmark Benchmark Accuracy Accuracy Claude Sonnet 4 Hard-36 (Naive) 72% Claude Sonnet 4 Claude Sonnet 4 Hard-36 (Naive) Hard-36 (Naive) 72% 72% Claude Sonnet 4 246-question full (Naive) ~70% Claude Sonnet 4 Claude Sonnet 4 246-question full (Naive) 246-question full (Naive) ~70% ~70% Claude Opus 4.6 Hard-36 (MCP) 100% Claude Opus 4.6 Claude Opus 4.6 Hard-36 (MCP) Hard-36 (MCP) 100% 100% 100% Claude Opus 4.6 Conceptual-10 (MCP) 100% (quality: 0.967) Claude Opus 4.6 Claude Opus 4.6 Conceptual-10 (MCP) Conceptual-10 (MCP) 100% (quality: 0.967) 100% (quality: 0.967) 100% Claude Haiku 4.5 Hard-36 (MCP, with prompt patches) 100% Claude Haiku 4.5 Claude Haiku 4.5 Hard-36 (MCP, with prompt patches) Hard-36 (MCP, with prompt patches) 100% 100% 100% Haiku — the weakest model tested — achieved 100% accuracy under MCP after three targeted prompt patches (fallback escalation, exhaustive enumeration, normative nuance check). With 53% fewer tokens than Opus. This was the result that convinced me the architecture was real, not an artifact of model capability. The cheapest model with proper navigation matches the most expensive model without it. When Keywords Fail: Topology Holds Five of ten benchmark queries require inference — there is no direct keyword match anywhere in the document headings. These are the queries that separate structured navigation from keyword search: inference Query Missing match How the system resolves it Record immutability "immutability" absent from any heading record → derived type → metadata flags → Annex A classification Enforcement follow "follow" absent from enforcement index follow → enrichment co-occurrence → heading scan of §7.0 Surrogate evolution "evolution" absent from any index onto=WHY boosts design principles → §1.4.6 "deterministic transition" Layer 3→4 boundary "level 3/4" not index keywords T&D enrichment adds "conway space", "domain boundary" → §5.0.2 new + binder gap Two unrelated constructs, zero keyword overlap binder (§2.6.2) → via references → new (§3.15.3) → boundary modifier (§3.3.7) Query Missing match How the system resolves it Record immutability "immutability" absent from any heading record → derived type → metadata flags → Annex A classification Enforcement follow "follow" absent from enforcement index follow → enrichment co-occurrence → heading scan of §7.0 Surrogate evolution "evolution" absent from any index onto=WHY boosts design principles → §1.4.6 "deterministic transition" Layer 3→4 boundary "level 3/4" not index keywords T&D enrichment adds "conway space", "domain boundary" → §5.0.2 new + binder gap Two unrelated constructs, zero keyword overlap binder (§2.6.2) → via references → new (§3.15.3) → boundary modifier (§3.3.7) Query Missing match How the system resolves it Query Query Missing match Missing match How the system resolves it How the system resolves it Record immutability "immutability" absent from any heading record → derived type → metadata flags → Annex A classification Record immutability Record immutability "immutability" absent from any heading "immutability" absent from any heading record → derived type → metadata flags → Annex A classification record → derived type → metadata flags → Annex A classification Enforcement follow "follow" absent from enforcement index follow → enrichment co-occurrence → heading scan of §7.0 Enforcement follow Enforcement follow "follow" absent from enforcement index "follow" absent from enforcement index follow → enrichment co-occurrence → heading scan of §7.0 follow → enrichment co-occurrence → heading scan of §7.0 Surrogate evolution "evolution" absent from any index onto=WHY boosts design principles → §1.4.6 "deterministic transition" Surrogate evolution Surrogate evolution "evolution" absent from any index "evolution" absent from any index onto=WHY boosts design principles → §1.4.6 "deterministic transition" onto=WHY boosts design principles → §1.4.6 "deterministic transition" Layer 3→4 boundary "level 3/4" not index keywords T&D enrichment adds "conway space", "domain boundary" → §5.0.2 Layer 3→4 boundary Layer 3→4 boundary "level 3/4" not index keywords "level 3/4" not index keywords T&D enrichment adds "conway space", "domain boundary" → §5.0.2 T&D enrichment adds "conway space", "domain boundary" → §5.0.2 new + binder gap Two unrelated constructs, zero keyword overlap binder (§2.6.2) → via references → new (§3.15.3) → boundary modifier (§3.3.7) new + binder gap new + binder gap Two unrelated constructs, zero keyword overlap Two unrelated constructs, zero keyword overlap binder (§2.6.2) → via references → new (§3.15.3) → boundary modifier (§3.3.7) binder (§2.6.2) → via references → new (§3.15.3) → boundary modifier (§3.3.7) binder via new Every resolution chain is fully deterministic. Given the same indices and query, the pipeline produces the same reading plan every time. I ran each of these queries 5 times — same chains, same files, same line ranges. No variance. Why This Is Not RAG This system has zero embedding-based retrieval. No vector database. No cosine similarity. No chunk boundaries. The distinction matters because normative documents break RAG's core assumptions: Standard RAG This system Unit of retrieval: chunk (fixed-size substring) Unit of retrieval: chain address (structurally meaningful fragment) Boundaries: token count Boundaries: document's own structure (§, paragraphs, tables) Ranking: embedding similarity Ranking: compiled priority (tier × order × ontological role) Cross-references: invisible (may span chunks) Cross-references: compiled into a directed graph (267 edges) Normative modality: invisible Normative modality: machine-readable priority signal Same query → same retrieval? No (stochastic) Same query → same retrieval? Yes (deterministic) Standard RAG This system Unit of retrieval: chunk (fixed-size substring) Unit of retrieval: chain address (structurally meaningful fragment) Boundaries: token count Boundaries: document's own structure (§, paragraphs, tables) Ranking: embedding similarity Ranking: compiled priority (tier × order × ontological role) Cross-references: invisible (may span chunks) Cross-references: compiled into a directed graph (267 edges) Normative modality: invisible Normative modality: machine-readable priority signal Same query → same retrieval? No (stochastic) Same query → same retrieval? Yes (deterministic) Standard RAG This system Standard RAG Standard RAG This system This system Unit of retrieval: chunk (fixed-size substring) Unit of retrieval: chain address (structurally meaningful fragment) Unit of retrieval: chunk (fixed-size substring) Unit of retrieval: chunk (fixed-size substring) chunk Unit of retrieval: chain address (structurally meaningful fragment) Unit of retrieval: chain address (structurally meaningful fragment) chain address Boundaries: token count Boundaries: document's own structure (§, paragraphs, tables) Boundaries: token count Boundaries: token count Boundaries: document's own structure (§, paragraphs, tables) Boundaries: document's own structure (§, paragraphs, tables) Ranking: embedding similarity Ranking: compiled priority (tier × order × ontological role) Ranking: embedding similarity Ranking: embedding similarity Ranking: compiled priority (tier × order × ontological role) Ranking: compiled priority (tier × order × ontological role) Cross-references: invisible (may span chunks) Cross-references: compiled into a directed graph (267 edges) Cross-references: invisible (may span chunks) Cross-references: invisible (may span chunks) Cross-references: compiled into a directed graph (267 edges) Cross-references: compiled into a directed graph (267 edges) Normative modality: invisible Normative modality: machine-readable priority signal Normative modality: invisible Normative modality: invisible Normative modality: machine-readable priority signal Normative modality: machine-readable priority signal Same query → same retrieval? No (stochastic) Same query → same retrieval? Yes (deterministic) Same query → same retrieval? No (stochastic) Same query → same retrieval? No (stochastic) Same query → same retrieval? Yes (deterministic) Same query → same retrieval? Yes (deterministic) Yes (deterministic) Lewis et al. (2020) introduced RAG as a general framework for combining retrieval with generation. Most implementations use dense passage retrieval or embedding similarity — approaches that work well for natural-language corpora but struggle with normative documents. A chunk boundary landing between a MUST clause and its exception renders both useless. Embedding similarity cannot distinguish a section that defines "delegate" from one that merely mentions it. defines mentions Liu et al. (2024) documented the "Lost in the Middle" effect — as context grows, models lose track of information placed far from the edges. My full-context baseline (178k tokens, 53% failure on cross-referential questions) is a textbook demonstration. The fix isn't smaller context — it's targeted context. targeted An enhanced RAG system — with structure-aware chunking, normative metadata injection, cross-reference traversal — converges toward what I built. Microsoft's GraphRAG (Edge et al., 2024) takes a step in this direction by building entity-relationship graphs, but still relies on LLM-extracted entities rather than compiled structural metadata. The enhancements needed to make RAG competitive on normative documents are the components of this system. are The Reverse Navigation Property Every chain address in the system can be traced backward: from the extracted text to the unit that selected it, to the index that contained it, to the ontological role that routed it. This means the system can answer not only "what should I read?" but "why am I reading this?" why I work in compliance. When an AI system says "§5.0.2 specifies a four-layer domain model," the first question from any auditor is: That §5.0.2 actually says this. That §5.0.2 was selected for a defensible reason (not random chunk retrieval). That no conflicting section was excluded. That §5.0.2 actually says this. That §5.0.2 was selected for a defensible reason (not random chunk retrieval). That no conflicting section was excluded. The index system provides all three. The reading plan is a logged, inspectable artifact — every query produces a deterministic chain of decisions that can be replayed and audited. Practical Implications Who This Works For The system targets ISO-grade normative documents: standards, regulations, technical specifications, compliance frameworks. Documents that exhibit: Deep hierarchical numbering (multi-level sections) Explicit cross-references ("see §X.Y.Z") Normative modality (MUST/SHOULD/MAY or equivalents) Annexes with classification matrices Separation of semantic, structural, and behavioral layers Deep hierarchical numbering (multi-level sections) Explicit cross-references ("see §X.Y.Z") Normative modality (MUST/SHOULD/MAY or equivalents) Annexes with classification matrices Separation of semantic, structural, and behavioral layers This includes: ISO/IEC standards, EU regulations (GDPR, DORA, AI Act), RFCs, NIST frameworks, technical manuals, corporate policy documents, patent specifications. What It Costs The initial creation of aspect indices is a one-time investment: approximately 20–30 hours of domain expert work per document type. Once the index schema is established for a document class (e.g., "EU regulation" or "ISO language specification"), new documents of the same type require significantly less effort — the aspect structure, keyword patterns, and ontological roles transfer across instances. After compilation, the system runs queries at ~3 seconds and ~2–4k tokens each. No GPU required. No embedding model beyond a lightweight relevance gate (~22 MB). The MCP server is ~4,850 lines of TypeScript. What It Does Not Do The system assumes structural discipline. Unstructured blog posts, narrative prose, or documents without consistent heading hierarchies are not candidates. The indices reflect the document as written — if the specification contains contradictions or omissions, the system faithfully returns those flawed passages. It makes content addressable; it does not perform semantic repair. Data Integrity The evaluation corpus — the E.L.I.A. specification (~500 pages) — is guaranteed not to appear in any LLM training corpus. It is a private, unpublished language specification developed as part of this research, hosted in a private repository with no web-crawlable presence. This eliminates data contamination risk entirely and ensures that every correct answer is attributable to the navigation architecture, not memorized training data. guaranteed not to appear in any LLM training corpus Additional controls: scorer ≠ answerer (separate sessions), raw dumps preserved before scoring, all 246 questions authored before any benchmark runs, 5× stability runs per question, 800+ evaluation artifacts across 3 models and 4 evaluation modes. Conclusion When I started this project, I assumed the hard part would be making the model understand normative language — the interplay of MUST and MAY, the way an annex can override a main-body clause, the implicit relationships between constructs defined 200 pages apart. I was wrong. The model understood all of that just fine. It failed because it couldn't find the relevant paragraphs. find 100% accuracy on 246 questions across three models — versus 70% for the same models reading the same document without indices. The 7× token reduction isn't an optimization; it's the difference between a system that works and one that fails on every third question. The architecture is deliberately simple. No vector database, no fine-tuning pipeline, no ML training loop. A compiler that runs in 2 minutes, 14 JSON index files, and a TypeScript MCP server. The indices I built for the E.L.I.A. specification have worked unchanged across four model generations — from Claude 3.5 Sonnet through Claude Opus 4.6, plus GPT-4o and Gemini — because the skill isn't in the weights. It's in the map. The companion repository contains approximate source code of the MCP server, redacted indices, benchmark runners, and 800+ evaluation artifacts — published for review and study purposes under a non-commercial license. The full specification and normative index content remain proprietary. If you work with structured documents — regulatory, legal, technical, medical — the architecture and tooling patterns are yours to study and adapt. companion repository This article is based on the research paper "Skill Without Training: Deterministic Knowledge Navigation for Large Language Models over Structured Documents" (Chudinov, 2026), available on Zenodo. The companion repository includes the MCP spec-reader server, all 14 indices, benchmark questions, evaluation artifacts, and the index compiler. This article is based on the research paper "Skill Without Training: Deterministic Knowledge Navigation for Large Language Models over Structured Documents" (Chudinov, 2026), available on Zenodo. The companion repository includes the MCP spec-reader server, all 14 indices, benchmark questions, evaluation artifacts, and the index compiler. Zenodo companion repository References References P. Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS, 2020. N. F. Liu et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 12, 2024. D. Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130, 2024. S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, 1997. P. Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS, 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. N. F. Liu et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 12, 2024. Lost in the Middle: How Language Models Use Long Contexts. D. Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130, 2024. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, 1997. Key words for use in RFCs to Indicate Requirement Levels.