Quality review
What Heimdall reads before it judges a record, how it grades and codes a finding, why the score is arithmetic, what a review costs and where it stops: it never writes to the record.
By the end of this page you will know how Heimdall's quality reviewer thinks: what it is given, what it is told to look for, how it must answer, how its answer becomes a score, and the lines it never crosses. The task itself, pressing Review now and working through the findings, is on the Quality review page of the planning guide.
What Heimdall is given
The reviewer has no tools and no memory of earlier turns. Everything it knows about the record arrives in one brief, written the same way every time:
- The record, field by field. A story's sentence, description, kind, status, priority, points, labels, epic and persona, and every acceptance criterion with its Given, When and Then; a requirement's statement, rationale, measure, verification method and source; a rule's statement, condition, action, exceptions, worked examples, authority and dates in force. An empty field is named as empty, so a missing rationale is a fact Heimdall sees, not a gap it has to guess.
- What the record is linked to, read from the record's side: the requirement a story implements, the rule a requirement honours.
- The project's business rules, each by reference, name and statement, so a conflict is named against a real rule rather than a hunch.
- The titles of the record's siblings: the other stories of the same kind, the other requirements of the same type, or every other rule in full, so a duplicate is named by reference.
- The house stack, so a record that assumes another framework is caught before a developer reads it.
Markup is stripped and long fields are cut, and anything the person asking may not read (a rule list on a project where their role cannot see rules) is left out rather than refused.
What it is told to look for
The brief carries the same standing instructions on every review: the INVEST qualities for a story, outcome and done-ness for a task or a bug, one testable statement with a rationale and a measure for a requirement, condition and action and examples and authority for a rule; vague words to flag; conflicts and duplicates to name by reference; and the house stack to hold the record to. The full checklist per kind, with the finding codes, is on the planning page.
Heimdall is told to quote the words it objects to, to suggest a rewrite in the record's own words, to report nothing when the record is sound, never to report the same problem twice, and to stop at ten findings with the most serious first.
How it must answer
The reviewer answers in a fixed shape, not prose: a short summary and a list of findings, each with a code from the fixed list, a severity of high, medium or low, a message, a suggestion and the field concerned. A finding that comes back without a message is dropped; a code or a severity the list does not know falls back to Other and Medium rather than breaking the panel. The model never names a score.
Why the score is arithmetic
A number from a model is a guess that changes between two runs on the same text. The score is instead 100 less the penalties of the findings Heimdall graded (25 for high, 10 for medium, 4 for low), floored at 0, so two reviews with the same findings score the same and a person can read why a record scored 61 from the cards alone. The band is a reading of the score: Ready from 80, Needs work from 50, Not ready below.
What a review costs
One call to the model configured for quality reviews, which thinks longer than the inline assists do, filed in the team's AI ledger under Quality reviews and counted against the month's budget on Settings → AI. The budget is checked before the call, the usage is filed right after, and only then is the review written with the ledger row it cost, so a review never exists without its cost and a failed call never costs anything. A team at its cap is refused before the model is asked.
Cost grows with what Heimdall has to read: a story with many criteria on a project with many rules costs more than a two-line task. Review a record when it changed or was never reviewed; the panel always shows the latest review, so repeating a review of an unchanged record only repeats the cost.
Where it stops
- It never writes to the record. No field, status or version changes; the findings sit beside the record for a person to act on, through the editor or an inline assist.
- It never decides for you. Ask Heimdall on a finding opens the panel with the finding in the composer and waits for you to send it.
- It never runs for a client guest, who sees neither the panel nor the badge.
- It never runs where assists are off, per project, under Settings → AI.
- It never runs unmetered. The same guard that stops any model call outside a budgeted window stops the reviewer.
The council that lands with the brief import will put more than one voice on a record at the moments that matter, such as submission for approval, and feed their accepted findings into the review queue. Today's reviewer is Heimdall alone, on demand.
Related
How is this guide?
Last updated on
Inline assists
Ask Heimdall beside any long field of an epic, story, requirement, rule, use case, RAID item, decision or dictionary entry: draft it, improve it, shorten it, make it testable or rewrite it as Given, When, Then, then take the draft or drop it.
Brief import
What Heimdall is given before it reads a brief, how it fills each kind of suggestion from one uniform row, how it judges its own confidence, why it runs on the queue as you, what it costs and where it stops.