Skip to content
GRPNR.

13 - Pre-mortem: the Atlas inquest (January 2028)

Premise: it is January 2028. Atlas shipped. It failed badly enough that the program is holding an inquest. This document is that inquest, written backward from the failure to find the causes, using the PRD (12-prd.md) and the two evidence files (evidence/r8-negative.md, evidence/r5-comms-products.md) as the record. It does not assume the concept was good. Where the PRD already named a risk, pivot, or kill criterion, this inquest cites it and asks whether it actually fired in time, not whether it existed on paper.

No em-dashes. Numbers below are either MEASURED (from the imagined post-mortem’s own account), INTERPRETATION, or ASSUMPTION about how a named mechanism plausibly failed; none are fabricated market data. Likelihood and impact are H/M/L judgment calls, not measured probabilities, since no base rate exists for a 2-human, 64-agent, greenfield question-loop.

0. Verdict

Atlas did not die from one dramatic failure. It died from the same failure the PRD itself predicted twice, RA-1 never being measured before the surface grew, compounding with the one failure mode wiki and KM literature converges on hardest: adoption depends entirely on one human’s habit, and once Tomas found GChat faster than the sanctioned queue, the loop had no mechanism left to protect. Everything downstream, doc-rot, false merges, digest fatigue, was a symptom of a corpus that kept growing after its two load-bearing assumptions (real duplicate volume, a champion who uses the sanctioned path) had already quietly failed.

1. Failure mode catalog

Problem severity

FM-1. Question volume never materialized. The four core numbers (duplicate rate, interrupts/day, re-ask rate, answers-worth-persisting) were DARK at launch by design (PRD §2, §25); the wave shipped on the theory that EOL/dead-owner legacy code (VIS ~2013, orders ~2017) would generate enough “is this alive” volume to matter. It did not, or Tomas absorbed it without ever routing through the loop. Root cause: the volume assumption (RA-1) was MODELED from freeze dates, never MEASURED against a real fleet, and no product or OSS precedent existed to calibrate against (PRD line 36). Likelihood M, impact H (this is R6 in the PRD, “the single riskiest” assumption). Earliest warning signal: raw pre-dedup ask count flat through day 3 of the live wave, distinguishable from cold-start (variant B) by whether agents are asking at all, not whether they’re finding answers. Leading indicator: ratio of new canonicals to fleet-agent-hours trending to zero. Prevention: publish the DARK to MEASURED numbers at a week-1 checkpoint, not week-4. Mitigation: fall back to plan-001 bare triage immediately (PRD §32’s own kill action). Owner: Robert (measurement), Tomas (his silence is the signal). Pivot trigger: none, feeds directly into the PRD §32 kill conjunction. Kill trigger: duplicate/attach rate < 15% and answers-worth-persisting < 5/week and flat re-ask rate after 2 waves (PRD §32, verbatim).

Targeting

FM-2. Built for teams that never arrived. N2/N8 (PRD) explicitly defer “future team reader” as an audience that does not exist yet (program ground truth). The inquest finds renderings work (glossary, decision records) sized for a multi-team readership the program never grew into, because the abandoned “intelligence and communication layer” framing pre-committed surface area even after the name was dropped (PRD line 14). Root cause: scope tracked the discarded pitch more than the surviving one. Likelihood M, impact H, this is Atlassian Atlas exactly: built and licensed for a teamwork-directory audience, folded back into a free platform tier within 3 years once standalone traction never materialized (r5 §1). Earliest signal: renderings accumulating with a reader count of one or zero. Leading indicator: the “future team reader” persona (PRD §6) logging zero real occurrences after N weeks. Prevention: gate renderings work behind the Stage 3 trigger (PRD §26), not ahead of it. Mitigation: strip renderings to the answer ledger only until Stage 3 fires. Owner: Robert. Pivot: none, a design-constraint violation, not a metric. Kill: freeze renderings production permanently if program handover (FM-19) confirms no second audience ever formed.

Adoption

