diff --git a/HANDOFF-2026-04-21-presentation.md b/HANDOFF-2026-04-21-presentation.md new file mode 100644 index 0000000..341c39d --- /dev/null +++ b/HANDOFF-2026-04-21-presentation.md @@ -0,0 +1,108 @@ +# Handoff: Presentation Materials — 2026-04-21 + +## Context + +This session was primarily infrastructure and communication work, not pipeline or +training work. The purpose was to prepare presentation materials for a technical +audience (data science background) covering the actual transformer training approach +in whetstone_RSA. + +The session also established a new workstation (`spindoctor`) as a Gitea client +for this repo. Gitea SSH runs on port 2222, not 22. An SSH config entry for +`borgswarm` with `Port 2222` is in place at `~/.ssh/config` on spindoctor. + +--- + +## What Was Created + +### presentations/slide_deck_brief.md + +Full briefing document for a slide deck agent. Describes a 35-slide deck in two acts: + +- **Act I (slides 1–17):** Refers to the existing `rsa_tiny_models_talk.md` as-is. + No changes to that file. + +- **Act II (slides 18–35):** New material covering the actual training work. + Each slide is described with: title, content, visual reference, speaker notes. + +The brief references each HTML visual by filename and includes honest framing of the +weak baseline results and their structural cause. + +### presentations/visual_rsa_pipeline.html + +The core RSA pattern as a four-box pipeline: + +``` +Fuzzy input → RSA Gate → Typed Contract → Deterministic Execution +``` + +Includes two worked examples: a developer tools query and a whetstone_DSL +prereq gate decision. Dark theme, standalone HTML. + +### presentations/visual_training_pipeline.html + +Six-step pipeline from run artifacts to trained specialist: + +1. whetstone_DSL run corpus (1000 runs) +2. Gate extraction (`extract_gate_rows.py`) +3. Gate decomposition (1 gate → 2 binary classifiers) +4. TSV generation (`gen_prereq_op_rsa_data.py`) +5. Fabricate training (~213K params, 4000 steps, GPU desktop) +6. Specialist checkpoint (~800KB) + +Includes the corpus caveat (17 unique templates) as an inline note. + +### presentations/visual_gate_decomposition.html + +Shows how `prereq_op_selector` decomposed into two independent binary classifiers +after discovering `needs_validate_intake` is always True across all 1297 accepted rows. + +Displays: +- Gate A: `needs_resolve_dependencies` — 76.9% positive, 69.4% baseline accuracy +- Gate B: `needs_architect_review` — 19.8% positive, 75.0% baseline accuracy +- Accuracy bars with honest majority-classifier context +- Three bottom notes: why two models, what the corpus lacks, next step pointer + +### presentations/visual_dataset_anatomy.html + +Dataset statistics for the prereq_op_selector extraction: + +- Top-line numbers: 1000 runs, 1297 accepted rows, 24 schema-drift rejected, ~17 unique templates +- Class balance bar chart for both binary gates +- Corpus limitation callout (why 1297 rows ≠ 1297 diverse examples) +- Sample rows in Fabricate TSV format (`label hop text`) + +### presentations/visual_model_tiers.html + +The entropy → model tier hypothesis as a five-tier diagram: + +| Tier | Description | Size | +|---|---|---| +| 0 | Deterministic rules | 0 params | +| 1 | Tiny specialist (Fabricate) | ~213K params / ~800KB | +| 2 | Medium specialist (planned) | ~10× tier 1 | +| 3 | Large specialist (planned) | ~16× tier 1 | +| 4 | SLM / LLM (escalation only) | billions | + +Includes an entropy axis, the current sizing hypothesis as pseudocode, and the +"check schema before moving up a tier" caveat. + +--- + +## What Was Not Changed + +- `rsa_tiny_models_talk.md` — untouched. Act I of the deck uses it as-is. +- All `docs/`, `src/`, `include/`, `semantic/`, `tools/`, `schemas/` — untouched. +- All sprint documents — untouched. + +--- + +## Known State + +The Fabricate training project has been deleted. The trained specialist checkpoints +(`/mnt/storage/fabricate_runs/`) are on the GPU desktop, not accessible from +spindoctor. The training results cited in the visuals come from +`HANDOFF-2026-04-12-session2.md`. + +The HTML visuals are standalone — no external dependencies, no build step required. +Open in any browser. diff --git a/presentations/slide_deck_brief.md b/presentations/slide_deck_brief.md new file mode 100644 index 0000000..e523980 --- /dev/null +++ b/presentations/slide_deck_brief.md @@ -0,0 +1,363 @@ +# Slide Deck Brief — whetstone_RSA: Tiny Models for Bounded Decisions + +**Audience:** Whetstone_RSA, ex data science instructor. Technical depth expected. +Wants to understand the actual transformer training approach, not just the concept. + +**Format:** Slide deck, dark theme preferred. One idea per slide, minimal text. +Visuals are in the same directory as this file (HTML files — embed or screenshot them). + +**Length:** ~30–35 slides across two acts. + +--- + +## Act I — The Problem and the Pattern (Slides 1–17) + +These slides are already written in `rsa_tiny_models_talk.md`. Keep them as-is. +They establish the motivation: fuzzy input → bounded output → deterministic execution. +Key points already covered: +- Why regex is brittle +- Why LLMs are oversized for bounded tasks +- What RSA does (contract layer between user and tool) +- The core pipeline: input → RSA gate → typed contract → deterministic software +- Where this pattern shows up (command palettes, search bars, workflow routing) + +**Visual for Act I:** `visual_rsa_pipeline.html` + +--- + +## Act II — The Actual Training Work (Slides 18–35) + +This is the new material. It covers the real implementation, dataset, and results. + +--- + +### Slide 18: The Case Study + +**Title:** First Real Target — whetstone_DSL + +**Content:** +- whetstone_DSL is a C++ IDE with an AST-first codegen pipeline +- It uses an LLM to make many bounded decisions bundled together +- Goal: replace those bundles with one tiny specialist per decision gate +- First gate selected: `prereq_op_selector` + - Decides which prerequisite operations a taskitem needs before it can execute + +**Speaker notes:** This is not a toy example. These gates run on real pipeline decisions. + +--- + +### Slide 19: What a Gate Is + +**Title:** The Gate Contract + +**Content:** +``` +input: task title · requirements · acceptance criteria · constraints +output: needs_resolve_dependencies: bool + needs_architect_review: bool + needs_validate_intake: bool (always true — dropped) + confidence: float + abstain: bool +``` + +**Visual idea:** Simple box diagram: structured text in, typed struct out. + +**Speaker notes:** The output is not generated text. It is a typed struct with known fields. + +--- + +### Slide 20: The Training Pipeline Overview + +**Title:** From Run Artifacts to Specialist + +**Visual:** `visual_training_pipeline.html` — use full slide. + +**Speaker notes:** Six-step pipeline. Real data from real pipeline runs. The training +framework (Fabricate) lives on the GPU desktop — can demo it live there. + +--- + +### Slide 21: Step 1 — The Corpus + +**Title:** Source Data: 1000 Pipeline Runs + +**Content:** +- whetstone_DSL was run 1000 times on real and synthetic projects +- Each run produces JSON log artifacts recording every taskitem decision +- `extract_gate_rows.py` parses these into per-gate supervision rows + +**Visual idea:** Stack of JSON files on left → extraction tool → rows on right. + +--- + +### Slide 22: Step 2 — Gate Extraction + +**Title:** Isolating One Decision at a Time + +**Content:** +- Each row contains: decision_context · decision_label · decision_provenance +- Only the information available at decision time is allowed in the context +- Rows with schema-drift labels are rejected (24 of 1321 total) +- Result: 1297 clean rows for prereq_op_selector + +**Key extraction rule:** Never leak downstream fields into the context. +A gate must only see what was available when it would actually fire. + +--- + +### Slide 23: The Discovery — Gate Decomposition + +**Title:** needs_validate_intake Is Always True + +**Content:** +- Analysis of 1297 rows: needs_validate_intake = True in all 1297 of them +- A label with zero variance cannot be learned — it is a constant, not a gate +- Real gate decomposes into two independent binary classifiers: + - needs_resolve_dependencies (76.9% positive rate) + - needs_architect_review (19.8% positive rate) + +**Visual:** `visual_gate_decomposition.html` + +**Speaker notes:** This is a real finding, not a design choice made upfront. The data +told us the gate shape was wrong. That's the process working correctly. + +--- + +### Slide 24: Dataset Anatomy + +**Title:** What 1297 Rows Actually Looks Like + +**Visual:** `visual_dataset_anatomy.html` — use full slide. + +**Speaker notes:** The ~17 unique templates is the important number. High row count +does not mean high diversity. This is the honest accounting. + +--- + +### Slide 25: The TSV Format + +**Title:** Fabricate Training Format + +**Content:** +``` +label hop text +``` +- label: 0 (no) or 1 (yes) — one file per binary gate +- hop: always 0 (unused routing field in Fabricate) +- text: composed from title · reasons · acceptance criteria · constraints + +**Four files produced:** +- prereq_resolve_train.tsv (1102 rows) +- prereq_resolve_eval.tsv (195 rows) +- prereq_architect_train.tsv (1102 rows) +- prereq_architect_eval.tsv (195 rows) + +**Split:** 85% train / 15% eval, random seed 42. + +--- + +### Slide 26: The Model — Tiny Transformer + +**Title:** ~213K Parameters. ~800KB on Disk. + +**Content:** +- Framework: Fabricate (custom tiny transformer training tool) +- Architecture: transformer encoder with binary classification head +- ~213K parameters per specialist +- Serialized checkpoint: ~800KB +- Training: GPU desktop, 4000 steps per specialist +- Inference: CPU-friendly, local, no network dependency + +**Visual idea:** Size comparison — model checkpoint vs. a JPEG photo (~800KB each). + +**Speaker notes:** This is the whole point. A model smaller than an average image file, +making a bounded yes/no decision. Can demo inference live on the GPU desktop. + +--- + +### Slide 27: Training Results + +**Title:** Baseline Results @ 4000 Steps + +**Content:** + +| Specialist | Accuracy | Steps | Positive rate | +|---|---|---|---| +| prereq_resolve (needs_resolve_dependencies) | 69.4% | 4000 | 76.9% | +| prereq_architect (needs_architect_review) | 75.0% | 4000 | 19.8% | + +**Important context:** +- A majority classifier on needs_resolve would score ~77% (model is below naive baseline) +- A majority classifier on needs_architect would score ~80% (model is learning minority class) +- These are weak baselines — expected given the 17-template corpus + +**Visual idea:** Bar chart with majority-classifier baseline marked as a reference line. + +--- + +### Slide 28: Why the Baselines Are Weak (And Why That's Fine) + +**Title:** The Corpus Was Not Designed for This + +**Content:** +- The taskitem schema was designed to record execution outputs, not discriminative inputs +- 1297 rows, but only ~17 unique text patterns — the model has almost no signal variation +- The labels are correct; the features are not rich enough yet + +**The fix is not more data from the same corpus.** +The fix is adding RSA-native fields to the taskitem schema upstream. + +**Speaker notes:** This is an architectural finding. The pipeline methodology is validated. +Signal quality is a schema problem, not a model problem. + +--- + +### Slide 29: What Would Make the Signal Better + +**Title:** Better Input = Better Gate + +**Content:** +Each taskitem needs to carry: +- `architectural_surface` — what part of the system is touched +- `cross_component_deps` — explicit dependency flags +- `security_sensitive` — flag for security-relevant changes +- `uncertainty_score` — explicit uncertainty signal + +With these fields, some gates that currently need ML may become deterministic rules. +The RSA entropy threshold shifts as the contract gets richer. + +**Visual idea:** Taskitem schema before vs. after adding RSA fields. + +--- + +### Slide 30: The Entropy → Model Size Hypothesis + +**Title:** Match the Model to the Decision Surface + +**Visual:** `visual_model_tiers.html` + +**Speaker notes:** The hypothesis is measurable and falsifiable. The experiment is: +train each tier on the same gate, record the smallest one that clears the target. + +--- + +### Slide 31: Gate Entropy Factors + +**Title:** What Makes a Gate Hard? + +**Content:** +Factors that increase required model tier: +- output_cardinality (more labels = harder) +- class_imbalance +- lexical_variation in inputs +- context_width_required +- label_boundary_fuzziness +- world_knowledge_dependence +- slot_interdependence + +**Target deliverable:** +``` +gate_id | entropy_score | smallest_passing_tier | accuracy | latency_ms +``` + +**Speaker notes:** We don't have this table yet. It's the next experiment. + +--- + +### Slide 32: What's Next — SPRINT-004 + +**Title:** Pipeline Decision Audit + +**Content:** +Before training more gates, map every decision in the full whetstone_DSL pipeline: +- Start at RegisterArchitectIntakeTools.h (pipeline entry point) +- At every stage: what decision is being made? +- What inputs are available? +- What is the optimal method: deterministic / RSA / SLM / LLM / human? + +`generate_taskitems` alone bundles 10+ separable decisions. + +**Output:** `docs/case_studies/whetstone_dsl_pipeline_decision_map.md` + +**Speaker notes:** Train data collection strategy follows from the decision map. +Don't collect data for the wrong gate shape. + +--- + +### Slide 33: What Is Already Deterministic + +**Title:** Most of Whetstone Is Already Right + +**Content:** +Once the AST and target language are fixed, most current code generation is deterministic: +- Target generator dispatch — deterministic +- AST concept dispatch — deterministic +- Environment gating — deterministic +- C++ raising profile validation — deterministic + +RSA is highest value in: +- taskitem generation +- execution contract shaping +- routing decisions +- pre-codegen profile decisions + +**Speaker notes:** This is a feature, not a gap. Don't replace deterministic software +with models. Find the actual ambiguity boundary. + +--- + +### Slide 34: The C++ Runtime + +**Title:** whetstone_RSA Runtime Scaffold + +**Content:** +A C++ library wrapping the gate contracts: +- `GateDefinition` · `GateEvidence` · `GateDiagnosis` · `GateSuitability` +- `ProbeRegistry` + `DiagnosisEngine` +- First concrete probe: `confidence_threshold_probe` +- Builds with CMake, demo executable runs + +This is the deployment layer — gates are loaded here at runtime. + +**Visual idea:** Stack diagram: Fabricate specialist → RSA runtime → whetstone_DSL pipeline. + +--- + +### Slide 35: The Summary + +**Title:** What This Is + +**Content:** +1. Real, running pipeline decisions in whetstone_DSL +2. Real extracted training data (1297 rows, two binary gates) +3. Real trained specialists (~800KB each, ~213K params) +4. Honest baselines (weak corpus, clear reason, clear fix) +5. A measurable hypothesis: entropy → tier selection +6. A C++ runtime that loads and runs them + +**Not a chatbot. Not a search engine.** +A bounded decision contract layer, with real data and real results. + +--- + +## Appendix Slides (optional, for Q&A) + +- Rejection taxonomy (schema drift, sibling-uniform labels) +- Full gate inventory for whetstone_DSL +- The decision_contract_ontology (input_structure, output_topology, policy_stability, etc.) +- Backend selection taxonomy (transformer vs. gradient boosting vs. Bayes — kept separate from gate identity) +- The abstain/escalate policy design + +--- + +## Files in this directory + +| File | Description | +|---|---| +| `rsa_tiny_models_talk.md` | Act I source (31 slides, already complete) | +| `slide_deck_brief.md` | This file | +| `visual_rsa_pipeline.html` | The core RSA pattern — fuzzy in, contract out | +| `visual_training_pipeline.html` | Six-step pipeline from run artifacts to trained specialist | +| `visual_gate_decomposition.html` | prereq_op_selector decomposed into two binary gates | +| `visual_dataset_anatomy.html` | Dataset stats, class balance, TSV format sample | +| `visual_model_tiers.html` | Entropy → model tier sizing diagram | diff --git a/presentations/visual_dataset_anatomy.html b/presentations/visual_dataset_anatomy.html new file mode 100644 index 0000000..adb4244 --- /dev/null +++ b/presentations/visual_dataset_anatomy.html @@ -0,0 +1,140 @@ + + + + +Dataset Anatomy + + + +
+

