Who it is for
For business teams
Your policies, processes, and know-how decide what a product may and may not do. The workbench makes that knowledge the only thing models work from, puts your reviewers in charge of what counts as approved, and keeps the trail from every requirement back to the passage that justified it.
What changes for you
-
Your knowledge is used, not paraphrased
Requirements quote and cite your policies and procedures. A product decision that contradicts them shows up as a conflict, not as a surprise in testing.
-
You decide what counts
Nothing reaches a model until a reviewer approves it. A correction you add travels with every citation of that passage, without editing the source.
-
You are asked where it matters
When a stage needs a fact the documents do not hold, it asks the person running it, and the answer is recorded as theirs. Gaps in your knowledge become visible, so you know what to write down.
-
You can see why
Every requirement leads back to the document version, the passage, and who approved it. Every approval, answer, and decision is in the audit log.
Your knowledge, in the places it already lives
The workbench reads from where your documents are today and keeps up with them. Connectors bring in Confluence Cloud spaces, public websites within the domains you allow, and shared folders on a schedule. People can upload Word, PDF, Markdown, text, and spreadsheet files, or type in tacit knowledge that was never written down. Spreadsheets keep their rows and columns, so a tariff table is still a table when it is cited. A new kind of source is a plugin written against a published contract.
Nothing is used until someone approves it
A document is the unit of approval. A reviewer reads it, sees what was extracted and any warnings, and approves or rejects it. Corrections and notes sit beside the source text without changing it, so the link to the original is never broken. Two documents that disagree can be marked as conflicting, and that conflict reaches the workbench as an open question.
When a source changes, the old version stays in use until it is approved again
If the text of an approved document changes at its source, the new version waits for re-review while the approved version keeps being served, with a flag. Changes to a title or formatting alone do not trigger review. When the new version is approved, every artifact that cited the old one is marked stale within one check, which runs every 15 minutes.
Restricted content stays where it is allowed to be
Any document can be classified as restricted, by hand or by a rule on its source. Restricted passages are never sent to a model run by a third party, and the product refuses before anything leaves. They can be used with a model you run yourself. They are never rendered into a mockup, and their excerpts are withheld from the handoff bundle unless your organization allows them.
How it fits the way your team works
Reviewers work one queue, filtered by source, kind, and age, with a diff for every re-review and a bulk approve for a source's first load that still records one decision per document. Nobody moves their documents: the wiki stays the wiki. Product people bring the questions your documents cannot answer, and the answers they give are kept beside the artifact for you to read.
A trail from every decision to its evidence
Every requirement and story carries its citations: the document version, the passage, where it sits in the document, and who approved it. An audit log records every approval, every artifact version, every run with the answers given in it, every key use, and every setting change.