Skip to main content
Epode is identity-aware, but never identity-inventing. Companies can attach their own authenticated customer references and first-party anonymous references. Epode never identifies the customer’s agent, uses behavioral similarity as proof, or silently merges people.

​
Progressive customer identity

Customer activity can be verified, pseudonymous, ephemeral, or unresolved:
  • accountRef represents an authenticated organization, tenant, or workspace.
  • userRef represents an authenticated end user.
  • anonymousRef represents a stable, product-owned pre-login visitor.
  • customerRef remains only the compatible Ask-once subject. When richer identity is present it must exactly equal accountRef; never pair it with userRef alone or with a different account.
References are server-side telemetry only. Do not send names, email addresses, prompts, task text, caller fields, tool arguments, or agent-provided identity claims. Epode stores a keyed, product-scoped representation and a bounded display hint; the agent-facing feedback envelope never receives a raw identity reference.
When a request legitimately contains both anonymousRef and an authenticated userRef, Epode can link the earlier pseudonymous journey to the verified customer. That deterministic link is company-authorized, auditable, and product-scoped. Conflicts fail closed. Similar behavior may suggest a relationship but never performs a verified merge.

​
Typed signals and provenance

Accepted outcome feedback becomes evidence-backed signals such as outcome, friction, feature need, workaround, satisfaction, or intent. Every signal links to the exact session, interaction, or feedback report that supports it and labels how it was obtained:
  • agent_reports_user_statement
  • agent_reports_current_task
  • agent_inference
  • product_activity
  • company_assertion
An inference is never displayed as a confirmed user fact. Corrections create new evidence rather than silently rewriting history.

​
Scoped permission

Permission is purpose-specific: sharing an outcome does not authorize remembering preferences or personalization. The initial customer-intelligence release preserves the existing feedback workflow and maps it only to share_outcome. Preference sharing, durable memory, and personalization remain denied until they are separately authorized. Ask-once decisions keep their monotonic revision and revocation history.

​
Session continuity

Journeys exist only when an experience graph or your product/MCP integration supplies a stable, application-level reference. Epode does not group requests by timing, IP address, user agent, or inferred identity. HTTP adapters may retain IP address, user agent, language, referrer origin, and client hints as request facts for an already resolved customer. Those observations remain evidence attached to the exact interaction; they never create, merge, verify, or link a customer and never establish session continuity. Use a session reference when your product already has a meaningful journey—such as a checkout attempt, support workflow, or research run. If no stable reference exists, leave it out and use interactions instead.
An MCP transport session is not product-session proof. MCP 2026-07-28 transport is stateless; application continuity must be explicit.

​
Retention

Collection policy accepts any whole-number retention period from 1 to 365 days. Dashboard queries apply a new period immediately. Feedback, interactions, and sessions outside the window stop appearing at once and are physically removed by the scheduled purge, which can take up to one purge interval. The HMAC-derived Ask-once permission decision is intentionally separate from telemetry retention. It survives until the permission is explicitly changed or the product is deleted. Expired signals stop contributing to active customer intelligence even when policy permits retaining their audit record.