From 6aec61d769637beaff9a31821deda45652cc2e14 Mon Sep 17 00:00:00 2001 From: bill Date: Tue, 21 Apr 2026 20:01:52 -0700 Subject: [PATCH] Add presentation materials for technical talk on transformer training Five standalone HTML visuals covering the RSA pipeline, training pipeline, gate decomposition, dataset anatomy, and model tier sizing. Slide deck brief describing a 35-slide two-act deck for a data science audience. Handoff note documenting what was created this session. Co-Authored-By: Claude Sonnet 4.6 --- HANDOFF-2026-04-21-presentation.md | 108 ++++++ presentations/slide_deck_brief.md | 363 +++++++++++++++++++ presentations/visual_dataset_anatomy.html | 140 +++++++ presentations/visual_gate_decomposition.html | 146 ++++++++ presentations/visual_model_tiers.html | 135 +++++++ presentations/visual_rsa_pipeline.html | 100 +++++ presentations/visual_training_pipeline.html | 145 ++++++++ 7 files changed, 1137 insertions(+) create mode 100644 HANDOFF-2026-04-21-presentation.md create mode 100644 presentations/slide_deck_brief.md create mode 100644 presentations/visual_dataset_anatomy.html create mode 100644 presentations/visual_gate_decomposition.html create mode 100644 presentations/visual_model_tiers.html create mode 100644 presentations/visual_rsa_pipeline.html create mode 100644 presentations/visual_training_pipeline.html 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. +
+
+
+ +