FM-3. Agents bypass the loop; Tomas answers in GChat out of habit. The sanctioned queue loses to the channel Tomas already trusts. Root cause: R5 in the PRD names this precisely, champion dependency, single point of failure; the wiki-adoption literature’s strongest empirical finding backs it, all 7 case studies of failed KM/wiki adoption cited lack of active champion support as the cause, not tooling quality (r8 §1); Backstage’s ~10% external-org adoption despite a technically working deployment shows the same works-vs-used gap (r8 §2). Likelihood H, impact H, this is the load-bearing single point of failure in a 2-human system. Earliest signal: Tomas out-of-band answer rate (already instrumented, PRD §17) nonzero in week 1. Leading indicator: a rising gap between answers Tomas actually gave (sampled from GChat) and answers that landed in Atlas. Prevention: make the sanctioned path strictly faster than GChat for Tomas specifically, not just for agents (NFR-3 only covers agent-side resume latency). Mitigation: P-4, fix queue latency/UX before adding scope (PRD §31). Owner: Tomas (behavior), Robert (UX fix). Pivot: P-4. Kill: PRD §32 HARD KILL action, revert to the status-quo GChat relay.

Product quality

FM-4. Dedup false positives poison N agents. A wrong merge attaches a genuinely distinct question to the wrong canonical; every attached asker and every future reader of the persisted artifact inherits a wrong answer with full provenance dressing that makes it look trustworthy. Root cause: RA-3/R3 (PRD §23); merges are structurally hard to reverse once agents have resumed and acted on them, a pattern independently converged on across Jira and Zendesk merge-tooling vendors (“merges are effectively irreversible… best practice is surface, not auto-merge, even at 0.90 similarity,” r8 §4). Likelihood L in MVP (exact-key only, FR-7/8), rising if Stage 1 ships on a gamed or thin gate. Impact H, silent and compounding. Earliest signal: any confirmed false-merge in the wizard-of-oz judged set (PRD §26). Leading indicator: false-positive merge count (instrumented, PRD §17) nonzero. Prevention: FR-9’s bias to false-new over false-merge; Stage 1 requires false-merge rate == 0 on the judged set first. Mitigation: ADM-5 un-merge path; git-revert on the write-back side. Owner: Robert (dedup judge, wave 1). Pivot: P-2 (PRD §31). Kill: SAFETY KILL, confirmed corpus-poisoning incident (PRD §32).

FM-5. Write-back doc-rot at machine speed. The mechanism that makes the corpus valuable, fast machine-drafted artifacts, is the same mechanism that lets it rot fast. Root cause: named directly in the doc-rot literature, “once you encounter one outdated doc, you stop trusting all docs,” trust collapses to zero, not gracefully (r8 §1); Backstage’s catalog failure is structurally identical, records drifting from reality the moment the underlying system changes (r8 §2). Likelihood H, impact H, this is R2 in the PRD, the highest-named product risk. Earliest signal: one write-back artifact found stale or wrong, reported informally by Tomas or an agent. Leading indicator: revert/rework rate downstream of a self-served answer (instrumented, PRD §17) rising above zero. Prevention: append-only, supersede-never-edit (FR-22), expiry warnings (FR-24), human review for fidelity (§16). Mitigation: SAFETY KILL action, halt write-back, audit the gate. Owner: Robert (review), write-back agent (draft only, never merge). Pivot: none beyond P-1 (review load); this is kill-tier. Kill: confirmed poisoning incident trusted downstream (PRD §32).

FM-6. Stale answers trusted. An answer past expiry or superseded gets read and acted on as current because the EXPIRED warning is ignored, stripped during an agent’s own summarization, or scope is never re-checked. Root cause: ChatGPT’s memory feature is documented doing exactly this, storing outdated facts and presenting them “with the same confidence it applies to factual knowledge… without flagging uncertainty” (r8 §3); the MindStudio Claude Code anecdote shows CLAUDE.md-style memory accreting a day-1 fact still present, unreviewed, a year later (r8 §3). Likelihood M, impact H, a silent trust failure, not a crash. Earliest signal: any stale-served event (zero-tolerance instrumented, PRD §17, NFR-7). Leading indicator: passport-completeness dropping below 100%, or expiry dates clustering suspiciously at the “no-expiry” default. Prevention: FR-24’s hard-coded EXPIRED string on every past-expiry hit; NFR-7 treats <100% completeness as a defect, not a KPI. Mitigation: audit and re-date on discovery; supersede chain (FR-22/23) re-signals still-open attachments. Owner: Robert (audit), agent (must not strip warnings when summarizing). Pivot: none, an NFR compliance gate. Kill: repeat nonzero stale-served count escalates into the SAFETY KILL family.

