Learning Loop

The Learning Loop is the factory's self-improvement mechanism — a structured process where every app build produces a retrospective that captures wins, failures, and actionable learnings, which are then fed forward to improve the next build cycle. It is the mechanism that makes the factory compounding rather than repetitive: each iteration makes the factory smarter, faster, and more reliable than the last.

The loop works as follows: after each app completes the pipeline (SUBMIT, MARKET, TRACK), the factory runs a post-review retrospective. This is not a free-form discussion — it's a structured review against the pipeline's defined quality gates and scoring rubrics. Did the Discovery Gate's opportunity score correlate with actual app performance? Did the Design Gate's 95/110 score predict user satisfaction? Did the Polish Gate's 70% threshold correlate with App Store ratings?

The retrospective captures specific data points: which opportunity characteristics predicted strong downloads, which design patterns correlated with high retention, which polish features users mentioned in reviews, which competitive gaps the factory missed that users complained about. This data goes into the factory's intelligence layer — not into a general memory file, but into the scoring models that drive the quality gates.

For Discovery Gate specifically, the learning loop improves the 28/40 rubric calibration. When an opportunity that scored 30/40 produces an app that fails, that's a false positive — the rubric said it was viable but it wasn't. The factory's response is to adjust the rubric weighting: which factors in the rubric are actually predictive of success? Over time, the rubric becomes more accurate because it's been calibrated against real outcomes rather than assumed correlations.

For Design Gate, the learning loop tracks which design patterns produce apps with high App Store ratings and which produce complaints. If a specific component pattern consistently causes accessibility failures or usability complaints, the Design Station's reference library gets updated to deprioritize that pattern. If spring animations consistently get praised, the Polish module gets more emphasis on that dimension.

The learning loop also captures failure patterns that the Angry Mob should have caught but didn't. When a security vulnerability surfaces in production (see angry-mob), the retrospective adds that vulnerability class to the Security Auditor's checklist. When a performance issue causes crashes, it gets added to the Performance Saboteur's scope. The Angry Mob grows smarter with each failure.

The operator's role in the learning loop is to review the retrospective findings and approve changes to the scoring models and gate criteria. The factory produces the data; the human makes the judgment calls on whether the data warrants changing the operating system. This keeps the factory from drifting into unintended behavior while preserving the compounding benefit of real-world feedback.

The practical output of the learning loop is documented in weekly memory maintenance — the cron job that reads the past week's memory files, identifies patterns, and proposes MEMORY.md updates. The learning loop feeds this process by providing structured data about what worked and what didn't, rather than relying on the operator to manually extract insights from raw session logs.

  • ios-factory-pipeline — Step 10 (LEARN) is the formal retrospective moment
  • memory-system — the persistence layer where learning loop outputs are stored
  • discovery-gate — which gets calibrated by learning loop false positive data
  • angry-mob — which grows through learning loop failure pattern capture