Prove who approved access, why, and what was checked.

Every action on a case appends a row to a hash-chained audit log. Submission, screening completion, reviewer assignment, note added, info request issued, match resolution, approval, denial, conditional approval, expiration — each shows up as a timeline entry with who acted, in what role, and when.

The timeline is append-only by design. Update and delete are blocked at the data layer even for elevated service contexts, and each row carries a SHA-256 link to the previous row in the same tenant. A tampered or deleted entry breaks the chain detectably.

Each case records the screening run that drove the decision: the source families queried, when the run executed, the potential matches surfaced, and the configured policy outcome. Screening integration has been validated in controlled testing; production screening is available for configured pilot tenants under a written scope.

The evidence pack carries the structured screening summary — counts, source families, policy outcome — not third-party screening source data. Raw responses from external providers are excluded from the pack by design.

Configured policy outcomes are evaluated against the screening run and any open matches. The evidence record names which policy was applied, what its threshold or severity was, and the resulting gate state — passed, blocked, or pending reviewer resolution.

Policy state moves with the case. A reviewer cannot approve a case while the configured gate is blocking. The evidence pack captures the gate state at the moment of decision, not just the final outcome.

Every potential match is resolved explicitly by a reviewer: false positive, confirmed, escalated, or resolved by policy exception. The resolution carries the reviewer's rationale and is written to the audit timeline alongside the match itself.

Match resolution is not summarized away. The evidence pack lists each match (by structured identifier), the resolution classification, and the reviewer who applied it — so an assessor can read the case without asking how a flag was disposed.

The decision history captures the path from submitted request to final outcome. Reviewer assignments, info requests, notes, step approvals, the final approve / deny / conditional / expire action, and any post-decision changes (re-screening results, expiration) all live on the case.

Every case can export an evidence pack in three forms: a JSON manifest covering the full decision chain, an optional PDF summary suitable for sharing with an assessor or auditor, and an optional ZIP package combining both. Packs can be exported on the day of the decision, six months later, or in response to an inquiry.

The hash-chained audit log behind every pack means the record can be verified as unmodified after export. The evidence pack is the deliverable.

{
  "case_id": "00000000-0000-0000-0000-000000000000",
  "organization_id": "00000000-0000-0000-0000-000000000000",
  "status": "approved_with_conditions",
  "counts": {
    "audit_rows": 14,
    "matches": 2,
    "match_resolutions": 2
  },
  "audit": {
    "first_row_hash": "abc123…",
    "last_row_hash":  "def456…"
  },
  "timestamps": {
    "intake_submitted": "2026-05-25T09:42:00Z",
    "screening_completed": "2026-05-25T09:42:11Z",
    "decision_recorded":   "2026-05-25T11:18:43Z"
  }
}

Evidence packs carry the structured decision record. They do not include third-party screening source data, and they do not bundle document originals (passports, visas, sponsorship letters). Document originals stay behind signed URLs on the case record so reviewers can open them in-product without inheriting them into every exported pack.

The audit log itself is PII-free by design: names, emails, passport text, document filenames, IP addresses, and user-agent strings are not written into audit rows. What the audit log carries — who acted, in what role, on which case, what the outcome was, and when — is precisely the evidence an assessor or auditor needs.

Access approval evidence is what Regulated Access is built to produce. The product is commercial pilot ready and available for configured pilot tenants under a written scope.

Federal-readiness is a separate track. SecurePoint is not claiming federal authorization, agency-specific deployment boundaries, or formal compliance attestation today. See the security page for the current operating scope.