Govern
Record/version, authority, retention and holds
Trusted Records · Integration & Developer
LTANS and evidence-preservation integration
The Records–provider boundary covers validation, profiles, receipts, status and export. Website contracts are design proposals, not Mobile-ID LTANS APIs.
Content, usability and evidence
Store content
Source bytes, replicas, locations and operator permissions
Preserve usability
Formats, representation information, migration/lineage
Preserve evidence
Contract-specific validation, profiles, receipts, renewal and verification
Backup / DR
Restore operations without replacing preservation layers
LTANS — long-term evidence preservation
Connect records lineage to Mobile-ID’s published LTANS capability; agree the Records configuration in a contract and profile.
Read detailsPreservation Profile Center
Choose preservation configurations by record class, designated community and required evidence. Illustrative profiles are not approved service offerings.
Read detailsPreservation standards and evidence
Standards → controls → workflows → contracts → evidence. Reference design mappings rather than Trusted Records certification.
Read detailsService Playground — task-based experience
Exercise a records workflow with forms, requests/responses and a timeline. Use synthetic data in offline simulation or a local HTTP mock.
Read detailsVerified source boundary
Mobile-ID lists LTANS Archiving in its TrustedHub brochure. Records connectivity, storage models, profiles and detailed API/SDK contracts are unverified.
TrustedHub · Mobile-ID ↗Workflow control points
| Stage | Decision | Evidence and exceptions |
|---|---|---|
| Admission | Are validation/hashes/profiles eligible? | Quarantine mismatches; do not submit to the provider |
| Provider submission | Correct storage model, scope and request reference? | Timeout: query before retry; retain INDETERMINATE |
| Receipt recording | Does binding match record/version/hash/profile? | Missing/mismatched receipts cannot become VERIFIED |
| Monitoring | Does policy/crypto/format require strengthening or migration? | Retain old/new evidence lineage; escalate failures |
| Export | Is the recipient authorized and what retention survives? | Manifest, evidence, verifier and retained-copy inventory |
Public API versus provider adapter
POST preservation-packages is a proposed Records contract. An LTANS adapter must map to authorized provider APIs/SDKs/profiles: objects/bytes/hashes, validation material, preservation requests, receipts/evidence and lifecycles. Website REST paths are not provider endpoints. No sufficient LTANS contract was received to verify this mapping.
State model
SIP_VALIDATING → PROFILE_REVIEW → PROVIDER_PENDING → RECEIPT_RECORDED; VERIFIED requires content/evidence verification under the profile. VALIDATION_FAILED, RECEIPT_MISSING and EVIDENCE_MISMATCH are not success. The mock stops preservation jobs at PROFILE_REVIEW and never manufactures LTANS receipts or cryptographic evidence.
Retries and evidence
Scope idempotency to tenant/project/operation/key/body; query/reconcile request references after provider timeouts. Renewal/augmentation uses policies and old/new evidence links. Retain validation reports, object hashes, provider/profile versions, correlations and verification traces without sensitive content or tokens.
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