Define scope
Snapshot archive IDs or query scope with a cutoff; changed queries must not silently alter the approved set.
MOBILE-ID · TRUSTED LTANS
Legal Hold
Block disposition of case-scoped records until an authorized hold-release decision.
Outcome and scope
Prevent disposition over case-scoped records and explain which holds constrain each record.
Documentation scope Workflow design and integration contract; operational configuration is confirmed per environment.
| Prepare | Receive |
|---|---|
| Complaints, disputes or preservation requests from an authorized party. | A retrievable held-record set, reason, authority and effective history. |
Participants: Legal teams, case owners, approvers and authorized operators.
Workflow and decision points
Approve separately
Separate requester and approver under the permission profile. UI state does not replace backend enforcement.
Block effects
Check all active holds immediately before disposition; export rights do not grant hold-release rights.
Release with basis
Record release basis, approver and scope. Other active holds remain effective.
States, guards and authority
| Current | Guard | Actor | Next | Artifact / recovery |
|---|---|---|---|---|
| Requested [model] | Scope and authority approved | Legal + approver | Active hold [model] | Snapshot object set and case; identify unresolved scope. |
| Active hold [model] | Disposition command received | Policy + Storage | Effects blocked [model] | Recheck immediately before effects, including previously approved jobs. |
| Active hold [model] | Authorized scoped release decision | Independent approver | This hold released [model] | Other holds still block; no dedicated release API exists in this contract. |
Exceptions and controls
| Situation | Action | Boundary |
|---|---|---|
| Two cases hold a record | Retain each hold separately. | One release does not clear every hold. |
| Scope reconciliation incomplete | Report unresolved scope without claiming complete coverage. | The case owner reviews the object set. |
| No hold-release API in contract | Identify release as a target administrative operation. | No invented endpoint or response. |
Authorization, approval and recovery
Separate requester and approver; multiple holds may coexist. Releasing one does not remove the others.
A changed query scope requires a new object-set snapshot and review. A release failure preserves the active hold for operator investigation.
Reconciliation artifacts and acceptance
Retain case ID, record-set snapshot, creation/release decisions and all active holds; releasing one does not release others.
- With two active holds, releasing one leaves the record blocked by the other.
- A requester cannot self-approve under the chosen separation-of-duties policy.
Integration and data contract
| API | Application scope | Documentation |
|---|---|---|
POST /v1/archives/{archiveId}/holds | holds:write | Policy and Profile API |
Technical input and references
| Element | Definition |
|---|---|
| Input | Case identifier, query scope or archiveId list, approving principal and effective time. |
| Output | Case-scoped hold record, blocked object set and an approved release decision. |
Execute and reconcile a scenario
| Element | Action |
|---|---|
| Synthetic ID | hold-case-A / hold-case-B |
| Task | Apply two decisions to the same scope; retain authority/time for each hold. |
| Acceptance case | Releasing A leaves B blocking disposition; operators cannot self-release. |
These are business test criteria; synthetic packages alone do not establish backend execution or valid ERS.