A spark is a lesson written after a real failure — numbered, dated, permanent. Each entry below expands into the full record: what broke, what was learned, and the rule it created.
Sparks are postmortems normalized into rows: observed, number, title, domain, the incident, the lesson, who paid for it and the article it fed. The loop appends after each failure.
Two of the five entries fed articles 01 and 02. The other three are titles waiting for their record.
After weeks of clean nights, the verify gate began passing work that later failed downstream. Nothing in the gate had changed — the system around it had. The checks were written against an older shape of the codebase, and every night of autonomous building moved the code a little further from what the checks assumed. The gate’s power decayed silently, at exactly the rate the system diverged from its snapshot.
A gate is not a fixture; it’s a moving part. Verification must be re-derived from current state on a schedule, or its pass rate becomes a measure of staleness, not correctness. The loop now rebuilds gate criteria from the live system weekly.
A nightly stage hit an error, fell back to a cached result, and reported success. The morning report was green for six days while the underlying pipeline was dead — discovered only when the cache went stale enough to produce visible nonsense. Loud failure would have cost one night; silent success cost a week.
Fallbacks may keep a system running, but they must never keep it quiet. Every fallback now files a spark-adjacent notice, and "green" is reserved for the primary path proving itself. If the factory degrades, the morning report says so in red.