Concept shell — design framework, not shipped work
Designing AI as Decision Support in an Operational Workflow
A design framework for putting machine predictions inside a human decision workflow: what the user is deciding, what evidence they inspect, where a model can genuinely help, and what has to be true about confidence, override, and accountability before anyone should trust it.
Concept shell — no shipped AI evidence claimed
A capability case about designing AI into complex, trust-sensitive B2B workflows. The premise: in operational domains, AI earns its place as decision support — a well-behaved input into a human decision — not as a novelty layer or a chatbot bolted onto the side. This page documents the structure and principles I design against.
This is a concept and framework page, marked as such throughout. It contains no shipped AI product, no model performance numbers, and no client evidence — those are shown as pending artifacts and will only ever be filled with real, cleared, anonymized material. The design judgment on this page is the evidence it offers.
Context
Concept setting: an operational domain where a specialist reviews incoming data and makes consequential accept / flag / escalate decisions under time pressure — the workflow shape shared by inspection, monitoring, triage, and quality-control work.
Problem
Problem type: the decision itself is sound but expensive — high volume, high vigilance cost, error consequences that are asymmetric. The design question is where machine assistance genuinely reduces that load without displacing accountability.
Constraints
Wrong decisions are costly and traceability is mandatory, so the design must assume the model will sometimes be wrong and make that survivable: visible uncertainty, inspectable evidence, human override, and a working fallback path are requirements, not enhancements.
Proxy evidence
Until a shipped case can be documented, the evidence here is the framework itself: the section structure below is the checklist I hold AI features against, and each section states the design position it encodes.
The task before AI
Every credible AI feature starts with a precise account of the work as it exists without the model. Who decides, on what cadence, with what consequences when they are wrong. If the task cannot be described crisply without mentioning AI, the AI has nothing concrete to support — and the feature is decoration. Writing this account first also sets the baseline that any later measurement of the AI has to beat.
Artifact pendingTask model
TODO (real project only): a recreated, anonymized model of the human task — the decision being made, its inputs, its frequency, and the cost of each kind of error. Neutral role labels; no client or system names.
Cognitive load
The honest reason to add AI to a workflow is usually cognitive: sustained vigilance over mostly-normal data, comparisons across more items than working memory holds, or pattern checks that fatigue erodes over a shift. Locating exactly where attention is being spent — and where it degrades — tells you what the model should absorb. It also tells you what it must not absorb: the judgment calls where human context, accountability, and situational knowledge do the real work.
Artifact pendingAttention map
TODO (real project only): an anonymized map of where the specialist’s attention goes across a work session — which checks are exhausting, which are trivial, where errors cluster in time. This is the artifact that justifies (or kills) the AI feature.
The data being inspected
Decision-support design is data design. The user is already inspecting something — images, sensor streams, records, events — and their trust in any machine suggestion depends on being able to see the same evidence the suggestion points at. Cataloguing the data honestly matters: its volume and update rhythm, but also its failure modes — gaps, sensor noise, stale readings, ambiguous cases — because those are exactly the conditions under which a model quietly stops deserving trust.
Artifact pendingData inventory
TODO (real project only): a recreated inventory of the inspected data — types, freshness, volume, known quality problems — with neutral labels. Mark which properties the interface must surface so the user can judge the evidence themselves.
Where AI enters — and where it does not
The support role has to be chosen, not assumed. A model can rank what deserves attention first, pre-fill what is tedious to enter, flag what deviates from normal, or draft an assessment for review — and each role implies a different interface contract. What stays constant is the boundary: the model proposes, the human disposes. A recommendation is an input to the decision, never the decision itself, and the interface should make acting against the model exactly as easy as acting with it.
Deliberately absent here: a chat window. Inspection-and-decision workflows are spatial and stateful — the user is looking at evidence, not composing prose — and forcing that through conversation adds friction while hiding the data. A conversational surface earns a place only when the workflow genuinely is a dialogue, and that need would have to show up in research, not in a trend.
Artifact pendingSupport-role decision
TODO (real project only): the anonymized reasoning for which support role the model plays — options considered, the one chosen, and which decisions were deliberately left fully manual and why.
Confidence & uncertainty
Uncertainty must be visible, and it must be designed against overtrust as much as undertrust. A raw probability invites false precision; a traffic light hides too much. The working position: express confidence in terms of what the user should do differently — “worth a look” versus “needs your judgment” versus “the model has little basis here” — and make low confidence loud rather than apologetic. The most dangerous state in decision support is a wrong suggestion delivered fluently, so the design treats calibrated doubt as a feature, not an embarrassment.
Artifact pendingUncertainty display
TODO (concept mock or real project): recreated UI showing how confidence is expressed at each decision point — including the explicit low-confidence and no-basis states, not just the happy path.
Explainability & inspectable evidence
“Why is the system suggesting this?” must have an answer a practitioner can check, in the vocabulary of their domain. That rarely means exposing model internals; it means pointing at evidence — the region of the image, the readings that deviated, the past cases this one resembles — so the user can agree or disagree with the suggestion on its merits. Explanation the user cannot verify is reassurance, not explainability, and reassurance is precisely what a trust-sensitive workflow does not need.
Artifact pendingEvidence view
TODO (concept mock or real project): recreated UI for the evidence behind a suggestion — what the model looked at, surfaced in domain terms, one interaction away from the recommendation itself.
Human override & control
Override is a first-class action, not an escape hatch. The user can reject, correct, or annotate any suggestion without justifying themselves to the interface, without extra friction, and without the system nagging them back toward agreement. Defaults matter most here: nothing consequential proceeds on model output alone, and “accept” is a deliberate act rather than the path of least resistance. The accountability structure stays intact — the person who decides is the person the organization already holds responsible, and the interface never blurs that.
Artifact pendingOverride flow
TODO (concept mock or real project): recreated flow for disagreeing with the model — reject, correct, annotate — showing that it costs no more effort than accepting.
Error states & fallback
The system will be wrong, late, or unavailable, and the workflow has to survive all three. That means designing the degraded modes explicitly: what the screen says when the model has no answer, how stale predictions are marked before they mislead, and — most importantly — a manual path that remains a complete, practiced way to do the job. If the fallback only exists in documentation, the AI has become a single point of failure wearing a helpful face.
Artifact pendingDegraded-mode states
TODO (concept mock or real project): the recreated state inventory — no prediction, low-quality input, stale output, service down — and the manual path the user follows in each. These states get designed with the same care as the happy path.
Feedback loops
Every override, correction, and confirmation is signal — about the model, and just as often about the data or the workflow around it. The design questions are consent and honesty: users should know what their corrections are used for, feedback capture should ride inside actions they already take rather than adding chores, and disagreement must never be treated as user error. A feedback loop users understand builds the habit of correcting the system; one they distrust teaches them to route around it.
Artifact pendingFeedback capture
TODO (real project only): the anonymized design for how corrections flow back — what is captured, what the user is told about its use, and how the loop avoided becoming unpaid labeling work.
Audit trail
In trust-sensitive domains, “what did the system suggest, what did the person decide, and what did they see at the time” must be answerable months later. The audit trail records suggestion, confidence, evidence shown, and the human action taken — and it exists to make decisions reconstructable, not to put operators under surveillance. That distinction is a design decision with real consequences for whether people use the system honestly, and it deserves the same intent as any screen.
Artifact pendingDecision record
TODO (concept mock or real project): a recreated decision record — model suggestion, confidence, evidence displayed, human action, timestamp — with neutral data, plus the reasoning about who can read it and why.
Risk guardrails
Some failures should be structurally impossible rather than merely discouraged. Guardrails are decided per decision, with the domain’s risk owners at the table: which actions always require human confirmation regardless of confidence, which are capped in scope or reversible by design, and where automation is refused outright because the error asymmetry is too steep. Writing these down early also keeps scope honest — a guardrail agreed on paper is much harder to erode later under delivery pressure.
Artifact pendingGuardrail matrix
TODO (real project only): the anonymized matrix of decisions × automation level — fully manual, suggest-only, suggest-with-confirmation — and the reasoning for each boundary.
Measurement plan
The AI is worth keeping only if the human decision gets better or cheaper without new failure modes — so the plan measures the joint human-plus-model outcome against the pre-AI baseline, not model accuracy in isolation. Alongside decision quality and time: override rates and their trend, calibration between stated confidence and actual correctness, and drift in user behavior — because both blind acceptance and silent abandonment are failure modes that a healthy accuracy number can hide.
To be completed with real evidenceNo results are reported here because none are claimed. When a real deployment can be documented, this section carries measured outcomes if they are real, attributable, and cleared — and structural proxy evidence otherwise. Nothing gets invented to make the concept look shipped.
Working principles
The compact version of everything above — the positions I hold AI features against before any of them reaches a screen:
A recommendation is not an action. The model proposes; a person decides. Consequential steps never proceed on model output alone.
Confidence is visible — and designed against overtrust. Uncertainty is expressed in terms of what the user should do, and low confidence is presented loudly, not apologetically.
Evidence is inspectable. Every suggestion points at checkable evidence in the practitioner’s own vocabulary. Explanation you cannot verify is reassurance, not explainability.
The user stays in control. Overriding is as easy as accepting, requires no justification to the interface, and leaves accountability where the organization already places it.
A fallback path exists — and works. The workflow survives the model being wrong, late, or absent, because the manual path is complete and practiced, not theoretical.
Why this shape
This framework is the AI-specific edge of the same practice as my operational-product work: complex B2B domains, many roles, decisions with real consequences, and trust that has to be built structurally rather than claimed. The order of the sections is the argument — task and data before model, uncertainty and override before polish, measurement before celebration. That is also why this page is labeled a concept shell instead of dressed up as a case study: in trust-sensitive design, not overclaiming is part of the craft.
To be completed with real evidenceWhen real AI-assisted workflow projects can be documented and cleared, they attach here under the same anonymization rules as the rest of the portfolio — recreated artifacts, neutral labels, decisions over confidential detail.
