Home / Ops / More in this area

Technique Pipeline - Build Brief v1

Updated Jun 27, 2026 · Affirmology_TechniquePipeline_BuildBrief_v1.md

Technique Pipeline - Build Brief v1

How to actually implement the technique toolkit (registry Part 1). The key finding: most of the plumbing already exists, so this is a small, mostly-additive build, not a from-scratch system. Do it in phases; each phase is independently useful.

What already exists (verified in the engine)

• The nightly grower mines techniques into the corpus craft table (252 entries, on R2 at corpus/corpus.db). Fields: area, name, method, why, when_to_use, how_to_apply, one_liner, body, tags, confidence, source, source_doc, rule, form, scope.
• affirmology-agent/src/affirmology/corpus/craft.py search_craft(query, n, area, rule, form, scope) already retrieves and ranks craft, and ALREADY filters by area / rule / form / scope. Ranking is score then confidence then updated_at.
• affirmology-agent/src/affirmology/agents/council.py select_craft(concept) is THE render-time sprinkle hook: it pulls ~12 techniques + practitioner methods + a healing slice and the agent selects and sequences from them. So techniques already flow into audios.
• api/hermes_tools.py search_craft() exposes craft search to Hermes.

The four gaps (this is all we are building)

• GAP A, the approval gate: there is no status/approval concept; every mined technique is eligible. We want only vetted techniques used.
• GAP B, type and slot tagging: form/scope/rule exist but there is no explicit identity-vs-transformation TYPE or open/body/close/arc SLOT, which is what lets us "know our tools" and target them.
• GAP C, rotation: retrieval is deterministic (same concept gives the same top techniques), so audios can repeat techniques. We want variety, weighted by confidence, avoiding what a person heard recently.
• GAP D, a place to browse and approve: none yet. (The corpus-browser tab on resources.affirmology.ai becomes this front-end later.)

PHASE 1 - Toolkit data model + approval gate (DO THIS FIRST, keystone)

Smallest change, highest leverage. Additive and safe; the gate ships dormant so nothing changes until we approve a starter set.

1. Schema migration on the R2 corpus.db (additive columns, all nullable with safe defaults so the nightly upsert_craft keeps working): - status TEXT default 'mined' (mined | candidate | approved | rejected) - technique_type TEXT default '' (identity | transformation | both | '') - slot TEXT default '' (open | body | close | arc | '') - approved_at REAL, approved_by TEXT, review_notes TEXT Do the migration the cloud-safe way: pull corpus/corpus.db from R2, ALTER TABLE craft ADD COLUMN ... for each, push back to R2. Coordinate so it does not race the nightly cron (run right after a nightly completes, or pause the cron for the migration).

2. Backfill the 252 existing entries with a one-time, cost-capped Haiku pass that proposes technique_type and slot from each entry's method/one_liner/form/scope. Leave status='mined' (do NOT auto-approve; a human approves). Write results back to R2.

3. Extend craft.py search_craft with optional status, technique_type, and slot filters, mirroring the existing rule/form/scope filter pattern (same code shape). Default: no filtering, so existing callers are unchanged.

4. Add a config flag TOOLKIT_APPROVED_ONLY (env, default OFF). When ON, select_craft (and the Hermes craft search) pass status='approved'. Keep it OFF until a starter set is approved, so the council is never starved.

Result after Phase 1: a structured, filterable toolkit and a ready-but-dormant approval gate. No behavior change yet.

PHASE 2 - Browse + approve (manual MVP, no heavy UI)

5. Add two Studio endpoints in api/main.py (team-token gated): - GET /api/toolkit lists craft with status/type/slot, filterable by area/type/slot/status. This is the "know what tools we have" list. - POST /api/toolkit/{id}/status sets status (approved/rejected/candidate) + approved_by + review_notes. This is how Jeff/Sol vet. Approving a starter set is then a handful of calls (or a tiny admin view). The corpus-browser tab (Phase 4) becomes the nice front-end over these same endpoints.

6. Approve a starter set: Jeff/Sol mark ~30 to 50 of the highest-confidence, best-fit techniques approved across the slots (enough open/body/close/identity/transformation coverage that the gate has plenty to draw on). THEN flip TOOLKIT_APPROVED_ONLY ON. From this point, only vetted techniques are used.

PHASE 3 - Rotation / anti-repetition (the "don't repeat" payoff)

7. Capture which techniques a render actually used: when the council selects, log the chosen technique ids per person/render (a small render_techniques table or a field on the job).
8. Add variety to selection: in select_craft / search_craft, pull a larger approved candidate set (e.g. top ~20 by score), then choose with confidence-weighted randomness, EXCLUDING techniques the person heard in their last N renders. This gives same-truth, different-ingredients across audios, which is exactly the monthly-bake-to-monthly-bake rotation in the registry.

PHASE 4 - Corpus-browser tab on resources.affirmology.ai

9. Extend the existing resource-hub/ generator (the cron that builds resources.affirmology.ai) to also pull the corpus from R2 at build time and render the toolkit (craft) as browsable, searchable cards showing status/type/slot/confidence/source, plus a "recently synthesized" feed from the nightly growth reports. Reuses the existing static-generate-and-deploy architecture. This is the human-facing window into the toolkit and reads the same data Phase 2 writes. Needs its own short build brief (similar to Affirmology_ResourceHub_BuildBrief_v1.md).

Recommended sequencing and why

Phase 1 is the keystone and is cheap: it turns the existing free-for-all craft store into a structured, gate-ready toolkit without changing any audio yet. Phase 2 makes vetting possible with two endpoints, no big UI. Then flip the gate ON once a starter set is approved, and you have Jeff's core ask (only vetted tools, browsable by type/slot, sprinkled into audios) with the rotation in Phase 3 and the pretty browser in Phase 4 following. Phases 3 and 4 can run in parallel after Phase 2.

Rules / safety

• All corpus work is cloud-only: pull from R2, edit, push back; never store corpus.db on the Mac.
• Every schema and code change is additive and nullable-defaulted so the nightly grower's upsert_craft and all existing renders keep working unchanged.
• TOOLKIT_APPROVED_ONLY stays OFF until a starter set is approved (never starve the council).
• This touches audio CONTENT selection (Phase 3 especially), so per the project working agreement, verify renders and review with Jeff before flipping the gate ON or shipping rotation.
• No em dashes. Update Affirmology_PROJECT_STATE.md last.

Verification per phase

• Phase 1: search_craft(..., status='approved') returns only approved rows; with the flag OFF, an existing render produces byte-identical craft selection to before. Backfill: spot-check 10 entries' type/slot are sensible.
• Phase 2: GET /api/toolkit returns the list with new fields; POST flips a status and it persists to R2.
• Phase 3: two renders of the same structure for the same person draw different technique sets; none repeats the person's last render.
• Phase 4: the tab lists and searches the toolkit and refreshes on the cron.