Controlled metadata updates
Create correction requests with expectedVersion/reason; do not silently edit declared records.
Request schema from OpenAPI
| Field | Type | Required | Constraints | Technical definition |
|---|---|---|---|---|
expectedVersion | integer | Yes | {"minimum": 1} | Proposed expectedVersion field. Synthetic identifiers must not contain personal data. |
reason | string | Yes | {"minLength": 1} | Proposed reason field. Synthetic identifiers must not contain personal data. |
metadata | object | Yes | {"minProperties": 1} | Proposed metadata field. Synthetic identifiers must not contain personal data. |
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
PATCH /v1/records/{recordId}/metadata · scope records:metadata. Tenant/project and correlation contexts are required. POST/PATCH use Idempotency-Key; examples/schemas below are proposed contracts.
States and outputs
REQUESTED → REVIEW → APPROVED → VERSIONED. Retain previous versions and audit.
Exceptions and controls
Version conflicts return 409, field/schema defects 422, insufficient metadata permissions 403.
HTTP example — proposed contract
Request
PATCH https://records.example.invalid/v1/records/{recordId}/metadata 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
{
"expectedVersion": 1,
"reason": "synthetic correction",
"metadata": {
"title": "Synthetic record"
}
}Response · 202
{
"jobId": "synthetic-job-003",
"status": "REVIEW_PENDING",
"correctionRef": "synthetic-correction-001"
}Required fields and shared controls
| Item | Proposed rule |
|---|---|
| scope | records:metadata |
| required | expectedVersion, reason, metadata |
| 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