Dataset Anatomy — prereq_op_selector

+ +
+
1000
runs extracted
+
1297
accepted rows
+
24
schema-drift rejected
+
~17
unique text templates
+
+ +
+
+
Class balance
+
+
needs_resolve_dependencies = yes
+
997 rows
+
76.9%
+
+
+
needs_resolve_dependencies = no
+
300 rows
+
23.1%
+
+
+
+
needs_architect_review = yes
+
257 rows
+
19.8%
+
+
+
needs_architect_review = no
+
1040 rows
+
80.2%
+
+
+ +
+
⚠ Corpus limitation
+
+
▸
+
Only ~17 unique text templates across 1297 rows. High row count masks low actual diversity.
+
+
+
▸
+
The taskitem schema records outputs, not discriminative inputs. RSA-relevant fields were never stored.
+
+
+
▸
+
Baselines are intentionally weak. Pipeline is correct; signal improves with schema changes upstream.
+
+
+
+ +
+
Fabricate TSV format — prereq_resolve_train.tsv (sample rows)
+
+
label
+
hop
+
text (title · reasons · accepts · constraints)
+
+
+
1
0
+
title: Execution Readiness Primary | reasons: high_confidence_clear_path | accepts: at least one tool selection event; no malformed mcp payloads
+
+
+
0
0
+
title: Intake Foundation Primary | reasons: high_confidence_clear_path | accepts: deterministic taskitems with strict execution contracts | constraints: primary language go
+
+
+
1
0
+
title: Intake Foundation Primary | reasons: high_confidence_clear_path | accepts: scenario 1 given when then; scenario 2 given when then | constraints: language runtime constraints
+
+
+
0
0
+
title: Execution Readiness Primary | reasons: high_confidence_clear_path | accepts: at least one tool execution event; no unbounded loops
+
+
+ +
+ + diff --git a/presentations/visual_gate_decomposition.html b/presentations/visual_gate_decomposition.html new file mode 100644 index 0000000..8fd7e86 --- /dev/null +++ b/presentations/visual_gate_decomposition.html @@ -0,0 +1,146 @@ + + + + +Gate Decomposition + + + +
+

