Transparency

What Systimus stores

Plain-language architecture. Written for engineers tracing data flows, not lawyers parsing legalese. The legal version lives at /privacy.

The short version

Systimus stores structural metadata about how you work — dimensions, distilled preferences, what was delivered and how it was received. It does not store your source code. The memory MCP is content-bearing by design: to build memories it receives your exchanges, and by default your AI extracts the memory-worthy facts on your machine and sends only those. When a client sends the full exchange instead, it is PII-redacted and the raw transcript is scrubbed after 30 days — only the distilled memory persists. Client-side usage tracking is the opposite contract — whether it reaches us through the transparent proxy or Claude Code's telemetry export, it sends token counts only, never prompt or response bodies. Sharing beyond your account is consent-scoped: for personal accounts, hivemind contribution is off until you switch it on; inside an organization, sharing is on by default but walled — org learnings never leave the org. Either way, only distilled, PII-redacted learnings move. Raw memories never do.

Everything below is the long version, tiered by what you opt into.

Two data surfaces

Systimus has two integration points with different data contracts. Understanding which is which is the prerequisite for everything below.

	Usage tracking (proxy or telemetry)	Systimus MCP server
What it sends	Parsed token counts, model, latency, session metadata	Full message content (via `systimus_push` / `log_exchange`)
Prompt/response bodies	Never written to disk, never sent to Systimus	PII-redacted server-side before distillation
Retention	Token-count events only	Raw transcripts scrubbed after 30 days; distilled memories persist
Purpose	Cost visibility — how much you used the model	Behavioral memory — what you discussed, distilled

Client-side usage tracking is optional. Without it, Systimus still attributes its own model spend — native chat and the MCP loop — to your work items; you just don't see what your AI client spends on its own provider account. Two routes add that external spend, both under the token-only contract above: the transparent proxy if you bring your own API key, or Claude Code's OpenTelemetry export if you are on a Pro/Max subscription — which ignores the proxy's ANTHROPIC_BASE_URL override, so the export is the only route that reaches it. The proxy reads token counts off billed responses and is labelled Exact; the telemetry export carries dollars Claude Code computes locally, so it is labelled Estimated.

Tier 1 — Personal sleeve, no OAuth (default)

This is what every account gets on signup. Nothing is connected yet.

What Systimus stores:

Your nine sleeve dimensions (0–100 scale) and the archetype they resolve to.
Distilled memories — substantive patterns extracted from conversation ("user is debugging a race condition," "user prefers concise responses").
Token usage totals for billing and rate limiting.
Session metadata: IP, user agent, timestamps for authentication.

What Systimus does not store at this tier:

Source code, file contents, or file paths from your machine.
Raw conversation transcripts past the 30-day scrub window.
Project names, company names, or ticket numbers — there is no integration to learn them from.

PII (emails, phone numbers, credit-card-shaped strings, SSN-shaped strings) is scrubbed from content before distillation runs. The memory corpus is yours alone. Nobody else sees it, and the server has no mechanism to surface it to anyone else.

Tier 2 — OAuth connected (GitHub, Jira)

You connect an outbound integration from the settings page. Read-only scopes only. You can revoke at any time; correlation stops immediately on revocation.

What changes when you connect:

Systimus can now correlate memories with tickets and PRs — repo names, ticket numbers, branch names, merge timestamps.
Cost-per-deliverable economics becomes possible. Without this, the server has no way to know which shipping artifact corresponds to which AI spend.
Work-output metadata is pulled on a schedule: PR titles, additions/deletions, review counts, merge state. Not the diff contents.

This is the opt-in that trades a bit of identifiable project context for economic visibility. If that trade is not worth it for your use case, the Tier 1 features continue to work.

Tier 3 — Team / Enterprise (hivemind)

When you belong to an organization, additional storage kicks in — governed by a consent model and hard architectural constraints. Here is exactly how it works.

What changes:

