Evidence verification
Verify integrity against manifest/reference hashes; do not infer provenance or legal status.
Request schema from OpenAPI
| Field | Type | Required | Constraints | Technical definition |
|---|---|---|---|---|
manifestRef | string | Yes | {"minLength": 1, "maxLength": 128} | Proposed manifestRef field. Synthetic identifiers must not contain personal data. |
expectedHash | string | Yes | {"minLength": 1, "pattern": "^[a-fA-F0-9]{64}$"} | Expected SHA-256 of referenced content; agreement does not establish manifest authenticity. |
Read the operation and next actions
Errors and next actions
A consistent error envelope guides recovery without disclosing sensitive data.
Read detailsReliability, concurrency and recovery
Retry design follows the side effect rather than repeating every request blindly.
Read detailsAPI Explorer — local simulator
Explore requests/responses and failure scenarios using synthetic data; no backend connection.
Read detailsInput, scopes and processing
POST /v1/evidence/verification · scope evidence:verify. Tenant/project and correlation contexts are required. POST/PATCH use Idempotency-Key; examples/schemas below are proposed contracts.
States and outputs
CHECKED → MATCH / MISMATCH / INDETERMINATE. Simulator results do not verify actual files.
Exceptions and controls
Invalid hash formats return 422; insufficient permissions 403; missing reference evidence is INDETERMINATE.
HTTP example — proposed contract
Request
POST https://records.example.invalid/v1/evidence/verification HTTP/1.1
Authorization: Bearer <example-token>
X-Tenant-Id: synthetic-tenant-001
X-Project-Id: synthetic-project-001
X-Correlation-Id: synthetic-correlation-001
Idempotency-Key: synthetic-key-001
Content-Type: application/json
{
"manifestRef": "synthetic-manifest-001",
"expectedHash": "0000000000000000000000000000000000000000000000000000000000000000"
}Response · 200
{
"verificationRef": "synthetic-verification-001",
"integrity": "MATCH",
"provenance": "NOT_EVALUATED",
"legalStatus": "NOT_EVALUATED"
}Required fields and shared controls
| Item | Proposed rule |
|---|---|
| scope | evidence:verify |
| required | manifestRef, expectedHash |
| tenant / project | Token and context must match; headers alone are insufficient. |
| idempotency | POST/PATCH: same key/body returns original result; changed body returns 409; confirm retention window. |
| error | code, message, requestId, correlationId, retryable, details; no sensitive data. |
Continue the workflow
Two journeys, one records lifecycle
Connect paper and born-digital records through persistent identifiers, policies and evidence.
Read detailsIntegration quickstart
Exercise ingest → job tracking → registration → verification with synthetic data.
Read detailsIntegrity, provenance and evidence
Each evidence type answers a different question; hashes, timestamps and approvals are not interchangeable.
Read detailsStart with a verifiable scope.
Agree record classes, quality criteria, permissions and evidence before scaling.
Plan assessment