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.
By the end of this page you will know how Heimdall's brief reader thinks: what it is given, how it is told to draft each kind of record, how its answer becomes the cards on the review queue, how the reading is metered, and the lines it never crosses. The task itself, from New Import to the last decision on the queue, is on the Brief import page of the planning guide.
What Heimdall is given
The reader has no tools and no memory of earlier readings. One brief, written the same way every time, carries everything:
- The project in two lines: its name and key, and its description when it has one.
- Every record the project already holds, by reference and title: the epics, stories, requirements, rules, use cases, RAID items and decisions, each list cut at sixty with the count of what was left out, plus the names of the terms, the personas and the stakeholders. A list the person who started the import may not read is left out rather than refused.
- The house stack, so a brief that names another technology is answered with a decision to confirm rather than quietly built on.
- The brief itself, between tags, up to 60,000 characters.
How it is told to draft
Every kind of record is answered with the same row (a title, three texts, a list, a category and two numbers), because a schema that changes shape per kind is one a model fills badly. The standing instructions say what each slot means for each kind: for a story the second text is the story sentence and the list is the criteria; for a rule the first text is the statement, the second the condition, the third the action and the list the worked examples; for a non-functional requirement the third text is the measure and the category the quality. A mapper gives the texts their names before anything is written, parses the story sentence into its three parts, splits "Given, When, Then" into a criterion's rows and "input → expected" into an example, and matches a category to the record's own enum by value or by label.
Heimdall is told to draft from the brief and not from imagination; where it adds what any product of this kind needs, it lowers its confidence and says so in the rationale. It quotes the passage each suggestion draws on word for word, so the queue can light it up. It names a record of the project as a duplicate when a suggestion repeats one. It nests stories under their epics by key, proposes the records before the improvements, and stops at sixty rows.
How the answer becomes the queue
A row without a kind or a title is dropped, a research row is dropped (research is the sweep's kind, not the reader's), a confidence is clamped to 0 to 1, a quote is placed in the brief by searching for it, and a duplicate reference is resolved against the records the brief listed. Stories are joined to their epics by the keys Heimdall gave them. The rows are written in order as pending suggestions, and the batch is marked ready with how many it holds, which provider and model answered and the ledger row the call cost.
Why the reading runs on the queue as you
A brief takes a minute or more to read and nothing should wait on it, so the batch is queued and the page polls. The queue binds the tenant as the person who started the import: every record Heimdall checks for duplicates is read with their permissions, the call is metered to them, and a batch whose starter has left the team fails with that reason rather than reading with nobody's rights.
What a reading costs
One call to the model configured for brief imports, which thinks longer than the inline assists do, filed in the team's AI ledger under Brief imports 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 are the suggestions written with the ledger row they cost; a reading that fails costs nothing and leaves the batch failed with the reason. Cost grows with the brief and with the number of records the project already holds, because Heimdall reads them all to name duplicates.
Where it stops
- It never writes a record. A suggestion becomes a record only when a person accepts it, and then through the record's own create action, with the first version saying Heimdall drafted it and the person accepted it.
- It never decides for you. Merge, reject and dismiss are a person's; Accept All Pending takes a kind at once, on your say-so.
- It never runs for a client guest, who sees neither the page nor the sidebar entry.
- 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 reader.
The research sweep that joins this module reads the brief's domain for what the client will expect and proposes research and improvement notes beside the records; the council then puts more than one voice on an imported scaffold before it is accepted.
Related
Brief import
New Import to the last decision on the review queue.
Quality review
Read what Heimdall drafted the way a developer will.
Research
What the brief never states: Heimdall reads the web for the domain's demands.
Usage and budgets
Where every reading is filed and what stops it.
Safety and permissions
The rules every Heimdall feature keeps.
How is this guide?
Last updated on
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.
Research
What Heimdall is told before it reads the web for a project, what it searches for, how its notes and suggestions are shaped and filtered, why a dismissed idea never returns, what a run costs and where it stops: it never writes to the record.