Skip to content
Dust & Observer

Issue tracker + QA agent

Your acceptance criteria, verified — with the evidence attached.

Dust is the issue tracker. Observer is the QA agent that verifies against your criteria and files what it finds, with proof. Together they leave a trail your auditors can follow.

  • Source readable by a licensee
  • Run it yourself, or use the shared instance
  • No cookies, no analytics, no third-party scripts
  • The numbers are published with their caveats
For QA teamsRead a real verification report first — the artefact, not a demo.See the sample report →For owners & leadershipWhat is verified before you sign off, and how to be running today.Read the leadership view →
SAMPLE-104 — Password reset link is single-use and expires after 30 minutesSynthetic example. Not a client engagement.

Verdict

Red — 1 critical finding open, 78% of automated checks pass

  • 7/9 automated checks passing (78%) across 1 suite
  • last QA-checked 2026-09-23
  • 4 open findings (1 critical)

Open risks

  • criticalReset link remains usable after it has been used once
  • highPassword change leaves other sessions signed in
  • _Full detail in Dust: http://dust.example.test/issue/SAMPLE-104 · generated 2026-09-23_

Read the whole report, and the engineer’s render of the same issue →

The problem

The verification happens. The evidence does not travel with it.

A test run produces a result, a capture, a trace, a line in a console. The tracker produces a status: To Do, In Progress, Done. What neither produces on its own is the link between them — which criterion on this issue was checked, by what, and what it showed.

So the question “is this verified?” gets answered from memory, in a meeting, by whoever ran the tests. The evidence exists. It is simply not attached to the thing being decided, and it does not survive the person who made it.

How it works

Two halves of one loop

Neither half is worth much alone: the agent has nowhere to file, and the tracker has nothing to show. The seam between them is the issue.

  1. 1

    A criterion becomes a set of checks

    Acceptance criteria live on the issue. Observer plans checks against them, including the negative cases — the ones that ask what the application does when it is supposed to refuse.

  2. 2

    A finding is filed against the criterion it violates

    Not into a document nobody opens: onto the issue, bound to the exact criterion, with the steps and the evidence that produced it.

  3. 3

    The developer resolves it, and the issue goes back

    Resolving returns the issue to its reporter. Verification and closure belong to the reporter, the QA role or an admin — and closing is blocked, server-side, while any criterion is unchecked.

  4. 4

    The tracker wakes the agent, and the check runs again

    The event log is the seam. When the linked issue moves, the scenario that found the defect runs again against the new build, and the result lands back on the same issue.

What you get

One issue, rendered for whoever has to act on it

  • Every acceptance criterion with its state — passed, failed, or not executed, and the reason when it was not executed.
  • Every finding with the evidence that produced it: the steps, the observations, the capture from the run.
  • A verdict that is arithmetic over the checks rather than an opinion, and a dismissed finding that stays visible as dismissed.
  • An append-only event log behind all of it: who moved the issue, when, and from what.

Read a sample verification reportSee the leadership render

About the proof

There are no customer logos here, because there are no customers yet.

The usual page of borrowed credibility — customer logos, quotes, a wall of five stars — would have to be invented, so it is absent. Here is what you can check instead, and how.

  • Two sample reports, rendered by Dust itself from a synthetic issue: the engineering render and the leadership render of the same one.
  • The author’s own audit numbers from seven applications — 218 runs, 197 findings filed, 118 confirmed by human review, 2 explicitly marked wrong — with the limits of that measurement stated beside them.
  • The source, readable by a licensee under the agreement, so your engineers can follow the verification path instead of taking it on trust.
  • The independence answer in full: who checks the checker, and what happens to a finding that does not hold up.

The sample reportsThe numbers and their limitsWho checks the checker

For your reviewers

Built for the questions you will be asked

  • Closing is gated on the criteria

    An issue cannot be closed while a criterion is unchecked or unlinked — enforced in the server that owns the issue, not in the interface.

  • Every change is in the log

    The event history is append-only: what moved, who moved it, and when. Nothing is edited out of it afterwards.

  • The agent borrows your permissions

    It answers with the asker’s own token, narrowed to one workspace, so it can never show more than the asker can see.

  • Three services see data, one job each

    The model, the typed judgments, and the embeddings each receive only what their step reads — documented on one page.

    What leaves the machine

  • Reproducible, not neutral

    A verification is a set of checks against a build. Run the same checks yourself and you should get the same findings.

  • Read the source, run it yourself

    The software is proprietary, licensed to the organisation that runs it, and a licensee’s engineers may read the source. The supplier question is answered in full in the pack.

    Read the pack

Start with the artefact, not the pitch.

Read the sample reportTake the pack to your teamInstall it and connect a workspace