Build Legal Hold Notice Schema (Purview / EDRM)

Skill: Convert custodian and matter data into a platform-ingestible legal-hold record

Region: United States Category: Legal / eDiscovery Does: Takes a custodian list and matter data and assembles a structured litigation-hold notice — a Microsoft Purview eDiscovery hold JSON or an EDRM custodian-record XML, with delivery-confirmation and custodian-acknowledgment fields — for ingestion by hold-management platforms (Purview / Exterro / EDRM-conformant tools). Spec: Microsoft Purview eDiscovery (hold/case API) · Exterro · EDRM (Electronic Discovery Reference Model)

This is the platform-interchange / schema variant of a litigation hold. It produces the machine-readable record a hold-management system ingests to issue, track, and audit a hold — not the human-facing prose notice. For the court-defensible written preservation directive itself, see the sibling skill generate-legal-hold-notice (the prose notice); this one targets Purview / Exterro / EDRM ingestion and the surrounding delivery/acknowledgment audit trail. Medium confidence. Element/field names below follow the form of the platform record, not a single canonical schema — vendor APIs differ. Counsel owns scope and timing; the platform owns issuance, reminders, and the audit log.

When this applies

• A litigation hold must be issued and tracked through a platform (Microsoft Purview eDiscovery, Exterro, or another EDRM-conformant hold tool) rather than only as an email/PDF notice.
• Custodian acknowledgments, reminders, escalations, and release events need to be logged in a defensible audit trail the platform can produce on demand.
• Custodian and matter data must be exchanged between systems (HR roster, matter-management system, hold platform) in a structured format.

Structure (custodians + matter → hold record)

Hold / Case record
  matter_id / case_name / matter_number
  hold_id, hold_status (active / released)
  issued_date, preservation_scope (date range, sources, keywords)
  legal_basis_reference (link to prose notice / FRCP 37(e) trigger)
Custodian record (repeating)
  custodian_id, display_name, email, department, manager
  in_scope_sources (mailbox, OneDrive/SharePoint, Teams, file share, devices)
  notice_sent_datetime, delivery_confirmed (Y/N)
  acknowledgment_status (pending / acknowledged / declined)
  acknowledgment_datetime, reminder_count, escalation_flag
Audit-trail event (repeating)
  event_type (issued / delivered / reminded / acknowledged / released)
  event_datetime, actor, notes
Release record (when matter closes)
  release_date, release_authorized_by

Data rules

• The structured record complements the prose notice — store a legal_basis_reference linking to the human-readable hold (from generate-legal-hold-notice) so scope wording and the machine record stay aligned.
• Delivery confirmation and acknowledgment are distinct: a sent notice is not an acknowledged one. Track delivery_confirmed and acknowledgment_status separately so non-acknowledgments trigger reminders/escalation.
• Preservation scope (date range, custodial data sources, search terms) must match the matter's scope; in Purview this maps to the hold query/locations, in EDRM to the custodian/source elements.
• Every status change is an immutable audit-trail event with timestamp and actor — this is the defensibility record under FRCP 37(e).
• Release only on documented authorization after the matter and any appeal/limitations period close; never silently drop a custodian — record a release event.
• Identifiers (custodian_id, hold_id, matter_id) must be stable and unique so cross-system reconciliation works.

Worked example (outline)

Hold: hold_id=H-2026-0042  matter=Acme v. Doe (No. 26-cv-1234)
  status=active  issued=2026-06-04
  scope: 2023-01-01..present; sources=Exchange,OneDrive,Teams; terms="Project Falcon"
  legal_basis_reference: notice-Acme-Doe-v1.pdf (FRCP 37(e) trigger)
Custodian:
  custodian_id=C-118  name="Jane Doe"  email=jdoe@acme.com  dept=Finance
  in_scope_sources: mailbox, OneDrive, Teams
  notice_sent: 2026-06-04T14:02Z  delivery_confirmed: Y
  acknowledgment_status: pending  reminder_count: 0  escalation_flag: N
Audit events: [issued 2026-06-04, delivered 2026-06-04]

Emitted as a Purview hold JSON (or EDRM custodian XML) and ingested by the hold-management platform, which issues the notice, tracks acknowledgment, and maintains the audit log.

Validation checklist

• Target platform/schema confirmed (Purview hold JSON / Exterro / EDRM XML) — element names match the current vendor API
• matter_id, hold_id, and per-custodian custodian_id present, stable, and unique
• Preservation scope (date range, sources, terms) matches the matter scope and the prose notice
• legal_basis_reference links to the court-defensible prose notice (generate-legal-hold-notice)
• Delivery confirmation and acknowledgment status tracked separately; reminders/escalation modeled
• In-scope data sources enumerated per custodian (mailbox, OneDrive/SharePoint, Teams, devices)
• Audit-trail events captured immutably with timestamp + actor for every status change
• Release modeled with date + authorizing party; no silent custodian drops

Last updated: 2026-06-04 — this is the platform/schema interchange variant; for the court-defensible prose notice see generate-legal-hold-notice. Counsel owns scope and timing. Confirm the current Microsoft Purview eDiscovery hold schema/API, Exterro/EDRM record formats, and FRCP 37(e) preservation obligations against current vendor and edrm.net guidance before use.