prereq_op_selector — Gate Decomposition

+ +
+
+
Original gate
+
prereq_op_selector
+
Which prerequisite operations does this taskitem need?
+
+
+ +
+
🔍
+
+ Analysis of 1297 accepted rows revealed needs_validate_intake is always True (1297/1297). + It is a constant, not a decision surface — no model can learn from a label with zero variance. + The effective gate is two independent binary classifiers. +
+
+ +
+
+
+
Gate A — prereq_resolve
+
needs_resolve_dependencies
+
"Does this task require resolving cross-task dependencies before execution?"
+
+ 997 / 1297 positive + 76.9% base rate +
+
+
Baseline accuracy @ 4000 steps 69.4%
+
+
+
+ Note: high base rate — a majority classifier would score ~77%.
Baseline is learning something, but corpus is weak. +
+
+
+ +
+ +
+
+
Gate B — prereq_architect
+
needs_architect_review
+
"Does this task require architect review before proceeding?"
+
+ 257 / 1297 positive + 19.8% base rate +
+
+
Baseline accuracy @ 4000 steps 75.0%
+
+
+
+ Note: a majority classifier here scores ~80%.
Baseline is learning from the minority class. +
+
+
+
+ +
+
+
Why two separate models
+
Each gate fires independently. A task can need both, either, or neither. Coupling them into one multiclass model creates false label structure.
+
+
+
What the corpus lacks
+
Only ~17 unique text templates across 1297 rows. The taskitem schema was not designed to carry discriminative RSA fields. Better signal requires schema changes upstream.
+
+
+
Next step
+
Pipeline decision audit (SPRINT-004): walk the full whetstone_DSL pipeline and identify every decision point before collecting more training data.
+
+
+ +
+ + diff --git a/presentations/visual_model_tiers.html b/presentations/visual_model_tiers.html new file mode 100644 index 0000000..d38cbeb --- /dev/null +++ b/presentations/visual_model_tiers.html @@ -0,0 +1,135 @@ + + + + +Model Tiers + + + +
+

