Stage S8 — Precipitation
P Stage correspondence. S8 Precipitation. These are the same stage identities used by the product overview and case walkthrough. A checkpoint or nested task conversation stays inside its owning stage.
Purpose
This is the stage that exists because of a named v1 pain point: recurring and long-running investigations are not being turned into skills or durable memories, so the next occurrence costs the same one to two hours that a skill or a memory entry would cut to minutes (stated 31.08.2026).
Precipitation is the case paying for itself. It is mandatory, it is recorded, and nothing is a legitimate outcome — provided it is justified.
Where the events are raised
P A precipitation event is a declared property of a stage — precipitates on the stage in its module manifest (data, configuration, source, commercial). Seven stages across the four working lanes carry it, and the detailed map draws the mark in purple, in the same place as a decision checkpoint:
| Lane | Stage that raises the event | Why there |
|---|---|---|
| Data & Manipulation | Stage 6 Validation · Stage 7 Reversal / restoration | the mechanism is proved on the customer's surface — or the failure and its restoration are; both are what the next case needs |
| Configuration | Stage 6 Joint proof · Stage 7 Release and verify | the joint proof holds what the four domains had to agree; the release holds what the target actually accepted |
| Customer-specific development | Stage 5 Review and corrections · Stage 8 Deploy and verify | the review holds what the change had to become; the deployment holds what the environment required |
| Assessment & Offers | Stage 5 Communicate decision | the estimate meets the decision: what was assumed, what it cost, what the customer accepted |
P The event holds nothing open. The stage files its experience entry — and what was missing — as a proposal, and moves on (§ 3). Delivery follow-through is the opposite obligation: packet review, execution permission, independent target proof and any due recovery belong to the requested delivery and never wait for precipitation (Configuration Work Procedures, Stage Deployment Scripts).
P One workflow serves every lane, asynchronously, in three steps. A scheduled summarisation whose cadence a person sets — the dreaming pass (§ 6). Then creation: the facts, skills and tested tools, by common.experience-curator — the shared profile Data declares as its Stage 8, and the one every marked stage files to (§ 1). Then seeding for everyone, which is the publish gate and always a person (Gating, Agents Memory § 7.4b). Until that gate is answered the proposal changes nothing, for anyone.
What runs this stage
| Agents | common.experience-curator confirms the shared experience index; methodology and source/tool changes go to their canonical domain owner for confirmation. |
| Isolated sub-agents | — |
| Memory domains | owns support/experience; reads and proposes to support/methodologies, owned by support.resolution. The owner alone activates shared revisions (Modules). |
| Skills it runs | skill creation goes through governance (Agent Framework § 6); the catalogue itself is Agents Memory and Skills |
| Its branch of the graph | Data & Manipulation Module § 0 — the working stages' tree, memory branch and skills · the component list is Data & Manipulation components |
Every stage also uses support.root — the only profile that reaches the human — and, where it writes, the shared skill common.effect-applier (Gating).
Inputs → Outputs
In: the events raised by the marked stages of any lane — Data after validation or restoration, Configuration after joint proof or release, Customer-specific development after review or deployment, Assessment after the communicated decision. Closure is the customer's (D49) and precipitation does not wait for it. With each event: its papers, its mechanism, what was reused, what was missing, and the budget it used. Out: a precipitation decision, the mandatory experience entry and one coherent capability change when justified: tool source/binary, tests, skill binding and related knowledge/index changes; or a recorded reason that nothing new is needed.
0. The approach — why v1's memory does not fire, and what changes
F v1 does precipitate: 548 memory files, 509 analyses (frozen baseline 31.08.2026), 56 known issues and living checklists exist (Baseline § 2). What fails is retrieval and application: the 20.05.2026 audit found four error families recurring after their rule already existed, and cached knowledge that is 10–60× cheaper than rediscovery going unused (write-time discipline, measurement). The pain is therefore not "we do not write things down"; it is that what is written down is flat, retrieved by grep on one-line descriptions, and has to happen to be read at the moment it matters.
P The approach, in the order it pays back (decision 02.09.2026):
| # | Move | What it fixes | Where it is specified |
|---|---|---|---|
| 1 | Mechanics, not memories. Anything that must always happen becomes a pipeline phase with a required output — the nine investigation mechanics, the closing walk reconciled like a plan, the assertion form | the "rule existed, was not applied" family: a phase cannot be forgotten, a memory file can | Stage Investigation § 1, § 3 below |
| 2 | Retrieval at the moment of need, not at boot. Triage queries the experience index with the symptom signature before investigation starts and returns precedents as hypotheses; the investigator reads outward from its own node on demand | knowledge present but never consulted | Stage Classification § 5, Agents Memory § 2 |
| 3 | Skills over articles for anything executable. A diagnostic query pack, a compare checklist, a master-data operation is a tool the agent calls, with assertions — not prose it must remember to follow | the "checklist halted silently" family | Agents Memory and Skills, Agent Framework § 6.6 |
| 4 | Measure the firing rate, and let it decide. Migration of a domain is accepted only when the held-out triage hit-rate beats grep; consolidation passes are judged the same way; the retrieval mechanism (grep vs vector) is chosen by that number | rebuilding a corpus that does not fire | Agents Memory § 7.2 |
| 5 | Refine on use, not on writing. The 3 / 7 / 20 ladder revisits a skill or article when it has actually been used, with more evidence | entries written once and never revisited | § 2 below |
| 6 | Governance for memory. Proposed → active → retired, provenance on every write, version pinning per case, dependency-scoped eval re-runs | an article that quietly misleads every later case | Agents Memory § 7.4b |
P The retrieval measure for this part of learning is the triage hit-rate on held-out v1 cases (Agents Memory § 7.2) — and it was measured on the v1 corpus on 02.09.2026, before any platform existed: 30 held-out resolved tickets, each presented as it arrived, against what the current memory/ offers a grep. The result is the baseline to beat — a cited precedent in the top five for 3 of 30 (10 %), 98 % of the 150 possible slots noise, and 7 tickets returning nothing (Measurements § TB). The target is ≥ 50 % top-5 hit-rate per domain before acceptance (D111, Metrics).
1. The decision
P Every result records an experience entry and one coherent learning decision. A capability change may include a tool, its skill binding and the knowledge/index required to use it; these are related deliverables, not a choice limited to one file. The owner checks both what should be remembered and which repeated mechanical work should become executable.
| Outcome | When | Produces |
|---|---|---|
| Tool | repeated reasoning, latency, usage or inconsistent output reveals a bounded operation with testable inputs/results | source code and/or a binary, tests, exact package binding and usage/index documentation; Tools as retained learning |
| Skill | the investigation shape will recur and is mechanizable — a diagnostic query pack, a repeated master-data operation, a check sequence | a skill, published through governance (Agent Framework § 6.6) |
| Article | a pattern worth recalling: a mechanism, a trap, a rule of the running system | a memory article in the owning domain, under the writing practice |
| Index line | the domain's AGENTS.md one-liner needs updating so the thing is findable |
an index change in the same edit |
| Nothing | the case taught nothing new | the justification, recorded — not silence |
The mandatory experience entry is written case-locally by the agent that worked the case and filed as a proposal; the domain's curator promotes it into shared storage (D25/D56).
P The decision is an audit record, so precipitation rate and reuse hits are parsed rather than claimed (Metrics).
2. The recurrence ladder — 3 / 7 / 20 (a configuration default)
P Case journeys § 6 separates fix-shape occurrence, confirmed-trigger recurrence and clean execution. The existing mechanism/object signature drives this ladder; an evidenced trigger-family relation joins different repairs with one cause. Count canonical requests, not mirrors/subcases. The S8 job is keyed by request and verified result revision and durably queued at resolution. Later customer evidence or a contradiction creates an amended result/proposal while preserving earlier evidence. Closure and retries never silently double the count.
P Precipitation is not one event but a refinement ladder, driven by how often the same shape actually recurs (decision 01.09.2026); the three counts are a platform-policy value with the defaults below (Whitelabel Catalogue):
| Occurrence | What happens |
|---|---|
| 1st–2nd | record experience; reuse existing tools. Earlier automation is allowed when repeated work within the case or an established correctness need justifies a bounded, tested tool |
| 3rd | require an automation/reuse assessment: tool, skill, article, an improvement to an existing capability, or a reasoned decision not to automate |
| 7th | first refinement pass. The agent revisits its own first version with four more cases of evidence and spends real time improving it — a version written from three examples will show it |
| 20th | second refinement pass. By now the shape is load-bearing and worth the cost of getting right |
Why a ladder rather than a threshold: a created skill is not a finished skill. The v1 corpus is full of entries written once and never revisited, which is a large part of why it does not fire. Scheduling the improvement at a known occurrence count means refinement happens because the thing is used, not because someone remembered it.
P The counter is the same fix signature the solution take uses, so one count drives both ladders.
P The ladder is a review cadence, not permission to repeat waste or leave a defect. A wrong claim or tool is corrected immediately, with its regression evidence and a new version. A new reusable tool can be justified before the third case by known repeated work and a testable algorithm. Frequency never substitutes for tests. Keep a single coherent capability change rather than scattering the same finding across unrelated articles.
3. The closing walk
P Closing runs the v1 step-10 propagation walk, and — the part v1 got wrong — the walk is reconciled like a plan: every item is marked done or explicitly skipped with a reason. A silently halted checklist is the measured v1 failure mode; what the audit of 20.05.2026 counted is four error families recurring after their rule already existed (Baseline § 5) F: [audit, propagation rule].
The walk covers: the known-issue register (a closed ticket does not close its KI — 56 are open, KNOWN_ISSUES.md) · the living checklists (e.g. the policy sync compare checklist, which is meant to be extended by the cases that use it) · the experience index · the domain articles · the eval sets.
4. Writing rules
P Writes go only into the agent's own domain; cross-domain findings are handed to the owning domain's agent with their evidence, as a request record (Agents Memory § 2).
F The writing practice, inherited: belief order running system → consuming code → memory; four kinds of wrong (wrong, stale, ambiguous, environment-specific) with four different treatments; fix the claim where it is made; guide, not diary — no dates, sessions or incidents in article bodies, provenance in metadata, values replaced by the regenerating query; record the pattern, never the incident; no customer PII (rule).
5. Feedback into evaluation
P A precipitated skill or article changes what the module knows, so it re-runs the affected eval sets (CR-4). This is the loop that keeps precipitation honest: an addition that degrades the module's golden corpus is not an improvement, and the platform finds that out at publish time rather than on the next real case.
6. Consolidation — the dreaming pass
P On a schedule, separate from case closing — and this is where curation lives (decision 01.09.2026). The experiencing agent writes the entry while it still holds the context; the dreaming pass is what later catches the entry that only makes sense to someone who was there, and rewrites it for a reader who was not.
The pass: merge duplicates, re-read entries against the would this help a stranger test, prune what the running system has outgrown, resolve or explicitly mark contradictions, refresh each node's AGENTS.md one-liners, and run any 7th/20th refinement passes the ladder (§ 2) has fallen due. New nodes only when the § 2 gate is met — recurring content, a distinct owning profile, and a retrieval need the parent index cannot serve (Agents Memory § 5).
Challenges
- P Article proliferation: 548 v1 files with the recall problem this stage is meant to fix. The consolidation pass must be measured by the same triage hit-rate as migration (Agents Memory § 7.2), or precipitation just rebuilds the corpus that did not fire.