Skip to content
Dust & Observer
Sign in

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, rendered by Dust itself.See the sample report →For owners & leadershipWhat is verified before you sign off, and how to be running it today.Read the leadership view →
SAMPLE-104 — Password reset link is single-use and expires after 30 minutesA synthetic example; no client engagement is represented.

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 test evidence never reaches the issue being signed off

A test run produces a result, a capture, a trace. The tracker produces a status: To Do, In Progress, Done. Neither one records which criterion on this issue was checked, by what, or what it showed.

So the question “is this verified?” is answered from memory, in a meeting, by whoever ran the tests. The evidence never attaches to the item being decided, and it leaves with the person who produced it.

The loop

From criterion to retest in four moves

The agent needs somewhere to file what it finds. The tracker needs something to show for the work. Four moves connect them, and all four happen on 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 that ask what the application does when it is supposed to refuse.

  2. 2

    A finding is filed against the criterion it violates

    The finding lands on the issue, bound to the exact criterion it violates, 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 the server blocks closing while any criterion is unchecked.

  4. 4

    The tracker wakes the agent, and the check runs again

    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, and a dismissed finding that stays visible as dismissed.

Read a sample verification reportSee the leadership render

An append-only event log sits behind all of it: who moved the issue, when, and from what.

About the proof

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

Customer logos, quotes and a wall of five stars would have to be invented here, so none of them appear. Everything below is something you can check yourself.

  • 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 real field use, with the limits of that measurement stated beside every figure.
  • 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. The refusal comes from the server that owns the issue, so it holds for every client.

  • 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

  • Run the same checks yourself

    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

Read a report Dust rendered itself, then connect a workspace.

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