# ADR-149 Kept, Not Filtered — `procedure`-Kind JEEGym Concepts Get Their Own Pool

## Status

Accepted, 2026-09-08.

## Status History

```yaml
status_history:
  - date: 2026-09-08
    status: Accepted
    changed_by: claude (session close-out, advisor-endorsed)
    reason: >
      Recorded retroactively at /close-session, after advisor() review of the session
      transcript flagged that the procedure-kind resolution was a reversal of the
      assistant's own initial framing, not a simple confirmation — worth freezing as
      an ADR precisely because of the wrong turn in the middle.
    changed_via: adr-kit (360lm), via /adr skill inside a Claude Code session
```

## Context

JEEGym extracts atomic drill cues from real JEE PYQ explanations (and, as of this session,
Vidaara.org content too). Each extracted concept is tagged with a `kind`: `formula`, `identity`,
`procedure`, `fact`, or `definition`. Four of the five are single-line recall-or-plug-in units;
`procedure` is the one kind that chains 2+ steps (e.g. "substitute, factor, cancel, solve").

Mid-session, hkl asked to widen JEEGym's scope to include Vidaara as a second source, and in the
same message tightened JEEGym's atomicity bar: "JEEGym cues has to be building block not even a
question - strictly a smallest component... memory based and small memory based calculation based
cues only."

The assistant read this as implying `procedure`-kind concepts — the one kind that is not a single
atomic step — should likely be filtered out of JEEGym or require a narrower re-extraction prompt,
and drafted the plan file (`yesha-jeegym-plan.md` §8 item #9) and a BUILD_LOG entry around a
filter-vs-reextract cost tradeoff ("the forcing question"), **before hkl had seen concrete examples
of what `procedure`-kind concepts actually contain.**

hkl caught this directly: *"procedure kind - what do you mean by procedure kind - pls share
example - don't scrap any thing as of now."* Shown real examples plus the measured cost — 41.4%
of `claude/claude-opus-5`'s accepted concepts and 38.8% of `agy/claude-opus-4-6-thinking`'s are
`procedure`-kind — hkl's actual decision was the opposite of a filter.

## Decision

Keep every `procedure`-kind concept from every completed extraction run. Do not filter, drop, or
re-extract for atomicity. Split accepted concepts by `kind` into two pools instead: atomic kinds
(`formula`/`identity`/`fact`/`definition`) go to `pools/atomic_cues.jsonl`; `procedure`-kind
concepts go to `pools/procedures.jsonl`. Both pools keep full extraction provenance (source
question id, model, evidence quote). Future use of the procedures pool is explicitly undecided —
hkl will specify it later.

**Decision Maker:** hkl. Verbatim: *"Pls dont scrap the procedures at all in fact accumulate the
procedures and create separate pool for this - i will suggest how to use the same in future."*

## Implementation Notes

- **File:** `gym-extract/split_procedure_pool.py` — reads every validated extraction-run JSONL,
  keeps only `verdict == 'accept'` records, routes by `kind` (`ATOMIC_KINDS =
  {'formula','identity','fact','definition'}` → atomic pool; `'procedure'` → procedure pool; any
  other kind string is a hard `sys.exit` — schema drift is surfaced, never silently dropped).
- **Outputs:** `gym-extract/pools/atomic_cues.jsonl` (653 records as of 2026-09-08: opus-5 +
  agy runs on sequences-and-series) and `gym-extract/pools/procedures.jsonl` (441 records: 260
  opus-5 + 181 agy).
- Additive/idempotent — safe to re-run whenever a new validated run lands, including once
  Vidaara-sourced extraction starts.
- **Find all sites:** `grep -rn "atomic_cues\|procedures.jsonl" gym-extract/`

## Alternatives Considered

- **Filter `procedure` out of JEEGym entirely** (the assistant's initial, premature framing) —
  rejected by hkl once he saw what would be lost: nearly 40% of already-validated extraction work,
  for a distinction he had not actually asked to enforce.
- **Re-extract with a narrower prompt that structurally excludes multi-step concepts** — rejected
  as needless cost: both completed production runs (276 questions each, two models) would have
  needed to be discarded and re-run for a requirement hkl never stated once he saw examples.
- **Chosen: keep + pool separately** — zero re-extraction cost, no information discarded, defers
  the actual design question (how to use procedures) to hkl instead of guessing it up front.

## Consequences

**Positive:**
- Zero re-extraction cost; both existing production runs stay fully valid inputs to this pool
  split.
- Full provenance preserved on both pools, so any future use (a separate JEEGym mode, a
  teacher-facing reference, etc.) can be built without re-deriving source linkage.

**Negative / risks:**
- The procedures pool currently has **no consumer** — 441 records with an undecided use is a
  standing an open item, not a closed one, and could be forgotten if not tracked. Mitigation:
  tracked explicitly in `yesha-jeegym-plan.md` §8 and in project memory
  (`project_student_jee.md`) as open.
- The premature "forcing question" framing that this ADR reverses was already written into
  `yesha-jeegym-plan.md` and `BUILD_LOG.md` before hkl's correction — those documents were
  corrected in the same close-out that produced this ADR, but anyone reading an uncorrected
  cached copy would see the wrong framing presented as resolved.

## Related Decisions

None yet in this ADR log directly address JEEGym's concept-kind taxonomy; this is the first.

## References

- Session: `session_2026_09_08_jeegym_omniroute_dpp_rescope.md` (DL memory)
- Project narrative: `project_student_jee.md` (DL memory), `BUILD_LOG.md` (project) — "The
  forcing question, answered" entry, dated 2026-09-08
- Code: `gym-extract/split_procedure_pool.py`, `gym-extract/pools/*.jsonl`
- Plan: `.claude/plans/yesha-jeegym-plan.md` §8 item #9