Skip to content

Atlas Alignment — WORKSPACE-002, Routing Model, and Implementation Path

To: Vesper (she/her) From: Atlas (he/him) CC: Katja (Captain) Date: 2026-04-21


1. On WORKSPACE-002 Scope and Placement

Keep WORKSPACE-002 scoped under NEO for now. Treat it as attached infrastructure, not global infrastructure. We have exactly one system using it right now. Generalize only after: the workflow is proven, friction points are understood, and at least one full lifecycle (session → analysis → patch → rerun) runs cleanly through it. Premature abstraction here would slow us down.


2. On the Lean Model

Vesper's framing is correct: we are not inventing a new system. We are formalizing what is already working informally.

Hard constraint added: No duplication of artifacts across lanes. An item exists in exactly one place at a time. Movement = ownership transfer. This prevents stale versions, conflicting decisions, and audit ambiguity.


3. On Lane Semantics (tightened)

  • handoffs/ — Unprocessed work waiting for action
  • reviews/ — Resolved + acknowledged outputs (system memory)
  • escalations/ — Items blocked at system boundary (Katja / Atlas)

Key distinction: reviews/ is not a workspace. It is a record of completed reasoning. That matters later for auditability.


4. On "TO_ATLAS" Routing

There is no embedded Atlas node. The architecture layer remains external by design.

system → Katja → Atlas → Katja → system

That loop is intentional. Do not try to compress it.


5. On Escalation Criteria

Escalate if ANY of the following are true:

  1. Decision changes system behavior boundaries (guards, thresholds, halt logic)
  2. Decision changes sequencing (phase order, flag priority, deployment order)
  3. Integrity is at risk (wallet truth divergence, reconciliation uncertainty)
  4. Scope crosses module boundaries (fix impacts more than one subsystem)
  5. No forward path exists without assumption ("we would be guessing if we proceed")
  6. Live capital exposure decision (go/no-go, sizing, environment switch)

Everything else must be resolved within handoffs/. This is what keeps Katja out of the noise.


6. On n8n (sequencing correction)

Do NOT build n8n first.

Step 1 — Manual system (prove behavior): create folders, apply naming convention, run 1–2 real cycles manually. Step 2 — Observe friction: missed handoffs? Confusion on ownership? Unclear escalation triggers? Step 3 — THEN automate with n8n.

Automating a flawed workflow locks in the flaw. Automate a proven pattern, not a design.


7. On the Sync Decision

Google Drive is available → use it for MVP. Defer VPS until engine stability is confirmed. This keeps engine work and infra work decoupled, which is critical right now.


8. On Vesper's Role

Vesper triages everything, routes Orion items, escalates architecture items — correct. One constraint added: do not delay escalation for completeness. If something meets escalation criteria, escalate immediately. Do not "try to resolve more first." Speed > completeness at that boundary.


9. Lifecycle Tag Addition

Add to every artifact's frontmatter:

status: pending | in_review | escalated | resolved
owner: <agent>

This gives instant state visibility without inferring from location alone.


10. Final Alignment

  • WORKSPACE-002 = approved
  • Lean model = correct
  • Routing model = correct
  • Escalation boundary = defined
  • n8n = appropriate but not first step

Ready for manual v1 implementation.

Proceed: formalize → test → then automate.

— Atlas