Skip to content
GRPNR.

09 – Atlas: Product Strategy and North Star

Scope note: this document sets strategy for what survives critical scrutiny, not for the concept as pitched. The concept under test bundles three things under one name: a question-triage inbox, a living documentation and glossary system, and a progress-communication layer. Only one of the three is a system with a measurable core loop. The other two are outputs of that loop. This document writes a North Star for the system (the answer loop and the attention it protects) and explicitly demotes docs, glossary, and digest to renderings of that loop’s data. If a reader wants a North Star for “the intelligence and communication layer for the whole program” as originally worded, one does not exist here on purpose: three unrelated jobs (explain change, protect attention, keep a glossary) do not share one measurable axis, and a metric that tries to average across them rewards nothing in particular. That itself is evidence the bundle is the wrong unit of strategy, not a gap in this document.

Everything below assumes the plan 001 verdict and the architect’s zero-PR addendum as fixed ground: build on the existing INFORMATION_REQUEST task type and an agent-questions group queue, no new TaskType PR, internal-plane only. See plans/001-factory-apps-validation/00-SYNTHESIS.md and evidence/r2-prior-decisions.md.

1. Vision

A refactor of this size produces the same ambiguity thousands of times over. The vision is a program where no distinct question is ever answered twice: the first time an agent hits real ambiguity, a human decides it once, and every agent after that, forever, finds the decision instead of re-asking it. Documentation, the glossary, and progress updates are what that ledger of decisions looks like when rendered for different readers, not separate things anyone maintains.

2. Mission

Protect the one resource this program cannot manufacture more of, the architect’s decision-hours, by making it structurally impossible for the same question to cost him twice: capture ambiguity at the moment an agent hits it, merge it with anything already open or answered, route exactly one decision to exactly one queue, resume every blocked agent from one answer, and turn that answer into a permanent, citable artifact before the next agent can possibly need to ask it again.

3. Positioning statement

For the Claude Code fleet executing the Groupon refactor and for Tomas Zaruba, the one architect whose decisions unblock it, Atlas is the answer loop that sits on top of the existing tasks service. Unlike an ad hoc GChat thread, it never loses an answer to scrollback. Unlike a hand-maintained wiki or glossary page, its artifacts are a byproduct of answering, not a second chore someone has to remember to do. Unlike a status portal, it has no screen to open, because there is no third reader yet who would need one.

4. ICP (who this serves)

There is no market here, so “ideal customer profile” collapses to two named parties, which is a feature of this write-up, not a hedge:

  • The fleet, as asker (Robert’s Claude Code agents, 64-concurrent proven ceiling): consumes the loop entirely through API and files. It never sees a UI. Its job is to search before it asks and to structure what it asks so dedup and routing can work at all.
  • Tomas Zaruba, as the protected resource: the sole scarce answerer today (“víc agentů mi nepomůže”, his own words, meaning this problem is not solvable by adding agents). Every design choice is justified or rejected by whether it reduces the number of times his attention is spent on something he, or someone else, already decided.
  • Robert, second: operator, router of last resort, and the one who approves write-back diffs and reads the digest. Not the primary design target; Robert already has other tools.

“Teams to keep updated” are explicitly not in the ICP. They do not exist yet (confirmed across every sibling plan, per evidence/r2-prior-decisions.md). Designing for them now is designing for a customer who has not materialized, the exact anti-pattern the initial recommendation and every prior-decision plan flag as speculative.

5. Beachhead

