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: every consent flag for egress defaults false and there are zero outbound network paths from the memory subsystem. The inventory exists because future versions may add opt-in egress (for example, privacy-preserving aggregate sharing), 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 automatic scanner behind this flag is still being built out; today records stay unknown until 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 privacy-preserving aggregate sharing (a future opt-in feature; not active today).
Marketplace listable	Eligible for inclusion in a user-created marketplace bundle (a future opt-in feature; not active today).

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 flags, in two groups.

Egress (off by default):

Flag	Default	What it would enable
Share aggregate metrics with Cerevisor	off	Send aggregate metrics about your usage to Cerevisor for analytics. Not active.
Donate to AI training	off	Allow your data (after PII scrubbing) to contribute to AI training datasets. Not active.

(A third egress flag, marketplace participation, exists in the consent schema for the future marketplace direction; it also defaults off.)

Local processing (on by default — never causes egress):

Flag	Default	What it does
PII detection on memory records	on	Local-only annotation of records that may contain third-party PII. Nothing is sent anywhere.
Derived insight generation	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.

The complete list of network calls Cerevisor makes

The memory guarantee above covers your data. For full transparency, here is every network call the app itself makes — there are exactly two, both first-party, and neither carries any of your content:

1. Update check — on launch, Cerevisor asks releases.cerevisor.com whether a newer version exists. This discloses your IP address and current app version, nothing else. You can turn it off in Settings → Updates → "Check for updates automatically"; with it off, the app makes no network calls at launch, and the manual "Check for updates" button still works whenever you choose to use it.

2. License validation (paid licenses only) — when you activate a license, and once a day while it stays activated, Cerevisor sends your license key and an instance id to api.lemonsqueezy.com (our payments provider) to confirm the license is valid. No usage data, no content, no personal details beyond what you provided at purchase. If the license server is unreachable, your paid features keep working for a 14-day offline grace period. If you never buy a license, this call never happens.

That's the whole list. Everything else — your workflows, runs, memory, skills, settings — stays on your device. Calls your agents make to AI providers happen only with the API keys and providers you configured, when you run a workflow.

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 Inventory 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.

Structured datapoints

Alongside the prose memory, Cerevisor collects a few structured datapoints that make your memory filterable and queryable:

• 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: a primitive for grouping records under a shared consent scope (reserved for a future opt-in feature; not active today).

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.