Submit source
You upload a ZIP or provide a supported public GitHub repository.
Source content
PRIVACY FIRST
Your code is processed. Your code is not kept.
CodeSeal is designed to retain signed provenance evidence—not a private archive of submitted source repositories.
THE CORE PRIVACY RULE
Source in. Fingerprints out. Source destroyed.
A ZIP upload or temporary GitHub checkout exists only long enough to safely extract/scan supported source files and calculate technical fingerprints. The source working copy is deleted before the scan-result page is returned.
01
DATA LIFECYCLE
What happens from upload to future comparison
→
Fingerprint safely
CodeSeal extracts/reads supported files, calculates SHA-256 evidence, structure, and package fingerprints, and never executes submitted code.
Temporary working copy
→
Destroy source
The uploaded archive, extracted files, or Git checkout is removed. Registration and forensic review continue from evidence only.
Source deleted
→
Sign evidence
If you register, CodeSeal creates PTCS IDs, timestamps the observation, signs the manifest, and returns the signature/evidence package to you.
Signed evidence
→
Keep provenance record
The registry retains hashes, file paths, PTCS identifiers, timestamps, structural/package fingerprints, signed event metadata, and protected signer fields.
No source contents
→
Compare new submissions
A later ZIP or repository is fingerprinted independently. Its fingerprints are compared with historical evidence already in the registry—not with somebody else's stored source code.
Evidence ↔ evidence
Temporary processing laneDESTROYED
- Uploaded ZIP bytes
- Extracted source files
- Temporary public GitHub checkout
- Temporary working directories
These materials are needed to calculate evidence and are not the historical record.
Provenance evidence laneRETAINED
- Per-file SHA-256 fingerprints and relative paths
- Package and structural fingerprints
- PTCS Application / Event / Seal identifiers
- Observation time and source-origin metadata
- Signed manifest, registry signature, and public verification key
- Protected signer metadata and optional encrypted notification contact
- Forensic match/audit/notification-trace events
This evidence is what allows future submissions to be compared without retaining the original source code.
CodeSeal returns your evidence
You receive the PTCS identifiers and Ed25519 registry signature and can download the signed evidence JSON. CodeSeal keeps the corresponding historical evidence so the event can later be verified.
Their source is scanned independently
CodeSeal calculates a fresh evidence set, then checks those hashes against prior registry fingerprints. Exact, relocated, modified, missing, and new-file relationships can be identified without recovering the prior source tree.
History is evidence, not an accusation
A match can append a later observation, create a forensic comparison, and—when the earlier registrant opted in—queue a provenance alert. CodeSeal does not declare infringement or determine who legally owns the code.
02
IDENTITY & CONTACT
Public history is intentionally limited
Public/basic history
Application history, PTCS identifiers, observation timestamps, source-origin context, and limited organization context where appropriate.
Protected provenance metadata
Signer name, email, and address are not published in the free/basic history experience. Signer identity remains explicitly labeled self-declared until a future verification capability exists.
Notification contact
When future-match tracing is enabled, the contact email is stored separately in encrypted form for alert routing and is not displayed in public history.
AUDITABILITY
Registry activity leaves evidence too.
Phase 5 records provenance audit events for registrations, material prior-source matches, notification enrollment/queue activity, signed-evidence downloads, and forensic-report access. This establishes the foundation for later authenticated and paid-report audit trails.
03
PASSWORDLESS ACCOUNT DATA
Authentication without a password database
Verified email
Your email is the CodeSeal account identifier. Magic links are short-lived and single-use. CodeSeal does not create or store an account password.
Authenticator secret
If you enable TOTP, the authenticator seed is encrypted at rest and never appears in public history. Recovery codes are shown once and only hashed copies are retained.
Private workspace
Authenticated registrants can view their linked seals and trace activity without making protected contact or authentication information part of the public registry view.
04
PRODUCTION STORAGE BOUNDARY
Production history must survive the container.
Managed registry database
Local SQLite remains a development convenience. Production mode refuses local SQLite and requires managed PostgreSQL-compatible persistence so CodeSeal history is not lost when a Cloud Run container is replaced.
Secrets outside the image
Registry signing material, protected-data encryption keys, session secrets, database credentials, and mail credentials are designed for runtime secret injection rather than container-image storage.
Source still remains ephemeral
Moving registry evidence to managed persistence does not change the source-handling rule: submitted source content is temporary working material and is not the durable history record.
05
TRANSIENT DATA LIFECYCLE
Temporary processing data has an expiration path.
Source working copies
Upload and repository working areas are transient processing locations. Phase 8 adds lifecycle cleanup for expired working/session material in addition to normal post-scan deletion.
Authentication metadata
Expired/used magic-link records and old authentication-attempt metadata have configurable retention windows. CodeSeal does not need to keep transient login mechanics forever to preserve provenance history.
Provenance history is different
Signed PTCS observations, fingerprints and audit evidence are the durable registry record. Lifecycle cleanup explicitly does not delete provenance events.