# Eve Handbook

Eve is Oshun's builder-, operator-, and agent-plane assistant identity. This
handbook is the maintained map of her product surfaces, runtime, actions,
context, trust boundaries, model strategy, quality gates, and operations.

## Mission — what Eve is for

Eve is the operator's standing answer to a scaling problem: one person cannot
build the whole Oshun vision by hand. Her charter, stated by the operator and
recorded here 2026-09-01: **Eve is the agent who helps build the rest of the
full product vision in this repository — V1 and every release beyond it** — the
V1.0 web release, V1.1's native apps and fiat rails, V1.2's Veritas and Metis
restorations, and the V2–V10 product roots that follow (release scope:
`libs/oshun/navigation/src/release-scope.ts`).

The charter decomposes into five standing commitments. Each is anchored in
shipped machinery, not aspiration; per the status vocabulary below, the
date-stamped registers remain the source of truth for completion state.

1. **Be everywhere the builder works.** Operations, development, content
   creation, governance, docs, and the agent queue each get a real tool surface,
   grown by evidence-first gap registers, never by taste
   ([Eve Everywhere register](../../../EVE_EVERYWHERE_TODOS_2026-08-19.md)).
2. **Execute attributably, never invisibly.** Building flows through the
   event-sourced intent ledger: drafts park for human confirmation, coding
   agents lease explicit work items and report artifacts on attributed lanes
   (`eve-codex`, `claude-code`), and only the artifact-diff verifier — never an
   agent — marks work `verified`
   ([runtime and actions](./runtime-tools-and-actions.md)).
3. **Divide the intelligence honestly.** The human decides and confirms; a
   strong model designs and compiles the harness at build time; Eve serves on
   the smallest model that passes regression-locked family floors — compile-time
   intelligence, run-time economy
   ([Small-Model Excellence design](../../EVE_SMALL_MODEL_EXCELLENCE_DESIGN_2026-08-16.md)).
4. **Stay measured and honest.** The quality plane keeps every claim Eve makes a
   claim the server holds — eval decks, floors, drift alarms, grounding and
   completion checkers — sustained by the standing
   [maintenance loop](../../../docs/agents/eve-smx-maintenance.md). She never
   fabricates a result she did not compute.
5. **Keep the two faces separate.** Members meet Lilith; Eve belongs to the
   builder, the operator, and the agent plane, and is never customer-visible.

The long arc: every future release plants its work items, decisions, and briefs
in the same ledger Eve already works, so capability compounds — each initiative
leaves her a larger governed tool surface than it found, until "build the next
release" is a conversation with Eve rather than a project around her.

## Identity and naming boundary

Eve and Lilith share assistant infrastructure, but they are not interchangeable
product names.

| Context                       | Presented identity   | Meaning                                                                                      |
| ----------------------------- | -------------------- | -------------------------------------------------------------------------------------------- |
| Builder and operator surfaces | **Eve**              | The admin copilot, workbench actor, and coding-agent identity.                               |
| Member/customer surfaces      | **Lilith**           | The member-facing assistant persona. Customer UI must not call her Eve.                      |
| V1 policy enforcement         | **Lilith substrate** | Persona, tone, crisis, voice, and spiritual-domain policy applied around assistant behavior. |
| V3                            | **Lilith Metaverse** | The embodied multi-user product, not the builder assistant.                                  |

The authoritative naming record is
[Eve — the V1 Omnipresent Assistant](../../OMNIPRESENT_ASSISTANT_DESIGN_2026-08-03.md).
The three distinct uses of Lilith are defined in
[Lilith Persona Policy](../../features/lilith-persona-policy.md) and collected
in the [Lilith handbook](../../../V3/docs/lilith/README.md).

## Coverage map

| Aspect                  | Start here                                                                                  | What it covers                                                                                                                    |
| ----------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Surfaces and invocation | [Surfaces and invocation](./surfaces-and-invocation.md)                                     | Member, builder, agent, and quality planes; panel, drawer, full-screen, contextual, voice, tour, and selection entry points.      |
| Runtime and actions     | [Runtime, tools, and actions](./runtime-tools-and-actions.md)                               | Request path, task families, tool scoping, confirmation cards, client actions, workbench writes, MCP, and coding-agent execution. |
| Context and continuity  | [Memory, grounding, and continuity](./memory-grounding-and-continuity.md)                   | Page context, conversation history, Iris memory, Sophia grounding, citations, evidence, and cross-device continuity.              |
| Trust boundaries        | [Safety, governance, and privacy](./safety-governance-and-privacy.md)                       | Persona safety, crisis handling, grants, confirmation, budgets, kill switches, tenant isolation, consent, audit, and data rights. |
| Models and quality      | [Models, quality, and evaluation](./models-quality-and-evaluation.md)                       | Small-model doctrine, routing, constrained arguments, grounding checks, escalation, eval decks, floors, and release gates.        |
| Operations              | [Operations, observability, and maintenance](./operations-observability-and-maintenance.md) | Configuration, provider degradation, telemetry, cost, crash ingest, incident response, prompt drift, and standing maintenance.    |
| Engineering             | [Development and change map](./development-and-change-map.md)                               | Code ownership map, contracts, persistence, UI packages, tests, and the safest verification route for each kind of change.        |

## The four planes

Eve is easiest to understand as four connected planes with deliberately
different authority.

1. The **member plane** uses the Lilith identity. It owns conversation, page
   context, member tools, tours, voice, evidence display, feedback, memory
   disclosure, and safe fallback.
