Making AI-drafted regulatory documents trustworthy

How the work was structured

The design moved through rounds, each building on what the last one taught us:

• Foundations (13 March): sign-in, the dashboard, template creation and template import.

• Product creation and editing (19 March): creating a document from a template and uploading its sources.

• Ingredient document (27 April): the full review experience, including editing, viewing sources and configuring hints.

By the final round, the product's vocabulary had settled on the term Ingredient Document.

Each round went in front of users before the next one began. That loop is the main reason the later screens are more specific and more confident than the early ones.

Decision 1: Make trust visible, field by field

The most important design decision was refusing to treat a document as simply done or not done. Every field carries its own state:

• Suggestion: the AI proposed this value and no human has looked at it.

• Un-Verified: the value is present but not confirmed.

• Unsaved Edit: the user has changed it and not yet saved.

• Verified: a human confirmed it. These values appear in bold green so the finished parts of the document stand out from the rest.

• Empty: the AI found nothing. These rows are visibly shaded, so the gaps are the first thing a reviewer sees.

A reviewer can regenerate a single field, and once a section has been checked they can confirm it in one action with Verify All in Section. That matters for speed: the expert slows down where the AI is uncertain and moves quickly where it is not.

What I chose not to do: a single confidence score or a single Approve button for the whole document. Trust in a regulatory form is built one value at a time.

Decision 2: Put the evidence next to the answer

Experts do not trust a value they cannot trace. When a reviewer opens a field's source, the screen splits: the form stays on the left and the original PDF opens on the right, at the relevant page. Nobody has to open files, find the page or remember which document a number came from.

When several documents disagree, the field does not silently pick one. It shows the competing proposals, each with the file it came from, and lets the reviewer choose. For list-style content such as the composition table, a priority banner explains that suggestions come from multiple sources and offers Accept All or Reject All, so a block of rows can be handled in one move and then fixed individually if needed.

What I chose not to do: hide the source behind a tooltip or a link that opens a new tab. Comparing a value with its source is the core task of the product, so it has to be one click, side by side.

Decision 3: Let experts steer the AI in their own terms

The people who understand which document should answer which question are the USPL specialists, not the engineers. So I designed hints as something a specialist can see and edit directly on the form.

• A small icon beside each field and section shows its hint state: no hint, a single hint, or a secondary or additional hint, with a sparkle marker so it reads as AI guidance.

• A section-level prompt description lets the expert explain what a section is about, and a Test hint control lets them try it.

• Edit Hints and Edit Document are separate switches, and turning one on disables the other. A user is always in exactly one mode, so they cannot accidentally change the document while configuring the AI, or the reverse.

What I chose not to do: hide the AI's configuration in a settings page. Hints affect every document made from a template, so they belong where the template is.

Decision 4: Be honest about processing and failure

Uploading dozens of PDFs is slow and some will fail, especially scanned files. The toolbar at the top of the document shows the state of the sources at all times: Add Sources, a Processing indicator that becomes a count of processed sources, and a red Failed count with a dropdown listing what went wrong.

Failures are surfaced, not buried. A user who knows four files failed can fix them. A user who does not will assume the AI read everything and will trust a document built on incomplete evidence.

Decision 5: Teach the order of work through the empty state

The system has a dependency that new users cannot guess: a template has to exist before an ingredient document can be created. The first thing a new user sees on the dashboard is an empty state that says exactly that, with two clear paths, Import Template and Create Template.

Once there is activity, the same dashboard becomes a pipeline view: totals for documents, documents actively processing, source files and templates (with locked and draft counts), and a recent-documents table with status labels for Draft, Locked and Archived. Importing a template accepts PDF, Word and JSON files, shows upload progress and ends with a confirmation and a View link. Creating a document is a short guided step: choose a template, name the product, upload sources.

Decision 6: Make a dense, high-stakes form safe to work in

The ingredient document is long and full of tables. I kept it calm and reversible:

• Undo and Redo are always present.

• Auto Save is on, with a plain reminder to review carefully before saving.

• Save As New Template lets a user branch from an existing template instead of editing one that other documents depend on, which keeps finished work intact.

• Export JSON and a Feedback button sit in the same toolbar, so the main exits and the way to report a problem are always in reach.

Result

I will be precise about what I can and cannot claim. The scope and the results here come from design phases tested with users and from the project's stated goals, and I am not reporting final accuracy or time-saved figures.

What the work produced:

• A complete experience for AI-assisted document creation, from an empty account to a verified document: dashboard, template import and creation, document creation, review, source viewing and hint configuration.

• A field-level trust model, with five visible states, that turns the AI from a black box into a draft the reviewer controls.

• A side-by-side source view that makes checking a value fast enough to be worth doing.

• A working process in which every phase was reviewed with the people who will use the product before moving on.

The project defined success as at least 80 percent accuracy and more than a 50 percent effort reduction compared with manual creation. The design's job was to make that achievable: the AI can only save effort if experts trust it enough not to redo its work, and can only be accurate in the document if errors are easy to catch.

How I would measure the design's contribution:

• The share of fields verified through the source view rather than retyped.

• Time from upload to a finalized document, compared with the manual process.

• How often reviewers override an AI proposal, by field type, which also points to where the hints need work.

• How many documents contain failed sources at finalization.

What I would do differently

I would add a confidence signal for each suggestion, so the reviewer can prioritize the fields the AI is least sure about instead of working through the form in order. I would also make the failed-source list actionable, letting a user replace or re-upload a file from the dropdown itself. And I would capture the corrections users make as structured feedback right inside the review flow, so each document improves the next one.

Reflection

Working directly with the people who use the product changed what I designed. The interesting problems in an AI tool are rarely the AI. They are whether an expert can see what the machine did, check it against evidence, correct it quickly, and steer it next time. Designing for that, and testing it with those experts at every step, is the approach I would bring to a new product from day one.