SEIF Trace privacy and retention
Environment retention
The underlying modes are content and metadata. Development defaults to content; staging and production to metadata. Flight Recorder adds explicit metadata, incident and replay profiles with content lifetime and byte budgets. Each environment also bounds retained traces (1–100000, default 10000). The Registry applies its current policy at ingestion; running deployments keep their capture policy until redeployed.
Metadata keeps ids, consumer/objective, correlation, Build/deployment/binding coordinates, selection and exclusion decisions, material locators and fingerprints, estimated budgets, unknowns and currentness, rendered fingerprint, consumption relation, timings and application-supplied outcome labels. It removes request input, rendered and consumed messages, and retained provider results. Metadata is not anonymous data: identifiers and locators can be sensitive. Content additionally keeps sanitized input and messages; redaction cannot recognize every confidential fact. Mark material sensitive: true to force metadata retention for that resolution.
Live provider data
The customer database never enters a Build; only the requested record is looked up, only when a layer the profile can use needs it. Provider retention is set per provider in the Deployment Binding and can never exceed the environment's:
| Provider retention | Trace keeps |
|---|---|
metadata (default) | provider, status, binding revision, version, currentness, counts, durations; request digest and item fingerprints keyed with the binding's trace key |
digest | as metadata, with plain SHA-256 item digests (verifiable against a source of truth) |
content | the returned items, only where the environment retains content; enables reproduction when complete identity and semantic checks also pass |
Why keyed: lookup keys (customer ids) and small records ("Plan: Enterprise") are low-entropy. A plain digest of CUST-1042 or of a short record can be confirmed by guessing; an HMAC with a per-binding key cannot be confirmed without that key, which the Registry never returns. Under metadata retention every digest covering provider content — request, items, provider material, rendered and consumed context, projection revisions — is keyed, while equality within a binding still works for search and correlation. Provider record ids never appear in locators (customer-data/item-<16 hex>).
Limits
Retention policy edits apply to subsequent ingestion; the expiration described below removes retained content from active stores, not backups. A granular deletion API is FUTURE. Explainability from retained ids and fingerprints remains; metadata-only traces cannot claim exact reproduction. Outcome labels, latency, cost and metrics are application-supplied observations, not model truth or causal evidence. Default operational logs exclude context content, provider data and credentials.
Historical content controls (0.6.0)
New content traces carry contentExpiresAt. Runtime --content-retention-seconds / config contentRetentionSeconds defaults to 86400 (one day), with a permitted range of 1–604800 seconds. A Flight Recorder policy can further shorten this deadline; it never extends it. Runtime and Registry remove retained input, rendered/consumed messages and provider items on reads and in a 60-second sweep. The Registry bounds each sweep to 100 expired traces; readers always enforce expiration even during a backlog. Metadata, revisions and digests remain. Content with no original expiry is downgraded when the recorder enforces its policy, rather than receiving an invented deadline. Historical operations never recreate expired input. Offline stores cannot purge until opened; backups require the operator's retention policy.
Budget/profile downgrades preserve existing fingerprints and coordinates; they do not retroactively key fingerprints captured under content retention. Choose metadata at capture when keyed provider fingerprints are needed from the start. Byte budgets measure retained logical content envelopes, not total disk usage or backup size.
Registry trace.content is separate from trace.view. Developers and Reviewers have content access under their existing project scope; Viewers receive metadata. Reproduction also requires trace.reproduce and historical Build access. Raw runtime proxy trace reads require content access. Current authorization is checked for every request, irrespective of historic permission. Local personal mode trusts the OS account and private user/project directory permissions.
Input retention is bounded to 16 KiB, rendered/consumed messages to 256 KiB, and trace ingestion to 2 MiB/100 records. Inputs redacted or beyond the bound cannot support exact replay. New local trace directories use mode 0700; reproduction receipts use 0600. Registry at-rest encryption remains an operator/filesystem responsibility; no new encryption or tenant boundary is claimed. Reproduction documents the minimum retained provenance and the limitations of external dependencies.
Tool receipts
Tool gateway receipts retain keyed argument/result/reason fingerprints and bounded execution metadata, never raw argument or result bodies. Tool schemas and availability are retained as release/disclosure facts; historical replay never executes a tool. The Runtime’s local fingerprint key stays in its private data directory. Tool retention and uncertainty.