Status Reference
Every status badge the application shows, enum by enum: client and project lifecycle statuses, project health, the review of a glossary term or data entity, design reference kinds, Git providers, epic statuses and priorities, work item kinds, statuses, resolutions, priorities, bug severities and criterion kinds, requirement kinds, categories, verification methods and statuses, business rule kinds, use case flows, RAID kinds, areas and statuses, decision kinds and statuses, baseline kinds and statuses, change reasons, change request statuses and impact levels, document statuses, sprint statuses, link kinds, attachment kinds, quality bands and finding severities, import, research, council sitting, council finding and suggestion statuses, suggestion kinds, revision reasons, webhook delivery states and the states of a Heimdall action.
Every status in Zuse Bifrost is a fixed set of named states, shown as a coloured badge wherever the record appears and sent as a lower-case code over the REST API, the MCP server and the webhook events. This page lists each set, what every state means and what moves a record into it. Statuses are never user-defined: a project configures which board columns it shows and what a checklist demands, not new states.
Codes and labels
The badge shows the label in the first column; the API, the MCP tools and the event payloads carry the code in the second. A filter on a list page takes the code.
Client status
The lifecycle of a client account, set by hand on the client's record.
| Label | Code | Meaning |
|---|---|---|
| Prospect | prospect | A client you are talking to, with no project started yet. |
| Active | active | A client with at least one project in flight; the default for a client with live work. |
| Dormant | dormant | A client with no active project at the moment, kept for its history and a possible return. |
| Churned | churned | A client that has left; their projects stay readable, nothing new is started under them. |
Project status
Where a project stands in its lifecycle, set on the project's record and shown in the registry, the project selector and Heimdall's answers.
| Label | Code | Meaning |
|---|---|---|
| Discovery | discovery | The brief is being gathered; the intake has started and the scope is not settled. |
| Planning | planning | The scope is being written down and approved: epics, stories, requirements, rules. |
| In development | in_development | Sprints are running against the approved backlog. |
| In testing | in_testing | The build is under test: plans are executed, defects raised, UAT prepared. |
| Live | live | The product is in production use. |
| Maintenance | maintenance | Live and under a maintenance arrangement: incidents, tickets and change requests come first. |
| On hold | on_hold | Paused by the client or by Zuse; nothing moves until it is resumed. |
| Archived | archived | Closed. Read-only, left out of lists unless archived projects are asked for. |
Project health
A summary the application recomputes from the record, never set by hand: overdue work, failing test runs, open severe incidents and stalled approvals each weigh on it as the modules that raise them land.
| Label | Code | Meaning |
|---|---|---|
| On track | on_track | Nothing overdue, nothing failing, nothing stuck. |
| At risk | at_risk | Something needs attention this week: an overdue item, a failing run, a stuck approval. |
| Off track | off_track | Several signals at once, or a severe incident open past its SLA. |
| Not assessed | unknown | Too new or too empty to judge; the badge stays grey until the record fills in. |
Environment kind
What an environment is for, set on its record. The kinds are also the order the table lists environments in and the order releases will promote through; a client guest is shown the UAT and production environments only.
| Label | Code | Meaning |
|---|---|---|
| Local | local | A developer's own machine; listed so its conventions are written down. |
| Development | development | The shared environment the team deploys work in progress to. |
| QA | qa | Where the QA team executes test runs against a build. |
| Staging | staging | A production-like environment for final checks before a release. |
| UAT | uat | Where the client tests and signs off what was built. |
| Pre-production | preproduction | A mirror of production for rehearsing releases and migrations. |
| Production | production | The live environment the client's users depend on. |
| Custom | custom | An environment none of the other kinds describe. |
Environment health
What the last check of an environment's health check address found, or what a monitoring system
reported over the API. Written by the application, never set by hand; a change from one health to
another is announced as environment.health_changed.
| Label | Code | Meaning |
|---|---|---|
| Healthy | healthy | The address answered with a success status. |
| Degraded | degraded | The address answered, but not with a success status: a redirect, a 404, a 401. |
| Down | down | The address answered with a server error or did not answer within the timeout. |
| Not checked | unknown | No health check address is set, or the first check has not run yet. |
Stakeholder side
Whose side a stakeholder speaks for, set on their record. The side says whose sign-off their approval is and groups the people page.
| Label | Code | Meaning |
|---|---|---|
| Client | client | Someone on the client's side: the sponsor, the product owner, the people who sign off. |
| Zuse | zuse | Someone at Zuse who speaks for the project: an account manager, an architect, a department head. |
| Third party | third_party | A vendor, an auditor, a regulator, a partner: anyone outside both organisations. |
Influence, interest and proficiency
One three-step scale rates a stakeholder's influence and interest and a persona's tech proficiency, so the badges read the same wherever a rating appears.
| Label | Code | Meaning |
|---|---|---|
| Low | low | Little weight, little attention, or little ease with new software. |
| Medium | medium | The default: worth keeping informed, follows the project, manages everyday tools. |
| High | high | Their word decides, they follow every change, or they take to new software without help. |
RACI letter
A stakeholder's default part in a RACI matrix: the letter they get on an epic unless the epic says otherwise. Set on the stakeholder's record, staff only.
| Label | Code | Letter | Meaning |
|---|---|---|---|
| Responsible | responsible | R | Does the work or sees that it is done. |
| Accountable | accountable | A | Answers for the outcome; one person per decision. |
| Consulted | consulted | C | Is asked before a decision is made. |
| Informed | informed | I | Is told once a decision is made. |
Artefact status
The review of a reference artefact: a glossary term, a data entity or a use case. A term or an entity is moved by hand from the list or the flyout, or through the status endpoints; a use case reaches in review and approved through its approval and is moved by hand otherwise. A client guest sees an artefact while it is approved and not otherwise.
| Label | Code | Meaning |
|---|---|---|
| Draft | draft | Being written; the team reads it, the client does not yet. |
| In review | in_review | Put up for review; waiting for the people who approve it. |
| Approved | approved | Agreed and read by everyone, the client included. |
| Deprecated | deprecated | Retired; kept for the record and no longer used in new work. |
Draft, in review and approved may each move to any other status, the review states of a use case only through its approval; a deprecated artefact can only go back to draft, so a retired word, entity or use case is rewritten before it is approved again.
Design reference kind
What a design reference points at, set when the link is added. The badge colour groups the cards on the Designs page and the kind filter reads it.
| Label | Code | Meaning |
|---|---|---|
| Figma | figma | A Figma file or frame: the designs as the designer keeps them. |
| Wireframe | wireframe | A low-fidelity sketch of a screen or a flow. |
| Prototype | prototype | A clickable prototype the client can walk through. |
| Screenshot | screenshot | A picture of a screen as it is or as it should be. |
| API contract | api_contract | An OpenAPI or similar contract the developers build against. |
| Sequence diagram | sequence_diagram | A diagram of who calls whom, in what order. |
| Entity diagram | erd | A diagram of the entities and how they relate. |
| Document | document | A written document: a spec, a brief, a guideline. |
| Other | other | Anything else worth a link; the default when nothing fits. |
Git provider
Where a repository is hosted, set when it is registered. The provider decides the address derived from the owner and the name, and which integration will connect the repository once Git hosting lands.
| Label | Code | Meaning |
|---|---|---|
| GitHub | github | Hosted on GitHub; the GitHub App connects it first. The default. |
| GitLab | gitlab | Hosted on GitLab, cloud or self-managed; the connection follows GitHub. |
| Bitbucket | bitbucket | Hosted on Bitbucket Cloud; the connection follows GitHub. |
Webhook delivery status
What became of one event posted to one endpoint, shown on the deliveries log and returned by the deliveries endpoint and tools.
| Label | Code | Meaning |
|---|---|---|
| Pending | pending | Queued or between attempts; the next attempt is scheduled. |
| Delivered | delivered | The endpoint answered with a success status; the delivery is finished. |
| Failed | failed | The last attempt was refused or timed out and another attempt is still due. |
| Dead | dead | Every attempt failed, or the endpoint's allowed addresses refused the host; it is dead-lettered until someone retries it. |
Heimdall action status
What became of a tool Heimdall ran or asked leave to run, shown on the work timeline and the confirmation cards in the panel.
| Label | Code | Meaning |
|---|---|---|
| Ran | ran | A read or an additive tool that ran at once and answered. |
| Awaiting confirmation | pending | A destructive tool held behind a card, waiting for Confirm or Cancel. |
| Confirmed | confirmed | You confirmed the card; the tool ran and Heimdall finished its answer. |
| Cancelled | rejected | You cancelled the card; nothing ran. |
| Expired | expired | Nobody answered the card within ten minutes; ask again and Heimdall prepares it afresh. |
| Failed | failed | The tool threw before it could answer; nothing was changed by it. |
Epic status
Where an epic stands, from the first draft to done. In review and approved are reached through the epic's approval; the other moves are made by hand from the list or the flyout, or through the status endpoint. A client guest sees an epic once it is approved and from then on, through in progress and done, and loses it when it is cancelled.
| Label | Code | Meaning |
|---|---|---|
| Draft | draft | Being written; the team reads it, the client does not yet. |
| In review | in_review | Put up for review; waiting for the people who approve it. |
| Approved | approved | Agreed as scope and read by everyone, the client included. |
| In progress | in_progress | Being built; its stories are on the board. |
| Done | done | Delivered; every story under it is done. |
| Cancelled | cancelled | Dropped; kept for the record and never built. |
A draft is submitted for review or cancelled; a review is approved or returned to where it stood by the approvers; an approved epic is submitted again when it changes, goes on to in progress or to cancelled; one in progress goes to done or cancelled; a done epic may be reopened to in progress; a cancelled one is revived as a draft.
MoSCoW priority
The priority of a planning artefact, agreed with the client in four words. Epics, requirements, business rules and use cases carry one. The badge shows the letter; the sprint planner and the release composer read the rank.
| Label | Code | Letter | Meaning |
|---|---|---|---|
| Must have | must | M | The release cannot ship without it. |
| Should have | should | S | Important, and the release ships without it only with a reason. |
| Could have | could | C | Welcome if time allows; the first thing to drop. |
| Won't have | wont | W | Agreed to be left out this time, written down so nobody asks again. |
Work item kind
What a row of the backlog is. All six kinds share the project's tracker sequence and the columns every item carries; a kind adds its own fieldset in the editor and the record keeps only the fields of the kind it is. The badge is painted in the kind's colour and carries its icon.
| Label | Code | Meaning |
|---|---|---|
| Story | story | Something a persona wants, with the criteria that say when it is done. |
| Task | task | A unit of work that is not a story in itself. |
| Sub-task | subtask | A piece of a story, a task, a bug or an improvement; it must have a parent. |
| Bug | bug | Something that does not work as agreed, with its severity and how to reproduce it. |
| Spike | spike | Time-boxed research or a prototype that ends in an outcome, not a feature. |
| Improvement | improvement | A small change to something that already works. |
A sub-task must hang under a parent and a bug may; a story, a task, a bug or an improvement may be that parent.
Work item status
Where a work item stands, from the backlog to done. Moved from the Backlog page, the flyout, the
status endpoint or the move_work_item tool; the board, the Git integration and the Definition of
Done will move items too as they land. A client guest sees an item once an approval pins it.
| Label | Code | Meaning |
|---|---|---|
| Backlog | backlog | Written down and waiting; not yet planned. |
| Ready | ready | Refined and ready to be picked up. |
| In progress | in_progress | Being built. |
| In review | in_review | Built and in code review. |
| In QA | in_qa | With QA, being verified against its criteria. |
| Done | done | Finished and accepted. |
| Cancelled | cancelled | Dropped; kept for the record with the reason. |
From the backlog an item goes to ready, in progress or cancelled; from ready back to the backlog, on to in progress or to cancelled; from in progress to ready, in review, in QA, done or cancelled; from in review to in progress, in QA, done or cancelled; from in QA to in progress, done or cancelled; a done item may be reopened to in progress; a cancelled one goes back to the backlog. The first move into progress stamps when work started and a move into done stamps the finish; a move into done or cancelled carries a resolution and a move into an open status clears it.
Resolution
Why a work item closed; set by the move into done or cancelled and cleared by a move back into an
open status. Done takes done; cancelled takes any of the other four, won't do unless the move
says otherwise.
| Label | Code | Meaning |
|---|---|---|
| Done | done | Finished and accepted. |
| Won't do | wont_do | Agreed not to do it. |
| Duplicate | duplicate | Already covered by another item. |
| Cannot reproduce | cannot_reproduce | The bug could not be reproduced. |
| Deferred | deferred | Put off to a later release. |
Work priority
How urgent a work item is, in five steps. The backlog sorts by it and the sprint planner reads it; the badge carries an arrow pointing the way.
| Label | Code | Meaning |
|---|---|---|
| Lowest | lowest | Whenever there is time. |
| Low | low | After the medium items. |
| Medium | medium | The ordinary case. |
| High | high | Ahead of the medium items. |
| Highest | highest | Before anything else. |
Bug severity
How badly a bug hurts, kept on bugs only. A blocker or a critical bug in a release's scope will hold the release; the readiness score reads them.
| Label | Code | Meaning |
|---|---|---|
| Blocker | blocker | Nothing ships until it is fixed. |
| Critical | critical | A main flow is broken with no way round it. |
| Major | major | A main flow is broken but there is a way round it. |
| Minor | minor | Something is wrong but the flow works. |
| Trivial | trivial | Cosmetic; nobody is blocked. |
Reproducibility
How reliably a bug comes back when its steps are followed, kept on bugs only.
| Label | Code | Meaning |
|---|---|---|
| Always | always | Every time the steps are followed. |
| Sometimes | sometimes | Now and then, under conditions not yet pinned down. |
| Once | once | Seen once; the steps may not bring it back. |
| Not reproduced | not_reproduced | Reported, but nobody has made it happen again. |
Criterion kind
What an acceptance criterion checks. The test generator drafts one case per kind and the quality review flags a story without a negative row.
| Label | Code | Meaning |
|---|---|---|
| Functional | functional | The happy path: what the persona can do. |
| Negative | negative | What must be refused or must not happen. |
| Edge case | edge | The boundary of the input: empty, huge, the last day, the first user. |
| Non-functional | non_functional | A quality the story must keep: speed, access, accessibility. |
Requirement kind
What a requirement is about. The kind is chosen on a create and fixed after, because each kind numbers on its own sequence and the reference carries the kind's infix.
| Label | Code | Meaning |
|---|---|---|
| Functional | functional | What the system does for a person: a behaviour that can be shown. CRM-FR-12. |
| Non-functional | non_functional | A quality the system keeps while it does it, with a category and a measure. CRM-NFR-3. |
NFR category
The quality a non-functional requirement is about. One category per requirement; the standards presets and the readiness score group by it.
| Label | Code | Meaning |
|---|---|---|
| Performance | performance | How fast it answers and how much it handles under load. |
| Scalability | scalability | How it grows with more users, data or traffic. |
| Availability | availability | How much of the time it is up, and when it may be down. |
| Reliability | reliability | How rarely it fails and how it recovers when it does. |
| Security | security | How it keeps out who should be out and keeps data safe. |
| Privacy | privacy | How personal data is collected, kept and removed. |
| Usability | usability | How easily a person gets things done with it. |
| Accessibility | accessibility | How people with disabilities use it, and the standard it meets. |
| Compatibility | compatibility | The browsers, devices, systems and versions it works with. |
| Maintainability | maintainability | How easily the team changes it without breaking it. |
| Portability | portability | How it moves between environments, hosts or providers. |
| Compliance | compliance | The laws, regulations and standards it must satisfy. |
| Observability | observability | How its health, errors and behaviour can be seen from outside. |
| Localisation | localisation | The languages, formats, currencies and regions it serves. |
| Other | other | A quality none of the other categories names. |
Verification method
How a requirement is shown to be met. Written with the requirement, so the test module knows which ones get a test case, which are checked by reading, which by calculation and which by walking the client through them.
| Label | Code | Meaning |
|---|---|---|
| Test | test | Shown by running a test against it. |
| Inspection | inspection | Shown by examining the code, the configuration or the documents. |
| Analysis | analysis | Shown by calculation, modelling or a review of the data. |
| Demonstration | demonstration | Shown by walking through it in front of the people who asked. |
Requirement status
Where a requirement or a business rule stands, from the first draft to a frozen baseline. In review and approved are reached through the record's approval; baselined is reached when a baseline that holds the record is frozen and left when an approved change request unlocks it; the other moves are made by hand from the list or the flyout, or through the status endpoint. A client guest sees a requirement once it is approved and from then on, through baselined, and loses it when it is deprecated.
| Label | Code | Meaning |
|---|---|---|
| Draft | draft | Being written; the team reads it, the client does not yet. |
| In review | in_review | Put up for review; waiting for the people who approve it. |
| Approved | approved | Agreed; read by everyone, the client included, and built against. |
| Baselined | baselined | Frozen in a baseline; changed only through a change request. |
| Deprecated | deprecated | Withdrawn; kept for the record and no longer built against. |
A draft is submitted for review or deprecated; a review is approved or returned to where it stood by the approvers; an approved requirement is submitted again when it changes, is frozen into baselined by a baseline (or moved there by hand, a badge that carries no lock), or goes to deprecated; a baselined one returns to approved when a change request unlocks it and goes to deprecated only once no frozen baseline holds it; a deprecated one is revived as a draft.
Business rule kind
What a business rule is: the six classic kinds of decision a business writes down. The kind shapes how the rule is read, tested and coded, and it may change at any time because every rule numbers on the same sequence.
| Label | Code | Meaning |
|---|---|---|
| Constraint | constraint | Something that must or must not be the case: a limit the system refuses to cross. |
| Derivation | derivation | A fact that follows from other facts: how one value is derived from others. |
| Computation | computation | A number worked out from others: the formula, the rounding and the units. |
| Inference | inference | A conclusion drawn when conditions hold: if this is so, then that is true. |
| Action enabler | action_enabler | An action the system takes when a condition holds. |
| Policy | policy | A standing decision of the business, written down so nobody asks again. |
Use case flow
Which flow a step of a use case belongs to. The main flow is numbered from
one in the order its steps sit; a branch leaves a numbered main step, carries a label such as
2a, and the stories drafted from a use case come one per flow.
| Label | Code | Meaning |
|---|---|---|
| Main flow | main | The path where everything goes right, from the trigger to the goal. |
| Alternate flow | alternate | Another way to the goal that leaves a main step and comes back. |
| Exception flow | exception | A failure that leaves a main step and ends without the goal. |
RAID kind
What an entry of the RAID log is. The four kinds share one sequence
(CRM-RSK-4) and one table, so a kind may change at any time; the kind decides which columns the
item carries and how it is scored.
| Label | Code | Meaning |
|---|---|---|
| Risk | risk | Something that may happen and would hurt the project; scored by probability times impact. |
| Assumption | assumption | Something taken as true for the plan to hold; reviewed until it is confirmed or fails. |
| Issue | issue | Something that has happened and hurts the project now; scored by impact alone. |
| Dependency | dependency | Something the project needs from outside itself: a team, a vendor, a decision, a delivery. |
RAID area
The part of the project a RAID item touches. The area groups the log at the review meeting and filters the table; it never changes how an item is scored or moved.
| Label | Code | Meaning |
|---|---|---|
| Technical | technical | The stack, the architecture, an integration or the data. |
| Schedule | schedule | Dates, sequencing and the time the work takes. |
| Scope | scope | What is in and out, and what keeps growing. |
| Resource | resource | People, skills and availability. |
| Budget | budget | Money: the hours, the licences, the vendors. |
| External | external | A third party, a client decision or something outside the team. |
| Security | security | Access, data exposure and abuse. |
| Compliance | compliance | Law, regulation and the policies the client must honour. |
| Quality | quality | Defects, test coverage and what the client will notice. |
| Other | other | Anything the other areas do not name. |
RAID status
Where a RAID item stands. Moved by hand from the list or the flyout, or through the status endpoint; open, monitoring, mitigating and occurred count as needing attention and fill the sidebar badge.
| Label | Code | Meaning |
|---|---|---|
| Open | open | Raised and not yet looked at. |
| Monitoring | monitoring | Watched at every review; nothing to do yet. |
| Mitigating | mitigating | Being worked on to make it less likely or less bad. |
| Resolved | resolved | Dealt with; the issue is fixed, the dependency delivered, the assumption confirmed. |
| Closed | closed | Off the log; kept for the record. |
| Occurred | occurred | The risk happened; the contingency is now the plan. |
| Accepted | accepted | Lived with on purpose; nobody will act on it. |
Every status may move to every other, except that a closed item can only be reopened.
Decision kind
What a decision is about. The kind says who should sit at the table and where the record is read later; it may change at any time because every decision numbers on the same sequence.
| Label | Code | Meaning |
|---|---|---|
| Architecture | architecture | How the system is built: the stack, the shape of the code, the data, the integrations. |
| Product | product | What the product does and for whom: scope, behaviour and trade-offs the client agrees to. |
| Process | process | How the team works: ceremonies, branching, reviews, releases. |
| Vendor | vendor | Which third party is used and on what terms. |
| Security | security | How access, data and abuse are handled. |
Decision status
Where a decision stands. Moved by hand from the list or the flyout, or through the status endpoint; accepting a decision that names an earlier one moves that one to superseded in the same breath.
| Label | Code | Meaning |
|---|---|---|
| Proposed | proposed | Put forward with its options; not yet decided. |
| Accepted | accepted | Decided and in force; the team builds on it. |
| Rejected | rejected | Turned down; kept so the reasoning is not lost. |
| Superseded | superseded | Replaced by a later decision that names it. |
| Deprecated | deprecated | No longer applies and nothing replaced it. |
A proposed decision is accepted or rejected; an accepted one is superseded or deprecated; a rejected or deprecated one may be proposed again, and a superseded one accepted again, so the log never needs a duplicate.
Link kind
How one artefact relates to another in the Links panel. A kind is stored once and read from either side: the label is the phrase read from the source, the inverse the phrase read from the target. Relates to and duplicates read the same from both sides, so the reverse direction counts as the same link.
| Label | Code | Read from the target | Meaning |
|---|---|---|---|
| implements | implements | is implemented by | The source builds what the target asks for: a story implements a requirement. |
| derives from | derives_from | is refined by | The source was written from the target: a requirement derives from a rule. |
| verifies | verifies | is verified by | The source proves the target holds: a test case verifies a requirement. |
| covers | covers | is covered by | The source walks the target: a test case covers a story or a use case flow. |
| depends on | depends_on | is depended on by | The source cannot finish before the target does. |
| blocks | blocks | is blocked by | The source stops the target from moving until it is done. |
| relates to | relates_to | relates to | The two belong together without one owning the other; the default kind. |
| duplicates | duplicates | duplicates | The two say the same thing; keep one and close the other. |
| is caused by | caused_by | causes | The source happened because of the target: a bug caused by a decision. |
| is fixed by | fixed_by | fixes | The source is put right by the target: a bug fixed by a story. |
| supersedes | supersedes | is superseded by | The source replaces the target, which stays for the record. |
Attachment kind
What kind of file an attachment is, read from its type and extension when it is stored, so the Files panel shows a preview for a picture and the right badge for anything else. The kind is never picked by hand.
| Label | Code | Meaning |
|---|---|---|
| Image | image | A picture: jpg, jpeg, png, gif, webp; shown as a preview. |
| Document | document | A PDF or a word-processing file: pdf, doc, docx, odt, rtf. |
| Spreadsheet | spreadsheet | A sheet or a CSV: xls, xlsx, ods, csv. |
| Presentation | presentation | Slides: ppt, pptx, odp. |
| Archive | archive | A compressed bundle: zip. |
| Text | text | Plain text, Markdown, JSON or a log: txt, md, json, log. |
| File | other | Anything else the operator allowed. |
Quality band
What a quality review's score means at a glance. The score is 100 less the penalties of Heimdall's findings; the band reads it for the badge on a list row and the top of the Quality panel.
| Label | Code | Meaning |
|---|---|---|
| Ready | ready | 80 to 100: fit for the people after you; the findings, if any, are polish. |
| Needs work | needs_work | 50 to 79: usable with questions; fix the medium and high findings first. |
| Not ready | not_ready | 0 to 49: something would block a developer or a tester; rewrite it. |
Finding severity
How much one finding of a quality review matters, and what it takes off the score.
| Label | Code | Meaning |
|---|---|---|
| High | high | A developer or a tester would be blocked or misled; 25 off the score. |
| Medium | medium | The record is usable but would be argued over; 10 off the score. |
| Low | low | Polish: a word, a missing example, a sharper title; 4 off the score. |
Import status
Where a brief import stands, from the moment a brief is handed to Heimdall to the last decision on its suggestions.
| Label | Code | Meaning |
|---|---|---|
| Queued | queued | Handed to Heimdall; the reading has not started. |
| Reading | running | Heimdall is reading the brief against what the project holds. |
| Ready to review | ready | The suggestions wait for people. |
| Reviewed | accepted | Every suggestion was decided. |
| Discarded | discarded | A person dropped the batch; its suggestions stay readable but cannot be decided. |
| Failed | failed | The model did not answer, the budget had no room, or the starter is gone; start it again. |
Research status
Where a run of Heimdall's research stands, on the badge beside the Heimdall suggests heading of a project's overview and on the run over the API.
| Label | Code | Meaning |
|---|---|---|
| Queued | queued | Asked for; the queue has not picked it up. |
| Researching | running | Heimdall is searching and reading; the rail polls until it is done. |
| Ready | ready | The notes are under the run and the suggestions wait on the overview. |
| Failed | failed | The model did not answer, its answer could not be read, the budget had no room, or the asker is gone; ask again. |
Council session status
Where a sitting of Heimdall's council stands, on the Council tab of the Heimdall panel and on the sitting over the API; a voice's turn passes through the same words without the summarising step.
| Label | Code | Meaning |
|---|---|---|
| Queued | queued | Convened; no voice has begun. |
| In session | running | The voices are reading and speaking; the tab refreshes as each finishes. |
| Summarising | summarising | Every voice has spoken; Heimdall is writing the verdict. |
| Ready | ready | The verdict is written and the findings wait for decisions. |
| Failed | failed | No voice could answer, or the moderator could not; the reason is on the tab, and the council is convened again. |
Council finding status
What a person decided about one finding of the council. A decision is never undone.
| Label | Code | Meaning |
|---|---|---|
| Waiting | pending | Waiting for a decision. |
| Accepted | accepted | On the review queue as a suggestion carrying the voice; the record the voice drafted was written in draft. |
| Dismissed | dismissed | Nothing written; the idea is remembered so no voice and no research run raises it again. |
Suggestion status
What a person decided about one suggestion of a brief import or of Heimdall's research. A decision is never undone: the record it wrote has its own lifecycle.
| Label | Code | Meaning |
|---|---|---|
| Pending | pending | Waiting for a decision. |
| Accepted | accepted | The record was written as Heimdall proposed; a note was kept. |
| Accepted with edits | edited | The record was written with the person's changes. |
| Merged | merged | Pointed at a record the project already held; nothing was written. |
| Rejected | rejected | Dropped; nothing was written. |
| Dismissed | dismissed | A note closed without a record. |
Suggestion kind
What a suggestion from a brief import proposes to add. Twelve kinds become a record when accepted; the two notes are read and kept or dismissed. The review queue groups suggestions in this order.
| Label | Code | Becomes |
|---|---|---|
| Epic | epic | An epic. |
| Story | story | A story on the backlog, under its epic. |
| Functional requirement | functional_requirement | A functional requirement. |
| Non-functional requirement | non_functional_requirement | A non-functional requirement with its measure. |
| Business rule | business_rule | A business rule with its examples. |
| Use case | use_case | A use case with its main flow. |
| Glossary term | glossary_term | A glossary term with its aliases. |
| Persona | persona | A persona. |
| Stakeholder | stakeholder | A stakeholder. |
| Risk | risk | A risk on the RAID log, scored. |
| Assumption | assumption | An assumption on the RAID log. |
| Decision | decision | A proposed decision. |
| Improvement | improvement | Nothing: a gap or a question for the analyst. |
| Research | research | Nothing: a finding of the research sweep. |
Revision reason
Why a version of an artefact was written. Every save of a revisable artefact writes one; the reason says what kind of save it was, so the history reads as a story rather than a list of diffs. Beside the reason, each version records through what it was written: a person in the dashboard, an API token, an MCP client, an integration, a webhook, Heimdall or the system.
| Label | Code | Meaning |
|---|---|---|
| Created | created | The first version, as the artefact was written. |
| Edited | edit | A person changed the fields by hand. |
| Drafted by Heimdall | ai_assist | Heimdall drafted the change and a person accepted it. |
| Imported | import | The change arrived from a brief import. |
| Moved | transition | The artefact moved along its lifecycle. |
| Restored | restore | An earlier version was put back. |
| Approved | approval | The version an approval froze. |
| Baselined | baseline | The version a baseline froze. |
| Saved as a version | manual | A person saved a version on purpose. |
Baseline kind
What a baseline marks. The kind is chosen when the draft is composed and decides who signs: a scope baseline passes the client's sign-off after the team's approval; the other kinds are frozen by the team's approval alone. Shown as a badge in the list and the flyout; a filter on the list takes the code.
| Label | Code | Meaning |
|---|---|---|
| Scope baseline | scope | The agreed scope of a piece of work; frozen by the team, then signed by the client. |
| Release baseline | release | What a release ships, frozen when its scope is cut. |
| Sprint baseline | sprint | What a sprint commits to, frozen when the sprint starts. |
| Milestone baseline | milestone | What was promised for a milestone, frozen when it is agreed. |
Baseline status
Where a baseline stands. Every move but the last is the approval engine's: submitting a draft puts it in review, the project manager's approval freezes it, the second submission of a scope baseline sends it to the client, and their signature signs it; superseding is the one move made by hand. A client guest sees a baseline from the moment it is frozen.
| Label | Code | Meaning |
|---|---|---|
| Draft | draft | Being composed; records can still be added and removed. |
| In review | in_review | Submitted to the project manager; nothing changes until the verdict. |
| Approved | approved | Frozen by the team; its records are locked and change only through a change request. |
| Awaiting sign-off | awaiting_sign_off | Frozen and sent to the client's stakeholders for their signature. |
| Signed off | signed_off | Signed by the client; the record the project is held to. |
| Superseded | superseded | Replaced by a newer baseline; kept for the record and no longer locking anything. |
A draft goes to in review; a review is approved or returned to draft; an approved scope baseline goes to awaiting sign-off, and any approved baseline to superseded; a baseline awaiting sign-off is signed or returned to approved; a signed baseline goes to superseded.
Change reason
Why a change request was raised. Chosen when the request is raised and changed until it is decided; shown as a badge and a filter on the list.
| Label | Code | Meaning |
|---|---|---|
| New requirement | new_requirement | Something the agreed record never covered. |
| Clarification | clarification | The record says it, but not clearly enough to build or test against. |
| Defect | defect | The record as agreed is wrong and must change, not merely the code. |
| Regulatory | regulatory | A law, a standard or a contract requires the change. |
| Client request | client_request | The client asked for it after the record was agreed. |
| Technical debt | technical_debt | The team asks to change the record to repay a shortcut. |
| Scope reduction | scope_reduction | Something agreed is dropped. |
Change request status
Where a change request stands. The moves into and out of the gate (awaiting approval, approved, rejected) are the approval engine's; the rest are made by hand from the list or the flyout, or through the status endpoint, and Heimdall's reading moves a request that was only submitted under analysis. A request is edited while submitted, under analysis or awaiting approval, and deleted while submitted, under analysis or rejected; the open statuses, everything but rejected, verified and closed, are what the sidebar badge counts.
| Label | Code | Meaning |
|---|---|---|
| Submitted | submitted | Raised and waiting for an analyst to pick it up. |
| Under analysis | under_analysis | The impact on scope, schedule, effort and risk is being worked out. |
| Awaiting approval | awaiting_approval | Sent to the approvers with its impact; nothing moves until they answer. |
| Approved | approved | Agreed; the baseline items it names are unlocked for the change. |
| Rejected | rejected | Refused by the approvers, with their reason; the baseline stands as it was. |
| Implementing | implementing | The team is making the change. |
| Implemented | implemented | The change is made and waits to be verified. |
| Verified | verified | Confirmed to have landed as asked, by whom and when. |
| Closed | closed | Finished, or withdrawn; kept for the record. |
A submitted request goes under analysis, to the approvers or to closed; one under analysis goes to the approvers or to closed; one awaiting approval is approved, rejected or returned under analysis by the approvers; an approved one goes to implementing or closed; a rejected one back under analysis or to closed; implementing to implemented, implemented to verified (or back to implementing), verified to closed.
Impact level
How hard a change request hits the project: the word the approvers read first, written by the analyst or proposed by Heimdall's reading. Shown as a badge in the list and the flyout; a filter on the list takes the code.
| Label | Code | Meaning |
|---|---|---|
| Low | low | Absorbed; no date and no price moves. |
| Medium | medium | A date or the effort moves, but the plan is reworked rather than renegotiated. |
| High | high | The scope, the schedule or the budget needs the client's agreement again. |
Document status
Where a generated document stands. The render moves it first: asked for, it is rendering; the file written, it is a draft; a render that stopped leaves it failed with the reason kept. The approval engine moves a draft into review and, when the request carries, to final, superseding the kind's earlier final copy; superseding by hand is the one move a person makes. A client guest sees a document from the moment it is final.
| Label | Code | Meaning |
|---|---|---|
| Rendering | rendering | Asked for; the file is being written in the background and the list refreshes itself until it is there. |
| Draft | draft | Rendered and readable; the title, the scope and the opening page still change, and each change renders it again. |
| Failed | failed | The render stopped; the reason is on the document, and Render Again clears it. |
| In review | in_review | Submitted to the project manager; nothing changes until the verdict. |
| Final | final | Approved: the copy the client sees, never edited or rendered again. |
| Superseded | superseded | Replaced by a newer final copy of its kind, or retired by hand; kept for the record, unchanged. |
Rendering goes to draft or failed; a draft or a failed document renders again, back through rendering; a draft goes to in review; a review is approved to final or returned to draft; a final copy goes to superseded, by the next approval of its kind or by hand.
Sprint status
Where a sprint stands. Planning writes it planned; putting it to the team moves it to awaiting commitment, and the team's approval starts it; the close completes it; cancelling is the one move made by hand. A client guest never reads sprints.
| Label | Code | Meaning |
|---|---|---|
| Planned | planned | Being planned; its dates, capacity and scope still change. |
| Awaiting commitment | committing | Put to the team for its commitment; the scope holds until they answer. |
| Active | active | Running: the team committed to its scope and the board follows it. One per project. |
| Completed | completed | Closed with its velocity recorded; the unfinished work was carried on. |
| Cancelled | cancelled | Called off before or during the run; its items went back to the backlog. |
A planned sprint goes to awaiting commitment or cancelled; one awaiting commitment is started to active or returned to planned; an active sprint is closed to completed or cancelled; a completed or cancelled sprint goes nowhere.
Approval status
Where an approval request stands. Submitting opens it pending; the verdicts of the people named, the author's withdrawal or the policy's clock settle it. Shown on the approval bar of the record and in the inbox; a filter on the inbox takes the code.
| Label | Code | Meaning |
|---|---|---|
| Pending | pending | Waiting for the approvers named on it; the record is in review. |
| Approved | approved | Carried: enough approvers agreed, or the clock ran out on a policy that approves by itself; the record is approved at a new version. |
| Rejected | rejected | One approver rejected it; closed, and the record went back to where it stood. |
| Changes requested | changes_requested | An approver asked for changes; held open for the author to edit the record and resubmit the next round. |
| Withdrawn | withdrawn | Taken back by the author or a person with approval:withdraw; the record went back to where it stood. |
| Expired | expired | Reserved for a request closed because its time ran out unanswered; no policy closes one this way yet. |
Approval verdict
What one approver said on one round of a request, kept with the time, the address and a signature hash; the author reads it beside the approver's name and the reason.
| Label | Code | Meaning |
|---|---|---|
| Approved | approved | Counts towards the approvals the policy needs; the record is approved once enough approvers agree. |
| Rejected | rejected | Closes the request under every rule and returns the record to where it stood. |
| Changes requested | changes_requested | Holds the request for the author to edit and resubmit; the approvers decide again on the next round. |
Related
- Webhooks — the delivery log and retries
- Heimdall panel — cards and the work timeline
- Error codes — the codes an API refusal carries
How is this guide?
Last updated on
Documents Shared With You
Where the final BRD and SRS of your projects appear, how to download or open one, what the status badges mean, and why a draft the team is still working on is not shown to you.
Changelog
Every change that reached Zuse Bifrost, newest first, dated by the day it landed and linked to the pages of this guide that describe it.