# Audit Log Target Experience Brief ## Metadata | Field | Value | | --- | --- | | Surface ID | UI-025 | | Route | `/admin/audit-log` | | Source screenshot | `../screenshots/desktop/ui-008-audit-log.png` | | Source page report | `../page-reports/ui-008-audit-log.md` | | Target sidecar | `../target-images/target/audit-log-target.md` | | Primary persona | Auditor / security reviewer | | Secondary personas | Workspace owner, support reviewer, compliance reviewer | | Repo-truth posture | Source route and screenshot are `repo-verified`; target composition is direction only. | ## Current-State Snapshot The page is clearly an audit log. The report says its product role should be audit evidence first and diagnostics second, with explicit filters and no raw payload dominance. ## Current-State Productization Problems - Event history can read as raw logs instead of proof. - Selected-event detail must respect active workspace/environment filters. - Customer/auditor export language requires dedicated review. ## Target User Promise In five seconds, an auditor can see what happened, who did it, when it happened, what scope it affected, and where the evidence detail is. ## First-Five-Seconds Target Show audit proof posture, filter scope, selected event summary, and evidence detail path before raw metadata. ## Primary Decision Does the current audit scope contain the event proof needed for review? ## Primary Action Inspect event proof. ## Secondary Actions Filter events, export scoped audit evidence, open affected record, reveal raw metadata. ## Target Information Hierarchy 1. Workspace/environment filter scope. 2. Audit event proof summary. 3. Actor/action/target/outcome/timestamp. 4. Selected event evidence. 5. Export/share safety. 6. Raw metadata. ## Main-View Keep / Promote / Simplify | Treatment | Elements | | --- | --- | | Keep | Action, actor, target, workspace/environment, timestamp, outcome. | | Promote | Filter scope, selected event proof, export-readiness note. | | Simplify | Raw metadata, dense payload fields, debug-only identifiers. | ## Detail Drawer Treatment Event drawer should show human-readable proof first, scope and entitlement context second, and raw metadata in a collapsed support section. ## Advanced/Admin Treatment Export and raw inspection require explicit scope and capability review. Support-only details should remain gated. ## Hidden/Removed Default Elements Hide raw payloads, fingerprints, provider internal errors, and unsupported customer-facing claims. ## Target Layout Direction Use a proof ledger layout: filter bar, event timeline/list, selected proof panel, and evidence/export rail. ## Visual Target Direction Dark audit surface with high text contrast, sand dividers, violet evidence links, amber for attention, and neutral outcome labels until verified. ## Status/Trust Model Separate event outcome, export readiness, data completeness, and scope filter state. Do not imply compliance certification. ## Dangerous Actions No destructive action should be visible. Export requires tenant-safe filtering, authorization, redaction, and audit in later implementation. ## Customer-Safe Review Notes Auditor-facing variants must avoid raw diagnostics and unsupported compliance language. Customer exports must be scoped and redacted. ## Workspace/Environment Context Workspace is explicit. Environment filter state must remain visible in list and selected detail. ## Empty / Loading / Error States Empty state should say no audit events match the active scope. Loading should preserve filters. Error state should avoid leaking raw exception detail. ## Accessibility Notes Event status and scope must be text-readable. Timeline order must be understandable by screen readers. ## Repo-Truth Classification | Target element | Classification | Notes | | --- | --- | --- | | Audit route and screenshot | repo-verified | Spec 323 browser pass reached the route. | | AuditLog fields | repo-verified | Existing model and page report concepts. | | Selected proof panel | plausible-existing | Uses current event data with new hierarchy. | | Export readiness | foundation-only | Must be verified against existing export/report behavior. | | Compliance-ready claims | unknown | Must not be stated without separate proof. | ## Screenshot-Anchored Image Prompt Start from `ui-008-audit-log.png`. Create a target design direction, not runtime implementation. Preserve audit event review. Show workspace/environment scope, selected event proof, actor/action/target/outcome/time, evidence link, export-scope note, and collapsed raw metadata. Keep customer/auditor language safe. Avoid generic SaaS dashboards, fake compliance claims, green success without verification, placeholder text, raw metadata dominance, and runtime implementation claims. ## Implementation Pattern Requirements - Scope filters remain visible. - Event proof is human-readable first. - Raw metadata is progressive disclosure. - Export/share actions are authorized, scoped, redacted, and audited. ## Later Implementation Candidate Evidence and review pack consumption productization. ## Non-Goals For Later Implementation Do not introduce compliance certification language or broad audit export behavior without separate requirements.