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).
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).
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).
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. 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.

The authoritative naming record is Eve — the V1 Omnipresent Assistant. The three distinct uses of Lilith are defined in Lilith Persona Policy and collected in the Lilith handbook.

Coverage map#

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#

This is a responsibility map, not a claim that every surface has identical capabilities. See the current capability register 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, context, and safety.

Engineering: read runtime, quality, and the change map.

SRE and governance: read safety, operations, and the standing SMX maintenance runbook.

Canonical companion documents#

• Assistant Experience — product behavior of the shared member assistant shell.
• Iris Memory and Identity — memory scopes, retention, consent, recall, and data rights.
• Sophia Grounding — grounded-answer and evidence contracts.
• Lilith Persona Policy — persona, crisis, voice, and cultural-safety policy.
• Omnipresent Assistant design — architecture, naming, and shipped phase record.
• Small-Model Excellence design — measured model and evaluation strategy.
• Eve Everywhere register — current builder-plane breadth and evidence-backed gaps.
• SOTA gap audit — 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 — 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 — 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.