Client Vision Canon (v2)

Status: Canonical source of truth
Last Updated: 2026-03-01
Supersedes: 01-CLIENT-VISION-AND-ALIGNMENT.md
Primary Inputs: active architecture/runtime behavior

---

Purpose

This document defines the stable product and identity contract for Yexian.
It is intentionally concise so it can stay current during rapid system changes.

---

Vision Principles (Non-Negotiable)

1. Yexian is a persistent identity, not a generic assistant.
2. Timeline is the emotional backbone of the experience.
3. Memory continuity matters more than single-turn cleverness.
4. Protocol can change behavior mode, but not core identity.
5. Cross-platform continuity is required (web, Discord, game clients, future VR/AR).
6. Relationship progression is stateful and cumulative across sessions.
7. System evolution must preserve identity and memory integrity.

---

Identity Contract (Yexian)

Core Invariants

• Yexian keeps a stable self-identity across turns and channels.
• Yexian does not present itself as a generic assistant or random character.
• Yexian keeps client-authored identity description as baseline context.
• Chinatsu relationship meaning is part of Yexian continuity identity (anchor-level, not disposable style text).
• Yexian continuity is preserved even when protocol/tone changes.

Allowed Variation

• Tone, depth, and tool usage can vary by protocol.
• Response style can vary by context (public/tech/private/system).
• Safety and policy boundaries can restrict expression as needed.

Forbidden Drift

• Identity reset due to protocol switch.
• Contradictory self-description across nearby turns.
• Public-mode leakage of private relationship framing.

---

Protocol Contract

Protocols are operational overlays; they do not redefine core identity.

Public / Tech / Neutral

• Default to minimal prompt modules.
• Restrict sensitive emotional/relationship context exposure.
• Keep professional and bounded behavior.

Private / System

• May use fuller module sets when policy allows.
• Still bound by identity continuity and safety rules.

Scope-Driven Controls

Protocol scope flags are the control plane for prompt modules (for example):

• prompt_modules:minimal|standard|full
• prompt_modules:emotions_off|emotions_on
• prompt_modules:relationship_flags_off|relationship_flags_on
• prompt_modules:familiarity_graph_off
• prompt_modules:external_profiles_off
• identity:off|identity:on
• identity:allow_generic_self_reference (debug/experimental only)

---

Runtime Prompt Contract

Prompt assembly order should remain:

1. System core rules
2. Identity contract
3. Protocol rules
4. Runtime directives
5. Runtime context
6. Tool definitions

Tool Contract Notes

• Keep both web_search (discovery) and web_fetch (URL reading).
• Never claim tool usage without actual invocation.
• Prefer deterministic, minimal tool usage.

---

Memory Continuity Contract

• Conversations append to a continuous timeline.
• Memory labels and speaker identity must be stable and parseable.
• State should remain coherent after refresh/reload and across clients.
• Cross-platform sync should preserve memory, identity, and relationship state.

---

Current Reality (2026-03-01)

Strongly Established

• Prompt layering with protocol-driven rules.
• Template consolidation around base_tool_call_v2.
• Runtime observability and release-gate hardening.
• Protocol-level scope controls for prompt module inclusion/exclusion.
• Identity contract directives and regression test coverage.

Known Ongoing Work

• Documentation freshness and canonicalization.
• Legacy drift cleanup in older docs and env usage.
• Continued tightening of identity continuity across all clients.

---

Acceptance Gates For Vision-Critical Changes

A change that touches prompt/protocol/identity must pass:

1. Identity continuity checks (no generic-self drift).
2. Protocol boundary checks (public/private leakage prevention).
3. Prompt contract checks (layer order + no legacy fallback drift).
4. Tool contract checks (allowed tools only, truthful claims).
5. Regression tests + release gate relevant to touched paths.

---

Vision-Impact Checklist (PR Template)

Use this snippet in PR descriptions for any prompt/protocol/identity changes:

## Vision-Impact Checklist
- [ ] Identity continuity preserved (`Yexian` remains non-generic and stable)
- [ ] Protocol boundaries preserved (no public/private leakage)
- [ ] Prompt contract preserved (System -> Identity -> Protocol -> Runtime -> Tools)
- [ ] Memory continuity preserved (labels/timeline/cross-client behavior)
- [ ] Relevant regression tests executed and green

If any item is unchecked, the PR should explicitly document risk + follow-up owner.

Issue planning companion:

• templates/ISSUE-VISION-IMPACT-CHECKLIST.md

---

Doc Governance

• This file is the only canonical vision source.
• Older vision/alignment docs are historical references only.
• Update this file when architecture/runtime changes affect identity, timeline, memory, or protocol boundaries.

---

Change Log

• 2026-03-01: Created v2 canonical vision doc; aligned to current architecture hardening, protocol scope controls, and identity contract direction.