Product Knowledge Workbench
Menu

The product

How it works

Two halves and a shared core. The knowledge side turns your documents into approved, cited knowledge. The workbench takes an idea through eight stages to a handoff bundle, reading only that approved knowledge and asking you for what it cannot find. Every stage produces an artifact, every artifact is versioned, and every version records what it was built from.

An initiative overview with one card per stage, from framing to handoff, each showing its status, its artifacts with stale badges, and the gaps the workbench found.
The initiative overview. One card per stage, in the default order, with its status, gaps, artifacts, and ready marks.

First, knowledge goes in and is approved

  1. Connect and collect

    Connectors sync Confluence Cloud spaces, allowed public websites, and shared folders on a schedule. People upload files or type in manual entries.

    Produces: Documents, each with its source, versions, and provenance.

  2. Extract and index

    Each document is turned into structured blocks, headings, paragraphs, lists, tables, and spreadsheet rows, then split into passages that keep their location for citing. Passages are indexed for words and, with an embedding model such as the local embedding service, for meaning.

    Produces: Passages ready for search once the document is approved.

  3. Review and approve

    Reviewers approve or reject each document, add corrections and notes, mark conflicts, and classify what is restricted. A changed source goes back for re-review.

    Produces: Approved knowledge, the only knowledge search and the workbench can see.

Then an idea moves through eight stages

The stages are a default order, not a gate. You can start any stage, go back, or work on two at once; the workbench shows the gaps that leaves instead of stopping you.

  1. Idea capture and problem framing

    The idea becomes a problem statement, the audience, outcomes, constraints, non-goals, and the knowledge it rests on.

    Produces: A problem framing.

  2. Discovery

    The knowledge is interrogated. What is known becomes findings; disagreements between documents become open questions with both passages; missing topics become gaps with coverage counts.

    Produces: Discovery findings.

  3. Requirements

    Functional and non-functional requirements with priorities, each with a citation or an explicit assumption, and every default non-functional category covered or marked none.

    Produces: A requirement set.

  4. User flows and wireframes

    One flow per main scenario with steps, transitions, and screens, and a wireframe for every screen the flows name, with empty, loading, and error states.

    Produces: User flows and wireframes.

  5. UX and interaction design

    Interaction rules, component choices, copy and error messages, and accessibility notes for each screen.

    Produces: A UX specification.

  6. High-fidelity visual design

    Screens composed from the components of your registered design system, using its tokens only, with contrast checked against WCAG 2.1 AA.

    Produces: Visual designs and a design check report.

  7. Clickable proof of concept

    The screens assembled into a mockup you can click through, with sample content from approved documents and an annotated walkthrough drafted from the flows.

    Produces: A mockup and its walkthrough.

  8. Handoff

    Epics and stories with Given, When, Then scenarios, then a bundle export that resolves every citation and records gaps, staleness, and decisions.

    Produces: A backlog and a handoff bundle.

Each stage asks before it drafts

A question round in a stage's run panel before it drafts: three questions, one answered by choosing an option beside the passage the knowledge base already holds, one skipped and shown as an assumption, and one waiting for a free-text answer, with the time the run waits until and the actions to send the answers or stop asking and draft.
A question round in the run panel. One question answered, one skipped and shown as an assumption, one waiting for a free-text answer. From the design renders; a capture of the application is not available yet.

Before a stage writes anything, its workflow works out what it needs and looks for it in the approved knowledge and the earlier artifacts. What it finds, it shows you with the passage, so you can confirm or correct it. What it cannot find, it asks: a round of one to three short questions, each with one sentence on why it matters and, where it can, a few options to pick from.

Framing asks who has the problem and how success is measured; discovery, what to dig into first; requirements, priorities and targets; flows, entry points and roles; UX, tone and accessibility targets; visual design, brand constraints and density; the mockup, which scenarios to show; handoff, your team's story size and definition of done. You can answer, skip a question, or tell it to stop asking and draft. A skipped question becomes a visible assumption. Every answer is recorded on the version as your input, with when you gave it, and changing an answer later offers to regenerate with the new one. An administrator can turn interviews off or limit the rounds.

Each stage is worked by an agent you can steer

A run streaming its draft, with phases, knowledge searches, model calls, and cost as they happen. The run panel's test data drafts a framing about billing disputes.

A stage's workflow runs as an agent with a fixed set of tools: searching approved knowledge, reading documents and artifacts, asking you questions, and proposing a new version. Only the runtime that executes it can save anything, and it checks every identifier and citation before it does. You watch the run, steer it, and approve what it proposes.

Nothing is overwritten

The staleness panel on a requirement set: one row per reason, naming the document that changed, each with regenerate, keep as is, and merge.
The staleness panel on a requirement set. Each reason names what changed and offers the three responses.

Every change is a new version, made by a workflow or by you. A version records what it was built from: the upstream artifact versions, the document versions it cites, and the answers you gave. That record is how the workbench knows what is stale when something upstream changes, and how it can show "regenerated from requirements v3" beside a design.

The bundle goes out in the shape engineering uses

The handoff page as an engineering reader sees it: the exported bundles with schema version, size, warnings, and the gap and staleness summary, with no controls to change anything.
The handoff page, with the exported bundles, their schema version, and their warnings.

The export checks every citation again against current approved knowledge and embeds each passage, so the bundle stands on its own. It writes bundle.json against a published schema, a Markdown rendering, the mockup as one offline HTML file with its walkthrough, and the design checks. An export profile writes the same content into the folder layout a spec-driven engineering method reads, and a prompts/ folder carries the planning prompts for the architecture, the task breakdown, and the test plan.

Quality is measured, and two runs can be compared

Two evaluation runs compared metric by metric, with the configuration differences and regression flags.
Two evaluation runs compared metric by metric, with a flag where a metric moved beyond its tolerance.

Reference initiatives, each an idea with known documents, planted conflicts and gaps, a design system, and a rubric, run from idea to bundle with no human input. Deterministic metrics (citation coverage and validity, conflicts and gaps found, design checks passed, testable scenarios) and the rubric scores of a judge, a second model that scores the output and gives its reasons, are stored per run, and two runs are compared side by side with their configuration differences. Retrieval is measured the same way, so a change to models, prompts, or indexing is compared before it is confirmed.

Where it runs, and which models it uses

One application with PostgreSQL as its only required service: the database also holds the search indexes and the job queue. It runs on one computer, or on one virtual machine of your own with the demo-stage runbook. Models are reached through one gateway: OpenAI, Anthropic, or any server that speaks OpenAI's interface, chosen per task. A local embedding service runs beside the database, so search by meaning needs no third party; drafting can use a hosted model or one you run yourself.