Skip to main content

📗 UX-GOVERNANCE-COMPLIANCE.md

This document specifies the UX patterns for the Compliance Centre. This is where Evalium manages the data lifecycle—from DSAR exports to the “Right to be Forgotten”—to meet UK GDPR / GDPR accountability expectations.

Compliance UX must prioritise defensibility, traceability, and safe operator behaviour.

Capability Baseline (Validated 2026-02-25)​

Current backend is strong on compliance execution primitives, but not full case orchestration yet.

Backend-live now:

  • Compliance jobs and actions (forget, restrict, dsar-export, privacy-pack, unlink) and compliance ledger endpoints.
  • Retention incident surfaces and asynchronous processing model.

Target-state/pending backend:

  • First-class compliance request/case entity with canonical timeline projection.
  • DSAR extension-notification enforcement as a hard backend rule.
  • Review/redaction stage tracking and structured deny/partial outcomes as first-class case workflow primitives.

Rule:

  • Build UI so jobs/ledger workflows work today, while case/timeline UX remains clearly flagged as target-state until backend contracts are first-class.

0. Compliance Doctrine (MUST)​

0.1 Asynchronous by Design​

Compliance actions (Forget/Anonymise, Export, Restrict, Retention Scrub) are long-running jobs. The UI must never imply an “instant delete”.

0.2 Requests vs Jobs (MUST)​

  • A Compliance Request is the legal/operational case (DSAR / Erasure / Restriction / Retention action).
  • One request may spawn multiple Jobs (export build, media purge, projection scrub, etc.).

This separation enables a single Case Timeline while still tracking execution details.

Implementation note:

  • Today, jobs + ledger are backend-first-class.
  • A canonical request/case entity + timeline projection is target-state and must be feature-flagged until fully backed.

0.3 The Receipt Pattern (MUST)​

Every compliance action must produce:

  • a Ledger Entry (tamper-evident audit trail)
  • and where applicable, an Artifact Receipt:
    • artifact hash (e.g., SHA-256), algorithm, created_at, size, expiry
    • legal basis metadata and operator “Reason”

0.4 High-Friction Safeguards​

Irreversible actions (e.g., Forget/Anonymise) require:

  • explicit confirmation
  • mandatory “Reason”
  • capability gating
  • an additional “I understand” acknowledgement step

0.5 Silo Integrity​

All Compliance actions are scoped by org_unit_id unless the operator has tenant.silos.all.

0.6 Rights Are Not Always Erasure (MUST)​

The Compliance Centre must treat Restriction as a first-class outcome and support refusal/partial compliance when erasure does not apply (e.g., legal obligation or legal claims). Restriction is an alternative right that limits processing.

0.7 DSAR Time Boundaries & Extensions (MUST)​

For DSAR/Right of Access requests, the UI must show:

  • Due date (1 month from receipt)
  • Extension state (up to +2 months for complex/multiple requests)

Extension Notification Contract (MUST)​

If an operator extends a DSAR due date:

  • The Case Timeline must include a mandatory step: Notify Subject of Extension
  • The UI must record:
    • Notification Sent At timestamp (required)
    • Notification method (email / portal / other)
    • Operator + reason note (required)

Hard rule: the UI must prevent the due date from being extended unless a Notification Sent At timestamp is recorded.

Implementation note:

  • Treat this as a release gate requirement for case orchestration UX.
  • If backend does not yet enforce this invariant directly, UI workflow must enforce it and flag as pending backend hardening.

0.8 Compliance Interface Guardrails (MUST)​

  • DSAR/erasure/restrict actions must use explicit workflow states (requested, processing, completed, blocked) with timeline evidence.
  • Case and job surfaces must show due dates, extension state, and notification proof without ambiguity.
  • Destructive/high-risk actions require structured reason capture and confirmation language suitable for legal audit.
  • Compliance tables, timelines, and legal-basis controls must be keyboard-complete and screen-reader understandable.
  • Export/receipt artifacts and manifests must be accessible outputs (not image-only or structureless payload summaries).
  • Mobile/iPad supports case inspection and status actions; dense legal review/redaction workflows may be desktop-optimized with explicit handoff.

1. Compliance Hub (Primary Dashboard)​

The Compliance Hub is the entry point for privacy officers and admins.

1.1 Layout​

Two primary tabs:

  1. Requests (Cases)
  • DSAR (Access)
  • Erasure (Forget/Anonymise)
  • Restriction (Limit processing)
  • Retention / Scrub actions (system or operator-initiated)
  1. Jobs (Execution Queue)
  • operational worker jobs spawned by Requests (or system retention engine)

A third “Ledger” tab is available from both.

Current-vs-target guidance:

  • Jobs and Ledger are backend-live and should be the default production path now.
  • Full Requests (Cases) workflow is target-state until first-class case/timeline backend contracts are active.

2. Requests (Cases, Target-State)​

This section defines the intended case-centric UX once request/case orchestration is first-class in backend contracts. Until then, equivalent operator flows should run through Jobs + Ledger with clear subject/scope filtering.

