Generated Is Not Export-Ready: Designing Review Gates for Source-Bound AI

Generating an output and approving it for use are two different product events.

That distinction may not matter much when AI is suggesting an internal note or reorganizing a draft. It matters considerably more when the output can become a statement, timeline, customer record, assessment, or formal report.

In those workflows, the main design question is not simply:

Can AI generate this?

A stronger question is:

What must happen before the generated output can leave the product?

The answer usually requires more than a confirmation dialog. It needs source references, version control, review states, permissions, and an export rule that the interface cannot bypass.

The product needs more than a generated state

A common workflow moves directly from generation to download:

Source material
      ↓
AI output
      ↓
Export

That path is convenient, but it hides several unanswered questions:

• Which source material supports the output?
• Has anyone checked that support?
• Was the source changed after the output was generated?
• Who approved the final version?
• Can every user export it?
• What exactly was included in the exported file?

A stronger product path separates the workflow into distinct states:

Source captured
      ↓
Draft generated
      ↓
Source references checked
      ↓
Human review completed
      ↓
Output approved
      ↓
Export created

The additional states are not interface decoration. Each state represents a different level of confidence and product responsibility.

A public product context

One public Ascent Innovate Software case involved an investigation SaaS platform where recorded interviews had to become transcripts, structured statements, timelines, summaries, follow-up questions, and reports.

The product kept those outputs inside a controlled case workspace. AI-generated material remained connected to the original interview and case information, while investigators could review the basis of statements and summaries before export. Private workspaces and firm-level access controls were also part of the documented product path.

The architecture patterns below are transferable approaches. They do not describe the client’s confidential internal code.

Store the evidence with the artifact

An AI-generated artifact should not contain only its final text. It should also contain the information needed to understand where that text came from.

A simplified TypeScript model could look like this:

type ArtifactStatus =
  | "draft"
  | "needs_review"
  | "approved"
  | "exported";

type ArtifactKind =
  | "statement"
  | "timeline"
  | "summary"
  | "report";

interface SourceReference {
  sourceId: string;
  sourceVersion: number;

  // Useful for audio or video sources
  startTimeMs?: number;
  endTimeMs?: number;

  // Useful for files and documents
  pageNumber?: number;
  sectionId?: string;

  // Helps detect source changes
  contentHash?: string;
}

interface CaseArtifact {
  id: string;
  caseId: string;
  workspaceId: string;
  kind: ArtifactKind;

  content: string;
  sourceReferences: SourceReference[];

  generationRunId: string;
  version: number;
  status: ArtifactStatus;

  reviewedBy?: string;
  reviewedAt?: string;

  approvedBy?: string;
  approvedAt?: string;
  approvedVersion?: number;
}

The exact fields will differ by product, but the principle remains the same:

The source relationship should travel with the output.

Do not try to reconstruct that relationship only when someone opens the review screen.

Review should apply to a specific version

Suppose a user approves version three of a report. Another person then edits the report or regenerates one section.

Version four should not inherit version three’s approval.

A simple rule is:

function updateArtifact(
  artifact: CaseArtifact,
  newContent: string
): CaseArtifact {
  return {
    ...artifact,
    content: newContent,
    version: artifact.version + 1,
    status: "needs_review",
    reviewedBy: undefined,
    reviewedAt: undefined,
    approvedBy: undefined,
    approvedAt: undefined,
    approvedVersion: undefined,
  };
}

Any meaningful change should return the artifact to review.

This can include:

• Regenerating the output
• Editing its text
• Adding or removing source material
• Replacing a source file
• Changing a referenced transcript segment
• Moving the artifact into another case or workspace

Otherwise, the interface may display an approval that no longer applies to what the user is seeing.

Missing references should block approval

A source-bound workflow should define minimum evidence requirements for each artifact type.

For example:

• A statement may require at least one transcript segment.
• A timeline event may require a timestamped source.
• A summary may require references across the material included in its scope.
• A report may require every included section to have passed review.

The product should evaluate these rules before allowing approval:

function hasRequiredEvidence(
  artifact: CaseArtifact
): boolean {
  if (artifact.sourceReferences.length === 0) {
    return false;
  }

  return artifact.sourceReferences.every(
    (reference) =>
      Boolean(reference.sourceId) &&
      reference.sourceVersion > 0
  );
}

A missing source should not appear as a minor warning beside an active export button.

When source support is required for the output to be trusted, it should also be required by the workflow.

Export should be a controlled state transition

An export button is often treated as a presentation feature. In a sensitive workflow, it is closer to a release operation.

The export service should verify several conditions:

interface Actor {
  id: string;
  workspaceId: string;
  permissions: string[];
}

function canExport(
  artifact: CaseArtifact,
  actor: Actor
): boolean {
  return (
    artifact.workspaceId === actor.workspaceId &&
    artifact.status === "approved" &&
    artifact.approvedVersion === artifact.version &&
    artifact.sourceReferences.length > 0 &&
    actor.permissions.includes("case.export")
  );
}

The backend must enforce this rule even when the interface already hides or disables the export button.

A complete export event can also record:

• The approved artifact version
• The approving user
• The exporting user
• The export time
• The source versions
• The output format
• A stable export identifier

This creates a record of what left the system and under which approval.

Five failure paths worth testing

1. The source changes after review

Replace or edit a source file after the artifact has been approved.

Expected result: Approval is invalidated, or the product preserves the approved source version clearly.

2. The artifact is edited after approval

Change one paragraph after approval.

Expected result: The new artifact version returns to review and cannot be exported using the previous approval.

3. A source reference cannot be opened

Remove access to a referenced file or transcript segment.

Expected result: The reviewer sees the failure and approval is blocked.

4. A user changes workspaces

Attempt to access or export the artifact using credentials from another firm or workspace.

Expected result: The backend rejects the action regardless of any client-side state.

5. An export request is retried

Send the same request after a timeout.

Expected result: The operation is idempotent and does not create multiple conflicting export records.

Human review must have a defined job

Adding a human review step does not automatically make a workflow safer.

The reviewer needs to know what they are reviewing:

• Factual support
• Source completeness
• Participant attribution
• Timeline order
• Missing context
• Output wording
• Permission to release

The review interface should make these checks possible without forcing the user to search across disconnected tools.

The NIST Generative Artificial Intelligence Profile also notes that some uses of generative AI may require additional human review, tracking, documentation, and management oversight.

The appropriate controls depend on the context and potential consequence of the output.

A practical product test

Before allowing an AI-generated artifact to leave the product, check:

1. Can the reviewer open the supporting source?
2. Does approval belong to the current artifact version?
3. Do edits or regenerated sections reset approval?
4. Is export permission checked on the server?
5. Can the product show who approved and exported the artifact?
6. Does the exported file represent an immutable approved version?

When several answers are unclear, the workflow may have generation without controlled release.

AI can prepare the material.

The product must decide when that material is ready to carry consequence.

Related project

AI Investigation SaaS Platform

Sources

• Ascent Innovate Software: AI Investigation SaaS Platform
• NIST: Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile