Problem
Intent capture is configured only in code, at SDK init — withYavio(server, { intent: true }). Changing it means redeploying the customer's MCP server. There's no way to see or change per-project data-collection settings from the dashboard, and no way to answer "what are we actually keeping about these users?" without querying storage directly — which is exactly the question you need answered before turning any of it on, or when an app-store review asks.
Proposed Solution
A data-collection section in project settings, in two parts.
Settings
- (a) Intent capture — on/off
- (b) ChatGPT user logging — on/off
Review
A per-project view of what is actually being captured and retained right now: which identifying fields land in storage for this project's traffic, with real (redacted) examples from recent events, so the setting above can be changed from evidence rather than from memory of how the SDK was configured.
Alternatives Considered
Two places to enforce the settings, and they differ materially:
- SDK-side: the SDK fetches project config at startup and stops capturing at the source. Nothing sensitive leaves the customer's server, but it needs a config endpoint, caching, and a refresh story — and can't change for an already-running process without a restart.
- Ingest-side: the SDK keeps sending, ingest drops or redacts. Takes effect immediately, but the data has already left the customer's server.
Needs a decision before implementation.
Affected Package
Dashboard, @yavio/sdk
Problem
Intent capture is configured only in code, at SDK init —
withYavio(server, { intent: true }). Changing it means redeploying the customer's MCP server. There's no way to see or change per-project data-collection settings from the dashboard, and no way to answer "what are we actually keeping about these users?" without querying storage directly — which is exactly the question you need answered before turning any of it on, or when an app-store review asks.Proposed Solution
A data-collection section in project settings, in two parts.
Settings
Review
A per-project view of what is actually being captured and retained right now: which identifying fields land in storage for this project's traffic, with real (redacted) examples from recent events, so the setting above can be changed from evidence rather than from memory of how the SDK was configured.
Alternatives Considered
Two places to enforce the settings, and they differ materially:
Needs a decision before implementation.
Affected Package
Dashboard, @yavio/sdk