AIMasterTrainer — Architectural Decisions
Last Updated: 2026-04-14 (S55)
D1: Three-Layer Knowledge Architecture (Session 30)
Decided: raw_items → knowledge → meta_knowledge → wisdom → CLAUDE.md Why: Each layer is a different kind of abstraction. Raw items are facts. Knowledge entries are insights. Meta-knowledge is patterns across insights. Wisdom is universal principles. Only wisdom enters CLAUDE.md — preventing CLAUDE.md from becoming a dump of raw observations. Alternative rejected: Flat knowledge base (no hierarchy) — would have made CLAUDE.md grow unmanageably.
D2: Confidence ≥ 0.90 Gate for CLAUDE.md Integration (Session 30)
Decided: No wisdom entry enters CLAUDE.md unless confidence ≥ 0.90 + strip test passed + 3+ independent sources. Why: CLAUDE.md is sacred — it governs ALL future sessions across ALL projects. A premature principle embedded here degrades every session that follows. The gate prevents aspirational principles from being treated as proven ones. Evidence: 8 entries integrated cleanly. 0 retractions.
D3: Strip Test for Wisdom Validation (Session 30)
Decided: Every wisdom candidate must pass 4 strip test questions: (1) Is this universally true beyond AI? (2) Would this be true if Claude didn’t exist? (3) Does this survive the “so what?” test? (4) Does this change behavior when applied? Why: Wisdom without the strip test produces AI-specific observations that don’t generalize. WIS-010 was validated by ISO 10218 industrial robotics — proving it applies to physical systems, not just LLM agents.
D4: Single JSON Registry as Source of Truth (Session 30, ML#14)
Decided: All knowledge (sources, raw items, knowledge, meta-knowledge, wisdom) in one file: docs/mastertrainer-registry.json.
Why: One fact, one place (ML#14). If sources were in one file, knowledge in another, wisdom in another, cross-references would drift. The single file guarantees consistency at the cost of file size (now 207 KB).
Alternative rejected: Separate files per layer — would require sync logic and would drift.
D5: Windows Task Scheduler for Autonomous Harvesting (Session 47)
Decided: harvest-auto.bat runs every morning at 8:00 AM IST via Task Scheduler.
Why: Task Scheduler is local, reliable, requires no external dependency, and runs headlessly. No cloud service, no API key, no network dependency beyond the harvest itself. It has run for 5+ consecutive days without failure.
Alternative rejected: GitHub Actions (requires pushing to trigger), external cron services (network dependency).
D6: Deliberate Harvest Cap (Session 52 — learned from S43)
Decided: Cap each autonomous harvest at 3-4 sources maximum. Never try to catch up on all overdue sources in one run. Why: S43 added 8+ sources without WIS integration → score dropped -6.6. S52 score dropped -1.5. S54 with 4-source cap → 0.0 delta. Ratio dilution is structural: adding KNW without proportional WIS integration depresses the Self-Improvement dimension. The cap prevents volatility. Evidence: Score volatility trend: -6.6 → -4.2 → -1.5 → -0.1 → 0.0 across 5 sessions.