# Work OS V2 - Final Recommendation

Date: August 9, 2026
Recommendation status: ready for Nathan's design judgment

## Recommendation

Proceed with the selected Work OS V2 direction:

**Switchboard structure with Causal Loom focus behavior.**

Do not continue exploring alternate product shells unless Nathan rejects the
room itself. The major structural question is answered: Work OS should be one
dense causal field, not an AI chat product, dashboard suite, or collection of
workflow pages.

## What to build

Use the clickable prototype as the interaction target for the existing
`/operator` product:

`consequence -> proof -> your word -> machine work -> outcome -> receipt`

Preserve:

- stable one-room coordinates;
- dense causal rows;
- complete selected-line expansion;
- one shared drawer;
- append-only tape;
- actionable Dig history with honest coverage;
- people court state and person changesets;
- local hero verbs;
- editable delegation proposals;
- factual effort maps and named rejection;
- fact-versus-maybe treatment;
- verbatim words and separate machine interpretation;
- draft-only mail custody;
- requested-versus-actual receipts;
- weekly close and append-only reopen;
- capability research with expiring one-shot authority;
- mobile machine strip;
- five-second append-only recovery for reversible local actions;
- keyboard and focus return.

## What not to build

Do not add:

- an assistant chat home;
- permanent product navigation;
- separate activity, source, artifact, and result pages;
- a second orchestration model;
- opaque priority scores;
- progress percentages without real units;
- a send-email control;
- settings that make Nathan maintain learned behavior;
- generic cards for every object type;
- integrations without a concrete consequential use.

## Production sequence

### 1. Word

Implement `say it`, option answers, maybe judgments, reopen, and correction as
real append-only writes. This proves the durable word and receipt grammar used
by every later arc.

### 2. Work

Bind editable effort proposals, approval, runs, interventions, stop, retry,
maps, rejection, and results to the canonical orchestration model.

### 3. Memory

Bind the Dig, sourced deltas, promises, learned arithmetic, and corrections to
the existing graph, stream, and source content.

### 4. Custody

Implement bridge-backed draft review and placement, requested-versus-actual
receipts, weekly close, and append-only reopen. Preserve `sent: false` as a
structural invariant.

### 5. Daily driver

Finish responsive behavior, keyboard, reduced motion, observability, real-data
browser tests, rollout, and rollback.

## Production gaps

The prototype is self-contained and fixture-backed. Production still needs:

- authenticated durable state;
- canonical IDs and event schemas;
- API contracts and idempotency;
- real source freshness and denied-access states;
- orchestration binding;
- bridge-backed mail read and draft placement;
- provider receipts;
- learned-pattern persistence;
- close-period persistence;
- observability and support traces;
- production verification against actual state.

These are implementation gaps, not unresolved product direction.

## Main risks

### The field becomes too wide

Mitigation: preserve the closed row contract, compress metadata, and use the
selected line for depth. Do not add columns casually.

### The drawer becomes hidden navigation

Mitigation: keep one shell, one layer, stable close behavior, and visible room
context. Reject drawer-to-drawer navigation chains.

### Integrations weaken truth

Mitigation: fail closed, show freshness, preserve requested and actual states,
and expose raw receipts.

### Delegation becomes theater

Mitigation: use canonical runs, factual stages, explicit foreman checks, named
rejection, and durable result artifacts.

### Learning becomes maintenance

Mitigation: learn quietly from normal use and allow correction where a wrong
read appears. Do not create a taxonomy-management chore.

### Mobile becomes a long desktop page

Mitigation: preserve the selected causal composition and fixed machine strip.
The first viewport must keep word, work, and receipt awareness.

## Verification evidence

The packaged prototype passes:

- 36 end-to-end browser checkpoints;
- 153 control and safety checks;
- 28 isolated scenarios;
- all 44 declared `data-action` controls;
- 106 distinct visible control names;
- 390, 768, 1200, and 1440px viewport checks;
- light and dark contrast checks;
- reduced-motion checks;
- keyboard and focus-return paths;
- local-only network verification;
- zero browser console errors.

## The design judgment needed

Nathan should evaluate the prototype as the Work OS itself, not as a feature
demo.

The decisive question is:

> Does this selected room feel like an operator already working inside your
> world, and what still feels like software you would have to manage?

If the room passes that test, move directly into Arc 1. If it fails, revise the
room-level composition before production wiring. Do not solve a room problem
with more features.