How Mneme handles your repository data
The Mneme Architecture Audit analyses repository material to identify which documented architectural decisions are currently protected, potentially protectable, require additional modelling, or remain guidance. This page explains what data the Audit receives, where it goes, what is retained, and how it is deleted.
Version 1 · Last updated: 10 September 2026 · Describes the hosted Audit at mnemehq.com
The short answer
Your repository is processed by a deterministic analysis engine — the same open-source Mneme engine that runs locally — on Mneme infrastructure. Original repository files are working material: they are extracted to a temporary directory, analysed, and deleted when the audit finishes, whether it succeeds or fails. What survives is the audit result: the architectural decisions it discovered, their classifications, and the proposed guardrails.
Repository material is never sent to an external AI model provider. The Audit does not train models on your code. There is nothing to train — the analysis is deterministic.
What the Audit receives
The hosted Audit accepts two input methods — matching what is actually implemented today:
- Public GitHub repository URL. The Audit clones the public repository server-side. No GitHub account, OAuth, or token is involved; only material that is already public is received.
- ZIP upload. You prepare a ZIP of your repository and upload it in the browser. Recommended: exclude
.git,node_modules, build artefacts,.envfiles, credentials and other secrets before packaging.
The Audit also offers a demo repository (a public sample repo) if you want to see the output before submitting anything of your own.
Ingestion is bounded: maximum archive size 50 MB, maximum 2 MB per file, maximum 10,000 files, and a bounded clone window. Malicious archives (path traversal, symlinks pointing outside the working directory, zip bombs) are rejected.
Private repository credentials are not accepted today. There is no GitHub App, no OAuth flow, and no token field. When repository integrations that require credentials are introduced, their handling will be documented here before launch.
Where processing happens
The Audit API runs on Google Cloud Run in region us-central1 (Iowa, United States), with its database on Google Cloud SQL PostgreSQL in the same region. All public transport is encrypted (HTTPS/TLS). Data at rest in Cloud SQL is encrypted using Google Cloud's default storage encryption.
Processing happens in a fresh temporary working directory created for each audit on the Cloud Run instance filesystem. No customer repository is written to persistent storage as source material.
How the analysis works
The analysis is performed by Mneme's open-source engine — deterministic parsing and classification, no machine learning, no inference calls. It reads the architectural-intent sources in your repository:
- ADRs (Mneme's canonical format plus common loose ADR formats)
- Agent instruction files such as
CLAUDE.mdandAGENTS.md - Architecture documentation
- Configuration evidence (
pyproject.toml,requirements.txt, CI workflow files, Makefiles, and similar) - An existing
.mneme/project_memory.jsonif present
The engine's classifications are deterministic: the same governed inputs, Mneme version, and configuration produce the same classifications and verdicts. Audit identifiers and timestamps vary per run, and the surrounding pipeline is code-inspected rather than formally validated for bit-exact reproduction. The engine source is public on GitHub — you can verify what it does with your files, and you can run the identical analysis locally with the open-source CLI, which never leaves your machine.
Mneme does not use customer source code to train models.
There is no training pipeline in Mneme, and no external model provider in the Audit processing path. Repository content submitted to the hosted Audit does not reach any AI model, API, or training corpus.
Transient source data
Cloned repositories and extracted ZIP contents live only in the per-audit temporary directory. That directory is deleted when the audit completes — including when the audit fails. The uploaded ZIP archive is deleted after Audit processing.
Original file contents are not persisted, not copied to object storage, and not kept "for later".
What is retained: the audit result
What the Audit keeps is the result, not the repository:
- The discovered architectural decisions: title, requirement text as written in your decision documents, and the source file path and line reference each came from
- Each decision's classification: Protected, Mneme-ready, Requires modelling, or Guidance
- Proposed Mneme guardrails where a deterministic one exists
- Summary counts and protection metrics
- The repository identity you submitted (public GitHub URL, or "upload" for ZIP submissions)
- Timestamps and audit metadata
If you save a baseline, the audit result is persisted as a project record tied to the repository identity so you can re-audit and compare over time. Baselines are immutable; re-audits create new snapshots linked to the same project.
You can export any audit result as Markdown or JSON. Exports are generated from the stored result — exporting does not give Mneme any additional access to your repository.
Logs
Application logging is intended to capture operational metadata only: request timestamps, status codes, durations, and error classifications needed to operate and debug the service. Filenames and source paths appear in the audit result itself (that is the product); they are not intended to be echoed through infrastructure logs.
This is a code-inspection statement, not a runtime audit. The logging framework writes exception traces, and those traces can contain repository paths or filenames when processing fails. A runtime log audit and, where needed, log sanitisation are P0 engineering tasks on the trust track; until they are complete, treat this section as pending verification.
If you identify a case where repository content reaches Mneme's logs, report it — we treat that as a security defect.
Credentials and tokens
The hosted Audit does not collect, store, or process any repository credentials. There is nothing to leak because there is nothing accepted. See What the Audit receives.
Who can access what
Mneme HQ is a small, founder-operated company. The audit database is accessible only to Mneme HQ operators for the purpose of operating and supporting the service (for example, helping a design partner interpret a result). There is no formal access-control certification, no customer-facing audit log of internal access, and no dedicated security team — yet. Those are enterprise-track items on the roadmap, not current facts, and we won't describe them as current facts.
Isolation
The hosted Audit runs on shared hosted infrastructure: all audits are processed by the same service, and records are referenced by unguessable identifiers. There are no user accounts. There is no per-customer infrastructure isolation today; enterprise isolation guarantees are a future capability, not a present one.
Retention and deletion
Audit records are retained until deletion is requested. There is no automated expiry of audit records yet — a defined default retention window is on the enterprise-track roadmap, and this page will be updated when it exists.
To request deletion of an audit record or project (including baselines), email [email protected] with the audit ID or repository URL. Deletion is currently a manual process — we remove the record from the primary database and confirm the deletion to you. A normal in-application deletion path and a tested deletion runbook are pending P0 tasks on the trust track.
Backups: the database has automated backups. A deletion removes the record from the live system immediately; residual copies in backups expire on the backup schedule rather than being surgically removed.
Third-party services and infrastructure providers
Providers that may touch repository-derived or customer information in the hosted Audit flow. We call this list "providers" rather than "subprocessors" deliberately: which parties are legally processors, subprocessors, or independent controllers follows from the contractual and legal review in progress, not from code inspection.
| Provider | Service | Data involved | Location |
|---|---|---|---|
| Google Cloud | Cloud Run (Audit API) + Cloud SQL (PostgreSQL) | Repository material during processing; audit results at rest | us-central1 (US) |
| GitHub | Public repository clone source | Public repository content you point the Audit at | Global |
| Cloudflare | CDN / edge for mnemehq.com | Website traffic (not audit payloads) | Global edge |
| Formspree | Pilot request form delivery | Contact details you submit on the pilot form | US |
| Google Tag Manager / Analytics 4 | Website analytics (see Privacy Policy) | US and EU |
No AI model provider receives repository material, in any capacity.
Encryption
- In transit: HTTPS/TLS on the public endpoints (website and Audit API).
- Cloud Run → Cloud SQL: traffic is protected through Google Cloud's managed Cloud SQL connectivity; the Cloud SQL Auth Proxy connection is TLS-encrypted by design.
- At rest: Google Cloud default storage encryption for Cloud SQL; transport-level encryption elsewhere where repository material is transient.
What we can and cannot say yet
We would rather publish a shorter list of true statements than a longer list of aspirational ones. Each statement below carries one of three verification states:
Verified — technical demonstrated by code/infrastructure inspection of what ships today · Code-inspected implementation checked, runtime/process audit still pending · Not yet does not exist today
| Statement | Status |
|---|---|
| "Mneme does not use customer source code to train models." | Verified — technical |
| "Repository material is never sent to an external model provider." | Verified — technical |
| "Original repository files are deleted after each audit completes." | Verified — technical |
| "Repository credentials are never stored — none are accepted." | Verified — technical |
| "Repository file contents do not appear in application logs." | Code-inspected — runtime logging audit pending (P0) |
| "Audit records are deleted on request from the live system." | Code-inspected — manual process; in-app deletion path and tested runbook pending |
| "Source content is automatically deleted after a fixed retention window." | Not yet — no automated expiry exists |
| "Independent penetration testing has validated this page." | Not yet — on the enterprise roadmap |
| "SOC 2 / ISO 27001 certified." | Not certified — no claims made |
Incident handling and vulnerability reporting
Report security issues or vulnerabilities to [email protected] with the subject line "Security". Include reproduction steps where possible; encrypted disclosure channels and a dedicated security address are being established as part of the enterprise trust track.
If an incident affects customer repository material or audit records, then where we hold contact details for you and notification is required or appropriate, we will contact affected users directly and state what happened, what data was involved, and what changed. For anonymous audits (no contact details attached), we would publish notice on this page.