Your org gets a shared learning pool (the org hivemind), on by default and walled: learnings distilled from work on org sleeves flow into it, and nothing in it ever leaves your organization.
What flows is distilled only — PII-redacted behavioral learnings extracted from qualifying memories. Raw memories, conversations, and embeddings never cross the sleeve boundary.
Inbound is curated per insight: shared learnings arrive as pending items each member accepts, rejects, or blocks. Nothing writes itself into a sleeve.
The global commons (sharing outside your org, with unrelated users) is separate and doubly opt-in: an account-level switch plus a per-sleeve flag, both off by default. Switching the account toggle off retracts your prior global contributions.
Calibration runs can be aggregated across the team to surface patterns no individual could observe.

The 5-person floor on per-member data

Below 5 active members, Systimus withholds named activity signals and individual anomalies, and declines any time-shaped view of a small team. No one is singled out inside an aggregate. This is enforced at the query layer, not a toggle an admin can flip.

The team's own blended aggregate — total spend, deliverables shipped, task mix — still renders at any size: budgets do not stop mattering on a small team. Per-member economics are governed by each member's own consent tier rather than by headcount — the gate is the person's choice, at any team size.

What an admin can see is gated by the unit, not the number:

Work-item economics are the default. Admin dashboards show what a deliverable cost — per-work-item spend, deliverables shipped, average cost per deliverable, team totals. The unit is the ticket, not the person: Systimus never publishes which member a work item belonged to. Every active member counts toward these totals; tiers govern the resolution of what admins see about you, not whether the team's numbers include you.
Person-keyed data takes that person's consent. Raising your own tier broadens the admin/owner dashboard to named signals, narratives, and named per-member economics — your cost per deliverable, your drift from the team average. Only the member can raise their own tier; no admin can raise it for them. Peers never see another member's metrics, at any tier.
Time-keyed views of a person exist at no tier. Daily or hourly spend, activity timelines, who-worked-when: consent cannot unlock them, because the product does not compute them for any audience.
What the tiers govern is what Systimus computes and displays. Your organization's own tracker knows who was assigned each work item — Systimus does not repeat that mapping, but it cannot stop an org from joining data it already owns.

Active controls — things you can do

Ignore rules. Exclude specific patterns from distillation entirely. The distiller skips matching content before anything persists — not after.
OAuth revocation. Disconnect GitHub or Jira at any time. Correlation stops immediately. Historical correlations remain linked to the memories that observed them.
Memory deletion. Individual memories can be deleted from the intelligence page. Deletion removes the record and its embedding.
Account deletion. Starts a 30-day grace window, then a hard purge: messages, conversations, memories and their embeddings, calibration runs, activity signals, sessions, and integration connections are erased — a regression test asserts zero rows remain. Deliberately retained: sleeve configuration rows and their version history, revoked API-token digests, redacted audit logs, subscription records, and hivemind learnings other users already accepted, which persist in their sleeves marked source-retracted.
Hivemind contribution is switchable and retractable. Contribution to the global commons requires an account-level switch plus a per-sleeve flag, both off by default; switching the account toggle off retracts your prior global contributions. Inbound learnings always land as pending items you curate.

Architecturally impossible

These are not policy positions. They are properties of the system that require rewrites to change:

Systimus cannot reconstruct source code from stored memories. The memories are structural abstractions over behavior, not copies of your files.
Systimus cannot render named per-member signals for a team below 5 active members, and cannot render a time-keyed view of any individual at any size or any tier. Both refusals are enforced at the query layer, for every role — owner and admin included.
Systimus cannot use your conversation content to train models. It is not pushed to any training pipeline — ours, the model vendor's, or otherwise.

Per-member visibility is deliberately not on this list: it exists, gated by the member's own consent tier as described above. We claim "impossible" only where the system makes it so.

If this page left a question unanswered, that is a gap worth closing. Open an issue, DM, or email — a specific missing assertion is more useful than a general concern, and we will add it here if the answer is simple enough to commit to publicly.