Work items, fields, and types

This is the field-level map of the work model: every record type Disco Parrot keeps, the fields it carries, and the exact values an enum field can take. The guides tell you what a record is for; this page tells you exactly what it holds. When you are building a filtered view that keys off a precise field, configuring a workflow, or deciding which type a plan should be, this is where you confirm the name and the shape rather than infer them from a form.

The records and how they relate are covered in depth on the SDLC work model page and in each entity's own guide under plan and track work. This page is the flat reference those guides point back to. The lifecycle a record moves through, its statuses and the transitions between them, lives on the statuses and status machines page; here you will find the status field named, with its values cross-linked there.

How records relate

The shape comes before the field tables, because the tables make more sense once you can see how the records point at one another. The work hangs off a short spine: a portfolio links projects, a project holds initiatives, an initiative decomposes into plans. Bugs and test cases hang off the same initiatives, a bug optionally off a plan as well, and a sprint cuts across the whole thing as a delivery window that plans and bugs commit to. A goal sits to the side and draws its progress up from the initiatives beneath it rather than carrying a number of its own. The tables below name every field on each of these records; the map above is how they point at one another. Two links are worth holding onto as you read: a bug requires an initiative but a plan is optional, and a goal's connection to its initiatives is a rollup, not a structural parent.

Fields every record carries

A handful of fields are common to every work item, so they are worth settling once here rather than repeating in each table below.

Two distinctions recur across the tables below, so settle them once here. Owner is a label, assignee is an identity. The owner field is a freeform display name; the assignee field, where an entity has one, holds the actual user it resolves to. Deleting is soft. Every record carries a deleted marker rather than being erased, so a removed record leaves the active set without leaving the history.

Projects

A project is the container a team's work lives in. It binds to a repository and sets the default sandbox profile that planning chats inherit.

Project membership is a separate set of records rather than a field on the project, so a person's role on a project is tracked per membership. See projects.

Portfolios

A portfolio is the rollup container above projects, for looking across several at once. It links to projects and carries a privacy switch.

Access to a portfolio runs through the teams linked to it, not through a member list on the portfolio itself. See portfolios and teams.

Initiatives

An initiative is the captured intent at the top of the work model. It holds the spec that decomposes into plans.

An initiative does not store its own effort estimate. Its effort is the sum of its plans' estimates, rolled up rather than entered. See initiatives.

The spec and its clarifications

The body field is not a description that sits beside the work. It is the spec the plans decompose from, which is why it is markdown, versioned, and the one initiative field with real weight behind it. When the agent reads a spec and finds a question the spec does not answer, it does not guess. It raises a clarification: an open question recorded on the initiative, waiting for a person.

A clarification is a small loop, not a comment. It carries the question, the answer a person gave, the date that answer landed, and the spec revision the answer was folded into. That last part is what makes it more than a thread. Once the answer is incorporated, the clarification points at the exact version of the spec that now reflects it, so a reader can see not just that a question was asked and answered but where in the spec the answer changed the text. Plans carry the same loop, each clarification naming the revision its answer entered.

Plans

A plan is a reviewable piece an initiative decomposes into. It carries a type, an estimate, implementation steps, and, once shipped, a link to its pull request.

Both the hours estimate and the points estimate are stored on every plan. Which one your team works in is a team setting, covered under estimates and point scales. See plans.

Bugs

A bug is an issue that lives alongside plans. It rolls up to an initiative and can join a sprint. Bugs carry the most classification fields of any record in the work model.

See bugs. The classification value sets follow.

A bug carries its classification on four axes that answer four different questions, and they are set at different moments. Severity and priority are set at triage and say how bad the defect is and how soon to address it. Resolution and root cause are set when the bug closes and say why it was settled and what was behind it. The value sets for each follow.

Bug severity and priority

Severity describes the defect; priority describes the schedule. They move independently, so a low-severity bug can carry an urgent priority and the reverse.

Bug resolution

When a bug leaves the open states, its resolution records why.

Moving a bug to its canceled state requires a resolution, so a canceled bug always records why it was settled.

Bug root cause

Root cause is set when a bug is resolved and answers what was behind it.

Sprints

A sprint is a team-scoped delivery window that groups plans and bugs.

Sprint membership lives on the items, not on the sprint: a plan or a bug carries the sprint it is committed to. Capacity is tracked per member in its own set of records, holding each person's hours or points budget for the sprint, their personal days off, and whether they count toward the total. See sprints.

Goals and key results

A goal is an outcome the work supports, and it is the one record on this page that carries no workflow and no effort of its own. Its key results are the measurable targets, and they tie back to the initiatives that move them. Read the two tables together: the goal holds the framing and the health label, the key results hold the numbers, and the numbers climb from the initiatives a key result links to. That is why the goal splits into two tables: the framing and health on one, the moving numbers on the other.

