Evidence Register¶
| Field | Value |
|---|---|
| Status | draft |
| Owner | DIR |
| Applies to | All evidence that supports a Partile control: where it lives, how long it is kept, and whether it belongs in Git (Tier 1) or the restricted store (Tier 2). |
| Review cadence | Annual, or when a new evidence type is introduced. |
| Mapped controls | GOV-01, GOV-03 (the upkeep/accountability spine); supports every control's "Evidence" column. |
| Evidence | This data room; ../README.md two-tier rule; ../policies/data-classification-and-handling-policy.md. |
Purpose¶
Make the two-tier evidence model concrete: for each kind of audit evidence, state where it lives, how it is retained, and why. The control register's evidence links resolve into the types below.
Tiering rule (recap)¶
- Tier 1 (Git, here): governance evidence with no secrets/PII — policies, registers, control statements, design docs, code references, test results summaries.
- Tier 2 (restricted store, not in repo): evidence that itself contains secrets, PII, or sensitive operational detail. Git points to it.
Evidence types¶
| Evidence type | Tier | Where it lives | Retention | Notes |
|---|---|---|---|---|
| Control register & registers | 1 | dataroom/ in Git |
Life of project; Git history | The spine; per-PR upkeep |
| Policies & procedures | 1 | dataroom/policies, dataroom/procedures |
Life of project; versioned | Review cadence per header |
| Technology diligence pack | 1 | dataroom/technical/ |
Life of project; per-subject upkeep | Current-state narrative for reviewers; references controls/policies, no secrets |
| Readiness narrative docs | 1 | director-root readiness/*.md |
Life of project | Referenced by name as evidence |
| Code references / PRs | 1 | idea worktrees (partile-infra, …); Git |
Git history | Cited as repo: path:line / PR id |
| Test / smoke results | 1 | CI logs + summary in PR/notes | Per CI retention; summary in Git | e.g. safety_smoke.py, rate_limit_smoke.py, mobile npm run test:parser synthetic BCBP parser tests, mobile npm run test:selectors selector-contract check, mobile npm run test:automation hard-gated seam check, mobile npm run test:maestro Maestro flow static validation |
| Sanitized manual mobile QA summaries | 1 | PR notes/reflections and this data room | Life of project; Git history | Pass/fail summaries only. No build links, device IDs, tokens, real pass images/payloads, PNRs, passenger details, or account identifiers. |
| Decision log entries | 1 | READINESS.md |
Life of project | GOV-01 |
| Access review records | 2* | restricted store | ≥ 1 year rolling | *Non-identifying summary may be Tier 1 |
| DSAR / erasure request records | 2 | restricted store | Per statutory + retention policy | Pointer-only in registers/dsar-log.md |
| Incident records & post-mortems | 2 | restricted store | ≥ 1 year (longer if breach) | Non-identifying summary in registers/incident-log.md |
| Signed DPAs / contracts | 2 | restricted store | Life of contract + tail | Pointer in registers/subprocessors.md |
| Pentest reports (exploit detail) | 2 | restricted store | Life of project | Summary/remediation status Tier 1 |
| Secrets / credentials | — | env / GCP Secret Manager / local operator secret stores | n/a | Never evidence in any repo; labels only |
| Cloud state / operational console evidence | 2 | GCP console, private GCS Terraform state bucket, Cloudflare console, restricted screenshots/logs | Per operational need; do not retain secrets beyond necessity | Terraform state can contain generated secret material; Tier 1 may record only safe labels and summaries |
| Vendor security assurances (SOC2/ISO of vendors) | 2 | restricted store | While vendor active | Referenced in vendor diligence |
| Entity / contact / account IDs | 2 | restricted store | n/a | Not in Git |
Git vs restricted — the test¶
If an artifact contains a secret, real personal data, sensitive operational detail, exploit specifics, or counsel-private advice → Tier 2 (restricted). Otherwise, if it proves a control without exposing those → Tier 1 (Git). When unsure, treat as Tier 2 until reclassified by a DIR decision.
Retention of evidence¶
Evidence is kept long enough to demonstrate the control operated over the audit
period (typically a rolling ≥ 12 months once operational), and longer where law
requires (e.g. breach records). Tier-2 evidence retention is reconciled with the
data retention schedule and erasure obligations
(../policies/privacy-and-retention-policy.md).
Restricted store¶
Location: [to be designated] (Tier 2). Until designated, no Tier-2 evidence is generated at volume (pre-beta, no real users); the pointer registers are ready to receive references when it exists.