Control the system.
Keep human judgment.
An enterprise AI control plane connecting agent activity, policy decisions, and accountable human review.
I brought product strategy, governance UX, and design engineering together around one question: how can an operator understand what AI is doing—and intervene with confidence?
Pause the risk. Preserve the next step.
A patient identifier in an AI-generated claim summary creates one clear review moment.
- 01 / DETECT
Risk detected
patient_referenceSAMPLE-PATIENT-014The policy check flags an exposed identifier and explains why.
- 02 / HOLD
AI output paused
Human review requiredThe output waits at an explicit decision boundary.
- 03 / CORRECT
Human correction
patient_reference[REDACTED]The operator edits the payload beside the retained original.
- 04 / CONFIRM
Approved next step
Correction acknowledgedThe corrected context is ready for the next policy evaluation.
What I designedA visible pause, side-by-side correction, and explicit confirmation.
Why it mattersOperators can understand the risk and act without losing context.
The trade-offAdd review effort at a consequential moment instead of releasing uncertain output.
One execution. One accountable decision.
An on-page walkthrough of the review sequence.
Detect the risk
A policy check flags a sample patient identifier in the proposed claim summary.
patient_reference: SAMPLE-PATIENT-014Make oversight a usable workflow.
The audience is the platform, security, and compliance operator who needs context before making a consequential decision.
Strategy and design decisions
Agent executions, sensitive-data alerts, and approvals can become disconnected queues. Walled AI brings them into one operational picture: observe → inspect → decide → retain context.
The direction goes beyond reporting activity. Policy simulation and explicit review explore how an operator could anticipate risk before approving a change. Production prevention and compliance effectiveness require separate validation.
One system. Different risk contexts.
Healthcare, financial services, and infrastructure need different signals. A shared domain model changes the content and policy language while preserving familiar controls.
Reuse the governance model without flattening the differences between domains.
Make the reason for intervention visible.
Place the flagged execution, risk severity, and policy reason beside the review action. Use color with explicit labels so urgency remains understandable without relying on glow.
Reserve critical emphasis for actionable risk; respect reduced-motion preferences.
Keep people in control of the decision.
Compare the original output with an editable JSON correction. Validate the structure, require an explicit approval, and retain the original for inspection.
A suggestion is separate from an approved change. Human review has a visible boundary.
Connect the interaction to typed state.
Domain configuration, review status, selected payloads, and policy previews form a predictable state model. Reusable cards and tokens keep dense screens consistent.
Use bounded response types and explicit recovery states instead of arbitrary generated interfaces.
From a flagged execution to a clear decision.
Switch a domain, inspect an output, and test a policy. The local walkthrough uses sample data and makes no external model or policy requests.
Interactive governance workspace
Loading interactive workspace…
Choose a context
See the same workspace adapt to healthcare, financial risk, or infrastructure.
Inspect a decision
Open Review to compare and correct a sample JSON output.
Preview a policy
See which sample executions a rule would flag before activating a local preview.
Make the rules tangible in code.
The local React walkthrough turns domain configuration, payload inspection, and approval boundaries into working interactions.
State architecture and implementation
Changing domains resets review context. Stream timers stop on unmount; corrections must parse as JSON objects before approval.
A visible boundary before approval.
type Review = {
id: string;
status: 'pending' | 'approved';
original: Record<string, unknown>;
corrected?: Record<string, unknown>;
};
const parsed: unknown = JSON.parse(draft);
if (!isJsonObject(parsed)) {
return setError('Use a JSON object.');
}
// Preserve the original; record the correction.
approveReview(selected.id, parsed);Recharts visualizes the sample stream. Framer Motion introduces the case-study cards while respecting reduced motion. No mock API is presented as a production LLM integration.
Design system in action
One reusable React + TypeScript review card. Four explicit states. A working Storybook to inspect the behavior.
Isolated sample · state changes never affect live governance data.
Patient identifier detected
Waiting 18 min · Execution blocked
- Policy triggered
- Sensitive identifier protection
- Why blocked
- An unredacted patient identifier was found in the proposed output.
- Recommended correction
- Redact the identifier before requesting a context patch.
React + TypeScript
type ReviewCardState =
| 'default' | 'loading'
| 'error' | 'approved';
interface ReviewCardProps {
state?: ReviewCardState;
reason?: string;
recommendation?: string;
error?: string;
onReview?: () => void;
onRetry?: () => void;
onAudit?: () => void;
}Props excerpt from the component used in the governance app and Storybook. Approved means acknowledged completion, not a queued request.
Design tokens → rendered UI
- Color
- --review-surface / --review-focus
- Spacing
- --review-space-1 / 2 / 3 → 6 / 12 / 20px
- Typography
- --review-font / --review-title-size → 16px
Accessibility you can try
Tab and Shift+Tab move between enabled actions. Enter and Space activate them. The cyan ring makes focus visible; loading disables review, while errors announce feedback and offer Retry.
Inspect keyboard interaction tests ↗Prove decision quality, then scale the system.
The delivered evidence is an interactive interface and a working local state model. Enterprise effectiveness is the next validation question.
Validation priorities
Operator clarity
Can an operator explain why an execution was flagged and choose the right next action?
Review accuracy
Do comparisons and editable corrections reduce missed risks without creating unnecessary approvals?
Policy effectiveness
Compare false positives, missed detections, review time, and recovery against a defined baseline.
Does “approved” communicate the right boundary?
I would test whether operators distinguish a correction being acknowledged from an execution being safe to release. Ask participants to review a flagged output, correct it, and explain what happens next. Track mistaken release assumptions, correction accuracy, and requests for clarification.
Design response to test: replace a generic “Approved” state with “Correction acknowledged — awaiting policy reevaluation” if participants interpret approval as release. This is a testable hypothesis; no participant findings are claimed.
My takeaway: governance earns trust when the operator can see the evidence, understand the consequence, and retain control.
Talk about the work