Strengths
What makes it different
Each strength starts with what changes for a product or business team, then shows the mechanism in the product that makes it true. Each mechanism is something you can see in the product and check for yourself.
Drafts that rest only on what your organization approved
A product person gets a draft built from your policies and procedures, and a business team knows nothing unapproved went into it.
A model can only be as trustworthy as what it reads. The workbench makes approval the gate between your organization’s documents and everything a model touches, so the people who own a policy decide whether it shapes a product. Reviewers add corrections, notes, tags, and context beside the source text, so the original is never edited and the correction travels with every citation of that passage.
The proof: Approval before use
Every document has a trust state: ingested, pending review, approved, rejected, superseded, or archived. The interface the workbench uses to read knowledge returns approved content only, and a test proves it cannot be asked for anything else. Reviewers can search unapproved content in a separate, labeled reviewer mode whose results cannot be cited. When an approved document changes at its source, the approved version stays in use, flagged, until the new one is reviewed.
Questions instead of guesses
Where your documents are silent, each stage asks you, briefly, and keeps your answer as yours instead of inventing one.
The questions are the ones a good colleague would ask in the first meeting: who has the problem, how success is measured, what is out of scope, how big a story should be. They are short, never repeat what you already wrote on the initiative, and never ask what a cited passage already says. You can always say “just draft it” in one action. Changing an answer later offers to regenerate the artifact with the new one, so the record and the draft stay in step.
The proof: Stage interviews
Before a stage drafts, its workflow lists what it needs and looks for each point in the approved knowledge and the earlier artifacts. What it finds, it shows with the citation so you can confirm or correct it. What it cannot find, it asks in a round of one to three questions, each with why it matters and, where possible, options to pick from. A round waits for you until it expires, then the run continues with assumptions and says so. Each answer is recorded on the new version as human input beside its question, with who answered and when; a skipped question becomes an assumption marker or an open question. An administrator can turn interviews off or cap the rounds per run.
Every statement can be defended
Every requirement and story points to the exact approved passage it rests on, or says plainly that it is an assumption.
In a review, “where did this come from?” has an answer one click away. “Assumption” is a first-class answer too: a requirement without evidence carries the badge and the reason, and stays visible as one all the way to the bundle. The evaluation runs measure the share of citations that still resolve at the end of a run, and anything below all of them is flagged.
The proof: Citations resolved at export
A citation names a document version and a passage, with its location (heading path, page, table rows, or sheet rows), the approval record, a content hash, and an excerpt. The runtime that saves an artifact rejects a citation to anything that does not exist. When the handoff bundle is exported, every citation is checked again against the current approved knowledge and embedded with its surrounding section, so the reader needs no access to the knowledge base.
You know when work is out of date, and you decide what happens
When a cited document or an earlier artifact changes, everything built on it is marked stale, and you choose the response.
Change is shown, never prevented: before you roll back or edit an upstream artifact, the workbench says how many artifacts that will make stale and lists them. Regenerating a chain runs the stale artifacts in order after a cost estimate, and skips artifacts you edited by hand unless you include them. A decision to keep an artifact against a newer source travels into the handoff bundle, so engineering sees it was deliberate.
The proof: Staleness and the three responses
Each artifact version records the upstream versions it was built from and the document versions it cites. A version is stale when one of those is no longer current. Changed knowledge is checked every 15 minutes, when you open an artifact whose check is a day old, and on every export. Each reason offers three responses: regenerate it from the new inputs, keep it as is with a recorded note, or merge the new version with your edits in a three-column view, with the agent's help on any conflict.
Screens that look like your product, and are safe to open
Designs and mockups are built from your design system's tokens and components and shown in a sandbox that cannot reach the application.
Stakeholders click through something that already looks like your product, with every color and type size taken from your design system. You change a screen by pointing at an element on it, or leave a note anchored to it for the next draft, and the change goes through the specification so the checks still hold. Every design and mockup version has a contrast report for its color pairs, and each screen links back to the requirements and flow steps it implements. The mockup exports as a single HTML file that opens offline with navigation working.
The proof: Design-system screens rendered in a sandbox
The model never writes markup. It produces a screen specification against the components' declared properties, and a fixed renderer turns that specification into one self-contained HTML document the same way every time, using only the registered tokens. The document carries a content security policy, a browser rule, that allows only its own runtime script and stylesheet, and the application shows it in a sandboxed frame without access to the application's cookies, storage, or page.
Quality you can measure before you rely on it
Change a prompt or a model and see, metric by metric, whether the output got better or worse.
Nobody has to take a vendor’s or a colleague’s word that a new model is better for your work. A metric that moves past its tolerance is flagged, and the owner records a verdict. Retrieval has its own evaluation, with standard search-quality measures (how many of the right passages were found, how high they ranked, and how fast) per run, and a change to chunking or embeddings is compared against it before it is confirmed. The two fictional clients’ scripted runs are scored the same way, so the product’s behavior is compared across two very different domains.
The proof: Evaluation with metrics and a judge
Reference initiatives are fixtures: an idea, a set of documents with planted conflicts and gaps, a design system, and a rubric. A run takes one through every stage with no human input, then computes deterministic metrics (citation coverage and validity, conflicts and gaps found, topic coverage, design checks passed, screens covering must requirements, testable scenarios) and asks a judge, a second model, to score the rubric's questions with a rationale. Two runs are compared side by side with their configuration differences.
Spend you can see and cap
Every model call is accounted for, with its cost or a plain statement that no price is set, and budgets stop spending when you say.
A business owner can see what an initiative cost to draft, stage by stage, before anyone asks. Usage reports break spend down by task, person, initiative, stage, model, key source, and knowledge source.
The proof: Cost visibility
Each call records the organization, the person, the task, the initiative and stage, the model, the key used, and the tokens. Costs come from the prices an admin enters per model; a call without a price is reported as unpriced, never as free. Budgets raise an alert at a chosen fraction and can stop spending. A run shows its cost as it accrues, and regenerating a chain of stale artifacts shows an estimate from past runs first.
Your choice of models, local or hosted
Use OpenAI, Anthropic, or any OpenAI-compatible server, chosen per task, with keys you hold, and a local embedding service that keeps search on your machine.
You are not tied to one vendor’s roadmap or prices, and restricted content can be worked on by a model you run. Keys are stored encrypted, per organization. A person’s own key takes precedence over the organization’s when the admin allows personal keys, and a missing key is a clear error.
The proof: Model and provider independence
Every model call goes through one gateway with an adapter per provider: OpenAI, Anthropic, and OpenAI-compatible, which covers servers you run yourself. Each task (framing, requirements, embeddings, the judge, and so on) maps to a provider and a model per organization, so changing models is configuration. A local embedding service runs beside the database as an optional container and serves the embeddings task with a small open model. Embeddings live in one space per model, and moving to a new embedding model fills a new space and switches over only after the retrieval evaluation compares them.
Each organization's knowledge stays its own
Each organization's documents, artifacts, keys, and costs are kept apart by the database itself.
A team, a business unit, or a client can share one install without sharing knowledge. A person can belong to several organizations and switch between them; everything on screen follows the organization chosen. The two fictional clients are loaded into organizations of their own for the same reason, and neither’s search returns the other’s content.
The proof: Isolation per organization
Every table of organization data carries the organization and a row-level security policy in PostgreSQL, so a query can only see the organization the request belongs to. The application's data layer adds the same condition to every statement as well. Each organization's secrets are encrypted under its own key. The isolation tests read one organization's data as a member of another through every entry point and must find nothing.
Room for your sources and your stages
New sources and new stage workflows are added as plugins, each declaring what it may reach before you turn it on.
When your knowledge lives somewhere unusual, or your team works through a stage differently, you add a plugin rather than change how you work. The connector contract handles discovery, incremental change, removals, and resumable syncs, so a new source needs only the part that talks to that system, and the connector guide walks a developer through one.
The proof: Plugins for connectors and workflows
Every connector and every stage workflow, including the eight built in, is a plugin with a manifest: its version, its configuration, the hosts it may call, what it may read, and the model tasks it may use. An admin sees those permissions before installing it for the organization, and the runtime gives the plugin only the capabilities it declared. Every value that crosses the boundary is plain data, so plugins that run inside the application can run in a separate process without changing.