Entropy → Model Tier

+
The smallest model that clears the quality target for a given gate's entropy budget
+ +
+
+
← already valid
+
+
Tier 0
+
Deterministic Rules
+
0 params
+
Perfect when input–output mapping is explicit and stable. No training cost. Fully auditable.
+
+
+
+
← trained baseline
+
+
Tier 1 · current
+
Tiny Specialist (Fabricate)
+
~213K params · ~800KB
+
Binary/multiclass classifiers. Local, fast, inspectable. Target for bounded gates with sufficient entropy.
+
+
+
+
+
Tier 2 · planned
+
Medium Specialist
+
~10× tier 1 · ~2–3M params
+
For gates where tiny tier misses due to higher label boundary fuzziness or longer context dependence.
+
+
+
+
+
Tier 3 · planned
+
Large Specialist
+
~16× tier 1 · ~3–4M params
+
For gates with high lexical variation, world-knowledge dependence, or complex slot interdependence.
+
+
+
+
+
Tier 4 · escalation
+
SLM / LLM
+
billions of params
+
Only when the gate is genuinely open-ended. Not a default. Escalation when specialists abstain.
+
+
+
+ +
+ low entropy +
+ high entropy +
+
+ simple lookup + binary classification + slot filling + complex routing + open reasoning +
+ +
+
Current sizing hypothesis
+
+ if entropy <= A → deterministic
+ if entropy <= B → tiny specialist (~213K params)
+ if entropy <= C → medium specialist (~2–3M params)
+ if entropy > C → large specialist or escalate to SLM/LLM + Before moving up a tier: check schema, label set, missing context, and factorization options first. +
+
+ +
+ + diff --git a/presentations/visual_rsa_pipeline.html b/presentations/visual_rsa_pipeline.html new file mode 100644 index 0000000..6b78e96 --- /dev/null +++ b/presentations/visual_rsa_pipeline.html @@ -0,0 +1,100 @@ + + + + +RSA Pipeline + + + +
+

