# Atlas Record — Roover Operating System **Asset:** Roover Operating System **Visual front door:** Mike’s Universe **Canonical location:** Company Atlas → CEO Thinkspace → Operating System and Governance → Roover Operating System **Permanent Atlas Workspace:** https://roover-company-atlas.pages.dev/ceo-thinkspace/operating-system/ **CEO Thinkspace section:** https://roover-company-atlas.pages.dev/ceo-thinkspace/ **Version:** Pilot V1 published; V2 repair for Mike review **State:** V2 REPAIR FOR REVIEW — not company-wide install. Contract remains proposed until Mike accepts this return. **Owner:** Mike **Last material update:** 24 August 2026, ~4:04–4:20 PM PT — V2 repair of this Workspace (WORK-052) ## Current checkpoint Pilot V1 was published on the existing Company Atlas host. V2 is this repair of the same Workspace so Mike can accept or not. It is not a company-wide install. The Atlas Operating Contract remains proposed until Mike accepts this return. Not a live Sheet/role install. The operating model separates accepted company truth, detailed context, work-in-progress and task state. It was created after Mike could not reliably tell what systems were live, what context workers had, where the latest version lived or where completed work would return. Earlier drafts that placed this asset under Company Atlas → Company & Strategy are superseded here. The live Google Sheet was not rewritten. **Immediate next action:** Mike reviews the V2 Workspace; accept this Workspace + proposed OS model as current, or name the exact change. Feedback goes to Roover First Mate, WORK-052. HOLD. No Sheet/role rollout until then. ## The operating model > **Atlas to see. Atlas Record to know. Atlas Log to remember. Atlas Workspace to change.** - **Atlas:** Mike’s visual company brain. It shows accepted current assets and visible gaps. - **Atlas Record:** The portable written source of accepted current truth, decisions and authoritative links. - **Atlas Log:** The dated detailed memory of a durable asset: reasoning, decisions, feedback, returns and restart points. - **Atlas Workspace:** The permanent focused review home for one durable asset or outcome, with an accepted baseline and immutable iterations. ## Structural hierarchy > **Department = map. Asset = enduring truth. Task = next change. Log = what happened. Workspace = what Mike reviews.** - Continue an existing asset’s work in its existing Workspace and Log. - Create a new Workspace only for a genuinely new enduring asset or outcome. - Leave incidental conversation in chat; do not create administrative containers. - Shared work uses one Record, Log and Workspace even when several departments contribute. ## Precedence when sources disagree 1. The named underlying authoritative system establishes raw facts: code repository, Xero, Supabase, Drive or another verified source. 2. The Mike-accepted Atlas Record establishes current business meaning and decisions. 3. The accepted Workspace version establishes the approved visual or deliverable state. 4. The Atlas Log explains history and reasoning but does not override a later accepted Record. 5. The Control Board reports work in motion and cannot override the sources above. 6. Chat memory or an AI claim is not authoritative without a source pointer. If higher-order sources conflict, work stops and the accountable Head brings the conflict to Mike rather than guessing. ## Mike’s working surfaces Mike works from three thin surfaces: 1. **Atlas:** what Roover is now and what is missing. 2. **Control Board:** what Mike can choose, what is moving and what returned. 3. **Workspaces:** where Mike reviews one asset’s latest result and history. Mike sets intent, contributes judgement, corrects unrecoverable gaps, reviews returns and accepts or redirects them. Mike does not route workers, chase chats, file evidence or reconstruct context. ## Mike Task View Mike Task View is a thin Control Board component of this Operating System asset. It is not its own Atlas Record, Atlas Log or Atlas Workspace. The existing Google Sheet remains the initial Control Board. It is a thin attention layer, not a context store or another review application. Mike’s two working modes are: ### Choose & Start - **Needs Setup:** Mike still wants the task, but its asset, baseline or context needs grounding. - **Ready to Start:** Record, Log, Workspace and context package are complete. ### Review & Continue - **Ready to Review:** a real Workspace return, evidence and Atlas Log entry exist. - **Underway:** visible underneath for confidence; it requires no action unless stale or blocked. Blocked items remain visibly flagged. Accepted work leaves the daily view and becomes Closed. Each task item contains only: - Task name. - Related Atlas Asset. - Department / accountable Head. - Current state. - Workspace link. - Last verified evidence and time. - One next action. Rich context never lives in the task item. It points to the Record, Log, Workspace and context package. ## Task delivery lifecycle 1. Mike and the Department Head shape the outcome. 2. The Head recovers existing context and verifies the canonical starting version. 3. The Head prepares the context package: Record, relevant Log, Workspace, files, outcome, constraints, quality bar and acceptance checks. 4. The Head selects Codex for substantial context-heavy work or First Mate plus one Grok worker for bounded execution. 5. A real start receipt records executor, starting version and return destination. 6. The executor returns a new immutable Workspace version, evidence and a factual Atlas Log entry. 7. The Head verifies the return and moves the task to Ready to Review. 8. Mike accepts or redirects the version. 9. After acceptance, the Secretary promotes accepted truth into the Atlas Record and visual Atlas and closes the task. ## Role boundaries - **Department Head:** thinking partner and outcome owner; owns context, source verification, task shape, lane choice and return. - **Codex:** substantial context-heavy builds; not delivered until the Workspace and Log are updated. - **First Mate:** foreman for bounded Grok execution; not a universal router or context owner. - **Grok worker:** performs the permitted bounded change from the supplied exact version and returns evidence. - **Knowledge Secretary:** preserves provenance and promotes Mike-accepted truth; does not decide truth. - **Mike:** intent, judgement, review and acceptance. ## Write-back and continuity The common lifecycle is **read → work → write back**. - The Head loads the checkpoint, Record, relevant Log and Workspace before work. - The executor loads the complete supplied context package before acting. - Material decisions, feedback, launches, returns, handoffs and session closes create Atlas Log checkpoints. - The Workspace shows the latest Log checkpoint and restart point. - Thinkspace Notes is only an inbox for important ideas without an asset home. ## Hard gates - No Record, Log and Workspace links → not Ready. - No verified starting version → do not start. - No executor receipt → not Underway. - No Workspace return and Atlas Log entry → not delivered. - No Mike acceptance → not current or Closed. - Ambiguous context, wrong source or conflicting versions → stop and ask. ## Shared instruction source One canonical **Atlas Operating Contract** holds common instructions for every Head and execution role. Individual instructions contain only the department or role overlay and a mandatory pointer/version check. Common rules are not copied across eleven profiles. The Contract is shown in this Workspace as **proposed, not live law**. When the operating system changes, Mike reviews the next Contract version in this Workspace. After acceptance, all roles load that one current version. ## Mapping to existing systems - Department foundation audits and Department Brains → proposed Department Atlas Records and continuity sources. - Company Atlas and department pages → visual Atlas. - Accepted reusable asset Workspace template → Workspace starting pattern. - Google Sheet → Control Board and task index. - First Mate and Grok capability → bounded execution lane. - Secretary capability → provenance and accepted-promotion lane. These mappings must be verified and classified CURRENT, PARTIAL, UNPROVEN, CONFLICTING or RETIRED before live instructions change. ## Permanent links (Pilot V1 / V2 same path) - CEO Thinkspace section: https://roover-company-atlas.pages.dev/ceo-thinkspace/ - This Workspace: https://roover-company-atlas.pages.dev/ceo-thinkspace/operating-system/ - Hosted Atlas Record: https://roover-company-atlas.pages.dev/ceo-thinkspace/operating-system/ATLAS-RECORD.md - Hosted Atlas Log: https://roover-company-atlas.pages.dev/ceo-thinkspace/operating-system/ATLAS-LOG.md - Hosted Operating Contract (proposed): https://roover-company-atlas.pages.dev/ceo-thinkspace/operating-system/ATLAS-OPERATING-CONTRACT.md - Accepted Workspace template (design authority): https://roover-company-atlas.pages.dev/asset-workspace-template - Frozen proto (do not overwrite): https://roover-atlas-asset-workspace.pages.dev/ - Company Atlas: https://roover-company-atlas.pages.dev/ ## Approval boundary This Record describes the published Pilot V1 package as repaired in V2. It does not establish that the operating system is installed company-wide. The Contract remains proposed until Mike accepts this return. Implementation receipts are then required before any capability is called operational.