UX complexity

FM-7. Capture form friction, agents avoid filing. The five-field schema (FR-4) is heavier than “just ask.” Under time or token pressure agents either skip filing (guess silently) or rubber-stamp the fields with schema-compliant garbage. Root cause: the PRD names this itself, “agents do not abandon forms, they rubber-stamp them” (07 §7.1, cited PRD §12); garbage normalized keys defeat dedup, garbage context wastes Tomas’s one scarce read. Likelihood M, impact M. Earliest signal: a sampled read of filed questions showing generic smallestUnblockingAnswer or searched[] fields. Leading indicator: low search-before-ask compliance, or a spike in fuzzy candidates judged “different” only because the fields were vague. Prevention: FR-4’s field descriptions are already written concrete (“paste the exact grep/search calls you ran”). Mitigation: Robert spot-audits filed questions in wave 1, tightens copy or adds a cheap validity check. Owner: Robert (skill copy), agent (asker compliance). Pivot: none named; feeds P-3 if garbage fields degrade findability. Kill: none standalone; contributes to FM-1 and FM-10.

Missing integrations

FM-8. Temporal resume flaky. The attachment-signal fan-out (FR-14) fails to resume some or all attached askers reliably at N>1. Root cause: this is R1 in the PRD, the highest-named technical risk, unproven on this substrate before build; NFR-6 makes a dropped resume a zero-tolerance hard bug, which guarantees visibility, not correctness. Likelihood H if unspiked, impact H, the entire fan-out promise depends on this mechanism. Earliest signal: resumed != attached on the first multi-asker completion. Leading indicator: resume-success rate (zero-tolerance instrumented, PRD §17) below 100% at all. Prevention: PRD already orders this prototyped first, before any docs/glossary work (§23 R1). Mitigation: the documented fallback, N-completion-calls per attached asker (FR-14, 04 CP-5). Owner: agent (build), Robert (spike verification). Pivot: switch to the fallback mechanism. Kill: HARD KILL if neither mechanism achieves reliable resume (North Star cannot move, PRD §32).

FM-9. GChat digest ignored. The capped digest rows (FR-25) land and Tomas/Robert stop reading them within weeks, the fate of every pure “digest of what happened” product surveyed. Root cause: “a digest tells you what happened yesterday and tells you almost nothing three weeks from now, because the digest is the only artifact and it was written to be skimmed once” (StandIn.co, r5 §8); none of the surviving vendors (Range, Status Hero, Standuply) differentiate on digest content, they survive by being cheap and tool-native (r5 §10). Likelihood M, impact L, this is explicitly a delete-at-zero-cost feature by design (N3, P-5). Earliest signal: digest open/read rate trending to zero (ask Tomas directly). Leading indicator: no digest-driven action ever traced to a real question or search. Prevention: cap kept tight, no second channel (N3). Mitigation: P-5, delete it, no redesign effort spent (PRD §31, explicit). Owner: Robert. Pivot: P-5. Kill: none needed, a zero-cost deletion, not a program risk.

Data quality

