# AI Product Review Workspace — Reference Architecture

> Help people review an AI suggestion where they already do their work. This proposed product design keeps the original information, the suggestion and the final decision clear.

Canonical URL: https://marmation.com/lab/ai-product-review-workspace/

## About these examples

The wider Lab designs are proposals, not completed customer systems. The document review includes a working browser demonstration with 15 example orders and fixed rules. It uses no AI model or connected business software. User roles are example controls, not real sign-in, and reloading clears any changes.

A reviewer working through an order or customer document should not have to leave the task, explain it to a chatbot and copy the answer back. A suggestion beside the relevant field can help them decide while keeping the original information and final action visible.

This page proposes that review experience inside a business software product. No application has been implemented or tested. The scenarios use proposed sample data and do not describe a customer deployment or measured productivity gain.

## Put the suggestion where the person makes the decision

The user would open a work item and see structured fields drawn from the input document. A suggestion would appear beside the field it concerns, with its source, a reason or constraint and a way to edit it. A confidence category should appear only if real evaluation supports its meaning.

The user could accept, edit, defer or reject a suggestion. A versioned history would show corrections, and work would remain intact after leaving and returning. Another person with the appropriate role could review and complete the change. The first-use explanation would say what the AI does and which decisions remain with the person.

## Keep customer separation, suggestion and action distinct

**Separate each customer’s data.** In multi-tenant software, several customer organizations use one product. Every work item, document, search and action must belong to the correct tenant, or customer account. The server must enforce this boundary; hiding information in the interface is insufficient.

**Keep recommendations out of authoritative records until approved.** The product API, the interface through which software requests a change, would treat AI output as a suggestion. A typed domain layer would check its format and business rules before an update could occur.

**Isolate the model service.** An inference gateway would connect the product to the model provider through a replaceable adapter. It would enforce cost limits, timeouts and retry rules, and pin the model version so a release can be evaluated against known behavior.

**Show the stages of the work.** Proposed → edited → approved → committed → reconciled. The interface would show errors and a way to resume. Reconciliation means checking that the saved result matches the approved change.

**Evaluate more than fluent answers.** Use labeled sample cases before release, quality samples during operation, checks for malformed data, harmful-output tests and records of user overrides. Model quality and product behavior need separate evidence.

**Make correction usable.** Support keyboard operation and make the source, suggestion and final decision visually distinct. Correcting a field should not require composing a prompt.

## Compare two ways to finish the same task

The proposed trial would use sample line items with ordinary inputs, ambiguous product codes, conflicting documents, malformed inputs, an intentionally incorrect suggestion and an API timeout. Compare a separate chat panel with structured review beside the fields.

The question is where the person can understand and complete the decision. A trial would not establish a numerical productivity benefit without an appropriate baseline and measurement. No such trial has been run here.

## What a built workspace would have to demonstrate

- Changing a tenant identifier in an address must not expose another customer’s records.
- An unreviewed model suggestion must never update the authoritative business record.
- A lost connection must produce a clear error and allow the saved draft and version to be restored.
- A rejected suggestion must remain traceable without entering the final output.
- If the model service is unavailable, people must be able to continue manually.
- Model releases and product releases must have separate versioned acceptance tests.

Those conditions connect the product experience to the engineering underneath it. They remain proposed checks until there is an implementation to assess.

## When a simple summary is enough

An occasional exploratory question may need only a static summary. An inline reviewer adds engineering and maintenance cost. It is most justified when people repeatedly make important decisions using the product’s existing records and need to inspect, correct and save the result.

[Explore the Lab](<https://marmation.com/lab/>), read the [engineering articles](<https://marmation.com/review/engineering/>) or [discuss a product review task](<https://marmation.com/contact/>).

## Related reading

- [Proof has a structure.](https://marmation.com/lab/)
- [From working prototype to dependable system](https://marmation.com/review/engineering/)
- [Intelligent Document Operations — Reference Architecture](https://marmation.com/lab/intelligent-document-operations/)