# Handoff — 2026-04-30 — Presentation Decks + Training Prep

## Context

This was done on a temporary Ubuntu OS, not the main training machine.

Repos cloned into `/home/ubuntu/Documents`:

- `whetstoneRSA`
- `whetstoneDSL`
- `unchecked-io`

Gitea remote:

- `http://borgswarm:3000/bill/whetstone_RSA.git`

Temporary Gitea push token note:

- `/home/ubuntu/Documents/gitea-temp-token-today.txt`
- permissions are `600`

## Commits Already Pushed

Pushed to `master`:

- `39e0603 Add fast WhetstoneRSA presentation deck`
- `750353a Add full WhetstoneRSA cost story deck`

## Presentation Files

Existing/created presentation files:

- `presentations/whetstoneRSA_fast_deck.html`
  - first fast-slide deck
  - 35 slides
  - dark theme, keyboard/click navigation, speaker notes toggle

- `presentations/whetstoneRSA_overkill_deck.html`
  - intermediate deck
  - focuses on LLM overkill, regex enumeration, LoRA vs tiny transformer

- `presentations/whetstoneRSA_full_story_deck.html`
  - current strongest deck
  - 53 slides
  - starts with the product-spec-to-program story
  - includes the observed ~30 minute agent loop vs ~5 minute AST-first pipeline comparison
  - makes clear that AST-first created the speedup and RSA targets remaining repeated LLM planning decisions
  - includes API token pricing comparisons, 125-program extrapolation, local RTX 3060 training comparison, and a sources/assumptions slide

Deck controls:

- click / right arrow / space: next
- left arrow / backspace: previous
- `N`: toggle speaker notes
- `F`: fullscreen
- `#<slide number>`: jump to a slide

## Presentation Story Direction

Use plain language. Avoid phrases like "bounded decision-making" for this audience.

Core phrase:

> The input can be huge. The output is small.

Main story:

1. WhetstoneDSL already showed that AST-first code generation can make software generation much faster than interactive agentic coding.
2. A product spec can become a program in around five minutes.
3. RSA did not create that first speedup. AST-first generation did.
4. RSA is the next step: move repeated planning decisions out of general LLM calls and into local tiny transformer gates.
5. Regex gives predictable outputs but forces humans to enumerate messy inputs.
6. LLMs handle messy inputs but bring a large recurring token/runtime meter.
7. LoRA adapts a big model, but still carries the base model at runtime.
8. Tiny gate transformers learn the messy input while keeping the output menu fixed.
9. Training a gate took about 3 to 5 minutes on an RTX 3060.
10. The goal is faster, cheaper, more predictable planning inside the AST-first pipeline.

## Numbers Used In Deck

Measured from available repo artifacts:

- `semantic/extracted_gate_rows_1000.ndjson`
  - 999 runs
  - 1,321 taskitems
  - 5,284 extracted gate rows
  - 4 extracted gate rows per taskitem

- `sprints/SPRINT-004-pipeline-decision-audit.md`
  - `generate_taskitems` currently bundles 10+ separable decisions per taskitem

Extrapolated for the 125-program example set:

- 125 programs x 1.32 taskitems/program ~= 165 taskitems
- 165 taskitems x 10+ planning decisions ~= 1,650+ planning decisions

Tiny transformer numbers:

- ~213K parameters
- ~800KB checkpoint
- 4,000 training steps
- about 3 to 5 minutes per gate on RTX 3060

Existing prereq gate results:

- `needs_resolve_dependencies`: 69.4%
- `needs_architect_review`: 75.0%

Important caveat:

- The first dataset has about 17 unique text templates, so the early results are diagnostic rather than production quality.

## Training Environment Status

This temporary Ubuntu OS does **not** have the training stack:

- no `nvidia-smi`
- no PyTorch
- no numpy / pandas / scikit-learn
- no Fabricate trainer repo cloned

The `whetstoneDSL` clone here mostly contains the MPS language/project docs. It does **not** include the original taskitem run logs, specialist fleet, or Fabricate training code.

The usable local training data is in `whetstoneRSA`.

## New Training Prep Added

Added:

- `tools/gen_binary_gate_tsv.py`

Generated:

- `semantic/binary_gate_tsv/target_files_present_train.tsv`
- `semantic/binary_gate_tsv/target_files_present_eval.tsv`
- `semantic/binary_gate_tsv/acceptance_commands_present_train.tsv`
- `semantic/binary_gate_tsv/acceptance_commands_present_eval.tsv`
- `semantic/binary_gate_tsv/required_tools_present_train.tsv`
- `semantic/binary_gate_tsv/required_tools_present_eval.tsv`
- `semantic/binary_gate_tsv/manual_approval_present_train.tsv`
- `semantic/binary_gate_tsv/manual_approval_present_eval.tsv`

Generator command:

```bash
python3 tools/gen_binary_gate_tsv.py \
  --input semantic/extracted_gate_rows_1000.ndjson \
  --output-dir semantic/binary_gate_tsv \
  --eval-frac 0.15 \
  --seed 42
```

Generated dataset summaries:

```text
target_files_present:
  train: 1123 rows, 501 positive, 622 negative, 44.6% positive
  eval:   198 rows,  91 positive, 107 negative, 46.0% positive

acceptance_commands_present:
  train: 1123 rows, 501 positive, 622 negative, 44.6% positive
  eval:   198 rows,  91 positive, 107 negative, 46.0% positive

required_tools_present:
  train: 1123 rows, 501 positive, 622 negative, 44.6% positive
  eval:   198 rows,  91 positive, 107 negative, 46.0% positive

manual_approval_present:
  train: 1123 rows, 10 positive, 1113 negative, 0.9% positive
  eval:   198 rows,  2 positive, 196 negative, 1.0% positive
```

Recommended training priority:

1. `target_files_present`
2. `acceptance_commands_present`
3. `required_tools_present`
4. Skip or rebalance `manual_approval_present` unless intentionally testing rare-class behavior

## Important Caveat On New Binary Gates

The original strict extraction rejected `target_file_selection`, `acceptance_command_selection`, and `required_tool_selection` rows because labels were empty or sibling-uniform.

The new TSVs intentionally turn those into simpler presence/absence gates. They are useful for first-pass tiny transformer experiments, but they are not final high-quality gate definitions.

## Suggested Next Session

1. Pull latest `whetstone_RSA` on the main PC.
2. Open `presentations/whetstoneRSA_full_story_deck.html` and check the flow.
3. Copy `semantic/binary_gate_tsv/*.tsv` into the Fabricate training workflow.
4. Train the three balanced binary gates first:
   - `target_files_present`
   - `acceptance_commands_present`
   - `required_tools_present`
5. Record:
   - training time
   - eval accuracy
   - majority baseline
   - checkpoint size
   - notes on class balance
6. Update the deck with actual new gate training results if there is time before the talk.

## Push Note

If using this temp machine again, push with:

```bash
cd /home/ubuntu/Documents/whetstoneRSA
GITEA_TOKEN='<token>' git -c credential.helper='!f() { echo username=bill; echo password=$GITEA_TOKEN; }; f' push http://borgswarm:3000/bill/whetstone_RSA.git master
```