Ori Presence continuity, cognition, and consent integration

Audit date: 2026-07-18

Scope: RB.2 source-first integration note for the optional Rail narrator/concierge: what the V6 Ori substrate does now, whether a real model is wired, which consent systems are actually present, and the exact boundaries the believability beta must preserve.

Implementation status: The RB.2 adapter, durable authority, governed model host, optional Rail surfaces, and hard budget described as required below were implemented after this source audit. Deployment configuration, staged rollout, telemetry, rollback, and current verification commands are maintained in RB2_ORI_PRESENCE_BETA_RUNBOOK.md. The historical audit remains here to preserve the decisions and acceptance boundaries that implementation must continue to satisfy.

Integration decision#

Ori Presence cannot be connected by importing one finished V6 narrator. The repository contains real continuity, cognition, narration, governance, and consent pieces, but their deployed boundaries do not yet meet:

V1 account identity + durable, exact-scope consent (new Rail adapter/store)
  -> Rail server-side input firewall
       -> post-batched subscribed timeline, never adult-ring input
       -> coarse daypart / presence only when separately granted
       -> explicitly granted Ori projection and memory scopes only
  -> V6 Clio significance ranking + grounded recap contract
  -> injected Iris CognitionGateway host (new production composition)
       -> Moirai per-request budget + kill switches
       -> model generation + dialogue quality gate
       -> semantic grounding + Isis policy
  -> Rail inference/day budget (RB.2 cost-ceiling task)
  -> optional Thread / text / voice / remembrance surface
  -> append-only consent, inference, and provenance audit

The beta must remain default-off at three independent layers: deployment/cohort flag, user surface consent, and every data-awareness scope required by the requested behavior. Missing, invalid, expired, withdrawn, denied, or revoked consent means the data is structurally absent before prompt assembly. A model instruction such as “ignore private events” is not a consent boundary.

The best recap substrate is Clio's significance ranking and grounded narrated Chronicle, not ori-model itself. The best model substrate is the shared Iris CognitionGateway, mounted through Moirai. Neither has a production V6 host today. The next RB.2 implementation must therefore add a real host composition and provider configuration; a scripted test provider or the existing template fallback cannot satisfy the “real LLM path” acceptance criterion.

What @oshun/ori-model can do today#

libs/v6/ori-model/src/index.ts is an in-process, dependency-free event-log and projection library. Its descriptor accurately claims five capabilities: Ori identity, Ori events, an event-sourced biography, a cognition cache, and material-change cache invalidation. It does not claim consent, prompt assembly, narration, model dispatch, storage I/O, or an HTTP API.

The package's index.spec.ts covers every event handler, concurrent conflict resolution, cache hits and invalidation, trait drift, the dossier gate, 10,000-event rebuild/snapshot loading, append-only behavior, and forgiveness as a new reflection rather than erasure. Those tests prove the pure domain behavior; they do not prove deployed persistence or model availability.

Rust service reality#

apps/v6/egbe-ori-service/src/lib.rs contains substantial service-domain code, PostgreSQL/pgvector DDL, residency tags, operator-read audit structures, passport/DSAR logic, projection probes, and a Rust projection materializer. The runtime distinction matters:

• PartitionedPostgresOriEventStore currently stores streams and residency in BTreeMaps; it does not open a PostgreSQL connection or execute the embedded DDL.
• OriProjectionMaterializer stores projections and snapshots in BTreeMaps.
• the 1,536-dimensional pgvector column is declared, while the in-process search implementation uses a small curated four-dimensional embedding in its tests;
• run_service is a blocking TCP listener whose only implemented route is GET /health; all other requests receive 404.

The service code is valuable executable architecture, but the Rail cannot call it today to read an Ori. RB.2 needs an actual authenticated read endpoint or a repository-conventional direct service adapter backed by durable storage. It must fail loud when that boundary is not configured.

Where model wiring actually stands#

The real shared model path exists#

The model runtime itself is real. The shared CognitionGateway validates a V6 cognition request, creates a governed AgentRunManager run, passes bounded prompt/system/tool authority to an injected provider, records a queryable run envelope and usage, and can judge and refine dialogue behind a quality gate. The run manager enforces kill switches, quarantine, child-budget reservation, tool-authority subsets, token/call/cost budgets, and audit events.

V6 exposes three structurally compatible seams:

1. dispatchPsycheCognitionViaGateway sends dialogue/decision/reflection/summary work to an injected gateway, returns the model text and runId, surfaces the dialogue-quality status, and throws on a gateway error or empty output.
2. generateLocalizedAgentDialogueViaGateway generates in the target language, runs Sophia grounding and Isis policy, withholds a quality-blocked line, and records model/run provenance.
3. createMoiraiCognitionGatewayMount wraps an injected gateway and shared kill-switch registry. Default request caps are Clotho 2 calls/2 tools/4,000 tokens, Lachesis 6/8/16,000, and Atropos 16/24/64,000; callers may tighten them per request.

The gateway variants correctly fail loud. That is the path RB.2 must use. Calling a sync fallback and labeling the output “AI” would violate both the V6 honesty seam and the RB.2 task.

The production composition is absent#

Repository-wide non-test source search found no caller that constructs a CognitionGateway, AgentRunManager, provider, and createMoiraiCognitionGatewayMount for a V6 app or service. The only usages of the V6 gateway entry points are their definitions and tests.

The tests are meaningful integration tests of the real gateway class, but the provider is scripted in-process: its complete function returns a fixed AgenticCompletion with model id test-model. They prove structural compatibility, run envelopes, budgets, kill switches, quality verdicts, and failure behavior. They do not prove external credentials, provider routing, network timeouts, production model selection, deployment configuration, or inference economics.

The user-facing V6 fallback app makes the gap visible. Its createLocalizedAgentDialogueForLocale calls generateLocalizedAgentDialogue without a generator. The resulting source is deliberately template-fallback, generatedNatively: false, with reason no dialogue model wired. This is honest behavior, but it cannot power the Ori Presence beta.

Clio is the recap substrate, with the same host gap#

@oshun/clio-story already has most of the narrative-domain contract a recap needs:

• significance scores combine event type, emotional weight, arc relevance, relationship impact, and steward relevance;
• returning-player events are grouped by agent and arc thread, batched, and ordered newest-significant-first for long absences;
• the deterministic Chronicle preserves exact source event refs;
• createReturningPlayerChronicleNarrated accepts an injected ClioNarrativeWriter, trust-zones the prompt, rejects citations outside the allowed Ori-log slice, requires a semantic entailment verifier, and carries the grounding proof on every narrated beat.

The default createReturningPlayerChronicle is deterministic string assembly, despite budget fields named for model calls. No non-test caller of createReturningPlayerChronicleNarrated or implementation of ClioNarrativeWriter exists. For RB.2, adapt the real gateway to that writer interface and retain both citation-membership and semantic-entailment gates.

Clio is Ori-log-centric. A portfolio-wide Rail recap also needs a new adapter from the already-batched, already-ring-filtered Rail timeline into a bounded recap source contract. V6 event types must not be stretched to impersonate V2/V8/Veritas events, and Rail events must not be written into an Ori merely to make Clio accept them.

The consent systems that exist#

There is no single “V6 consent grammar.” Three distinct grammars solve different problems, and conflating them would create a fail-open design.

1. V6 agent autonomy: Aye incarnation consent#

@oshun/aye-bridge governs whether an Ori agrees to incarnate into another realm. Its agent attestation has a signal (willing | hesitant | unwilling), value alignment, state readiness, reason refs, and expression time. Acceptance is the weighted score

0.45 * values alignment + 0.35 * steward-bond average + 0.20 * state readiness

at or above 0.66, with a non-unwilling signal and timestamp. A steward override over non-acceptance is recorded as coercion, triggering welfare and Themis paths. Minor and destination policy gates are separate.

This is real agent-sovereignty logic, not a user data grant. It is scoped to incarnation and cannot authorize the Rail to read a user's timeline, daypart, presence, calendar, or meaningful dates. No equivalent agent-consent evaluator currently exists for narrator work. In the beta, an Isis/Ori refusal may only withhold output; it can never widen user data access.

2. V6 agent memory autonomy#

@oshun/memory-iris-agent provides episodic, semantic, and reflective stores plus an audit-labeled memory-consent policy. Its consent enforcement is specifically “forgiveness, not erasure”: a steward can never delete an Ori's episode, and only the agent can append a forgiveness salience reweight. It does not issue or resolve user grants for recall, personalization, daypart awareness, or presence.

This layer remains relevant to RB.2 because a recap must not mutate or erase an Ori's memory, and any future write requires its own explicit user grant plus the agent-autonomy rules. It is not the account-side consent ledger.

3. V1 user consent and Iris memory scopes#

V6 architecture delegates user data consent to V1. Two V1 contracts are useful:

