Skip to content
Cross-app memory — ELYSEAID

Your users arrive already contextualised.
Without you building anything.

A universal pseudonym. A context built across all ELYSÉA-compatible apps. Memory belongs to the user — not to the builders. Your app benefits from it under their consent.

The ELYSEAID — a pseudonym, not a real identity

Each user receives a universally auto-generated identifier:

soleil-bleu-cascade-42@elysea.app

Three words + number + ELYSÉA domain. Non-identifying by design: this identifier contains no email, no name, no biographical data. The user can choose a personalised handle — but the default pseudonym protects their anonymity within the ecosystem.

On the SDK side: builders receive an opaque coreUserId derived from the ELYSEAID. They never see the real pseudonym — let alone the underlying identity.


ELYSEA.DATA.MEMORY_ETHICAL.v1 — FIXED

5 types. Not one more.

Declared goals

What the user is trying to accomplish, as they have stated it. Never interpreted, never inferred — declared.

Communication preferences

Language register, response pace, formality level. The ELYSÉA brain adapts its voice accordingly across all apps.

Useful context

Active situation, relevant constraints. E.g.: "Works in a distributed team, UTC+2 timezone." Factual, limited to 256 characters.

Short session summaries

Lightweight summaries of past exchanges. Never verbatim content — only the contextual elements relevant to continuity.

Non-diagnostic scores

1-10 indicators on declared functional dimensions (e.g.: workload, interaction preferences). Never clinical. Never a diagnosis.

Each item: ≤ 256 characters · mandatory TTL · scoped consent required. This canon is fixed — ELYSÉA cannot extend it by commercial decision.


Guarantee K — sacred memory

Certain context items are marked “sacred” by the user in their data control portal. These items live in an inaccessible layer: no SDK API exists to access them. No builder, no pricing plan, no commercial agreement can expose them.

This is not a privacy policy: it is the total absence of an endpoint. You cannot bypass what does not exist.

ELYSÉA is guardian — not owner.

The platform stores and protects memory. It does not own it. This asset belongs to the user inalienably — exportable, erasable, revocable at any moment.


Granular consent — registry, revocation, export

Every app integrating ELYSÉA must collect separate consent. ELYSÉA consent is distinct from app consent — both must exist. The ELYSÉA ID portal gives the user a readable view of every granted access: which app, which part of the context, for which declared purpose, since when.

Revoke access

The user withdraws consent from an app. Access to their context stops immediately.

Export their memory

JSON export on request — open format, readable, portable to any other service.

Erase an item

Individual or total deletion, effective immediately. Right to erasure without delay.


For builders — what you can and cannot do

Permitted

  • Scoped memory write (with explicit user consent)
  • Resolving coreUserId from your auth JWT
  • Contributing to the 5 permitted memory item types
  • Reading the sociolect profile (if cross-app consent is active)
  • Defining TTL and scope for each item you write

Prohibited (P2 — immediate revocation)

  • Direct read of a user's memory items
  • Access to another builder's memory summaries
  • Memory export to an external system without scoped consent
  • Cross-referencing memory data from multiple users
  • Access to Guarantee K (no endpoint exists)

Source: ELYSEA.SDK.ELYSEAID.v1 §2 — ELYSEA.SDK.INTEGRITY_PROTECTION.v1 §4 (P2)

Memory is not your asset. That is what makes it valuable.

Talk to the teamDeveloper Quickstart