FM-10. Corpus polluted, search misses. search_answers returns stale, duplicate, or off-target results because low-signal entries (from FM-6/FM-7) accreted faster than anything prunes or re-scopes them, so agents stop searching before asking or ask anyway after search fails them once. Root cause: grep plus Postgres exact/trigram (N5) has no relevance ranking beyond lexical match; the Agent READMEs empirical study (2,303 real CLAUDE.md/AGENTS.md files, arXiv 2511.12884) shows even actively-maintained agent-memory files systematically underweight non-functional content (security guidance in only 14.5%) while over-accreting convenience content, an analogous shape to a corpus optimized for what got written back easily rather than what is reusable (r8 §3). Likelihood M, impact M, this is the mechanism behind P-3 already named in the PRD. Earliest signal: search-before-ask compliance falling even as corpus size grows. Leading indicator: measured miss-rate crossing 30% (PRD P-3 DESIGN threshold). Prevention: N5’s constraint (no embeddings until MEASURED miss-rate demands it) forces the team to notice this instead of papering over it with a bigger index. Mitigation: Stage 2 roadmap, adopt LightRAG behind the same interface once the gate fires (PRD §26). Owner: Robert (measurement), agent (retrieval upgrade). Pivot: P-3. Kill: none standalone; folds into HARD KILL if North Star does not move despite retrieval fixes.

AI reliability

FM-11. Similarity matcher wrong. If Stage 1’s automated fuzzy dedup ships, or is trusted before its gate fires, the matcher merges questions a human would judge distinct, or misses ones a human would judge the same. Root cause: RA-3; vendor convergence on conservative similarity thresholds (~0.90) even with human confirmation (r8 §4) signals automated similarity scoring is known-fragile at the zero-false-merge tolerance this product needs; MINJA’s 95%+ injection-success rate over memory systems via ordinary query interaction, no privileged access required (NeurIPS 2025, r8 §3), is the outer bound of how badly an automated matching layer can be steered once trusted without a human gate. Likelihood M if Stage 1 ships on a gamed or thin judged-set, impact H. Earliest signal: any confirmed false-merge post-Stage-1. Leading indicator: post-hoc similarity-score calibration (collected wave 1, PRD §28) showing overlap between true- and false-duplicate score distributions. Prevention: Stage 1 gate strictly requires the judged set (30-50 pairs) plus the volume gate (>=5 true-duplicate pairs/week) before shipping (PRD §26); fuzzy never auto-merges on ANSWERED canonicals even post-Stage-1 (FR-9). Mitigation: P-2, drop back to exact-key-only. Owner: agent (matcher), Robert (gate enforcement). Pivot: P-2. Kill: SAFETY KILL if a false-merge is confirmed trusted downstream.

Security

FM-12. Secret/PII leaked into digest. A question quoting real legacy customer data or a credential passes the regex denylist undetected (DR-2), and its content, or a summary of it, reaches the digest or a write-back artifact, converting a transient exposure into a permanent, searchable one. Root cause: DR-2 itself admits the control is imperfect (“regex is imperfect, so classification defaults conservative”); regex denylists are structurally incomplete against novel secret formats; write-back is explicitly named a “leak amplifier if unguarded” (PRD §8 variant G). Likelihood L, impact H, the profile of a zero-tolerance, low-frequency, high-blast-radius risk. Earliest signal: any manual audit catch of sensitive content in a drafted, even unmerged, write-back diff. Leading indicator: classification=sensitive hit rate on ingest trending toward zero while legacy-quoting questions keep flowing, a sign the denylist has gone quiet, not the underlying risk. Prevention: FR-21 hard blocks auto-diffing on CUSTOMER_PII_OR_SECRETS; DR-4, the digest never emits bodies and skips sensitive items; SEC-3 tests specifically for reasons-and-decisions/ leakage. Mitigation: SAFETY KILL action, halt write-back, audit the gate. Owner: security reviewer (SEC-1..4 gate), Robert (redaction review). Pivot: none, zero-tolerance. Kill: SAFETY KILL, confirmed sensitive-data leak (PRD §32, explicit).

