Data inventory & consent

Cerevisor maintains a structured inventory of every memory record it stores, what type of data it is, where it came from, and what you've consented to do with it.

Important: in v1.0.x, every consent flag for egress defaults false and there are zero outbound network paths from the memory subsystem. The inventory exists because future versions will add opt-in egress for things like personal-aggregate sharing or a user-data marketplace, and we wanted the consent contract on day one, not retrofitted later.

The Inventory tab

Open the Memory view → Inventory tab. You see:

• A summary count by data class.
• Per-record metadata: what it is, where it came from, when it was created, what its consent scope is.
• A search box to find a specific record.

Click any record to expand its details, including its current content and its provenance (which workflow run, which agent, which skill produced it).

Data classification

Every record is classified into one of four data classes:

Class	What it covers
identity	Information about you that identifies you (your role, name, communication preferences).
behaviour-aggregate	Patterns of how you use Cerevisor (which roles you use most, which models, which skills).
content	Specific content the harness produced or you authored.
derived-insight	The harness's observations and self-portrait — synthesis layered on top of the other classes.

Classification happens at write time, never at export time. New write sites in the codebase pin a dataClass explicitly.

Third-party PII flag

Each record also carries a flag:

containsThirdPartyPii	Meaning
unknown	Not yet checked. The default.
confirmed-no	A scan ran and didn't find third-party PII.
flagged-yes	A scan flagged this record as potentially containing someone else's personal data.

The PII detection capability is a Phase 1 plan, currently every record is unknown until manually flagged.

Consent scope

Each record's consentScope declares the maximum egress this record can ever participate in:

Scope	Meaning
personal-only	Never leaves this device. The default for every record.
aggregate-shareable	Eligible for inclusion in differentially-private aggregate sharing (Phase 2 feature; not active in v1).
marketplace-listable	Eligible for inclusion in a marketplace bundle the user creates (Phase 3 feature; not active in v1).

You can change a record's consent scope from the Inventory tab. The change is logged.

Egress flags

The Consent tab (Memory view → Consent) shows the system-wide egress flags:

Flag	Default	What it would enable
aggregateMetricsToCerevisor	off	Send aggregate metrics about your usage to Cerevisor for analytics. Not active.
marketplaceParticipation	off	Opt into the future user-data marketplace. Not active.
aiTrainingDonation	off	Allow your data (after PII scrubbing) to contribute to AI training datasets. Not active.
piiDetection	off	Run local PII detection (no egress; this just scans). Not active.
derivedInsightGeneration	on	Mirror of the meta-cognition enrichment flag.

Every change to these flags is logged to memory/consent/consent-history.ndjson, append-only, with timestamps and the diff. Auditable.

The "no telemetry" guarantee

The README has said it since v1.0.0 and it remains true: no memory record leaves your device unless you have explicitly, granularly consented for that egress. The architecture has the hooks for future opt-in features, but the default state is zero outbound calls from the memory subsystem.

This is not promise-only; it's enforced by the code. Every network path the future phases will add must check the relevant flag before any outbound call. We test this in CI.

Soft delete vs. hard delete

Records have two delete modes:

• Soft delete: marks the record as deleted but keeps the row for audit purposes. Future reads filter it out; the metadata still exists.
• Hard delete: removes the row entirely. No audit trail.

Use soft delete by default. Use hard delete when you have a specific reason to expunge (e.g. a record contains data you don't want to keep at all).

Export everything

The Consent tab has an Export everything as JSON button. It produces a single JSON file containing:

• Every record in the inventory, with its metadata.
• Every memory document's byte-for-byte content.
• The full consent state.
• The complete consent-history audit log.

This is the local equivalent of GDPR/CCPA right-to-portability. It's also a backup. The file stays on your device, Cerevisor doesn't ship it anywhere.

See Exporting your data for the full walkthrough.

Marketplace primitives

Even though the marketplace isn't active, Cerevisor collects a few marketplace-fit structured datapoints sidecar to the prose memory:

• User structured facets: typed enums (seniority, company size, industries, etc.) you set in your profile.
• Workflow shape: one row per run capturing agent count, wave count, providers/skills/roles used, tool call counts, token counts, status, control-flow presence.
• Outcome alignment: machine-readable score for "did this run achieve what the user wanted?" Computed deterministically from the run's worked/didn't-work flags.
• Record quality: sidecar to each record showing reinforcement count and maturity (one-shot / reinforced / stable / user-confirmed).
• Memory bundles: the primitive a future marketplace would use to group records into a sellable bundle.

These exist in the schema today but are local-only. The Inventory tab surfaces them as compact rollup strips so you can see what's been collected.

When this matters

Today: it matters because you can audit what Cerevisor knows about you and export it any time.

Tomorrow: when future features add opt-in egress, the consent contract is already in place and grandfathered to default-deny. Nothing gets retrofitted onto an existing user base: every egress goes through this consent surface, granularly, per-purpose.