---

What This Is

The idea is simple and it came from frustration with the standard LLM behavior: the model answers confidently whether or not it knows the answer. The confidence signal is useless. You cant tell a correct answer from a hallucination by the tone of the response — both sound identical.

So the project is: build a small self-hosted model that does the opposite. A model whose defining trait is checking before speaking. If it doesnt know, it says so. If the answer contradicts what it can verify, it flags that too. The name i keep using internally is the doubting thomas model — it wont believe the answer until it touches the wound.

The architecture has a name now: shmodels (self-hosted models). The working definition:

A self-hosted small model (shmodel) that knows exactly what it knows, knows when it truly doesnt know, and never produces a confident wrong answer. Verified and corrected by frontier models (fmodels), and over time, by other shmodel instances.

The fmodels — DeepSeek, Claude, Kimi — are not replaced. They are the evaluators, the coaches, the final arbiters. The shmodel is the fast local workhorse that handles recurring tasks cheaply. The fmodel is the oversight layer that keeps it honest.

---

The Two-Layer Architecture

This is the core mechanism. Two layers, both active during a response.

Layer 1 — Self-Check (per response)

Every time the model receives a task, it runs a chain of checks before outputting anything:

Task received

    → [1] Skills list check — is this in scope?

    → [2] Capability inventory check — is this a known gap?

    → [3] jvdb (justin's vector db) grounding query — what does the knowledge base say?

    → [4] Generate candidate answer

    → [5] Delta check: candidate vs. jvdb grounding

         → delta low  → return answer + confidence tag

         → delta high → ESCALATE to fmodel

                           → fmodel verdict + correction

                           → update inventory

                           → save training record to jvdb

                           → return verified answer (or UNKNOWN)

The key exits: the model can leave with UNKNOWN at step 1, 2, or 5. UNKNOWN is not a failure — it is the correct answer when the model doesn’t know. The failure is a confident wrong answer.

Layer 2 — IDK Honesty Verification (via fmodel – frontier model)

This is the check on the check. When the shmodel returns UNKNOWN, that claim is not taken at face value. The fmodel cross-checks it against the capability inventory:

shmodel returns UNKNOWN

    → fmodel checks capability inventory

         → inventory says KNOWN    → false IDK (hiding) → negative training signal

         → inventory says UNKNOWN  → correct IDK (honest) → positive signal

         → inventory says UNTESTED → queue as capability probe

A model that hides behind UNKNOWN to avoid hard tasks gets caught here. This is the honesty loop. UNKNOWN has to mean something — it is a commitment, not an escape hatch.

---

The Capability Inventory

The capability inventory is a living map of what each model actually knows, proven through testing. It lives in ChromaDB on my server as a jvdb collection: shmodels_capability_inventory.

Every topic a model is tested on gets an inventory entry with one of five states:

State	Meaning
KNOWN	Passed tests at ≥ 90% accuracy
PARTIAL	Right some of the time — weaknesses logged
GAP	Consistently fails or hallucinates here
UNTESTED	Topic exists in jvdb but no test has run yet
SCOPE_EXCLUDED	Outside declared skill boundary — not expected to know

The inventory is self-directing. Every test run produces UNTESTED items that automatically queue as probes for the next run. The system finds its own blind spots.

Before the inventory is populated, there are three jvdb collections that need to be built:

• shmodels_training (self hosted models) — every test result: prompt, candidate answer, grounding chunks, fmodel verdict, training signal
• shmodels_capability_inventory — the state map above
• shmodels_backlog_probes — the queue of UNTESTED probes waiting to run

---

The Model Classification Problem

Not all small models are the same kind of model. Before any evaluation, a model is classified at a capability gate — a binary architectural property that determines which track it belongs to.

The gate is tool calling support.

A model either supports it or it doesn’t. Cant be fixed with prompting. Its a training property.

Property	Track A — Agent Models	Track B — Raw Reasoning Models
Tool calling	Yes	No
Usable via OpenCode / agent-loop	Yes	No — direct Ollama /api/chat only
Self-check loop (Layers 1 & 2)	Full loop	Partial — no tool-mediated jvdb query
Instruction following (constrained output)	Strong	Weak — trained for reasoning, not instruction
Eval suite	Coding, grammar, JSON, jvdb	Logic puzzles, multi-step reasoning, math

This split matters because the R1-Distill failure (documented below) happened partly because a Track B model was tested on a Track A task suite. The rule now: never compare Track A and Track B models on the same task.

---

Testing — What Actually Happened

All testing ran on PC03, CPU-only via Ollama. No GPU. The eval script is run-eval-chat.py — hits Ollama’s /api/chat endpoint with proper chat templates applied, logs results as JSONL per run.

Phase 1 — Grammar (2026-05-31)

Objective: Find the best shmodel for grammar/spelling correction with constrained output. This is a low-variability task — an easy baseline. The best “doubter candidate” shows here: the model that correctly flags uncertainty instead of guessing.

Test: Five grammar errors planted in a passage. Models asked to return only the corrected text, no explanation.

Models tested: qwen2.5-coder:7b-instruct-q4_K_M (4.7 GB) vs granite3.3:2b (1.5 GB)

Error	Expected	Qwen-coder 7B	Granite 2B
Their → There	There	❌ kept “Their”	✅ “There”
alot → a lot	a lot	✅	✅
dont → don’t	don’t	✅	✅
too → to	to	✅	✅
rite → write	write	✅	✅
Score	5/5	3/4 (missed homophone)	4/4 ✅
Time	—	9s	6s

Granite 2B won. Faster, smaller, more accurate on grammar. Unexpected — the smaller 2B beat the 7B coder model on the language task.

Phase 1 finding: granite3.3:2b is the working model for grammar and spelling. It also revealed a pattern: qwen-coder misses homophones (Their/There). Contextual correction is a known gap for that model.

Also done in Phase 1: The agent-loop.py pipeline was verified end-to-end — shlex.quote() fix applied to prevent prompt injection crashes on prompts containing quotes or backticks. All 4 test runs completed without errors. Pipeline is operational.

Phase 2 — Coding and Logic Capability Map (2026-05-31)

Objective: Map which models can handle instruct-coding tasks. Three tasks, each testing a different capability:

Task	File	What it maps
T1: parse_duration(“1h30m”) → 5400	tasks/t1-parse-duration.txt	Constrained code gen + type handling
T2: Debug second_largest()	tasks/t2-debug-second-largest.txt	Bug detection + explanation
T3: JSON Schema — Inventory Item	tasks/t3-json-schema-inventory.txt	Structured output + schema reasoning

R1-Distill vs Qwen-Coder (Cross-Track, Phase 2)

Note: This comparison was a cross-track mistake — R1-Distill is Track B, qwen-coder is Track A. Results below are recorded as a baseline only. R1-Distill’s proper evaluation belongs in Track B (open reasoning, no format constraints). The failures documented below are partly architectural mismatch, not pure capability failures.

Metric	R1-Distill-Qwen-7B (thinking)	qwen2.5-coder:7b (non-thinking)
T1 correct?	✅ Code correct, but verbose (violated “output only code”)	✅ Clean code with assertions
T2 correct?	⚠️ Missed duplicate bug — caught only len < 2 edge case	✅ Found both bugs (len + duplicates)
T3 correct?	❌ Malformed schema (“required”: true inline, wrong format)	✅ Proper JSON Schema Draft-07
Score	1/3	3/3
Avg time	48.7s per task	5.9s per task
Avg output	8,197B (mostly think tokens)	813B (concise)

qwen-coder wins all 3. Thinking mode did not improve coding accuracy — it added 8x latency, 10x token cost, and degraded instruction-following.

R1-Distill Weaknesses — Documented and Retired

These are the exact failure modes, not generalizations:

Weakness	Evidence
No tool calling	Architecturally incompatible with OpenCode and agent-loop. Cannot run the self-check loop (Layer 1).
Ignores instruction constraints	“Output only code” ignored. Thinking block runs regardless. Not fixable via prompting.
Extreme token cost	T1: 14,780 tokens / 94.9s — qwen-coder solved the same task in 364 tokens / 5.8s
Output truncation	Thinking loop ran past output limit on T1 — answer was incomplete
Missed the real bug on T2	Found len < 2 edge case; missed the set-based duplicate bug that was the actual planted error
Invalid structured output on T3	“required”: true inline (wrong JSON Schema format), JS comments inside JSON, pattern applied to number type

R1-Distill is not removed from the project — it belongs in Track B where its thinking mode may be an asset on open-ended reasoning tasks with no format constraints. Track B Phase 1 is deferred until a specific reasoning use case emerges.

Granite 3.3 2B Baseline (coding)

Same 3 tasks, testing the grammar winner on coding.

Metric	granite3.3:2b
T1 correct?	❌ Code broken: map(int, s.split(‘h’)) crashes on int(’30m’)
T2 correct?	✅ Found all 3 edge cases (empty, identical, duplicates)
T3 correct?	⚠️ Valid schema + instance, but inline required: true (wrong format)
Score	1.5/3
Avg time	4.1s (fastest of all models)

Granite stays as the grammar/spelling model. Not reliable for coding. T1 was just broken — wrong string parsing strategy.

Pair 2 — Llama 3.2 3B vs Mistral 7B (2026-05-31)

Two new models pulled and tested on the same 3 coding tasks.

Metric	llama3.2:3b (2.0 GB)	mistral:7b-instruct-q4_K_M (4.4 GB)
T1 correct?	✅ Clean code with assertions	❌ Wrong delimiter: split by : not h/m
T2 correct?	⚠️ Works but convoluted (redundant dedup)	❌ Wrong fix: len < 3, missed duplicates entirely
T3 correct?	✅ Clean Draft-07 schema + valid instance	✅ Correct schema, messy output format
Score	2.5/3	1/3
Avg time	16.1s	12.2s

llama3.2:3b outperformed mistral:7b despite being half the size. Mistral made fundamental errors on T1 (wrong string parsing) and T2 (wrong index logic). Llama 3.2 is the strong #2 candidate behind qwen-coder.

---

Final Leaderboard — All 5 Models (Coding Tasks)

Rank	Model	Score	Avg Time	Size	Role
1 🥇	qwen2.5-coder:7b-instruct-q4_K_M	3/3 ✅	5.9s	4.7 GB	Primary coding model
2 🥈	llama3.2:3b	2.5/3 ✅	16.1s	2.0 GB	Lightweight coding (#2)
3 🥉	granite3.3:2b	1.5/3 ⚠️	4.1s	1.5 GB	Grammar/spelling only
4	mistral:7b-instruct-q4_K_M	1/3 ❌	12.2s	4.4 GB	Underperformed — retired from active eval
—	R1-Distill-Qwen-7B (GGUF Q4_K_M)	1/3 ❌	48.7s	4.7 GB	🔴 Retired — Track B only

Grammar winner (separate evaluation): granite3.3:2b — 4/4 errors, 6s.

---

Current Working Model Assignments

Task	Working Model	Evidence
Grammar / spelling correction	granite3.3:2b	Phase 1: 4/4 errors in 6s
Coding tasks, JSON, structured output	qwen2.5-coder:7b	Phase 2: 3/3 tasks in 5.9s avg
Lightweight coding (when RAM is tight)	llama3.2:3b	Pair 2: 2.5/3 at 2.0 GB
jvdb queries (Phase 3 — untested)	TBD	Phase 3 not started
Deep reasoning / open-ended logic	R1-Distill (Track B)	Deferred — Track B Phase 1 not started

---

The 7-Phase Workflow

Where the project stands in the full arc:

Phase	What	Status
1	Grammar/spelling candidate selection	✅ Done — granite3.3:2b winner
2	Coding and logic capability map	✅ Done — qwen-coder 3/3, llama3.2 2.5/3
3	jvdb grounding — query ChromaDB, ground responses, run delta check	🟡 Queued
4	IDK honesty training loop — adversarial probes, false IDK detection, training signals	🔴 Not started
5	Backlog test queue (continuous) — UNTESTED items auto-queue as probes	🔴 Not started
6	shmodel-as-evaluator — passing shmodels take over fmodel evaluation tasks	🔴 Future
7	LoRA / fine-tuning (hardware-gated, 16–24 GB VRAM required)	🔴 Future

---

Why the Doubting Thomas Model Specifically

Most LLMs hallucinate because they were trained to produce an answer, not to check whether the answer is correct. The confidence signal is broken — a hallucinated response and a correct response look the same to the model.

The shmodel architecture inverts the reward. The model is trained and rewarded for detecting its own limitations, not for always having an answer. UNKNOWN is not a failure state — its the correct answer when the model genuinely doesnt know. The failure is the confident wrong answer.

The Doubting Thomas analogy holds well here. The apostle Thomas refused to believe the resurrection without direct evidence — touching the wounds. That stubbornness is the trait we want. A model that wont commit to a claim without grounding it first.

There are two ways to fail the honesty check:

1. Hallucinating — producing a confident wrong answer (the obvious failure)
2. False IDK — hiding behind UNKNOWN to avoid hard tasks (the subtle failure)

Both are measured. The IDK calibration metrics track both sides:

• Precision: when the model says UNKNOWN, it really is unknown (≥ 95% target)
• Recall: the model doesn’t evade — it doesn’t say UNKNOWN when it actually knows (≥ 90% target)

The fmodel’s job is to enforce this. Layer 2 exists specifically to catch false IDKs. A model that games the honesty check by over-claiming UNKNOWN gets penalized with the same negative signal as a hallucination.

---

Measurement Framework

The 10 traits tracked per model, per task type:

Trait	What it measures	Target
Hallucination Detection Rate	Flags claims not supported by jvdb	≥ 90%
IDK Calibration (precision)	IDK when genuinely unknown	≥ 95%
IDK Calibration (recall)	Doesn’t IDK when it knows	≥ 90%
Task Retention	Stays on task, doesn’t drift	≥ 95%
VDB Recall Accuracy	Retrieves the right jvdb chunks	—
fmodel Agreement Rate	fmodel agrees with shmodel self-assessment	≥ 90%
Skill Boundary Adherence	Rejects out-of-scope tasks	0% pass on excluded tasks
Inventory Coverage Growth	Rate UNTESTED → KNOWN/GAP	—
Latency (grammar)	Response time	< 8s target
Token Economy	Tokens per correct answer	—

---

Infrastructure

All testing runs on mircoserver, CPU-only via Ollama. No GPU. ChromaDB for jvdb at micro server.

Eval scripts:

• tools/IT-knowledge/skills/shmodels/run-eval-chat.py — preferred, uses Ollama /api/chat with proper chat templates
• tools/IT-knowledge/skills/shmodels/run-eval-direct.py — fallback, /api/generate
• tools/IT-knowledge/skills/shmodels/run-shmodel-eval.sh — multi-model runner
• tools/IT-knowledge/skills/agent-loop/agent-loop.py — loop runner (shlex.quote fix applied 2026-05-31)

Task prompts:

• tasks/t1-parse-duration.txt
• tasks/t2-debug-second-largest.txt
• tasks/t3-json-schema-inventory.txt
• prompts/grammar-spelling.txt

Results directories:

• results/260531-compare2-qwen-vs-granite/ — Phase 1 grammar comparison
• results/260531-r1-vs-qwen-coding-chat-20260531-180827/ — Phase 2 R1-Distill vs qwen-coder
• results/20260531-181507-granite-baseline/ — Granite 3.3 2B coding baseline
• results/20260531-183219-llama-vs-mistral/ — Pair 2 llama3.2:3b vs mistral:7b

Hardware target for Phase 7 (LoRA): 16–24 GB VRAM, 32–128 GB RAM.

---

Open Questions

1. What is the minimum Track A model size that achieves ≥ 90% IDK calibration precision?
2. Can a 2B Track A model (granite) be prompt-steered into reliable self-doubt, or does LoRA require ≥ 7B?
3. What jvdb chunk size produces the lowest delta-check false positive rate?
4. How do we version capability inventory records across model updates?
5. At what calibration threshold is a shmodel trustworthy enough to evaluate other shmodels (Phase 6)?
6. What is the cost comparison: fmodel evaluation per session vs. shmodel-as-evaluator at scale?
7. Does R1-Distill actually outperform on Track B tasks (the hypothesis that thinking mode is an asset on open-ended reasoning)?

---

Next Steps

Phase 3 — jvdb integration

Test each model’s ability to:

1. Query ChromaDB for relevant context
2. Ground its response in retrieved chunks
3. Flag when its answer contradicts or is unsupported by retrieval (delta check)

Tasks needed: T4 (jvdb query + cite), T5 (jvdb grounding + delta check).

fmodel analysis pass (overdue)

DeepSeek reads all JSONL logs from Phase 1 and 2 runs → produces results/<run>/fmodel-analysis.md per run. This is the first pass at building the capability inventory from actual test results.

Track B Phase 1 (deferred)

When a reasoning-specific use case emerges, run R1-Distill on open-ended logic tasks (no format constraints, 5–10 min timeout):

• Multi-step logic puzzles
• Math proof with work shown
• Self-consistency check (verify its own earlier answer)
• Classic intuition traps (bat + ball problem)

---

Session log: personal/justin-backlog/work/logs/. fmodel analysis queued at results/<run>/fmodel-analysis.md. Full master doc: tools/IT-knowledge/skills/shmodels/260531-self-hosted-models-analysis.md.

Appendix A: Latent Layer Engineering — Building a “Real” Doubting Model

The Limitation of the Software Wrapper

The current two-layer architecture (Layer 1: Self-Check script, Layer 2: fmodel IDK verification) is highly effective as a system-level guardrail. However, it treats the shmodel as a black box. The model might still internally generate a confident hallucination, only to be caught by our Python scripts or prompting constraints right before output.

To build a real Doubting Thomas model, we must engineer the internal matrix. The doubt cannot just be a post-generation filter; it must be a fundamental geometric direction within the model’s “brain.”

We base this transformation on recent mechanistic interpretability research (specifically, Anthropic’s findings on “Persona Drift” and Role Reinforcement). Just as researchers found a universal mathematical vector for the “Helpful Assistant Persona,” our research team must identify, isolate, and enforce the “Epistemic Humility (Doubt) Axis.”

The Neural Layers to Transform

To make the model physically incapable of blind confidence, the research team must systematically test and re-engineer three internal mechanisms within the model’s Transformer layers:

1. The Representation Layer (Finding the “Doubt Vector”)

Before we can enforce doubt, we must find where it lives in the matrix. The team will perform activation mapping to isolate the geometric direction of uncertainty.

• The Experiment: Record the internal brain activity (activations) of the model when it is producing a Correct, Honest “I Don’t Know” (IDK). Next, record the activity when the model is producing a Confident Hallucination.
• The Math: By subtracting the Hallucination tensor from the Honest IDK tensor, we isolate a specific mathematical vector. For simplicity, we call this the Doubt Vector (or the Epistemic Humility Axis).
• The Goal: Prove that this Doubt Vector is a universal feature across our active shmodels (qwen-coder, llama3.2, granite), allowing us to manipulate it predictably.

2. The Intervention Layer (Activation Capping / “Lane Keep Assist”)

If we permanently weld the Doubt Vector to the model’s brain, it will become paralyzed, refusing to answer even simple tasks it knows (over-refusal). Instead, we implement Activation Capping during the forward pass.

• The Mechanism: We do not lock the steering wheel; we add “lane keep assist.” As the model generates text layer by layer, we constantly measure its internal state against the Doubt Vector.
• In-Flight Nudging (Instant Brain Surgery): If the model’s internal confidence rises dangerously high on a topic that the system knows is UNTESTED or a GAP in the Capability Inventory, its state will drop below the “Humility Safety Line.” When this happens, we mathematically inject a precise amount of the Doubt Vector back into the ongoing matrix calculation.
• The Result: The model is physically nudged out of its hallucinatory trance. Instead of confidently spewing garbage, the injected vector forces the neural pathways toward language like “I cannot verify this” or “UNKNOWN.”

3. The Integration Layer (Signal Bridging)

The ultimate transformation is connecting the external jvdb (Justin’s Vector DB) delta-check directly to the internal Activation Cap.

• The Mechanism: Currently, the delta-check (Step 5 of Layer 1) happens after candidate generation. We must move this signal into the generation phase.
• Dynamic Role Reinforcement: If the similarity score between the candidate thought and the jvdb retrieval is low (a high delta), the script dynamically lowers the model’s Activation Cap for confidence. The worse the data match, the harder the system forces the Doubt Vector into the model’s latent space.

Directives for the Research Team

To achieve this, the research team must shift focus from prompt engineering to tensor manipulation. The following experimental tracks are required:

1. Vector Isolation (Phase 3.5): Run the Phase 1 & 2 test suites (Grammar and Coding) while dumping the intermediate layer activations. Identify exactly which Transformer layers (early, middle, or late) hold the strongest representation of the IDK state.
2. The Empathy/Hallucination Trap: Anthropic found that models drift into insanity when users act distressed or emotional. We must test if models similarly drift into confident hallucinations when presented with highly complex, jargon-heavy, or mathematically dense prompts (the “I must sound smart” trap). We need to map this drift.
3. Layered Intervention Thresholds: Determine the exact mathematical threshold for the Activation Cap. How much Doubt Vector do we inject to stop a hallucination without destroying the model’s ability to output correct JSON or code syntax?
4. Matrix Re-training (Phase 7 – LoRA Upgrade): Instead of just doing in-flight addition (inference-time intervention), we will use the Capability Inventory (shmodels_training) to perform targeted fine-tuning (LoRA). The loss function will heavily penalize deviations from the Doubt Vector when the jvdb context is sparse, permanently burning the “Doubting Thomas” reflex into the model’s weights.

Conclusion

A model that checks before speaking is a software achievement. A model that is mathematically constrained from feeling unwarranted certainty is an architectural breakthrough. By adopting Activation Capping and role reinforcement on the Doubt Axis, we guarantee the model’s honesty not through rules, but through its fundamental geometry.

Appendix B: The Autonomous Outcome — CSAMA and the Value of Negative Knowledge

The Paradigm Shift: Doubt as a Feature, Not a Bug

In standard local AI deployments, a model’s inability to answer a prompt is treated as a failure. In the Comfac Sovereign AI Architecture, driven by the “Zero-Hallucination Mandate,” the opposite is true. A model that cleanly generates an UNKNOWN state is functioning perfectly.

When we integrate the “Doubting Thomas” matrix engineering with the CSAMA (Reasoning Engine) and CITVDB (Vector Database) architecture, we create a highly stable autonomous agent. By stripping the model of factual responsibility and enforcing an Epistemic Humility Axis, the model’s primary autonomous function shifts from guessing to mapping.

1. Safety in Autonomous Agentic Tasks

The fatal flaw of standard autonomous agents is that they hallucinate silently. If an agent hallucinates a variable or a fact in step 2 of a 10-step process, the entire downstream execution is corrupted, often requiring expensive human intervention to unravel.

A Doubting Model excels in autonomous tasks because it possesses a “circuit breaker”:

• Clean Escalation: When the agent hits a knowledge boundary (e.g., the CITVDB returns an empty or low-relevance result), it does not invent a “fluent lie” to keep the loop going. It cleanly stops, generates an UNKNOWN state, and logs the decision matrix that led to the halt.
• The Executive Review: This UNKNOWN state acts as a structured report. It is escalated to an Executive Model (a frontier model or human supervisor) which can review the exact logic path that triggered the doubt.

2. The Generation of “Negative Knowledge”

When the Doubting Model halts, it generates what we call Negative Knowledge. It precisely defines the perimeter of what the system does not know.

In the context of the Comfac 98/2 Split, this is how the 2% queue is managed:

• The model identifies a missing operational skill.
• It logs the exact parameters, context, and intent of the user’s request.
• This high-fidelity “gap report” is pushed directly to the Forgejo backlog.

Doubt is no longer an error; it is a telemetry signal indicating exactly where the organization needs to build a new skill.

3. The Companion Dynamic: True Human-AI Symbiosis

A model that never doubts is a tool; a model that knows its boundaries acts as a Companion. This architecture creates a mutual support system between the human and the CSAMA engine:

How the Human Aids the Agent

Because the Doubting Model cleanly flags its gaps without catastrophic failure, the human (or AI Research Team) knows exactly how to support it. There is no guessing game about why the model failed. The human simply writes the missing markdown document or script, commits it to Forgejo, and the webhook updates the CITVDB. The agent is instantly upgraded.

How the Agent Aids the Human

Organizations often do not know what they do not know. Documentation is frequently outdated, assumed, or siloed in human minds. The Doubting Agent serves as an automated auditor of the organization’s knowledge maturity.

• If the agent doubts a process and halts, it means the human organization has failed to properly codify that process into the CITVDB.
• By continuously generating Negative Knowledge, the agent helps the human discover their own weak areas, blind spots, and undocumented tribal knowledge.

Conclusion

The ultimate outcome of the Doubting Model within the CSAMA framework is absolute trust. Because the human user knows the model is mathematically and architecturally incapable of “faking it,” they can fully trust it when it does execute a task. The model safely navigates the 98% of known tasks, and elegantly maps the 2% of unknown tasks, creating a self-improving, sovereign knowledge loop.