Independent Project / AI-Native UX / Design Engineering
Designing Human Control Into AI-Assisted Operations
Designing and building an evidence-first investigation workspace that separates AI recommendations, human authorization, and simulated execution.
Project statusSelf-directed working prototype. Synthetic data and simulated operations; not a client deployment.
Investigation overview
Primary investigation scope and the 37-finding risk distribution.
What this screen shows
- 37 synthetic findings span ERP, payment-platform, and vendor-master records: 28 low-risk, 6 ambiguous, and 3 high-risk.
- The risk distribution supports prioritization; it does not authorize any operation.
Overview
AI assistance without delegated authority.
This self-directed prototype explores how enterprise reviewers can investigate AI-assisted assessments without giving AI authority to make or execute consequential operational decisions.
The investigation connects vendor-payment discrepancies across ERP, payment-platform, and vendor-master records.
The workflow moves from choosing an investigation and understanding its scope to triaging findings, comparing evidence, reviewing AI advice, authorizing exact operations, explicitly starting simulated execution, and inspecting outcomes.
Investigation & triage
Establish context before deciding what needs attention.
An investigation directory and filters establish scope before reviewers enter a detailed investigation. The risk distribution helps reviewers prioritize findings within that scope.
Search, sorting, filtering, and risk distribution support triage through desktop tables and responsive mobile cards. Finding-detail navigation retains the reviewer’s context rather than making each evidence review a fresh start.
Primary investigation / Deterministic synthetic fixture
- Total findings
- 37
- Low-risk
- 28
- Ambiguous
- 6
- High-risk
- 3
Other directory investigations are summary-only scenarios. These counts describe fixture coverage, not real operational findings.
Capture sequence 01 / Investigation and triage
Actual application captures using deterministic synthetic data: investigation context followed by the expanded high-risk group.
Design decision
Severity, verification, and action readiness remain separate so prioritization does not imply permission to act.
High-risk findings
The expanded high-risk group shows three findings and preserves the investigation context.
What this screen shows
- The expanded group lists three high-risk findings with Compare evidence actions.
- F-018 reports conflicting posting counts. A duplicate posting remains an unverified hypothesis.
Evidence & AI assessment
An observation is not an explanation.
Finding F-018 supports an explicitly requested advisory assessment in mock mode or configured real-provider mode. Its narrative was corrected to distinguish an observed posting-count mismatch from an unverified duplicate hypothesis. Assessment is available for this one application finding only.
Validated structured evidence selects from predefined React comparison and checklist components. This constrained adaptation changes how evidence is presented; the model does not generate arbitrary layouts or executable interface code.
Capture sequence 02 / Evidence and assessment
These captures show synthetic evidence and a deterministic mock assessment, not a real model response. The observed mismatch does not establish a duplicate posting or financial loss.
Design decision
Evidence and AI interpretation remain distinguishable so reviewers can inspect claims rather than treating recommendations as established facts.
F-018 source comparison
Source evidence and observed posting-count mismatch, separate from the duplicate hypothesis.
What this screen shows
- F-018 compares an ERP snapshot reporting two postings with a reference snapshot reporting one. Neither simulated snapshot establishes source authority.
- The discrepancy does not establish a duplicate posting or financial loss. The proposed operation remains blocked by missing evidence.
Mock advisory assessment
Explicitly requested advice with the mock-mode indicator visible.
What this screen shows
- The deterministic mock assessment reports insufficient evidence; it is not a live-model response.
- Its advisory next step is to obtain posting-level entries, credit memos, and reversal history from the ledger owner. Separate authorization is still required for any modification.
Missing-document checklist
Missing information and recommended next steps, without implying a resolved cause.
Detail crop of the original capture; application UI is unchanged.
What this screen shows
- Credit memo history: not supplied. It is needed to check whether a credit memo offsets the apparent extra posting.
- Ledger reversal history: not supplied. It is needed to check whether a prior reversal explains the different counts.
- These are simulated source requirements; no documents have been requested, collected, or verified here.
Citation traceability
Expanded F-018-E1 simulated source evidence alongside assessment provenance and evidence-version metadata. Source authority remains unverified; the assessment comes from a deterministic mock adapter, not a live model.
Detail crop of the original capture; application UI is unchanged.
What this screen shows
- Expanded reference F-018-E1 identifies simulated ERP snapshot ERP-1018 and the observation: two postings. Source authority remains unverified.
- Assessment provenance identifies a deterministic mock adapter. Assessment and evidence-version identifiers associate the result with its captured evidence version.
- The result is cached until reload and does not establish current source-system state.
Human authorization
Advice, authorization, and execution are separate steps.
Batch selection and deterministic eligibility checks separate eligible findings from blocked ones. Selecting a finding identifies a candidate for review; it does not authorize an operation.
Exact-scope confirmation creates an authorized-awaiting-start state. AI advisory output has no direct authorization or execution channel.
The completion report and session history make outcomes inspectable. Successful verification of simulated output is distinct from resolution of an actual business discrepancy; the prototype does not establish the latter.
Capture sequence 03 / Authorization and outcomes
These captures separate readiness, exact-scope authorization, explicit start, and simulated completion. Output verification does not establish real business-discrepancy resolution.
Blocked finding / Missing evidence prevents authorization
Detail crop of the original capture; application UI is unchanged.
- F-018 is blocked and excluded from authorization scope. Credit memo and ledger reversal history have not been supplied; resolve the missing evidence with the record owner before any change.
Eligible and blocked findings
Two selected synthetic findings: F-001 is eligible for simulated authorization; F-018 is blocked by missing evidence. Eligibility alone is not authorization.
What this screen shows
- Two findings are selected: F-001 is eligible for simulated authorization, while F-018 is blocked and excluded from scope.
- F-001 proposes only invoice-reference normalization. Eligibility and selection alone do not authorize that change.
Design decision
Authorization and execution require separate user actions so approving an exact scope does not automatically initiate operations.
Prior step / Review and confirm exact simulated scope
Authorized, awaiting start
The scope-confirmation screen precedes the authorized-awaiting-start state. Authorization does not start execution; Start Execution remains a separate action.
What this screen shows
- The scope screen identifies the exact F-001 invoice-reference change and requires explicit confirmation of those simulated operations and outputs.
- After confirmation, one operation is authorized and one finding remains excluded. Start Execution is a separate action; authorization alone does not run it.
Completion report
Simulated operation outcomes and output verification, retaining the simulation context.
What this screen shows
- The report shows one authorized operation, one simulated output verified, and one finding never authorized; no failures or unverified outputs are reported.
- Output verification does not establish business-discrepancy resolution. No external system writes or real-world verification occurred.
Architecture
Two paths, with different responsibilities.
The application uses React, TypeScript, and Vite, with a small Node/TypeScript backend for assessment requests. The advisory path validates evidence and structured output before presenting advice through predefined components.
Controlled simulated operations follow a separate path through deterministic readiness checks, exact-scope authorization, and an explicit start. Advisory assessment cannot authorize or execute those operations.
Conceptual architecture / Two separate paths
Advisory assessment
Advice and evidence presentation only.
- Synthetic evidence
- Version validation
- Mock / configured real-provider assessment
- Structured-output validation
- Predefined React presentation
Controlled simulated operations
Human authorization and start are separate.
- Selected findings
- Deterministic readiness checks
- Exact-scope authorization
- Explicit start
- Simulated operations & output verification
Advisory output cannot authorize or execute operations. Exact-scope authorization and explicit execution start belong to the separate controlled path. This diagram is conceptual, not an application screenshot.
Evaluation
Useful evidence, with explicit boundaries.
The evaluation snapshot after the F-018 narrative correction includes 104 passing automated tests, five repeatable synthetic evaluation scenarios, controlled adversarial fixtures, and one saved real-provider evaluation attempt. These are different forms of evidence, not interchangeable measures of reliability or usability.
What remains unvalidated
- Enterprise records are synthetic; operations and financial outcomes are simulated.
- There are no real ERP or payment-platform integrations.
- There is no production identity or authorization system and no durable audit infrastructure.
- User outcomes have not been validated.
- AI assessment is available for one application finding, with a limited set of predefined adaptive presentation components.
- Session state and session history are not durable across reloads.
- The Assistant destination is a disconnected placeholder, not a functional AI assistant.
Evaluation snapshot / Scope and limits
104 passing automated tests
Reported source-application checkpoint after the F-018 narrative correction; specified domain, API, UI, and workflow behaviors were tested.
Does not establish usability or validated user outcomes.
Five synthetic evaluation scenarios
Repeatable synthetic scenarios exercise the evaluation harness.
Does not establish model accuracy.
Controlled adversarial fixtures
Fixtures demonstrate some structural validation behavior.
Does not prove protection against all unsupported claims or prompt injection.
One saved real-provider attempt
One recorded integration exercise.
Not a representative reliability benchmark or proof of application-level F-018 performance.
The automated-test count belongs to the separate application’s reported checkpoint. It is not a count of tests run for this portfolio page.
Reflection
Make the limits of assistance visible.
The key design challenge is keeping these boundaries understandable as reviewers move from an individual finding to a batch decision and its outcomes.
Next steps toward real-world validation include task-based review with finance and operations participants, broader assessment evaluation, and investigation of production integration, identity, and durable audit requirements. These are future validation needs, not completed research or implemented production capabilities.