2.1 The Request List​

Each row shows:

  • Type: DSAR / Erasure / Restriction / Retention Action
  • Subject: User or Org Unit (read-only drawer peek on drawer-enabled surfaces)
  • Scope chips: org_unit, domains selected, plus any “hold” flags
  • Due by: required for DSAR (and visible for all case types)
  • Status: Open / In progress / Completed / Denied / Partially completed
  • Primary CTA: “Open case”

2.2 Case Timeline (MUST)​

Opening a case shows a single “timeline” view:

  • Request created (who/when)
  • Verification (if needed)
  • Extension (if applicable)
    • “Due date extended”
    • “Notification sent” (mandatory, timestamped)
  • Jobs spawned
  • Review/Redaction (if applicable)
  • Artifacts created (links + receipts)
  • Completed / Denied (with reason + legal basis)

Each timeline item links to a Ledger Entry.

2.3 Verification Panel (SHOULD)​

For DSAR/Erasure/Restriction cases, show:

  • Verified by (operator)
  • Method (authenticated account / email verification / other)
  • Timestamp

3. Jobs (Execution Queue)​

This is the primary backend-backed compliance workflow surface today.

3.1 The Privacy Job Queue​

Shows all active and historical jobs with operational fields:

  • Started At
  • Completed At
  • Duration
  • Status: Pending / Processing / Completed / Failed / Cancelled
  • SLA (if applicable): e.g., “needed for DSAR due by…”

3.2 Job Row Pattern​

  • Type: Export Build / Anonymise / Media Purge / Projection Scrub / Retention Scrub / Unlink
  • Subject: User or Org Unit (read-only drawer peek on drawer-enabled surfaces)
  • Status: Pending / Processing / Completed / Failed
  • Artifacts: download link(s) where applicable
  • Retry / Resume action (capability gated) for failed jobs

Artifacts (DSAR zip / Privacy Pack) must:

  • display expiry (“Download available until …”)
  • be downloadable from a stable “Artifacts” section in the case view (or jobs/ledger detail until case orchestration is active)
  • never be embedded inline into the UI

4. Compliance Ledger (Audit Trail)​

A read-only, filterable list of every high-stakes privacy event.

4.1 Event Taxonomy (MUST)​

Examples:

  • DSAR Requested / DSAR Export Built / DSAR Review Completed / DSAR Delivered
  • DSAR Due Date Extended / DSAR Extension Notified
  • Erasure Requested / Erasure Denied / Anonymisation Completed
  • Restriction Placed / Restriction Lifted
  • Legal Hold Placed / Legal Hold Released
  • Evidence Deleted / Media Purged
  • Retention Scrub Completed / Retention Incident Created

4.2 Receipt Detail (MUST)​

For any event that produces an artifact:

  • Hash: value + algorithm (e.g., SHA-256)
  • Artifact size
  • Created timestamp
  • Expiry timestamp
  • Legal basis (structured) + operator “Reason”
  • Link back to the Case Timeline node when available (otherwise job/ledger detail)

4.3 Anonymisation / Pseudonymisation Safety Note (MUST)​

If the system uses hashed identifiers for anonymised records, the UI must avoid implying “this is no longer personal data” unless the process is truly irreversible. Prefer neutral labels like “Anonymised (internal reference retained)” and route access via the Compliance case/ledger.

5. Legal Holds & Restrict Processing​

UI pattern:

  • A “Lock” icon on User and Org Unit hubs.
  • Hold banner in Compliance case and Subject drawer.

Impact:

  • Disables Forget/Anonymise and other destructive actions
  • Tooltip: “Action blocked by active Legal Hold”
  • “View hold” opens drawer showing:
    • hold reason (mandatory)
    • placed by / placed at
    • scope (domains affected)
    • intended review date (optional)

5.2 Restrict Processing (First-Class Right) (MUST)​

Restriction is treated as a separate case type with clear outcomes:

  • Plain-language messaging (“Processing restricted”)
  • Scope selection: which domains are restricted (telemetry, marketing, reporting exports, etc.)
  • Lift restriction (capability gated) requires:
    • legal basis picker (if applicable)
    • reason note

6. “Forget User” (Hybrid Scrub) Workflow​

This is the most critical compliance action. The UX must manage the transition from Active User → Anonymised Record, with explicit handling for holds and refusal scenarios.

6.1 Initiation​

Trigger from:

  • User Profile
  • Compliance Hub (“New request”)

6.2 Hold Check (MUST)​

If an active legal hold exists:

  • Block the action
  • Show hold reason and link to hold detail
  • Offer alternative: “Create Restriction Request” (if appropriate)

6.3 Impact Summary (MUST)​

Before committing, show what will be affected:

  • “PII will be redacted.”
  • “N Evidence uploads will be hard-deleted (if policy allows).”
  • “Derived skill profiles will be anonymised.”
  • “Audit trail will be retained.”

6.4 Refusal / Partial Compliance (MUST)​

The UI must support outcomes:

  • Proceed with anonymisation
  • Deny erasure
  • Partial (scrub selected domains, retain others)

