The tracker
Every issue shows its verification state and the evidence behind it.
An issue holds its acceptance criteria, the checks that ran against them, the findings those checks produced, and the result of the retest. Everything behind it is an append-only record of who moved what, and when.
The criterion, the finding and the retest live on one issue
A criterion is written on the issue. The checks that verify it are attached to it. A finding is filed against the exact criterion it violates, with the steps and the evidence that produced it. When the work is resolved, the scenario that found the defect runs again and its result lands back on the same issue.
So “is this verified?” is answered by the issue rather than by memory. Nothing has to be reassembled from a test console, a chat thread and somebody’s recollection, and the answer outlives the person who gave it.
Ask QA
Ask QA takes a question about the work in plain language — what changed on this issue since yesterday, which criteria are still unverified, which findings are open against this project — and answers it from the tracker and the last runs.
It answers with the asker’s own permissions, inside their own workspace. A question about a project the asker cannot open produces no answer, because there is nothing they were allowed to see.
The agent behind the chat runs in a read-only mode with no write tools active: it can read the tracker and the runs, and it cannot change anything in either.
Closing is gated on the criteria
An issue cannot be closed while any of its acceptance criteria is unchecked or unlinked to a check. The refusal happens on the server, in the transition path, so it holds for the board, for the API and for anything else that tries the move.
- Criterion checked and linked: the transition is allowed.
- Criterion unchecked, or checked but linked to nothing that ran: the transition is refused.
- The answer is the same whether the caller is a browser or a script with a token — the rule lives where the state is written, not in the interface.
A gate the interface enforces is a convention. This one is enforced in the server that owns the issue.
The retest is part of the workflow
Resolving returns the issue to its reporter rather than closing it. Verification and closure belong to the QA role, the reporter or a workspace administrator — the developer who wrote the fix is not on that list.
If the retest fails, the issue goes back to the developer, and the reason for sending it back is required rather than optional.
The shipped permission scheme grants verification to the QA role, the reporter and workspace administrators, and deliberately not to developers, so nobody signs off their own work.
Teams, roles and vocabulary
One deployment hosts many workspaces. A person is a single account seated in as many workspaces as they are given, with a role in each of them: administrators, developers and QA ship as system roles, and a workspace can define its own on top.
- A permission can be granted to a role, to the reporter of the issue, to its assignee, or to one named person.
- The status vocabulary and the workflow are configured per workspace, so a team names its own stages instead of borrowing another team’s.
- Each project maps its statuses onto board columns, so two projects can share one workflow and still show different boards.
- Project keys are unique across the deployment, so an issue link keeps working wherever the issue sits.
Instance administration and workspace administration are separate tiers: being an instance administrator does not make someone a member of a workspace’s administration.
It runs without a language model
Dust calls no model provider of its own. It stores state and enforces rules, and that is what it does with no provider key configured anywhere.
Ask QA is the single place a model is involved, and the question is passed to the harness — so the call is the harness’s, made with the harness’s key, under the harness’s allowance. Dust holds no key for it.
The one external service Dust contacts itself is TypeSafe, and only when an operator sets that key: a few narrow cross-checks over the wording of a report. With no key set, the output is unchanged.
Where the findings land
Findings are filed onto the issue by the agent rather than typed in by a person, each one bound to the criterion it violates and carrying the steps and the evidence that produced it. The issue’s own state moves as the finding moves, and a reopened issue wakes the scenario linked to it.