Data obfuscated for a secure public portfolio
Incline TrustAI exception-review workspace for corporate spend
Controllers rubber-stamp a drifting AI score, or ignore it and fall behind at close. Either way the audit signature is theirs. The problem is that the model’s confidence, drift, and peer context are invisible at the moment of attestation, so the reviewer cannot defend the call they just signed.
These are the failure modes the workspace is designed against: hidden confidence, invisible drift, weak peer context, and a signature that arrives after the reviewer has lost the evidence.
Incline Trust is a reviewer workspace that keeps model mechanism, uncertainty, and peer context visible so a controller can accept, reject, tune, or escalate each flag in under a minute, then sign a record that survives review.
Siarhei Mardovich designed an AI-trust and RegTech exception-review workspace that keeps model mechanism, uncertainty, and peer context visible, so a controller can accept, tune, or reject each flagged transaction with an immutable audit artifact. Built as a single-file D3.js and Material Design 3 prototype. The same Trust Architecture transfers to AML transaction monitoring, fraud detection, KYC review, and model-risk management under SR 11-7.
Role, approach, and outcome
Role
Principal product designer and prototype engineer. Designed the exception-review interaction model, score-and-uncertainty system, weight controls, and attestation artifact.
Approach
Trust Architecture for AI output: expose what drove the score, which signals matter, where uncertainty sits, and what the reviewer is about to sign.
What it enables
A reviewer can work a filtered queue, tune weights, cross-check history, attest the verdict under a confidence band, and emit a reviewable record without leaving the page.
From Thesis to Prototype
How the case was produced, end to end. Frontend coded by directing AI coding agents, so the judgment is the design work and the keystrokes are accelerated.
- Thesis
Trust Architecture and the 2 failure modes.
- Information architecture
One workspace, from inbox to signed record.
- UX flow
The 7-step signing path.
- Visual system
Score, sigma band, Material Design 3 dark.
- Prototype build
Single-file, framework-free shell.
- Frontend code
D3.js views and state, directing AI coding agents.
- Validation framing
Guided tour and scenario presets.
AI finance operations has a specific failure pattern: the model narrows a high-volume queue, but the reviewer still carries the audit signature. Too much trust lets drift pass under a clean-looking score. Too little trust turns every case back into manual review.
The workflow compresses the review around the evidence. A controller opens a filtered case, reads the signal mix, adjusts weights only when the evidence supports it, checks history and peer fit, then signs a verdict that captures the state of the decision.
I made uncertainty operational: confidence, variance, model weights, peer fit, timeline geometry, and the audit artifact stay visible because the reviewer has to own the final call.
The real failure is the interface around the model. A recommendation without visible mechanism asks the reviewer to choose between obedience and suspicion. Neither is a reviewer.
3 Accountability Anchors
The score is broken into visible signals and weights so the reviewer can challenge the recommendation.
The queue is governed by thresholds instead of a flat ranked list. Policy can move without hiding the tradeoff.
Approved, rejected, and escalated paths all terminate in the same reviewable audit artifact.
Exception review workspace
The guided path inside the prototype moves from queue to explanation to weights to score to timeline to verdict. That order matters. Reading the explanation before touching weights prevents the reviewer from tuning toward a preferred outcome. Reading history before signing prevents a decision that ignores seasonality or peer movement.
The result is a workspace instead of a dashboard. Each visual answers a question the reviewer has to answer before signing: what moved the score, how wide is the confidence band, what does the last year of behavior say, what does the peer cohort say, and what exactly will be captured in the audit record?
Workspace in 3 Frames
Black-Box Score vs Accountable Workspace
The same flagged case, 2 ways. The difference is whether the reviewer can own and defend the call.
Black-box score
- The reviewer sees a score with no mechanism behind it.
- The call cannot be defended when the audit arrives.
- Drift passes under a clean-looking number.
- Backlog grows and the AI gets written off as a failed productivity story.
Accountable workspace
- Every score exposes the signals that drove it.
- The decision is defensible, with the record built at signing.
- Uncertainty stays visible instead of flattened into a point estimate.
- The reviewer owns the call as an accountable colleague.
Where This Transfers
The case is corporate spend, but the accountability pattern is the transferable asset. Any regulated queue where a human signs off on an AI flag is the same design problem: a model narrows the work, a person owns the call, and an audit reads the record later.
- AML transaction monitoring
- KYC / KYB anomaly review
- Fraud detection queues
- Model-risk management (SR 11-7)
- Credit-risk review
- Operational-risk exceptions
5 Decision Questions, One Signing Path
The screen is a single workspace that carries a case from filtered inbox to attested artifact in one session. Each visualization answers a distinct question the reviewer must answer to sign the record.
Which cases are confidently flagged, and which have a wide band that deserves review?
Is the point estimate stable, or is the same score carrying enough variance to change scrutiny?
Does the current month break from its own history, or only look strange in isolation?
Is the score driven by signals the reviewer trusts, or by a signal that should be argued with?
Is this case the outlier, or is the cohort itself drifting into a policy question?
What did the reviewer see, weight, and sign at the moment the record was created?
The gauge keeps uncertainty visible, the timeline keeps history in a 12-month geometry, the sliders keep tuning explicit, and the inbox ranks by confidence band as well as score. Every visual is accountable to the signature at the bottom of the workflow.
A Threshold Instrument, Not a List of Flags
The threshold instrument makes the governance tradeoff tangible. Drag the escalation and auto-approve handles and the same synthetic queue re-bins in real time. The counts are a side effect. The purpose is to make policy changes visible before they become reviewer behavior.
Interactive confidence-band control
Every Verdict Path Creates the Same Reviewable Record
The state machine is the accountability model behind the screen. A low-confidence case is flagged, routed to review, then approved, rejected, or escalated. The branch can change, but the end condition does not: each verdict creates an audit artifact that can be re-read later.
What the Audit Record Captures
Every verdict, whatever the branch, writes the same immutable record. This is what a reviewer signs, and what the audit reads back later. Values below are illustrative.
Signed
The immutable record the audit review reads.
Model-Risk Concerns Mapped to Screen Controls
The governance map translates SR 11-7 expectations into things a reviewer can see and use without exposing the proprietary model.
| SR 11-7 expectation | On-screen control | What it answers |
|---|---|---|
| Model inventory | Live trust-score gauge | What is the current score and confidence band for this case? |
| Validation | Weight sliders | Which signals drive the score, and how sensitive is the output? |
| Monitoring | 12-month geometry timeline | Does the current case break from its own history? |
| Exception management | Confidence-band inbox + peer fit bars | Which cases need review, and how does this case sit against its cohort? |
| Audit trail | Signed audit artifact | What did the reviewer see, change, and attest at the moment of decision? |
Who This Workspace Serves
A prototype has no team to manage, but it still has an ecosystem to design for: the roles the workspace must answer to.
Implementation Notes
The interaction model and accountability pattern are the design work: a reviewer moves from queue pressure to model explanation, adjusts only the controls that affect the decision, and signs a record with the evidence still visible.
- Review model
Trust Architecture for AI-assisted review.
- Single-file prototype
Material Design 3 dark shell with D3.js views.
- Threshold calibration
Separate iframe instrument for policy handles.
- Lifecycle + governance
State machine and SR 11-7 control map.
- Live case page
This page, with annotated screenshots and schema.
What I learned: building this clarified that the hardest accountability surface is not the score but the record the reviewer signs. So the audit card drove the design, not the gauge.
What I would measure: median time from case open to signed verdict against the reviewer’s current queue tool; how often weights are adjusted before signing, the tuning-toward-a-preferred-outcome signal; and the share of signed records that survive a second-line audit challenge without rework. No baseline exists yet; the instrument is designed to capture all 3 from the first session.
Design Trade-offs
A senior decision is usually a trade-off made on purpose. Here are 3 I made on this build, and what each one bought.
Technical Details
Single-file HTML prototype using a Material Design 3 dark shell, D3.js v7 visualizations, and no framework runtime.
5 coordinated views: confidence-band inbox, score gauge, 12-month timeline, weight-tuning controls, and peer cohort fit bars.
Separate iframe instrument so the D3 logic stays outside the page editor and can be updated independently.
Native label-and-input pattern on the attestation checkbox, visible focus states, and keyboard shortcuts for queue review.
Immutable record captures verdict, signal weights, confidence band, peer cohort, timestamp, and control reference pattern.
Reduced-motion preference respected in the prototype and threshold instrument.
Let’s Talk
Open to principal/staff product design roles · Greater New York City Area · siarhei.mardovich@gmail.com · LinkedIn · Resume