A goal's completion is a rollup over its key results, derived rather than set. An automatic key result moves as its linked initiatives progress: a numeric metric tracks their weighted progress, and a boolean metric turns true once every linked initiative is done. See goals and OKRs.

Test cases

A test case captures what should be true and the status of checking it.

See test cases.

Documents

The word document covers two surfaces, and they are worth keeping apart.

The first is the Document Library, the files and pages you attach to your work. A library document records where it came from and how it is stored.

The second is repository documentation, the per-repository wiki the platform keeps. A wiki page is addressed by a slug and a scope (global, or a single repository) and holds markdown content. This is the surface documentation health reviews keep current. See documents and repository documentation and wiki.

Plan types

Every plan carries a type, and the type tells you what the plan is for. There are seven.

The type is a way to sort and reason about the work rather than a switch that changes the fields a plan carries; every plan type has the same shape. See plans.

Estimates and point scales

A plan or a bug can carry an estimate, and the platform stores it two ways at once: an hours estimate and a points estimate, each from 0 to 1000. Which one your team actually works in is a team setting, the primary estimate unit, set to either hours or points. Attested time spent is always recorded in hours, whatever the team estimates in.

When a team estimates in points, a point scale fixes the values a points estimate can take, so a team's estimates stay consistent.

The scale guides the points field and the agent's suggestions toward those values. It is set per team, alongside the primary estimate unit. See teams for where a team chooses its unit and scale.

How estimates and progress roll up

Two numbers in the work model are never typed where you read them. They climb. An initiative shows an effort figure, but it stores none of its own: the figure is the sum of the estimates on its plans. A goal shows progress, but it sets none of its own: the progress is drawn up from the initiatives its key results link to. Both are computed at the moment you look, from the leaves, which is why neither field is editable on the record that displays it.

The estimate roll is the straightforward one. An estimate lives on a plan, in the unit the team works in, and bugs carry one too. An initiative's effort is its plans' estimates added together, so resizing one plan changes the initiative total without anyone touching the initiative. Because the estimate is stored both ways on every leaf, the roll holds whether the team reads it in hours or in points.

The progress roll has one more turn in it, because a goal does not link to initiatives directly. A goal carries key results, and a key result links to initiatives. An automatic key result moves as those initiatives advance: a numeric metric tracks their weighted progress, and a boolean metric turns true only once every linked initiative is done. The goal's own completion is then a roll over its key results. So the path runs initiative progress, up into the key result, up into the goal, three records deep, with a person entering a number at none of the three.

This is the direction underneath the field tables. Effort and progress both flow up the spine from the work that actually moves, never down from a figure someone declared at the top, which is why an initiative total and a goal's health stay honest as the leaves change without a reconciliation step to keep them true.

One filter, start to finish

An example of the page doing its job. A release manager wants every bug that is a real regression still in flight: high or critical severity, a root cause of regression, and not yet closed. Each of those is a value set on this page. Severity is critical or high from the severity table. Root cause is regression from the root-cause table. And still in flight is any status that is not closed or canceled, from the bug status machine. They build the view with those exact strings, and because the grid matches the same values this page lists, the filter catches every bug that qualifies and nothing that does not. The page is where the filter's vocabulary comes from.

Why the work model is shaped this way

The shape of the model rewards a close look. The work hangs off a small spine, portfolio to project to initiative to plan, with bugs and test cases hanging off the same initiatives and sprints cutting across as a delivery overlay. Estimates live on the leaves and climb; a goal's progress is drawn up from the initiatives beneath it rather than typed in, the model the rollup section above draws in full. Once you see that, the fields stop reading as a long list and start reading as a structure with a direction to it.

That structure is only useful if the reference matches the product field for field, which is the rule behind the whole section: every field and every value here is read from the product as it behaves, not from an older intention. That matters most where two things look alike and are not. Owner is a label and assignee is an identity. Severity describes a defect and priority describes a schedule. A bug's status is where it sits in the workflow and its resolution is why it closed, two different fields that happen to share a couple of words. A reference earns its keep by drawing those lines cleanly, because a filter or a workflow built on the wrong field fails quietly.

For a power user, this page is the source for a precise filter or a custom view. When you key a view off severity, plan type, or sprint, the value sets here are the exact strings the grid matches.

For an administrator, the status fields named here lead straight to the statuses and status machines page, where the transitions you can customize live. The fields a record carries are also the fields a workflow's board and grid can show.

For an engineer, the relationship fields are the map: which record points at which, what is required, and what rolls up. The estimate fields and the point scale are where a team's sizing convention is set.

For a prospect, this is the evidence the model is real. An agent can only plan, build, and verify work if there is a structured work model underneath it, and this page is that model named in full, not a diagram on a marketing page.