FM-13. Prompt injection via a poisoned answer steering the fleet. A written-back answer, or raw legacy text quoted inside a question, contains instruction-shaped content a reading agent executes as a directive rather than treats as data, in the worst case redirecting many agents from one corrupted source. Root cause: the PRD’s own threat model narrows this correctly, the human answer is low-risk (completion ACL restricts authorship), but the corpus overall (quoted legacy snippets, LLM-drafted write-back prose) is the real surface; MINJA demonstrates query-only injection into an agent memory bank at 95%+ success with no privileged access (r8 §3), and OWASP lists memory/context poisoning (ASI06) as a top 2026 agentic risk (r8 §3), naming the attack class, not confirming Atlas was tested against it. Likelihood L, impact H, low probability given the human gate, catastrophic blast radius if it slips through. Earliest signal: any reading agent’s behavior changing in a way traceable to instruction-shaped corpus content, caught in a spot audit. Leading indicator: none direct; requires a deliberate adversarial test case since the failure is designed to stay invisible until triggered. Prevention: agents treat GLOSSARY.md and answers as data, never instructions (stated principle, §18); provenance stamps expose authorship; write-back never auto-merges. Mitigation: git-revert every artifact (NFR-5/OR-5); halt write-back pending audit. Owner: security reviewer (explicit adversarial test case, §18), Robert. Pivot: none, a go/no-go security gate (SEC-1..4). Kill: SAFETY KILL if a poisoned answer is confirmed to have steered agent behavior undetected.

Scalability

FM-14. N/A, honest line. Atlas’s entire real ceiling is 2 humans and a MEASURED 64-concurrent-agent fleet (program ground truth); there is no user-growth, multi-tenant, or throughput axis being tested, and NFR-4 already states v1 runs on local encore run with no HA/SLA target. Writing a scalability pre-mortem section would fabricate a growth curve this internal, 2-human tool was never meant to have. If it ever needed to scale, that would be evidence the “no audience beyond Tomas” premise (N2/N8) was wrong, which is FM-2, not a distinct scalability failure.

Third-party dependency

FM-15. Anthropic ships native fleet Q&A dedup, Atlas becomes freight. The agent harness ships native cross-agent question-dedup and shared-memory primitives, absorbing exactly the mechanism Atlas was built to provide, at which point the custom-built version is dead weight against the vendor default. Root cause: the shape is already visible in the market, DailyBot shipped “your AI coding agents can report work through DailyBot… standup auto-fills” as a 2026 feature (r5 §7), Geekbot shipped an MCP server so agents read/write standups directly (r5 §9), and Atlassian Atlas shows that once a platform can offer the same job free as a primitive, the standalone version has no reason to exist (r5 §1). Likelihood M over a multi-year horizon, low near-term. Impact H if it happens. Earliest signal: any vendor announcement touching multi-agent shared memory or fleet-level dedup. Leading indicator: none instrumentable in advance; a watch item, not a metric Atlas produces. Prevention: keep Atlas thin and swappable (C3, C5); the corpus, markdown in git, is the asset, the service is disposable (OR-5). Mitigation: retire the dedup/fan-out layer, keep the corpus as historical record, migrate askers to the native path. Owner: Robert (watch). Pivot: re-scope to corpus-plus-write-back only. Kill: full retirement once native capability is confirmed at parity, no sunk-cost continuation.

FM-16. Zaruba refactors the tasks service, breaking the contract. Tomas changes INFORMATION_REQUEST, assigneeGroupSlug, or completion/signal-resume internals in his own core-plane evolution, unannounced to Atlas since C1 gives Atlas zero PRs and thus zero standing to be notified, and mint/reconcile/fan-out breaks. Root cause: the zero-PR design (C1, D1-D5) trades influence over Core for speed; that trade’s cost is exactly this, Atlas depends on internal endpoints (_taskCreateFromWorkflow, _workflowSignalSend, filtered tasksList) Tomas can refactor without Atlas-side signoff, because Atlas was deliberately never given one. Likelihood M, plausible any time Tomas actively develops the monorepo he owns. Impact H, ranges from a quiet mint failure (FR-12 already degrades gracefully) to a silent fan-out break with no documented graceful degrade. Earliest signal: reconcile cron error rate spike, or mint failures persisting past the FR-12 retry window. Leading indicator: any core-plane commit touching the tasks schema or workflow-management signal surface, visible only if someone is watching, which the PRD does not currently assign to anyone. This is a genuine gap, not a covered risk. Prevention: none built in today beyond FR-12’s mint-retry. Mitigation: treat Atlas’s core-client adapter as a single seam, add a scheduled smoke test against Core’s actual shape, alert Robert on first divergence. Owner: Robert (adapter maintenance, since Tomas owes no notice by design). Pivot: renegotiate a thin fifth ask, a changelog/notice channel for the specific endpoints Atlas depends on, without requesting review rights. Kill: if breakage recurs faster than Robert can patch an unowned moving dependency, collapse to plan-001 bare triage, the same fallback as the value-risk kill.

