Skip to main content

Transparency

What Praxis stores

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

The short version

Praxis 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. It does not store the contents of your conversations verbatim. It does not share your personal memories with your team unless you explicitly broadcast them.

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

Tier 1 — Personal sleeve, no OAuth (default)

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

What Praxis 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 Praxis 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:

  • Praxis 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 — but with architectural constraints that make certain things not just policy-restricted, but impossible.

What changes:

  • Your org gets a shared memory corpus (the hivemind). Members can choose to broadcast specific memories into it.
  • Broadcast is opt-in per memory. Not a global toggle, not an auto-publish default.
  • Calibration runs can be aggregated across the team to surface patterns no individual could observe.

The 5-developer aggregate floor (architectural)

Team dashboards never surface data about fewer than 5 developers. Below that threshold, individual patterns are identifiable from aggregate output — so the aggregation pipeline refuses to produce a result. This is an architectural constraint enforced at the query layer, not a toggle that can be flipped by an admin.

The reason to do this architecturally rather than as a setting: epistemic hygiene. Below 5 developers, the statistics are neither privacy-safe nor meaningful. The floor doubles as a quality filter.

Explicit non-surveillance posture:

  • Managers cannot pull per-contributor reports. The data model does not expose individual rows to team-scope queries.
  • Per-user analytics that do exist (personal dashboards) are visible only to the user themselves.
  • Praxis made the explicit architectural choice not to surface per-actor identity to org admins. Not every platform in this category makes the same choice; we did.

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. Wipes everything in dependency order: messages, conversations, memories, sleeves, API tokens, sessions. Irreversible.
  • Hivemind broadcast is per-memory. Default is private-to-you. Choosing to share is an active decision per memory, not a global setting.

Architecturally impossible

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

  • Praxis cannot reconstruct source code from stored memories. The memories are structural abstractions over behavior, not copies of your files.
  • Praxis cannot surface a single contributor's data to org admins. The aggregation layer refuses to return results for populations smaller than 5.
  • Praxis cannot auto-publish personal memories into a team hivemind. Broadcast requires a per-memory action by the memory's owner.
  • Praxis cannot use your conversation content to train models. It is not pushed to any training pipeline — ours, the model vendor's, or otherwise.

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.

Are you sure?