Product
How it works
From a source to a checked requirement to what actually ran: the model, the delivery team and the two axes of the interface.
The model
One file per requirement
A requirement is a Markdown file. The top holds machine fields: id, type, parent, status, relationships and acceptance criteria. Below them are a few sentences for a human.
Files nest by parent, so the folder tree is the tree of the system. It lives in your git repository, next to the code.
Acceptance lives inside the requirement. The model describes the system as it is now; history lives in git and in the journal.
The methodology is data. Aspects, element types and relationships are declared in a YAML file. The bundled waterfall methodology is translated into five languages. A methodology can also be generated for a domain.
id · type · parent
status: draft reviewed confirmed
acceptance criteria
A few sentences for a human.
Statuses: draft, reviewed, confirmed, blocked, deprecated. The bundled methodology has aspects for sources, modules, user scenarios, user interface, data entities, non-functional requirements, implementation and metrics.
Sources
Everything that arrives is a source
A document, a bug, an incident or an idea is treated the same way: it comes in as a source and is turned into changes to the model.
Open core
Channels
Jira, GitHub Issues, Slack, Discord and Telegram, plus import of OpenSLO files.
Pro
Source fidelity
The result of analysis is checked against the source: the model does not receive what the source did not say.
The delivery team
Roles, and who owns what
spec-editor Pro adds a team of roles to the open core. Manager roles own the queues; a deterministic engine only moves events between them.
Pro
Analysts
Work on a source independently; a second pass reconciles their results.
Pro
Analysis manager
A manager role: owns the analysis queue.
Pro
Project manager
A manager role: owns the queue of delivery work.
Pro
Coder
Writes the code, on the machine where your subscription is logged in.
Pro
Tester
Checks the work against the acceptance criteria of the requirement.
Pro
Devops
Builds and deploys to the test stand; rollback exists.
Cost control belongs to this team: a difficulty classifier, a ladder of models from cheap to strong, cost attribution per source and role, budget guards, and a pool of subscription accounts with failover when one hits its limit.
Review
Review stages decided by evidence
Review stages carry risk classes A to D and are managed with spec-editor gate. A human is asked only where evidence is missing.
Every plan is deployed to a test stand (blue/green) and its acceptance criteria are run there before promotion. Rollback exists. A remote host for builds and stands is supported. Pro
Design and run
Two axes: time and medium
The element tree is on the left. For the element you select, the right side shows it along two axes: time (as designed, or what happened) and medium (text, image or dynamic).
| Time | Text | Image | Dynamic |
|---|---|---|---|
| As designed | Element card with its acceptance criteria | Trace map and the interactive graph editor: flowchart, ER, sequence, class, state and other diagrams | Delivery board, agent timeline and interaction diagram |
| What happened | Run log of operation events | Run-time trace map: which requirements actually ran | Event graph |
Run-time views fill from operation events. Code marked with an element writes them into a log that follows the tree of requirements: the level is set on any node with spec-editor set-trace and inherited by everything beneath it. Light and dark themes; the interface language is English.
Your accounts
Runs on your own subscriptions
Model providers: the local Claude Code CLI on your own subscription (no API key), API keys through LiteLLM, and local models through Ollama. We do not sell tokens, and your code is not sent to us. There is no external database: the graph index is embedded.