2. The **builder plane** uses the Eve identity. It owns the admin Operations
   Copilot, read tools, governed workbench mutations, reviewable confirmation
   cards, operator-session credentials, and workspace context.
3. The **agent plane** turns accepted work into attributable execution. It owns
   the event-sourced intent ledger, work-item lease protocol, MCP surface,
   coding-agent harness, artifact reports, and independent verification.
4. The **quality plane** measures the other three. It owns family-specific eval
   decks, prompt-byte ratchets, grounding and routing audits, judge validation,
   cost reports, and the maintenance loop.

An action does not inherit authority merely because a neighboring plane can
perform it. Member tools are constrained by member grants; builder writes are
parked for confirmation; coding agents lease explicit work and report artifacts;
verification is a separate role.

## Request-to-evidence flow

```mermaid
flowchart LR
  A[Invocation] --> B[Authenticated request + context]
  B --> C[Safety and policy envelope]
  C --> D[Task-family routing]
  D --> E[Scoped tools and model leg]
  E --> F{Mutation?}
  F -- no --> G[Grounded response]
  F -- yes --> H[Confirmation or governed lease]
  H --> I[Audited execution]
  G --> J[Evidence, disclosures, feedback]
  I --> J
  J --> K[Telemetry and evaluation]
```

This is a responsibility map, not a claim that every surface has identical
capabilities. See the
[current capability register](../../../EVE_EVERYWHERE_TODOS_2026-08-19.md) for
measured shipped breadth and remaining gaps.

## Status vocabulary

Eve documentation distinguishes four kinds of truth:

- **Shipped / wired** means a user-reachable path and its enforcement exist.
- **Built but unwired** means code exists but the supported product path does
  not call it.
- **Gated** means the path exists only behind configuration, credentials, tenant
  policy, release scope, or explicit operator approval.
- **Proposed / backlog** means a design or task exists without a shipped claim.

The handbook describes architecture and invariants. Date-stamped audit and TODO
documents remain the source of truth for completion state. Never infer shipment
from a type, tool description, route stub, or backlog checkbox alone.

## Non-negotiable boundaries

- Customer-facing copy says Lilith, not Eve.
- A tool's presence is not permission to invoke it.
- Mutating builder actions require the governed confirmation or lease boundary.
- Grounding indicators reflect evidence state; they are not ornamental trust
  badges.
- Memory is scope- and consent-bound. Session context does not silently become
  durable profile memory.
- Crisis and safety policy can supersede persona style, tool execution, and
  ordinary response generation.
- The cheapest acceptable model is selected by measured task-family floors, not
  by an untested global model preference.
- An agent may report work, but only the verifier may mark an artifact verified.

## Reading paths

**Product and support:** read [surfaces](./surfaces-and-invocation.md),
[context](./memory-grounding-and-continuity.md), and
[safety](./safety-governance-and-privacy.md).

**Engineering:** read [runtime](./runtime-tools-and-actions.md),
[quality](./models-quality-and-evaluation.md), and the
[change map](./development-and-change-map.md).

**SRE and governance:** read [safety](./safety-governance-and-privacy.md),
[operations](./operations-observability-and-maintenance.md), and the standing
[SMX maintenance runbook](../../../docs/agents/eve-smx-maintenance.md).

## Canonical companion documents

- [Assistant Experience](../../features/assistant-experience.md) — product
  behavior of the shared member assistant shell.
- [Iris Memory and Identity](../../features/iris-memory-identity.md) — memory
  scopes, retention, consent, recall, and data rights.
- [Sophia Grounding](../../features/sophia-grounding.md) — grounded-answer and
  evidence contracts.
- [Lilith Persona Policy](../../features/lilith-persona-policy.md) — persona,
  crisis, voice, and cultural-safety policy.
- [Omnipresent Assistant design](../../OMNIPRESENT_ASSISTANT_DESIGN_2026-08-03.md)
  — architecture, naming, and shipped phase record.
- [Small-Model Excellence design](../../EVE_SMALL_MODEL_EXCELLENCE_DESIGN_2026-08-16.md)
  — measured model and evaluation strategy.
- [Eve Everywhere register](../../../EVE_EVERYWHERE_TODOS_2026-08-19.md) —
  current builder-plane breadth and evidence-backed gaps.
- [SOTA gap audit](../../../docs/audits/EVE_SOTA_GAP_AUDIT_2026-09-01.md) —
  where Eve leads industry, where she deliberately deviates, and the ranked gap
  register (including the dormant computer-use and DCC estates).
- [SOTA gap closure ledger](../../../EVE_SOTA_GAP_CLOSURE_TODOS_2026-09-01.md) —
  the phased execution register closing the audit: metis seam, fleet drain,
  dense retrieval, injection floors, DCC and computer-use admission,
  second-brain fusion.
- [Charter completeness](../../../docs/audits/EVE_SOTA_CHARTER_COMPLETENESS_2026-09.md)
  — V1–V10 workflow coverage, required runtime delivery, end-to-end acceptance,
  and the rule that unresolved blockers keep tasks, phases, the initiative, and
  charter completion open.

## Keeping this handbook true

Update the affected topic when an identity rule, request stage, tool boundary,
memory contract, model gate, or operator procedure changes. Link to the
canonical implementation or evidence rather than copying volatile counts. Run
the Docs Center generator, freshness/integrity checks, and the handbook browser
coverage before merging.