• the generic ConsentRecordSchema represents subject, target, domain, category, status, legal basis, collection context and presented text, verification, permissions, evidence, expiry/withdrawal/revocation, supersession, and lifecycle history;
• the Iris IrisConsentLedger is an append-only per-user sequence of pending/granted/denied/withdrawn/expired events. Each event binds consent type, free-form purposes, data categories, memory-scope implications, terms hash/version, capture method, witness, effective/expiry time, and supersession into a deterministic fingerprint.

Iris scope resolution in memory-model.ts is useful and fail-closed for its declared consumers: conversation memory needs processing and storage grants, cross-domain memory additionally needs sharing and personalization, and pose memory additionally needs sensitive-data consent. However, IrisMemoryConsumer and IrisMemoryDomain do not include V10, and the active-consent helper folds by broad consent type rather than an exact purpose. An unrelated active data_processing grant must not satisfy v10.ori.daypart.read.

The existing V1 BFF customer-consent routes expose grant, withdraw, revoke, renew, and audit operations over the canonical taxonomy, but CustomerConsentStateStore is an in-process Map. Its comment's “durable across the BFF lifetime” does not mean durable across restart. The V10 Rail state already uses PostgreSQL-backed BFF stores for subscriptions, loudness, dayparts, discretion, and adult-ring audit, but it has no Ori-presence consent record. RB.2 must follow the durable Rail state pattern and reuse the canonical consent shapes; it must not rely on the current in-memory consent route as the launch authority.

Rail consent grammar#

Principals and invariants#

Ori Presence has two independent principals:

• the user controls which account and Rail context the narrator may observe and which surfaces it may use;
• the Ori retains its disclosure, refusal, welfare, and memory-autonomy gates.

Both sets of gates can deny. Neither can grant authority held by the other. There is no steward override for user privacy, no user override for a bond-gated dossier or agent refusal, and no model-generated consent.

Every grant is exact-purpose, explicit opt-in, independently revocable, and default-deny. Wildcards, bundled “all awareness,” and implication from channel subscription or loudness are forbidden. Subscribing to Ori Presence enables a channel candidate; it does not grant daypart, presence, memory, dates, or timeline access.

Exact scopes#

RB.2 should add one typed union to the V10 contract and one durable V1 record chain per scope:

The scope names are purpose ids, not broad legal categories. Their durable records should still map to canonical categories and permission actions:

• contextual reads: personalization, actions process and use, use scope personal;
• memory reads/writes: memory, target memory_scope, actions matching the actual read/process/store behavior;
• Thread and voice output: personalization / voice, action display or use as applicable;
• remembrance dates: personalization, with sensitive categories represented explicitly when the selected date carries health, religion, grief, or other sensitive context.

No record should use required: true to make an optional beta mandatory.

Grant record and resolution#

At minimum, every scope decision must retain:

• consent event/record id, user subject id, exact scope/purpose, target resource ids, category, permission actions, and allowed data categories;
• status, legal basis, collection method, the exact presented text plus version/hash, capture actor/witness, requested/effective/captured times, optional expiry, and the prior event it supersedes;
• denial, withdrawal, revocation, expiry, renewal, and policy-version changes as append-only history; and
• a tamper-evident fingerprint or canonical persistence payload hash plus the V1 audit reference.

Resolution at request time is deliberately narrow:

active(scope, now) =
  ledger/record validates
  AND latest exact-scope event belongs to this user and target
  AND status == granted
  AND effectiveAt <= now
  AND (expiresAt is null OR now < expiresAt)
  AND terms/policy version is accepted
  AND no later denial, withdrawal, revocation, expiry, or supersession applies

pending, missing, malformed, unverifiable, expired, denied, withdrawn, revoked, and superseded all resolve to false. A storage or consent dependency failure also resolves false and produces zero Ori surface; there is no cached authorization grace period.

Every generation request carries the exact consent event ids and a sorted list of admitted scope ids in its audit envelope. It must not carry the text of excluded events merely to prove they were excluded.

Input firewall and prompt contract#

The server, not the browser and not the model, builds the narrator input in this order:

1. Verify the default-off cohort/feature flag and v10.ori.surface.
2. Apply the R0.6 adult-ring exclusion before considering any user grant. Adult events are unrepresentable in the narrator input even if another service mislabels or returns them.
3. Read only the post-batching timeline view. Preserve source channel/event refs and rollups so recap coverage is testable.
4. Resolve every requested awareness scope from the durable V1 record. Drop fields for scopes that do not resolve active; do not substitute null plus a descriptive leak.
5. Apply Ori-side dossier, refusal, minor, grief, and memory gates.
6. Assemble a typed, bounded prompt whose data fields are a discriminated union of admitted scopes. Trust-zone all timeline/user/Ori text as untrusted source data.
7. Dispatch through the Moirai-mounted real gateway with no tools by default, a per-request budget tighter than or equal to its tier ceiling, and the RB.2 per-user-day budget reservation.
8. Require Clio citation membership, semantic entailment, Sophia grounding, Isis policy, and a cleared dialogue-quality verdict before publishing.
9. Write no user or Ori memory unless v10.ori.memory.write was active for the disclosed artifact. Generation/audit logs remain governed operational records, not recalled companion memory.

Prompt tests must inspect the serialized request presented to the provider and prove that ungranted fields and adult-ring fixtures are absent. Testing only the final prose is too indirect to establish privacy.

Remembrance and ritual boundary#

V6 has a real ending/legacy domain, but not the Rail feature described by RB.2. @oshun/ereshkigal-legacy can:

• preserve an Ori across departure, transcendence, and death;
• block every minor-coded death and every unsanctioned cause;
• freeze a deceased Ori to memorial annotations;
• append relationship-weighted grief writes to living Oris; and
• enqueue an idempotent Yemaya remembrance artifact with Book of the Ori, memorial reel, and Ancestor Grove placement stages.

It does not detect anniversaries, store user-selected meaningful dates, schedule a gentle moment, obtain the user's display consent, or render a Rail surface. The queued memorial.render.requested job is artifact production, not an ambient reminder.

The V6 agent-welfare-and-player-grief governance remains mandatory for RB.2: no surprise/autoplay grief, no deceased impersonation, no replacement or monetization adjacency, minor protections, and crisis-sensitive routing. The beta should accept only user-selected date refs tied to an eligible memorial/legacy ref, produce text-only by default, never infer a date from conversations or contacts, and degrade to silence when consent, eligibility, or policy is uncertain.

Required RB.2 implementation boundaries#

The tasks following this note should make these seams explicit and testable:

1. Durable consent authority: add the typed scope union, V1-backed durable grant/event store, authenticated BFF grant/withdraw/revoke/read/audit routes, expiry and policy-version resolution, and restart-level integration tests.
2. Server-side input firewall: build one function whose output type cannot represent adult-ring data or ungranted scopes. Test no grant, partial grant, revoke, expiry, malformed records, dependency failure, and prompt bytes.
3. Ori read adapter: expose a real authenticated projection/memory read path or report not_configured; do not instantiate the in-memory fixture log in production.
4. Real model host: construct one shared provider, AgentRunManager, kill registry, quality gate, CognitionGateway, and Moirai mount in a deployable V10/V6 host. Surface provider/run/usage provenance and fail loud on missing configuration.
5. Grounded recap: map bounded post-batch Rail events to a recap-source contract, retain exact coverage refs, adapt the gateway to Clio's writer, and require semantic entailment. A model may compress phrasing; it may not invent a channel event or treat source prose as instructions.
6. Surfaces stay optional: feature/cohort flag defaults off, Thread/text/ voice/remembrance permissions are independent, discretion mode applies, and flag-off yields zero tile, timeline, audio, Thread, telemetry-content, and prompt activity.
7. Spend is separately bounded: Moirai per-call caps are necessary but not the requested per-user-day ceiling. Reserve spend before dispatch, record actual usage afterward, and degrade to silence on exhaustion.
8. No accidental memory: read-only recap/greeting paths append no Ori or Iris memory. Add explicit tests that a successful generation leaves both stores unchanged without v10.ori.memory.write.
9. Governed remembrance: schedule only user-selected eligible dates, never synthesize a deceased person, never autoplay, and exercise grief/minor/ crisis policy in service and end-to-end tests.

Verification evidence#

• The nine directly relevant V6/Iris Vitest projects pass: 46 files and 591 tests across Ori continuity, cognition, the governed gateway, Clio narration, Aye consent, agent memory, grief/legacy, and V1 Iris memory/consent.
• The canonical ConsentRecordSchema cases pass: 8 focused tests.
• The Rust egbe-ori-service suite passes: 28 tests, including storage, projection, memory-index, residency, operator-audit, DSAR, and stewardship boundaries.
• Prettier, Markdown source-link resolution, and git diff --check pass for this note and its ledger entry.

This uses the real strengths of V6—continuity, significance ranking, grounded narration contracts, governed cognition, agent autonomy, and grief policy—while making the missing production host, account consent, storage, and Rail adapters visible rather than treating executable architecture as a finished narrator.