Mobile-ID · Long-term digital evidence preservation
Customers and partnersWorkflow demoContact
Trusted LTANS
Evaluate
MOBILE-ID · TRUSTED LTANS

Archive Service

Bring finalized records from source systems into preservation with an acknowledgement and tracking reference.

VI–EN terminology

Outcome and scope

Seal the exact record revision before evidence generation and reconcile intake without treating acceptance as preservation completion.

Documentation scope Workflow design and integration contract; operational configuration is confirmed per environment.
PrepareReceive
Contracts and attachments from signing platforms, closed DMS files and sealed data batches.Depositors can distinguish received records, work in progress and evidence readiness.

Participants: Source applications, record owners and intake operators.

Workflow and decision points

01

Freeze source

The source retains record ID, revision, MIME and attachment inventory; frozen bytes must not change under the same reference.

02

Check custody

PROVIDER_MANAGED uses uploadId; CUSTOMER_MANAGED uses dataReference; HASH_ONLY uses externalObjectId. File transfer is outside the 26 REST operations.

03

Reconcile intake

Check tenant authority, digest and permitted profile/policy. Bind idempotency to request content to detect a reused key with changed data.

04

Track evidence

Retain archiveId/jobId from the acknowledgement. Track the original job and evidence state; a disconnected HTTP call is not a reason to create a new command.

States, guards and authority

CurrentGuardActorNextArtifact / recovery
RECEIVED / VALIDATINGAuthorize tenant, profile and input digestArchive ServiceACCEPTED / REJECTEDReceipt binds archiveId/jobId; rejection retains a reason without evidence.
ACCEPTEDCommit evidence request with outboxArchive → EvidenceEVIDENCE_PENDINGReconcile outbox after disconnect; retain original command.
EVIDENCE_PENDINGRevision stored and binding checkedEvidence → ArchiveEVIDENCE_READY / EVIDENCE_FAILEDReady requires a result; failure retains identifiers and cause.

Exceptions and controls

SituationActionBoundary
Same key and bodyReconcile the accepted result.No second effect within the agreed window.
Digest differs from source bytesReject or quarantine at the detection stage.No completed-evidence claim.
TSA fails after intakeKeep the record ID and reconcile its job.Recover under policy without duplicate intake.
Authorization, approval and recovery

Authenticate the principal; check tenant, archives:write, format and permitted profile. Bind idempotency to tenant, method, path and request-body hash.

Reject an invalid profile before registration. TSA failure leaves EVIDENCE_PENDING or EVIDENCE_FAILED; resume the same job without creating a duplicate object.

Reconciliation artifacts and acceptance

Retain source IDs, request digest, intake configuration and per-item results; reconcile acknowledgements with archiveId/jobId.

Integration and data contract

APIApplication scopeDocumentation
POST /v1/archivesarchives:writeArchive API
GET /v1/archivesarchives:readArchive API
GET /v1/archives/{archiveId}archives:readArchive API
GET /v1/archives/{archiveId}/statusarchives:readArchive API
Technical input and references
ElementDefinition
InputArchiveRequest carries MIME type, metadata, profileId, policyId, archival period, group and data reference.
OutputDeposit acknowledgement contains archiveId, jobId, policy version and request time; it does not mean evidence generation has completed.
Record and evidence history
Record and evidence history · Target interface illustration; source images may contain English text.

Four distinct time concepts

TimeInterpretation
Business dateSource-declared issue/transaction date; retain provenance and authority.
Receipt timeService records receipt; evidence generation may still be pending.
genTimeTime in a verified TSA token; check digest binding and source.
evaluatedAtReport evaluation time; read with policy, evidenceVersion and trust context.

An old source date does not create historical evidence. Retain the source date/provenance; receipt or a new token cannot establish historical attestation.

Execute and reconcile a scenario

ElementAction
Synthetic IDLTANS-SYN-001/r1
TaskSource finalizes primary-record.txt, digest and clientReference; submit once with a stable key.
Acceptance caseReconcile archiveId/jobId; repeat identical key and test changed bytes under the same key.

These are business test criteria; synthetic packages alone do not establish backend execution or valid ERS.

Next steps

Search LTANS documentation

Expanded illustration