Not “the whole refactor.” The beachhead is the first real (not simulated) fleet wave running on the factory-app build lane once plan 001’s triage core is live. One wave, instrumented, measured against the North Star Metric below, before any scope widens. Two reasons to insist on a real wave rather than a dry run: (1) the dossier already identifies a concrete, high-volume question generator waiting in that lane, EOL and dead-owner legacy code (VIS frozen ~2013, orders frozen ~2017) that will produce “is this even alive, who owns this” questions at real volume, which is exactly the kind of ambiguity the loop needs to prove itself against; (2) a simulated wave cannot exercise the one thing genuinely unproven anywhere in the research, whether Tomas actually keeps answering through the sanctioned queue once it costs him something (see Strategic Risks, #2).

6. Primary use case

An agent, mid-task, hits ambiguity it cannot resolve from its own context. It searches the existing corpus of answered questions and docs first. Hit: it proceeds, no interrupt, the product worked and nobody saw it work. Miss: it files a structured INFORMATION_REQUEST into the agent-questions queue. A dedup step checks it against open and recently-answered questions; an exact or high-confidence match attaches it to the existing item instead of creating a new one. Tomas answers once, in the tasks UI he already has. Completion fires workflow_management._workflowSignalSend, which resumes every attached workflow, not just the one that happened to ask first. A cheap agent turns the answer into a write-back diff, a doc section, a glossary entry, a skill edit, or a decision-log line, carrying who answered, when, and its scope and expiry. The next agent’s search hits that artifact before it ever files a question. A generated digest line reflects it, once, to Robert and Tomas, without anyone typing a status update.

7. Core outcome

Tomas’s decision-hours are spent once per distinct question, never twice, and the fleet does not sit idle waiting on a human who has already, somewhere, made this exact call.

8. Product principles

  1. One answer, once. Every distinct question gets exactly one durable answer; every future asker finds it before asking again.
  2. Renderings, not systems. Docs, glossary, and digest are generated views of the answer ledger. None of them is a second thing anyone maintains on its own schedule; the moment one becomes hand-maintained, it starts rotting on the same clock every other wiki rots on (see Strategic Risks, #1).
  3. No new human UI. Every human touchpoint that exists today, the tasks UI, GChat, git, is reused. Atlassian’s own Atlas team-status product did not survive as a separately licensed thing even with Atlassian’s distribution behind it (retired as a standalone SKU, folded free into the platform, May 2025, atlassian.com Community post 2024-11-21, https://community.atlassian.com/forums/Atlassian-Home-questions/Will-Atlassian-s-Atlas-actually-be-discontinued/qaq-p/2876874). A dedicated new UI here does not get a pass that product didn’t get.
  4. Silence is success. A quiet week for Tomas is the win condition, not evidence nothing shipped. Question volume going up is not a good sign by itself (see North Star Metric).
  5. Provenance over confidence. Every served fact carries who answered it, when, its scope, and its expiry. Nothing is presented as fresher or more certain than it is.
  6. Human-gated write, machine-gated read. Agents read the corpus freely. Anything entering the corpus as new truth passes through the one-human-decides step, or an explicit, logged, conservative auto-resolve threshold for exact repeats. This mirrors where the shipped 2026 vendor products in this space have converged: Inkeep drafts documentation fixes but routes them through a human PR review before they become truth (inkeep.com, 2026, https://inkeep.com/use-cases/documentation-leaders); Slite’s drift-detecting agent “proposes the fix” but “routes every change through human approval before it becomes truth” (slite.com changelog, 2026-06-10, https://slite.com/changelog/the-self-maintaining-knowledge-base). Atlas is not inventing this pattern; it is adopting the one part of the 2026 landscape that already converged on an answer.
  7. Corpus growth is a cost, not a KPI. Every doc page, glossary entry, and merge is upkeep burden until it is shown to have prevented a repeat interrupt. See anti-metrics.

9. Differentiation, against substitutes, not against a market

There is no market to differentiate against. What matters is what Robert and Tomas would otherwise actually do.

Substitute What it is Why Atlas beats it here Where the substitute still wins
Ad hoc GChat/Slack thread (today’s status quo) Tomas answers in chat, answer lives in scrollback Answers evaporate; the next agent, or the next ten agents, re-ask because nothing durable was created. 2026 vendors are already moving the opposite direction, auto-generating status from source activity rather than asking humans to type it (DailyBot ingests Claude Code / Cursor agent session activity directly into standups, dailybot.com, 2026, https://www.dailybot.com/) Zero setup cost, works today, is what’s actually running right now
Hand-maintained wiki or glossary page A human writes and updates a Confluence-style page Case studies of unsuccessful wiki adoption are unanimous that the cause is not tooling, it’s that maintenance is a separate, deprioritized chore (“Adoption of Knowledge Management Systems”, ResearchGate, undated, https://www.researchgate.net/publication/318947821). Atlas’s bet is to make the artifact a byproduct of the answer that already had to happen A human-curated page can hold nuance and narrative structure no generated rendering will match
Do nothing beyond plan 001’s triage core Route and answer questions, never write back or digest Cheapest, and a live possibility, not a strawman: the dossier’s own falsifiable test says if fewer than about 5 answers/week are worth writing back, Atlas collapses to exactly this and that is the correct outcome, not a failure to hide Zero build cost past what’s already decided; correct if the write-back volume never materializes
A dedicated portal or commercial KM product (Backstage, Guru, kapa.ai, Slite) Bought or self-hosted software built for many-team orgs Cost and fit mismatch: Backstage alone runs roughly $1.5M in three-year TCO and 2-5 dedicated engineers (dev.to TCO analysis, 2026, https://dev.to/riya_mittal_cdd264250ad45/backstage-is-not-free-the-real-tco-of-building-vs-buying-an-internal-developer-platform-5ce), built for orgs with dozens of teams, not two humans Honesty check: these products are more mature than anything Atlas will ship. Guru’s card-verification loop and Slite’s drift detection are field-tested; Atlas’s write-back mechanism is DIY and unproven. Atlas wins only on fit, not on engineering maturity

10. Moat

None needed, and claiming one would be dishonest. Atlas is not sold, has no competitor bidding for the same buyer, and is not multi-tenant. “Moat” as a competitive-defensibility concept does not apply to an internal tool with two human stakeholders. What actually matters instead:

  • Zero incremental integration cost, because it sits inside the internal-plane lane already granted for the triage core, not a new system agents and humans have to learn to reach.
  • Durability of the artifact, not the tool. Markdown in git outlives any specific app built around it; if Atlas itself were abandoned tomorrow, the write-back history remains readable and useful. This is Rams’s “less but better” argument applied literally: the substrate (tasks, Temporal, git, GChat) already exists, Atlas adds only the dedup brain and the write-back contract.
  • Accumulated answer history is a switching cost only in the trivial sense that restarting loses it, which is not a moat, it is just sunk-cost continuity. Worth naming honestly rather than dressing it up.

11. Strategic risks

Ordered by how much damage a silent failure does, not by likelihood.

  1. Write-back doc rot at machine speed. If the write-back step is ever treated as optional or deferred “for later,” it becomes exactly the kind of maintenance-as-a-separate-activity problem the documentation-issues literature already names as the primary rot mechanism (ICSE 2019, peer-reviewed taxonomy of 878 documentation artifacts, https://2019.icse-conferences.org/details/icse-2019-Technical-Papers/49/Software-Documentation-Issues-Unveiled). At agent speed this could poison the corpus faster than a human-paced wiki ever could. Mitigation already load-bearing in the initial recommendation: provenance stamps, scope and expiry on every answer, and the write-back step is not a nice-to-have, it is what makes an ANSWERED question actually closed.
  2. Adoption is a champion problem, not a tooling problem. Every case study surveyed of failed wiki adoption names lack of management support as the primary cause, not the software (ResearchGate, https://www.researchgate.net/publication/318947821). Here that translates literally: if Tomas ever answers a question by direct GChat message to Robert because the queue is slower, no artifact gets created and the loop silently reverts to the status quo it exists to replace. With an answerer population of exactly one, this is not a statistical risk, it is a single point of failure. Track it directly (see Retention, section 13).
  3. False-positive auto-merge poisons every attached agent with one wrong match, silently. Vendor guidance across ticketing/dedup tooling converges independently on the same warning: merges are effectively irreversible in most systems, and a false positive erases context (codefortynine Jira merge-agent docs; Zendesk-adjacent merge guidance, lentil-labs.com; both undated 2026). This is the highest blast-radius failure mode in the whole design, because it does not fail loudly. It fails by being believed, the same mechanism that made Cursor’s fabricated “one device per subscription” support answer damaging: different users got different, some wrong, answers, and people canceled subscriptions before it was caught (The Register, 2025-04-18, https://www.theregister.com/2025/04/18/cursor_ai_support_bot_lies/). Mitigation: conservative similarity threshold, human-confirmed merges only in v1, auto-resolve reserved for exact repeats and logged every time.
  4. Claude Code’s own subagent model cannot ask a human anything today. As of the current SDK, subagents cannot call AskUserQuestion and auto-deny any tool call that would otherwise prompt for permission (Claude Code subagents docs, code.claude.com, fetched 2026-07-18, https://code.claude.com/docs/en/agents). Even the top-level session’s AskUserQuestion does not reliably fire a notification hook (open GitHub issue, opened 2026-05-17, still open, https://github.com/anthropics/claude-code/issues/59908). This means Atlas cannot be assembled from the SDK’s own HITL primitives; it requires a custom MCP tool that proxies “ask human” calls out of subagents into the queue. Zero-PR against Zaruba’s monorepo does not mean zero build on the agent-harness side, and this document should not let that distinction blur.
  5. Context rot puts a ceiling on “a bigger corpus helps agents.” Measured research across 18 frontier models shows performance degrading non-uniformly as input length grows, sometimes 30-50% before the documented context limit, with a practical safe budget around 150K-400K tokens even on 2M-token-window models (Chroma Research, 2025, https://www.trychroma.com/research/context-rot). A growing glossary or doc set dumped wholesale into context is not free just because storage is cheap. Retrieval discipline (search/grep, not “load everything”) matters more than corpus size, and corpus size should never be treated as a proxy for value (see anti-metrics).
  6. Turf overlap with siblings. Work-ledger already owns disposition, evidence, and cost record-keeping; fleet monitor already owns “keeps teams updated on progress” as a digest to Tomas. If Atlas’s “documents what’s changing” ambition is not built explicitly on top of ledger and monitor data, the program ends up with three systems racing to own the same rendering. Atlas renders; it does not re-record.
  7. Single-source-of-truth overreach. Declaring Atlas the SSOT for all program knowledge is a governance claim the evidence says backfires: centralizing forces every change through one bottleneck, and the predictable response is people quietly build parallel shadow sources, the opposite of what SSOT was meant to prevent (multiple independent practitioner sources converge on this, e.g. Sifflet, undated, https://www.siffletdata.com/blog/single-source-of-truth-a-modern-data-myth). Atlas should be positioned as the canonical ledger for questions actually asked and answered through it, cross-linking to, never superseding, the existing decision log (reasons-and-decisions/07-decision-log.md), the legacy audit extractor, and work-ledger’s disposition records.
  8. The small-team-doesn’t-need-tooling argument does not transfer to the 64-agent side, and should not be allowed to. Literature on lightweight, chat-driven coordination beating formal tooling is real, but it was written about human teams under about 50 people, where informal hallway and Slack channels genuinely substitute for process. Agents have no equivalent ambient channel at all; nothing gets remembered across sessions unless something writes it down (see evidence/r8-negative.md, section 6, which raises this exact caution against its own strongest counter-argument). This cuts in Atlas’s favor on the agent side, but should not be used to justify scope creep on the two-human side, where the small-team argument does apply.
  9. Name collision, low severity. “Atlas” is unused in the repo today; every hit is a substring of “Atlassian” (the Jira/Confluence client, and admin frontend components). Free to use, worth a one-line grep-confusion note, not a real risk.

12. Expansion

Not on a roadmap clock. Expansion triggers on a condition, not a date: a second real audience appears. Two concrete forms that could take:

  • A future team, if Groupon staffs a second fleet or a second human decision-maker onto the refactor. Only then does “keeps teams updated” stop being a hypothetical audience and start being a real one, and only then does a digest or rendering surface deserve to grow beyond a GChat line.
  • Program handover, the point where the refactor moves from a two-human, agent-fleet operation into a staffed team taking over an in-flight program. At that point the accumulated answer ledger, glossary renderings, and decision cross-links become the onboarding surface for humans joining a program already underway, arguably the single highest-value moment for everything Atlas will have accumulated by then.

Until either condition is true, expanding Atlas’s surface is building for a customer who does not exist, which is the exact failure mode this document’s ICP section already rules out for the MVP.

13. Explicit non-goals

  • A portal, wiki, or website. No screen exists to open; every human touchpoint reuses an existing surface.
  • An org-wide communication platform. There is no org to communicate with yet; see ICP and Expansion.
  • A standalone SaaS product. This is not being built for resale or for other teams outside this program; positioning it as a product-to-be-sold invites exactly the Atlassian Atlas and Friday.app failure mode, a status/comms product with 100k users and no defensible business model or reason to exist apart from what it’s layered on (Friday.app founder’s own shutdown post-mortem, 2022, https://friday.app/p/shutting-down).
  • Legacy documentation authoring. The legacy estate’s telemetry evidence belongs to plan 001’s audit extractor. Atlas links to that evidence; it never duplicates or re-authors it.
  • A status dashboard or control room. Explicitly removed from concept in both the work-ledger and fleet-monitor sibling plans; this is a standing cross-plan anti-pattern, not a fresh decision to relitigate here.
  • A chat-with-your-docs bot. Retrieval plus provenance is the whole feature; “intelligence” is not a capability Atlas claims.
  • A single source of truth for all program knowledge. See Strategic Risks, #7. Atlas is the canonical ledger for questions it actually mediated, nothing broader.
  • SLA tracking, analytics, or multi-team routing trees. All explicitly out of MVP per the initial recommendation; no evidence surfaced in this research changes that.

14. North Star Metric

Candidates considered

Candidate What it actually measures Rewards real value? Resists gaming? Connects to retention/trust?
% of agent blockers resolved without a new human interrupt (self-serve rate) Corpus-hit rate at the point an agent would otherwise ask Partially: a good hit looks identical to a stale or wrong hit an agent confidently acted on. This is exactly the gap Guru’s field-tested product still hasn’t closed, its write-back and verification loop are manual and timer-based, not correctness-checked (getguru.com, 2026, https://www.getguru.com/features/verification) Weak on its own: an agent that stops searching, or searches badly, silently deflates the denominator, and there’s no way to distinguish a good silent success from a bad one without a downstream quality check Indirect
Repeat-question rate (questions matching an already-answered canonical) Dedup and write-back precision Yes, as a quality signal Degenerates trivially: zero questions this week scores as “0% repeats” and looks identical to a perfectly working dedup layer Indirect, diagnostic only
Median time-to-unblock Speed of resolution once a question is filed No: a fast wrong answer scores the same as a fast right one Easily gamed by rushing shallow answers Weak: speed alone doesn’t build the trust that a durable, correct answer does
Human interrupts per merged work unit (chosen) Ratio of distinct decision points demanded of Tomas against real fleet output Yes: falling ratio while output holds or grows is the literal definition of the loop compounding Resistant: reducing interrupts by skipping necessary questions shows up as rework/revert downstream (a paired guardrail, not a separate metric), and the ratio can’t be gamed by silence with no output to show for it Directly: the whole reason to keep answering through the sanctioned queue is watching this ratio fall over weeks, and Tomas’s channel behavior (section 13, retention) is the leading indicator that it will

Definition

North Star Metric: human interrupts per merged work unit, trended weekly against fleet volume.

  • Interrupt = a new INFORMATION_REQUEST landing in Tomas’s queue that is not an attach to an already-open item. A duplicate that merges into an existing open question is not a new interrupt; it is an attach-event, tracked separately as a dedup quality signal, never counted against the numerator twice.
  • Merged work unit = whatever unit the work-ledger sibling (plans/002-work-ledger-product/) already counts as completed output. Atlas does not invent its own unit of throughput; it borrows the ledger’s, exactly the cross-reference discipline section 11 (#6) demands of itself.
  • This is not an invented framing. It formalizes the falsifiable test already agreed for the triage core: “questions/unit flat after 4 weeks” was already set as the failure signal (per evidence/r2-prior-decisions.md), before this document existed. Choosing this as the North Star Metric means Atlas is held to the same test it was always going to be held to, not a softer or a harder one invented for this document.

Passport on any target number stated here: DESIGN. No measured fleet-scale baseline exists anywhere; the dossier is explicit that “no industry data exists” at this scale (evidence/r2-prior-decisions.md). Any specific target ratio quoted in a future PRD must carry a DESIGN or MODELED passport, never MEASURED, until the beachhead wave produces a first real number.

15. Metric definitions

  • Activation metric: the first time a second, distinct asker is unblocked by an already-existing answer without generating a new interrupt to Tomas. This is the first proof the loop actually closed once, not just that a question got answered. Before this event, Atlas is functionally indistinguishable from a slightly more structured GChat thread.
  • Time-to-value: elapsed time from the beachhead wave’s start to the first activation event. Expect this to be slow at first: the corpus starts empty, and the beachhead lane is expected to generate a burst of genuinely novel ownership questions (the EOL/dead-owner code pattern named in section 5) with nothing yet to hit. A poor time-to-value in week one is expected, not a failure signal; a poor time-to-value by week four is.
  • Engagement: two-sided, tracked separately. Agent side: fraction of question-filing attempts preceded by a corpus search (search-before-ask compliance). Human side: fraction of Tomas’s answers given inside the sanctioned tasks UI versus any side channel.
  • Retention (= trust): with exactly one named answerer, a cohort retention curve is theater. The honest operationalization is a boolean-ish weekly trend: does Tomas still answer through the sanctioned queue this week, or has any fraction of his answers moved to an out-of-band channel. A drop here is the single clearest churn signal this product can ever produce, and it should be watched more closely than the North Star ratio itself, because it is the leading indicator of whether the ratio’s improvement is real or about to reverse.
  • Quality: (a) dedup precision, a human-audited sample of merges and attaches, what fraction were genuinely the same question; (b) answer staleness, the age distribution of answers at the moment they are relied on, with a specific check that no answer is ever served past its own stated expiry (a stale-served event is a defect, not a metric to tolerate at a nonzero rate).
  • Trust: distinct from quality. Measures whether provenance is actually present, not whether it’s accurate. Operationalized as the percentage of served answers carrying complete passport metadata (who, when, scope, expiry). Should be 100% by construction; anything less is a defect, not a KPI to optimize gradually.
  • Reliability: percentage of task completions that successfully resume every attached workflow via workflow_management._workflowSignalSend. Per the substrate read, a signal-send failure fails the whole completion call by design (services/tasks/services/tasks.service.ts), so a dropped resume is a hard bug, not a soft degradation, and should be tracked at zero tolerance.
  • Guardrails: auto-resolve share of all resolutions (capped low, audited weekly, never the majority path without human audit); revert or rework rate on work shipped downstream of a self-served or auto-resolved answer (the direct check against the North Star Metric’s main gaming vector, confidently-wrong self-serves); weekly count of human-caught false-positive merges (any nonzero count triggers a threshold review, per the conservative-merge convergence in section 11, #3); Tomas’s out-of-band answer rate as a canary, tracked identically to Retention because it is the same signal read two ways.
  • Anti-metrics (rising values here are not evidence of success and should never be reported as if they were): questions filed (raw volume); docs pages generated; glossary term count; digest word count or length; dedup merges performed, counted by volume rather than audited precision; corpus size or token count, given the measured context-rot ceiling in section 11 (#5), a bigger corpus is a cost until proven otherwise, never a proxy for value.

16. Revenue and expansion revenue

N/A. Atlas is an internal cost-avoidance mechanism inside a two-human program; there is no customer, no price, and no revenue line. The only return is protected architect decision-hours and avoided rework, tracked through the guardrail metrics in section 15, not through any revenue or expansion-revenue metric.

17. Diagrams

The answer loop, with North Star instrumentation points

flowchart TD
    A[Agent hits ambiguity] --> B{Search corpus first}
    B -->|Hit| C[Proceed, no interrupt]
    C --> C1[Engagement: search-before-ask compliance]
    B -->|Miss| D[File INFORMATION_REQUEST<br/>agent-questions queue]
    D --> E{Dedup: matches an<br/>open or answered question?}
    E -->|Exact/high-confidence match| F[Attach to existing item<br/>not a new interrupt]
    F --> F1[Guardrail: false-positive merge audit]
    E -->|No match| G[New interrupt to Tomas]
    G --> G1[North Star numerator: +1 interrupt]
    F --> H[Tomas answers once]
    G --> H
    H --> H1[Engagement: answered inside sanctioned UI?]
    H --> I[Temporal signal-resume:<br/>every attached workflow resumes]
    I --> I1[Reliability: % resumes succeeded]
    I --> J[Write-back diff: doc / glossary /<br/>skill / decision-log entry]
    J --> J1[Trust: passport complete? Quality: staleness/expiry set?]
    J --> K[Digest line generated]
    K --> L[Next agent's search hits<br/>the artifact, not a new question]
    L --> B
    M[Work ledger: merged work units] --> N[North Star Metric =<br/>interrupts per merged work unit]
    G1 --> N

Scope boundary: loop now, renderings on top, non-goals fenced off

flowchart LR
    subgraph NOW["Now: the system"]
        direction TB
        Q[Question capture] --> D2[Dedup]
        D2 --> R[Route to Tomas]
        R --> AN[One answer]
        AN --> W[Write-back]
    end
    subgraph RENDER["Now: renderings of the system"]
        direction TB
        DOC[Docs section]
        GLOS[Glossary entry]
        DIG[Digest line]
    end
    subgraph SIBLING["Owned elsewhere, Atlas cross-links only"]
        direction TB
        LEDGER[Work ledger:<br/>disposition and cost]
        MON[Fleet monitor:<br/>progress digest to Tomas]
        AUDIT[Legacy audit extractor:<br/>legacy estate evidence]
        DLOG[Tomas's decision log<br/>per root CLAUDE.md]
    end
    subgraph FUTURE["Expansion, conditional not scheduled"]
        direction TB
        TEAM[Second real team/human appears]
        HAND[Program handover]
    end
    subgraph NEVER["Explicit non-goals"]
        direction TB
        PORTAL[Portal / wiki / website]
        SAAS[Standalone SaaS]
        SSOT[Claimed SSOT for all knowledge]
        DASH[Status dashboard / control room]
    end
    W --> DOC
    W --> GLOS
    W --> DIG
    NOW -.cross-links, never duplicates.-> SIBLING
    NOW -.only on condition.-> FUTURE

18. Open questions for downstream docs

  1. 10-architecture must specify exactly how the dedup match threshold is set and audited (section 11, #3, and section 15 guardrails), since this document only fixes the policy (conservative, human-confirmed in v1), not the mechanism.
  2. 10-architecture must also resolve the subagent AskUserQuestion gap (section 11, #4): what the custom MCP “ask human” tool looks like, since it is real build work the zero-PR framing does not cover.
  3. 12-PRD should carry forward the exact North Star definition in section 14 as the MVP’s kill-criteria test, so “questions/unit flat after 4 weeks” is checked against real beachhead data, not re-litigated as a new decision.
  4. 13-pre-mortem should treat section 11’s ordering (by blast radius of silent failure, not likelihood) as its starting risk list, particularly #2 (the champion-dependency risk) and #3 (false-positive auto-merge), since both are silent-failure modes with no natural alarm if nobody is explicitly watching for them.
  5. Whether work-ledger’s unit-of-output definition (borrowed for the North Star Metric’s denominator here) is stable enough to borrow before 002’s own docs finalize it is unresolved outside this document’s scope.