AI Content Workflow Platform

A traceable local product workflow that connects source evidence, human decisions, AI output and final delivery.

The question

How do you turn an ambiguous content request into a testable product workflow without handing key decisions to the model?

Approach

  1. Preserve source material before analysis begins.
  2. Let people choose direction before AI produces candidates.
  3. Keep AI job receipts and candidate lineage reviewable.
  4. Separate implementation completion from browser acceptance.
  5. Deliver the private product as a Windows x64 executable.

Result

A complete vertical slice passed browser UAT and was delivered as a single Windows x64 executable with loopback-only boundaries.

Evidence

First-party product records, browser UAT, a Windows delivery manifest and sanitised interface evidence.

Content generation was not the real bottleneck

An ambiguous content request can quickly fragment across source files, AI conversations and manual edits. This project turned that work into a local product workflow: preserve the source, let a person choose direction, generate a candidate, then complete human editing and acceptance before delivery.

Before the product
Requests, source evidence and AI output lived in separate places, making decisions difficult to reconstruct.
After the product
Each stage retains its input, decision and output in one traceable chain.

Keep the model inside a human-owned decision system

AI accelerated analysis, candidate generation and implementation. Aaron kept the decisions that determine product scope, evidence quality and final delivery under human control.

  1. Define the problem before the features,Discovery and a Lean PRD narrowed the first product slice and its completion criteria.
  2. Make human decisions explicit,People choose direction, edit the candidate and decide whether the result can be delivered.
  3. Keep every AI run reviewable,Source records, context manifests, job receipts and candidate artifacts remain separate.
  4. Separate build completion from UAT,The browser flow was tested after implementation, including failure states, reload behaviour and navigation.
  5. Accept the Windows product, not the development environment,The final delivery criterion was a launchable local executable.

A traceable path from source to accepted delivery

The workflow gives every stage a defined input and output. When something fails, the team can return to the stage that owns the decision instead of rewriting the entire result.

  1. Preserve the source,Create a source record and raw snapshot before interpretation.
  2. Choose the direction,AI proposes options; a person selects the problem worth solving.
  3. Generate a candidate,The model works from versioned context and leaves a job receipt.
  4. Edit deliberately,A candidate becomes a deliverable only after human revision.
  5. Accept and record,Browser UAT and manual publication records close the workflow.

The product was accepted as a bounded local system

Completion required more than a working screen. The core lineage had to run end to end, failure states had to remain visible and the private product had to launch in its Windows delivery form.

Product definition
The Lean PRD fixed the single-user local scope, non-goals and acceptance criteria.
Integration and UAT
Core tests, provenance fixtures, Relay tests and the production build passed before browser acceptance.
Windows delivery
The private product ships as one Windows x64 executable and keeps application traffic on loopback.