The RSA Pattern

+
+
+
Input
+
Fuzzy natural language
+
Varied phrasing
Partial information
Ambiguous intent
+
+
+ +
+
+
RSA Gate
+
Tiny transformer specialist
+
Bounded output space
Confidence + abstain
~213K params / ~800KB
+
+
+ +
+
+
Contract
+
Typed structured decision
+
action + slots
confidence score
escalation flag
+
+
+ +
+
+
Execution
+
Deterministic software
+
No model past this point
Ordinary code
Auditable + fast
+
+
+
+
+
Example — developer tools
+
+ "show me the failed builds from yesterday"

+ → action: search_builds
+ → status: failed
+ → date: yesterday
+ → confidence: 0.93 +
+
+
+
Example — whetstone_DSL gate
+
+ taskitem: "Integrate auth middleware into API layer"

+ → needs_architect_review: true
+ → needs_resolve_deps: true
+ → confidence: 0.87 +
+
+
+
The design rule
+
+ Learned behavior lives only
+ where deterministic tooling
+ is not yet enough.

+ Everything after a bounded decision
+ is ordinary software. +
+
+
+
+ + diff --git a/presentations/visual_training_pipeline.html b/presentations/visual_training_pipeline.html new file mode 100644 index 0000000..6b3945f --- /dev/null +++ b/presentations/visual_training_pipeline.html @@ -0,0 +1,145 @@ + + + + +Training Pipeline + + + +
+

From Run Artifacts to Trained Specialist

+
+ +
+
+
Step 1
+
whetstone_DSL Run Corpus
+
+ Real pipeline runs stored as JSON log artifacts.
+ Each run records taskitem decisions, prerequisite ops, worker routing. + 1000 runs extracted +
+
+
+ +
+
+
Step 2
+
Gate Extraction
+
+ extract_gate_rows.py parses each run.
+ Isolates one gate's decision context and label per row.
+ Rejects rows with schema drift or sibling-uniform labels. + 1297 accepted / 24 schema-drift rejected +
+
+
+ +
+
+
Step 3
+
Gate Decomposition
+
+ Analysis revealed needs_validate_intake is always True — not a decision surface.
+ Gate reduces to two independent binary classifiers. + 2 gates from 1 +
+
+
+ +
+ +
+ +
+
+
Step 4
+
TSV Generation
+
+ gen_prereq_op_rsa_data.py converts rows to Fabricate TSV format.
+ Format: label <TAB> 0 <TAB> text
+ Text composed from: title · reasons · acceptance criteria · constraints. + 85% train / 15% eval split · seed=42 +
+
+
+ +
+
+
Step 5
+
Fabricate Training
+
+ Tiny transformer framework. GPU training on dedicated desktop.
+ ~213K parameter model architecture.
+ Binary classification head per gate. + 4000 steps per specialist +
+
+
+ +
+
+
Step 6
+
Specialist Checkpoint
+
+ Serialized model: ~800KB on disk.
+ Loaded at runtime by the RSA gate layer.
+ Returns: label · confidence · abstain flag. + ~800KB per specialist +
+
+
+ +
+
+
+ Corpus caveat: The 1000-run dataset contains only ~17 unique text templates — the taskitem schema was designed to record outputs, not discriminative inputs. These baselines are intentionally weak. The pipeline is correct; the signal improves when the taskitem schema carries RSA-native fields. +
+
+
+ +