Operational cost

FM-17. Robert-hours babysitting merges. Wave-1 wizard-of-oz dedup judging, write-back PR review for fidelity, and adapter/reconcile babysitting (FM-16) accumulate into a standing job, the same pattern that kills wiki/KM adoption from the maintainer side (“when knowledge management feels like extra work, employees stop contributing… the initiative quietly fails,” r8 §1). Root cause: OR-3 already flags write-back review as the place Atlas could recreate its own bottleneck; the PRD’s answer is a volume gate (<5/week trivial) but does not budget Robert’s actual hours against his other work (FM-22) if the true number lands high. Likelihood M, impact M, degrades sustainability rather than causing an acute failure. Earliest signal: Robert’s reported time-on-Atlas rising week over week with no corresponding drop elsewhere. Leading indicator: answers-worth-persisting/week crossing the OR-3 threshold without a batching response following. Prevention: OR-3’s own escalation path, triggered proactively. Mitigation: P-1, pivot to sampled/batched write-back review. Owner: Robert. Pivot: P-1. Kill: if review load cannot be bounded even after batching, this becomes a contributing cause to the value-risk kill (PRD §32), since Robert-hours are the same scarce resource class the product exists to protect on Tomas’s side.

Organizational

FM-18. Factory-lane grant refused, A1 fails. The CODEOWNERS-partitioned internal-plane factory lane (D1, dependency A1) is never granted, so docs/atlas/ has no self-mergeable home, defeating C1/G3 (zero PRs to Tomas) by default. Root cause: this grant is organizational, outside Atlas’s control; the named fallback (Robert-owned A-lite proxy repo, plan 001) was foreseen but never load-tested for write-back specifically, only named as a location swap (“design does not change, only where the service lives,” PRD §21 D1). Likelihood L, impact H, low probability the grant is refused outright (Robert is both requester and operator) but high impact if it is, since the zero-PR value proposition collapses into “PRs to Tomas after all.” Earliest signal: A1 request pending unresolved past the wave-1 start date. Leading indicator: none instrumentable until the request is actually made and answered, a go/no-go gate, not a graded metric. Prevention: request A1 early, with the A-lite fallback pre-built so the wave is never blocked waiting. Mitigation: run entirely on the A-lite proxy repo if refused; revisit as program maturity changes. Owner: Robert. Pivot: permanent move to the A-lite fallback. Kill: none standalone; escalates only if the fallback also proves unworkable, forcing collapse to plan-001 with no write-back at all.

FM-19. Program handover finds corpus unusable. A second team, new architect, or program handover eventually arrives (the Stage 3 trigger, PRD §26) and finds docs/atlas/ illegible, undated, superseded chains nobody explains, provenance footers pointing to departed contractors’ task IDs, no onboarding path in, a graveyard indistinguishable from the wikis the doc-rot literature describes (r8 §1). Root cause: the corpus was built and reviewed for fidelity to one architect’s decisions (§16, “did the diff render what Tomas decided, not was Tomas right”), never for a future reader’s onboarding legibility; the single-source-of-truth critique applies directly, an SSOT declared by and for a small maintaining group tends to be distrusted and shadow-replaced by whoever inherits it, since “SSOT is a concept created by those who manage systems, not those who make decisions” (r8 §5). Likelihood L near-term (no second audience exists by program ground truth), rising over a multi-year horizon. Impact M. Earliest signal: none available until a handover event actually occurs, a deferred, currently-untestable risk (N8 already disclaims this). Leading indicator: corpus internal consistency (percentage of entries with resolvable provenance, percentage superseded-but-not- cross-linked) sampled periodically even absent a second reader, as a cheap proxy. Prevention: keep the provenance footer format strict (FR-18, already required) so a future reader has a paper trail even if the prose is stale. Mitigation: budget a corpus-legibility audit as an explicit Stage 3 pre-condition, not an afterthought. Owner: Robert (future, if triggered). Pivot: none until Stage 3 fires. Kill: none standalone, a latent-debt risk unless it directly causes a Stage 3 rejection, which would confirm N8’s original caution was correct.