For Deny or Partial outcomes, the operator must select a structured legal basis (dropdown), e.g.:

  • Legal obligation
  • Establishment / exercise / defence of legal claims
  • Public interest
  • Other (requires structured note)

This legal basis becomes filterable in:

  • the Case Timeline
  • the Compliance Ledger
  • exports (where applicable)

A free-text “Reason” is still required, but it supplements (not replaces) the structured basis.

6.5 High-Friction Confirmation (MUST)​

  • Confirm step 1: type “FORGET” (or equivalent)
  • Confirm step 2: mandatory “Reason”
  • Confirm step 3: “I understand this is irreversible”

6.6 Completion: Anonymised State (MUST)​

Once completed:

  • Display name becomes: “Anonymised User” (optionally with internal reference token)
  • Link contract changes:
    • Links in Insights/Reporting no longer open a full user profile
    • They open the Compliance Case / Ledger view for that anonymised subject

7. DSAR & Privacy Packs​

DSAR exports assemble a “Privacy Pack” from durable sources.

7.1 Export Request (Case)​

From User Profile or Compliance Hub:

Payload selection

  • Allow include/exclude by domain (e.g., “Exclude competence profiles”)
  • Show scope chips summarising the selection

Cooldown enforcement (MUST)

  • If a recent export exists, display a warning and require confirmation to regenerate.

Due date tracking (MUST)

  • Case view shows DSAR due date and whether an extension is applied.
  • If extended, the timeline must show Notification Sent timestamp (per 0.7).

7.2 DSAR Export Pipeline (MUST)​

DSAR export is a staged flow:

  1. Build (job)
  • System assembles the pack candidate set.
  1. Review & Redaction (workflow)
  • Operator reviews items flagged for potential third-party disclosure and can redact.
  1. Generate Artifact (job)
  • Final pack is produced with receipt hash + expiry.

This makes the DSAR export defensible as a due-diligence process.

Implementation note:

  • Build/Generate job primitives are live.
  • Review/redaction stage tracking is target-state until first-class case workflow support is active.

7.3 The Privacy Pack Artifact​

Artifacts must be produced with:

  • Download link + expiry
  • Receipt metadata (hash/algo/size/created/expiry)
  • Manifest view (drawer)

7.4 Redaction Workflow (MUST)​

This is target-state and should be feature-flagged until case review/redaction contracts are first-class.

Review Stage (MUST)​

In the DSAR case, include a Review stage with:

  • A filterable list of items eligible for redaction (examples: observations, comments, attachments, free-text fields)
  • Per-item actions:
    • Mark as “Redacted for third-party privacy”
    • Provide redaction reason (preset + optional note)
  • A review completeness indicator:
    • “Review complete” is required before generating the final artifact (unless policy explicitly permits skipping, capability gated)

Redaction Summary (MUST)​

The case view must show:

  • Total items reviewed
  • Total redactions performed

Manifest Inclusion (MUST)​

The final Manifest must explicitly include:

  • “Third-party redactions performed: X”
  • Redaction rationale summary (high-level; no sensitive detail)

8. Data Retention & Incidents​

The Retention Policy Engine automatically cleans up telemetry and session data after defined windows.

8.1 Retention Incidents Surface (MUST)​

Incident list shows records that could not be deleted (e.g., legal hold or processing error).

Row fields

  • Domain (Telemetry / Media / Evidence / Other)
  • Blocked reason (hold / permission / processing error)
  • Affected subject link (read-only drawer peek on drawer-enabled surfaces)
  • First seen / last seen timestamps
  • Retry count (if available)

8.2 Triage Actions (MUST)​

Each incident row includes:

  • Retry
  • View hold (if blocked by hold)
  • Escalate (creates an internal task/flag for admins)

9. Summary of Navigation Contracts​

Compliance TaskPatternPrimary CTALink Contract (Peek + Full Page)
Create DSAR Request (Target-State)Case WizardCreate RequestSubject Drawer (User/Org Unit)
Extend DSAR Due Date (Target-State)Case Timeline (Guarded)Extend + NotifyLedger Entry (Extension + Notification Timestamp)
Track DSAR ExportJobs + Ledger (today) / Case Timeline + Jobs (target)Download PackReceipt Detail (Hash/Expiry)
DSAR Redaction Review (Target-State)Review WorkflowMark Redacted / Complete ReviewItem Detail (with redaction reason)
Forget/Anonymise UserHigh-Friction WizardConfirm & QueueCompliance Jobs/Ledger (case timeline when active)
Deny / Partial Erasure (Target-State)Guarded Outcome + PickerRecord DecisionLegal Basis Detail (filterable)
Restrict ProcessingJob-backed flow (today) / Case Wizard (target)Place RestrictionLegal Basis / Scope Drawer
Review LedgerTable + FilterExport LedgerArtifact Receipt Detail
Manage HoldsHub + TogglePlace HoldHold Detail (Reason/Scope)
Retention IncidentsTable + TriageRetryIncident Detail / Hold Detail