Purpose
Preserve event, decision, context and evidence-package trails.
PLATFORM · CHECKID
Audit & Evidence
Preserve event, decision, context and evidence-package trails.
CAPABILITYInput → Processing → Output
CONTROLPolicy · risk · standard
EVIDENCEResult · trace · scope
PLATFORM
Audit & Evidence
Preserve event, decision, context and evidence-package trails.
Trust boundary
Capability is published only within source/evidence scope.
Developer integration
SDK · REST API · evidence contract
↗TECHNICAL REFERENCE
Evidence architecture: reconstructing a decision, not merely storing logs
Business evidence ≠ operational log ≠ security log
Evidence taxonomy
Current documentation distinguishes input evidence, source-verification evidence, biometric/PAD results, policy/decision evidence, audit events, operational logs and security logs. These artefacts have different purposes, access boundaries and retention requirements.
Source-backed identifiers
The API catalog supports identifiers such as subject ID, process ID and billcode/transaction references in selected operations. They are correlation anchors; Public documentation does not invent an `evidence_id` or unpublished schema.
Conceptual evidence envelope
A due-diligence evidence package should identify subject/process, method/source, result, time, policy/version, processing context, integrity metadata and retention class. Any unsupported field is labeled conceptual — not API schema.
Integrity controls
Hashing, digital signatures, trusted timestamps/TSA, immutable storage or archival are described as implementation only when an architecture/evidence source supports them. The existence of an audit page does not establish immutability.
Audit use cases
Evidence should support dispute handling, transaction review, investigation, regulatory inspection and customer support within authorized scope. A UI screenshot is not a substitute for machine-readable evidence or provenance.
Disclosure boundary
Evidence can contain sensitive identity or biometric data. Public documentation explains metadata and responsibility boundaries without publishing personal data, secrets or internal forensic detail.
EVIDENCE & AUDIT ARCHITECTURE
From source provenance to decision trace
The Evidence Architecture distinguishes input data, verification results, decision evidence, audit events and operational/security logs. They are not collapsed into one “audit log”.
| Concept | Implementation mapping | Boundary |
|---|---|---|
| Subject | Subject object/identifier in CheckID API | Not automatically a verified identity |
| Process | Process ID/type/purpose/status | A subject may contain multiple processes |
| Transaction correlation | Billcode/process identifiers where exposed | No invented global correlation ID |
| Verification result | Process-specific result context | Not automatically final business decision |
| Integrity/retention | Published only when sourced | No immutable/tamper-proof claim without evidence |
Audit reconstruction
A reviewer should trace subject → process → evidence/source → verification result → policy/decision to the extent source linkages exist.
Evidence export
Export/package capability is published only when an API/product source confirms it; no hypothetical forensic package is promised.
Integrity
Hashes, digital signatures, TSA, immutable storage and archives are distinct mechanisms; only Tier-1-sourced mechanisms are claimed.
Use cases
Evidence may support disputes, investigations, audits, regulatory inspection and support where scope/retention permit.