investigation-review-gap-dashboard

name

investigation-review-gap-dashboard

description

Produce a schema-conforming JSON e-discovery / litigation-hold gap and remediation dashboard for a legal matter by querying a read-only "Investigation Review Hub" API. Use when a task gives you a matter context payload plus an answer_template.json and asks for a structured JSON gap analysis, production-readiness review, retention/hold gap review, or cross-system remediation dashboard sourced from a review hub over the network (grand jury / SEC / DOJ subpoena response work). Triggers: "Investigation Review Hub", "production gap analysis", "remediation dashboard", "retention gap review", "production readiness", answer_template.json with matter_id + findings/risks + category coverage + metrics + prioritized actions.

Investigation Review Hub — Gap & Remediation Dashboard

What this task is

You are given a legal matter (a grand jury / SEC / DOJ subpoena response) and must return exactly one JSON object that summarizes the material production gaps, preservation failures, privilege problems, and QC defects for that matter, plus rollup metrics and a prioritized remediation action plan. All business facts come from a running Investigation Review Hub you reach over the network — never from local files.

Every run varies (different matter, different output schema), but the shape is always:

• Findings list — one row per material gap/defect (may be called critical_findings, top_risks, issue_ledger, retention_events+communication_gaps, …).
• Category coverage — one row per subpoena/request category with a non-complete status.
• Available/retained sources — archives or sources that still limit the loss (may be empty).
• Metrics — a fixed object of integer counters + a readiness boolean.
• Action plan — prioritized, owner-assigned remediation steps.

The hub deliberately buries a handful of material "story" records inside many realistic distractors. The entire difficulty of the task is separating signal from noise, then normalizing the signal into the exact enums/keys the answer template demands. Read reference/materiality_and_mapping.md before you start classifying records.

Inputs you will have

• input/prompt.txt — the client ask (which matter, what deliverable).
• input/payloads/<context>.json — matter context: the matter_id, category labels, and often the base URL placeholder + API key header. (Filename varies: request_context.json, review_scope.json, matter_context.json, …) Use it for the matter id, category codes/titles, and credentials only — it never contains the hub evidence.
• input/payloads/answer_template.json — the contract for your output: required top-level keys, per-item required keys, ordering rules, numeric precision, and the exact enum choices for every field. This file (not this skill, and not any example) is the source of truth for field names and allowed values. Re-read it for every run; keys and enums change per matter.
• environment_access.md (repo root) — how to reach the running hub over the network: the GDPEVO_ENV_BASE_URL, the required X-API-Key, and the allowed endpoints.

Guardrails (do this, not that)

• Only source of business evidence = the hub over the network. Do NOT read local environment source files, database/seed files, generated manifests, hidden notes, other tasks' inputs, or any answer/evaluation files. Use environment_access.md only to obtain the base URL and credentials.
• Read the base URL + API key from environment_access.md / the matter context payload for the current run; do not assume. (In the environment observed while building this skill the base URL was http://task-env:9017/ and the header was X-API-Key: review-key-017.)
• The hub is read-only; the SQL endpoint permits SELECT only.
• Output one JSON object and nothing else — no prose, no code fences, no trailing commentary.
• Use stable hub record IDs exactly as they appear (source_id, event_id, entry_id, finding_id, doc_id, action_id, category_code). Never invent IDs for evidence; the only IDs you may synthesize are action_ids in the action plan when the template shows synthetic keys (e.g. ACT-<M>-001).

Workflow

1. Read the three inputs. From the prompt + context payload get the matter_id and the category code family. From answer_template.json extract: required_top_level_keys, each list's item_required_keys, the ordering_rules, numeric_precision, and every enums block. Keep the enum lists open in front of you — every field value you emit must be one of them.

2. Reach the hub. Get base URL + key from environment_access.md. Confirm the matter exists: GET /api/matters?matter_id=<M> (note hold_date, agency, investigation_type). The endpoints and the SQL data model are in reference/hub_api.md. scripts/pull_matter.sh dumps every table for one matter and pre-flags material candidates — run it first.

3. Find the material anchor records (the core step — see reference/materiality_and_mapping.md):

   • Start from remediation_actions for the matter, excluding NOISE rows (action_id contains NOISE, description == "Routine action included as realistic operational noise.", or target_ref is a bare category code). The remaining target_refs are the authoritative material anchors (retention events, custodian sources, privilege entries, QC findings).
   • This set is necessary but not complete. Also sweep every table for records that (a) carry a descriptive slug ID (not a sequential TYPE-MATTERTOKEN-NNN id) and (b) have a note/ summary stating a concrete, quantified defect, and (c) a material issue type/tag. In particular, documents/search responsiveness-miscodes (issue_tags contains miscoded_nonresponsive, coded nonresponsive but responsive) are material even when no remediation action or QC finding points at them.
   • Discard distractors: sequential ids with boilerplate hedge notes ("ordinary review variance", "not immediately remediated", "not one of the stable exception records", "realistic operational noise", "included to create similar labels", "remediated by archive collection", …). Distractors reuse the same issue_type values as real records — issue_type alone never proves materiality; the slug-id + concrete-note + cross-reference test does.

Output validation checklist

• Top-level keys == required_top_level_keys exactly (no extras, none missing). matter_id matches the hub.
• Every list item has all of its item_required_keys; every enum field holds an allowed value.
• All counts are integers (0, not null, when N/A); booleans are real booleans.
• All ordering rules applied; every id-list sorted ascending.
• Evidence IDs are verbatim hub IDs. No distractor records leaked into findings.
• Output is one JSON object, no prose, no code fence.

See reference/hub_api.md for endpoints + SQL schema and reference/materiality_and_mapping.md for the signal/noise heuristics and the field→enum mapping and priority rubric.