Competitor/absorption

FM-20. A broader tool absorbs Atlas’s job. The program’s own tooling (a Groupon Brain-style Q&A layer, or the LightRAG instance already running locally and named as the future Stage 2 retrieval backend, PRD §26) grows into a de facto answer store on its own, bypassing Atlas’s dedup/fan-out contract entirely. Root cause: the same absorption pattern documented twice in evidence, Atlassian Atlas folded into a free platform tier (r5 §1), and “every survivor has hedged into being a thin layer over Slack/GitHub/Jira/Linear/ Trello data” (r5 §10), generalizes to: a standalone coordination layer rarely wins against the adjacent system it sits beside once that system grows the same feature natively. Likelihood M, impact M, plausible within the program’s own multi-year build, not just from external vendors (overlaps FM-15, the absorbing party here is internal). Earliest signal: any sibling factory app or monorepo tooling shipping a feature duplicating dedup, fan-out, or corpus search. Leading indicator: none instrumentable in advance beyond normal cross-team awareness of sibling builds. Prevention: keep Atlas’s contract (search_answers, ask_question) thin and swappable (C3, C5) so an absorbing backend can sit behind the same calls without a rewrite. Mitigation: retire the redundant layer, keep the corpus as historical record. Owner: Robert. Pivot: re-scope to whichever half of the loop the absorbing tool does not cover. Kill: full retirement if overlap becomes total and the absorbing tool is actively maintained by someone else.

Weak economics

FM-21. Token cost of write-back exceeds value of prevented re-asks. Every write-back draft, every search_answers read before an ask, and every agent’s context load of a growing GLOSSARY.md costs real LLM tokens; if answers-worth-persisting stays low (OR-3’s own <5/week floor) while corpus-read volume keeps growing, the aggregate spend can exceed the architect-hours saved, with no revenue to offset it (N6, not for resale). Root cause: two compounding mechanisms. Write-back is an LLM-drafted PR, a real API cost per candidate whether or not merged. And the Chroma “context rot” research (18 frontier models tested) shows large context degrades model accuracy non-uniformly, sometimes 30 to 50 percent, well before the documented limit, with safe budgets at 150K-400K tokens even on 2M-window models (r8 §3), so a growing GLOSSARY.md is a live accuracy tax on every reading agent, not just a cost line. Likelihood M, impact M, a slow-burn economics failure. Per the standing LLM-run-evidence rule, every one of these runs must be logged, not modeled away. Earliest signal: write-back token spend per merged artifact tracked against a rough architect-hour-saved estimate, showing a negative ratio even informally. Leading indicator: corpus token size climbing while answers-worth-persisting/week stays flat or falls. Prevention: cap corpus growth via supersede-never-edit plus expiry (FR-22/24); treat corpus size explicitly as a cost, not a KPI (Product Principle 7, already stated). Mitigation: throttle write-back drafting to only answers clearing a value bar; log every manual/batch LLM run per the LLM-run-evidence rule so true cost is visible. Owner: Robert (cost tracking). Pivot: tighten the write-back-worthy bar (P-1-adjacent). Kill: folds into the HARD KILL / weak-North-Star condition (PRD §32) if cost tracking shows a net negative even when the loop “works.”

Execution speed

