An agentic investigation workspace, turning scattered data into an auditable evidence trail.

Quality Investigation Agent hero
Product Quality Investigation Agent

An agentic investigation workspace within Oracle's quality management product, designed for Quality Engineers in regulated manufacturing. The tool pairs human judgment with specialized AI agents to surface the context behind every defect, accelerating investigations and producing audit-ready Problem Reports.

Details
  • surface Web-based investigation workspace
  • role — solo designer embedded with PM and engineering Senior UX Designer
  • scope Problem Framing · Interaction Design · AI Reasoning Surfaces · Design Direction
Problem Data-Rich, Visibility-Poor

When a quality issue surfaces in regulated manufacturing, the data already exists, scattered across quality records, manufacturing logs, and inventory systems. Quality Engineers spend days stitching it together. Every day spent reconstructing context is a day production lines sit idle and costs climb.

Solution An Agentic Investigation Workspace

A single workspace where specialized AI agents surface evidence, recommend actions, and produce audit-ready Problem Reports. The design moved the engineer from stitching scattered data to reviewing an auditable argument, with the AI making the case and the engineer keeping command.

Result Design Direction Reached, Project Unshipped

In one month the project went from an empty page template to a fully defined agentic investigation workspace, three specialized AI agents, a node-based navigation model, and an interaction framework that makes AI reasoning auditable at every layer. The project was paused before it could ship; what's shown is the direction the work reached.

Context

Oracle's quality management product serves the engineers responsible for catching defects before they become recalls, investigators who work under regulatory scrutiny, where every claim has to be correct and traceable.

Oracle's quality management product is part of the SCM Execution suite, the software manufacturers use to run production. The quality engineer sits inside that system as the investigator-of-record: when a defect surfaces, they respond, figuring out what happened, who else was affected, and what to do next. Every investigation produces a Problem Report, an auditable artifact that documents the evidence, conclusions, and actions taken, and every claim inside one has to hold up to inspection.

Problem

The data and tools were there. What didn't exist was a way to move through them with the efficiency needed.

Quality engineers had everything they needed to investigate, scattered across the Oracle products they already used. Quality records in one place, manufacturing logs in another, inventory data somewhere else. There was no shortage of evidence, only a shortage of navigation.

Investigations don't move in a straight line. A flagged lot points to a parent batch, which points to a process deviation, which points back to an ingredient supplier. Each finding opens new questions, and the engineer has to hold the whole thread together while searching across systems that weren't designed to talk to each other.

Every day spent reconstructing context was a day production lines sat idle and costs climbed.

Problem Report
Goals + North Star

To design an investigation workspace that lets quality engineers move from stitching scattered data to reviewing an auditable argument, with the AI making the case and the engineer keeping command.

Surface the Evidence: Pull the data the engineer would otherwise hunt for and present it where the decision is being made, with the reasoning visible alongside it.

Match the Investigation, Not the Data Model: Build the workspace around how investigations actually unfold. They're cyclical, branching, and recontextualizing, not the way the underlying systems are organized.

Keep the AI Auditable: Make every recommendation traceable to its evidence. The engineer should be able to verify any claim in one click, because regulators will.

Process + Key Insights

I worked from the PM's existing requirements doc, mapped the investigation process alongside the quality engineers' real workflow, and organized the data domains Oracle already owned into a framework simple enough to navigate.

Key Insight 1

Investigations Loop. A Problem Report isn't built linearly. One suspect leads to another, each finding opens new questions, and the engineer has to follow the thread without losing where they started. The workspace had to support that movement, not flatten it.

Key Insight 2

The Data Was Already There. The agents weren't built on new data. The categories already existed across Oracle's products as isolated points. The design move was recognizing that each one answered a distinct investigative question, and organizing them around four questions: what was affected, where was it found, why did it fail, when has this been an issue.

Key Insight 3

Terminology Hides the Logic. A quality engineer doesn't need to know they're using a "Transactional Intelligence Advisor." They need to know they're answering why did this fail. Framing the architecture around investigative questions, not product domains, made it legible without training.

Solution

A workspace that moved the engineer from searching to reviewing, with specialized AI agents surfacing the evidence and the engineer keeping command of the investigation. Three design decisions defined how the system worked.

Design 1/3

The Mental Model

the template stays out of the way

Quality engineers already had a working mental model: validate, decide, communicate. The design move was to let the template disappear. Validate stopped meaning "search five systems" and started meaning "review what surfaced." Decide stopped meaning "cross-reference manually" and started meaning "approve what was recommended." Communicate stopped meaning "assemble the report" and started meaning "synthesize what was found."

The Mental Model — data architecture
Design 2/3

Nested Context

three levels, one thread

A quality investigation moves through relationships, not categories. A suspect lot points to its parent, to siblings, to the work order and to the operator. Every node is both a destination and a lead. The workspace adopted that structure directly: each item recontextualizes the screen around it. Three nested levels build inward from there. Summary, Advisor Expanded, Item Record. Each one deepens the visibility without losing the thread.

Nested Context — three levels of investigation
Design 3/3

Scope-Aware Natural Language

an AI that shows its work

A chatbot layered on top of the workspace would have answered the wrong questions. The engineer needs answers they can verify, cite, and stand behind in a regulated Problem Report. The design move was to make the interface scope-aware, reasoning within the engineer's current context, and to make every claim traceable to its source record the moment it appears. Where consumer LLMs cite sources from the web, the Quality Investigation Agent cites evidence from the engineer's own investigation. The AI proposes. The engineer audits. The Problem Report holds up.

Scope-Aware Natural Language
Where Work Was Headed

The design was resolved, and untested. Layoffs in early 2026 cut the work short before the framework could be put under real load.

The immediate next phase was usability testing with quality engineers at customer sites. The framework held up in design reviews, but the real question was whether it held up under load. Could an engineer move through a branching, recontextualizing investigation without losing the thread? Could the AI's reasoning stay legible across three nested levels of context? That's what the next phase was designed to find out.

The framework held. The interactions were defined. What it didn't get was the time to be tested against the engineers it was designed for.