Evidence Pipeline

• Documents — PDF, DOCX, XLSX, PPTX, ODF, plain text, Markdown.
• Images — PNG, JPEG, WebP (screenshots, photographs of physical controls).
• Logs & data — CSV, JSON, YAML, TSV.
• Archives — ZIP (inspected, macros disabled on upload).

Executables, scripts, and unknown MIME types are rejected at the edge before any bytes are persisted.

1. Upload — multipart/form-data POST to /api/evidence/upload. MIME type is checked against a whitelist and magic bytes are validated; size capped at 50 MB.
2. Hash — server computes SHA-256 over the raw bytes and stores it on the Evidence row.
3. Store — written to Supabase Storage at evidence/{orgId}/{evidenceId}/{filename}. The path is derived from the server-resolved org — never from client input.
4. Metadata row — Evidence record captures uploader, collected date, effective date, framework tag, and optional description.
5. Map to controls — one evidence record can satisfy many controls via ControlEvidence. Cross-framework mappings surface suggestions.
6. Review — a user with the Compliance Officer or Admin role approves or rejects. Decisions, comments, and timestamps are audit-logged.
7. Export — the Audit Package builder bundles approved evidence for a framework scope into a signed ZIP with a manifest.json (file list, hashes, control mapping, signer, export time).

An approved evidence record is immutable. Re-uploading a newer version creates a fresh record and marks the old one SUPERSEDED; auditors can walk the chain via the linked history on the control page.

• Upload — Member and above.
• Map / unmap — Control Owner (for owned controls), Compliance Officer, Admin, Owner.
• Approve / reject — Compliance Officer, Admin, Owner. Risk Manager can approve for risk-linked controls.
• Download — any role with read on the parent Control; each download issues a fresh 1-hour signed URL.
• Delete — Admin / Owner only; always soft-delete first.

Default retention is seven years, configurable per framework (e.g. a tighter window for GDPR-scoped artifacts). Deletion is a two-step process:

1. Soft delete — record moves to a retention holding area; file remains in storage; visible in audit log.
2. Purge — after the hold period, a scheduled job removes bytes from storage and writes the final audit entry with the pre-purge hash for forensic continuity.

• 400 invalid_mime — MIME type not on whitelist.
• 400 magic_mismatch — file extension disagrees with detected bytes.
• 413 too_large — exceeds 50 MB.
• 409 hash_exists — identical file already uploaded; server returns the existing record id.
• 403 wrong_org — attempted access to evidence outside active org.
• 410 purged — retention window expired; the hash remains but bytes are gone.