Impact analysis

By the end of this page you will know how Heimdall's impact analyst thinks: what it is given, what it weighs, how it must answer, what of its answer is written onto the change request and what is not, what a reading costs, how the council's change impact moment reads the same brief through several lenses, and the lines it never crosses. The task itself, pressing Analyse with Heimdall and keeping or changing the numbers, is on the change requests page of the planning guide.

What Heimdall is givenCopy Anchor Link

The analyst has no tools and no memory of earlier turns. Everything it knows arrives in one brief, written the same way every time and read through the same services a person reads through, so it sees nothing the person who asked could not open:

• The request as it was raised: its reference, title, reason, priority and status, who raised it and the stakeholder it speaks for, and what is asked for.
• The impact the analyst already wrote: the scope and the risk as prose, and the numbers (the level, the schedule in days, the effort in hours), or none yet when nothing was written.
• The baseline it changes: its name, kind, status and whether the client signed it, and every record it holds by key, title and version, unlocked ones marked, so a record the request forgot can be named. A request against no baseline is weighed against the record as it stands.
• Every record the request names, in full: a story, a requirement or a rule as the quality reviewer describes it (its fields, the project's business rules, its siblings), an epic or a use case by its key, title and status, and under each what links to it from either side: the stories that implement a requirement, the tests that verify them, the rules and the data they lean on.

What it is told to look forCopy Anchor Link

The analyst is briefed for the business analyst and the project manager who will decide the request, and told never to decide it and never to invent a fact about the product:

• Scope: every record the change touches, the named ones and the forgotten ones, written as short HTML naming records by their reference; for a scope reduction, what is removed and what depended on it.
• Cost: the effort in hours for the house stack, analysis to release with no padding, and the days the schedule moves, negative when the change shortens it; the summary says what the estimate assumes.
• Risk: regressions in the records that link to the ones changed, security and data exposure, the client's expectations after a signed baseline, the dates already promised, and what the request leaves ambiguous.
• Level: low when absorbed with no date or price moving, medium when a date or the effort moves but the plan is reworked rather than renegotiated, high when the scope, the schedule or the budget needs the client's agreement again.
• Questions: at most five to put to the client or the team before the request goes to the approvers; none when the request is clear.

Where the analyst already wrote an impact, Heimdall weighs it and says where it differs rather than restating it.

How it must answerCopy Anchor Link

The answer is structured, not prose: a summary of two or three sentences, the scope and the risk as HTML, the schedule in days, the effort in hours, the level as one of the three words, the records touched as a list of reference, title and how, and the questions as a list. A row without a reference is dropped, an empty question is dropped, an unknown level falls back to medium, an effort below zero to zero, and every text is cut to the length the request's fields hold.

What is written and what is notCopy Anchor Link

The whole answer is kept once, as Heimdall's reading on the request: the summary, the scope, the risk, the records touched and the questions, with when it was read. The request's own fields are filled from it only where they were empty: the level, the schedule, the effort, the scope and the risk. A number or a text the analyst wrote is never overwritten, so a second reading changes the draft and leaves the fields alone. A request still only submitted moves under analysis, because it has now been analysed. The save is a version of the request with the reason drafted by Heimdall, and change_request.analysed goes out with the level and how many records the reading named.

What a reading costsCopy Anchor Link

Each reading is one metered call under the team's AI budget, filed as Impact analysis with the project, the person who asked and the model's tokens; the budget is asked for room before the model is called, and a team past its cap gets a refusal, not a reading. The impact model is chosen by the workspace's AI settings; it thinks before it answers.

The council on a changeCopy Anchor Link

For a change that deserves more than one lens, the council sits on its Change impact moment: Odin for the architecture and the data, Loki for the security and the exposure, Týr for the rigour and the client's agreement, Frigg for the schedule and the capacity, by default. Each voice reads the same brief the analyst reads, with the read-only tools the person who convened it may use, and leaves findings; Heimdall's verdict ranks them and names where the voices disagree. A finding that names a record the request forgot is worth more to the council than a restatement of the request's words. The sitting is convened from the request's flyout and reads under The Council there; its cost is the council's share of the budget, one call per voice plus the verdict.

Where it stopsCopy Anchor Link

• It never decides a request, never submits it to the approvers and never unlocks a record; the approval engine does that on the people's word.
• It reads through the person's own visibility: a record they may not open is named as hidden, and a client guest cannot ask for a reading at all.
• It runs only for staff with change-request:analyse and ai:use, on a project whose assists are on, within the team's budget.
• A provider that does not answer leaves the request untouched and files nothing; the message says Heimdall was unavailable.

RelatedCopy Anchor Link

• Change requests — raising, analysing, approving and seeing a change through
• Baselines — the frozen record a change request unlocks
• The council — the voices, the moments and the verdict
• Quality review — the sibling reading of one record before it is approved
• Usage and budgets — where every reading is filed
• analyse_change_impact — the same reading on an agent's word