A large audit-log explorer is a permission-safe projection of immutable evidence, pinned to a reproducible query snapshot and designed to preserve identity, redaction, ordering, integrity state, and export receipts at scale.
An audit-log explorer looks like a search form above a table. That description misses the hard part. The screen is used to reconstruct who did what, when they did it, what the system observed, and which evidence the current investigator is allowed to see. A fast table that changes underneath the reader, leaks a hidden field through a facet, or exports a different result set is not merely inconvenient. It can produce a false conclusion.
The frontend therefore needs a stronger contract than an ordinary log viewer. Every visible row should be traceable to an immutable event, a query snapshot, a permission projection, and a display schema. Pagination must preserve that receipt. Redaction must cover every secondary surface. Selection and deep links must use stable event identity. Integrity state must say what was actually verified.
Clarify the investigation contract
Begin with the people and decisions the interface supports. A security analyst may follow one actor across services. A compliance reviewer may export every policy change during a fixed period. A support engineer may inspect a single event without permission to see the actor's email or IP address. An auditor may need evidence that a downloaded file is the same file the system produced.
Ask these questions before drawing the table:
- Which event sources and retention periods are in scope?
- Is the source immutable, append-only, or merely treated as immutable by this UI?
- Which clocks are available: event time, observed time, ingest time, and archive time?
- Are filters exact, sampled, eventually indexed, or capped?
- Can permissions differ by tenant, source, event type, field, geography, or legal hold?
- Must a saved query reproduce the same snapshot later?
- Which actions, such as viewing details, revealing a field, requesting an export, and downloading it, must themselves be audited?
- What does “verified” mean for this product, and who performs the verification?
The useful outcome is an explicit promise: the browser presents a permission-safe projection of a pinned evidence set and never implies more completeness or integrity than its receipts support.
The public interview prompt
Design a browser-based explorer for billions of audit events. Users can filter by time, actor, action, resource, tenant, and outcome; inspect structured event details; preserve deep links; compare related events; and request large exports. The source contains sensitive fields, permissions can change, new events arrive continuously, and the interface must remain accessible and responsive.
Explain:
- the client state and API contracts;
- stable event identity and cursor pagination;
- snapshot, permission, redaction, schema, and integrity receipts;
- filtering, facets, saved searches, details, and deep links;
- large-list rendering and keyboard behavior;
- live-arrival handling without rewriting an investigation;
- export jobs, expiry, and download auditing;
- partial results, failures, retry, and degraded operation;
- security, privacy, observability, testing, and rollout.
What the premium solution covers
The full solution builds the system from the evidence model upward. It follows a pinned query through server projection, page merging, row virtualization, selection, detail hydration, verification, and export. It also includes a frame-checked lifecycle animation, three high-resolution decision diagrams, and a deterministic browser-budget lab.