---
title: "Data inventory & consent"
description: "What Cerevisor knows about you, classified by data type, and the consent system that gates any future egress."
slug: guides/memory-and-learning/data-inventory-and-consent
section: guides
subsection: memory-and-learning
canonical_url: https://cerevisor.com/docs/guides/memory-and-learning/data-inventory-and-consent
last_verified: 2026-05-18
last_verified_version: "1.2.0"
updated_at: 2026-05-18T15:08:18.053416+00:00
---

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](./exporting-your-data.md) 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.