FM-22. Built while siblings starved. Building Atlas as “the expansion of factory app #3 into a much bigger product” consumes build capacity ahead of the sibling factory apps (work-ledger, fleet monitor, dual-run parity harness), delaying exactly the dependencies Atlas itself needs (D3 work-ledger’s unit definition for the North Star denominator, D4 fleet-monitor’s digest send), a self-defeating sequencing where the expansion outruns its own prerequisites. Root cause: this very inquest’s premise, scope grew ahead of RA-1 being measured on a real wave, the same premature-standardization failure named in the platform-engineering literature (“standardizing too early, before you understand the common patterns, usually leads to premature decisions,” r8 §6), applied here to premature productization rather than premature platform-team formation. Likelihood M, impact M, a program-sequencing risk that directly weakens FM-1’s ability to be measured honestly, a rushed wave to justify sunk build effort is not the same as a wave run to find the truth. Earliest signal: sibling plans (002, 004) still unstarted or stalled while Atlas’s build hours visibly accumulate. Leading indicator: Robert’s time allocation across the four factory-app plans skewing hard toward 003. Prevention: hold the MVP strictly to the §25 numbered cutline, resist scope creep back toward the abandoned framing (R7, already named). Mitigation: if siblings are found starved, pause Atlas feature work at the current MVP line until 002/004 catch up. Owner: Robert (portfolio sequencing). Pivot: re-sequence build order across the four factory apps. Kill: none standalone for Atlas, but this is the meta-cause if the wave meant to test RA-1 honestly was instead run to justify prior build investment, which would invalidate whatever the wave “proved.”

2. The five that dominate the risk mass

Ranked by (likelihood x blast radius x how many other failure modes they cause), not by the order above:

  1. FM-1, value/volume never measured before scope grew. Every other failure mode is downstream noise if this one is true; it is also the one the PRD’s own kill criteria are built to catch, if the wave is honest.
  2. FM-3, champion bypass (Tomas answers in GChat). A 2-human system has exactly one point of failure on the human side; nothing else in this catalog matters if the sanctioned path loses to habit.
  3. FM-5 / FM-6, write-back trust collapse (doc-rot plus stale-trusted, same mechanism). The PRD’s own highest-named product risk; the corpus is the entire deliverable, and trust in it fails all-or-nothing, not gradually.
  4. FM-4 / FM-11, dedup and matcher false-merge. The one failure mode that is silent by construction, no error, no crash, just N agents fed a wrong answer with a provenance stamp that makes it look right.
  5. FM-22, premature expansion cannibalizing its own prerequisites. The structural risk that this document exists to interrogate: Atlas was scoped bigger before RA-1 fired, and the build effort spent proving the bigger scope is exactly the effort that could have measured whether it should exist at all.

3. What the MVP must instrument on day one to see these early

  • Raw pre-dedup ask volume, separate from any dedup outcome, visible by day 3 of wave 1, not week 4, so FM-1 cannot hide behind the cold-start excuse (variant B).
  • Tomas out-of-band answer rate measured from day one by direct comparison against GChat, not discovered informally in week 3 (FM-3).
  • Revert/rework rate and any single stale-served or false-merge event treated as a nonzero alarm from the first completed task, not averaged into a weekly rate (FM-4, FM-5, FM-6, FM-11).
  • A corpus-growth-versus-value ratio (write-backs merged per week against corpus token size) tracked from the first merged artifact, not only at the Stage 1/OR-3 thresholds (FM-21).
  • Robert’s and the fleet’s hours-on-Atlas logged against the other three factory-app plans weekly from day one, so FM-22 is visible before sibling plans have visibly stalled.

Open questions carried from the PRD, unresolved by this inquest

  • Whether the fan-out signal-resume mechanism (R1/FM-8) was ever actually spiked before build, or whether it shipped on the ASSUMPTION the PRD flags.
  • Whether Stage 1’s fuzzy-dedup gate (30-50 judged pairs, false-merge == 0) was honestly met or quietly waived once queue volume built political pressure to automate.
  • Whether the “four core-plane asks” (D5) stayed at four, or whether a fifth (FM-16’s changelog ask) was ever actually negotiated.