Questions

Where you run the product: one computer, or one virtual machine of your own. The documents, their versions, the artifacts, and the search indexes are in its PostgreSQL database, and uploaded files are stored on its disk or in its object store. The only data that leaves is what a model call sends to the model provider whose key you added, and the product records every such call. With the local embedding service and a model server of your own, nothing needs to leave at all.

The passages a workflow retrieved from approved knowledge, the artifacts it is working on, and its instructions. Passages classified as restricted are never sent to a provider whose key is marked as third party; the product refuses before anything leaves and reports what it left out. Prompts and responses are kept for 90 days by default for tracing, and an admin can set that to any number of days, including none. Every call is recorded for cost either way.

People with the reviewer role. They approve or reject each document, one decision per version, and can add corrections and notes that travel with every citation. A product person can mark their own stage as checked, which is shown as a different kind of mark from a reviewer’s.

A model can still be wrong, so the product asks where it would otherwise guess, and makes the rest visible. Every requirement must cite an approved passage or be marked as an assumption with a reason, and the runtime rejects a citation to a passage that does not exist. Conflicts and gaps are reported rather than smoothed over. You read and decide every open question, and an evaluation run measures how often citations hold.

One decision per document, by people with the reviewer role, usually those who already own the policies and procedures. For a source’s first load, a reviewer can sample it and approve the whole source at once, and each document still gets its own recorded approval. After that, only new documents and documents whose text changed at the source come back to the queue; a change of title or formatting does not.

The ones you choose. The product has adapters for OpenAI, Anthropic, and any OpenAI-compatible endpoint, which includes model servers you run yourself. An admin picks the provider and model for each task, such as drafting requirements, writing wireframes, embedding passages, or judging an evaluation. A local embedding service ships with it, so search by meaning works without sending passages to anyone.

The product itself has no price on this site. Running it costs what your model provider charges for the calls it makes, plus the computer it runs on. Every call is accounted with its tokens, and with its cost when an admin has entered that model’s price; otherwise it is reported as unpriced. Budgets can alert and stop spending per organization, person, or initiative.

An organization key that an admin adds, or a person’s own key if the admin allows personal keys; a personal key takes precedence. Keys are encrypted at rest under a key that never enters the database, and they are never shown again after they are entered.

No. A run is structured work in a stage: it asks a few short questions where the knowledge has no answer, searches approved knowledge, drafts an artifact, and proposes a version you review. You can steer it, edit its draft, and cancel it, but there is no conversation to scroll back through. The result is a versioned artifact with your answers recorded on it, not a message.

No. It produces the material engineering builds from: requirements, flows, a UX specification, designs, a clickable mockup, and stories with acceptance criteria. It does not generate application code, and mockups use static sample content, never live data. It hands engineering the bundle in the folder layout their spec-driven method reads, with planning prompts for the architecture, the task breakdown, and the test plan, so the code they write starts from the evidence.

No. It reads from your wiki and folders, works from the design system you register, and hands engineering a bundle of files with a published structure. Designs are HTML and CSS rather than design-tool files. It does not create issues in a tracker; the stories are files a team imports in its own way.

Several people work at once, each on their own initiatives. Each initiative has one owner who does the work; reviewers read every initiative and mark its stages ready, and an admin can transfer ownership. Two people do not edit one initiative at the same time.

Before a stage drafts, it asks one to three short questions at a time, and only about what the approved knowledge and the earlier stages do not answer: for framing, who has the problem and how success is measured; for handoff, how big your team likes a story. You can answer, pick an option, skip a question, or tell it to stop asking and draft. A skipped question becomes a visible assumption, and an admin can turn the questions off for the organization.

Clone the repository and follow get started: three commands start the database and the application on your computer, and a setup page creates your organization. The seeded sample organization, the one in the pictures on this site, can also be explored, and each of the two fictional clients has a scripted demo; see it running explains how.

Node.js 24.7 or later, pnpm 12, and Docker with Compose. For the agent stages, a key for at least one model provider. Without Node.js, one Docker Compose command builds and serves the application instead.

You host it. It runs on one computer, or on one virtual machine of your own: the demo-stage runbook puts the application and its database behind TLS, with files in an object store, nightly backups, and a restore drill. No copy of your data is held by anyone else. Moving from one computer to a server is a database dump and restore and a change of configuration; the product and your work stay the same.

Yes. A user guide for reviewers and product people, an administrator guide, a reader’s guide for engineering, technical guides for developers with an operations runbook, the demo-stage deployment runbook, and a presenter’s script for each fictional client’s demo. They are in the repository under docs/guides/.