Jira & Documentation Tag Registry

Purpose

This is the canonical vocabulary for tagging StockLive documentation and Jira work items. The AI should use these labels when creating or triaging a ticket, based on the ticket's content and current delivery state.

Labels are lowercase kebab-case. Apply only labels supported by the evidence; do not infer a stage or decision that the ticket does not establish.

Delivery stages

Label	Definition
`discovery`	Evidence about what is true now: facts, observations, users, constraints, or an open question. Discovery is not a document type.
`requirements`	The technical or product conditions that must be true. This is a delivery stage, not a folder or document type.
`affordability`	Evaluation of whether the work is affordable in time, complexity, risk, and capacity for the intended horizon.
`prded`	The Engineering PRD stage: the work has settled enough to define the core workflow, data model, acceptance boundary, and value.
`phases`	The work has been decomposed into implementation phases or slices.
`erd`	The work includes or depends on an entity-relationship/data schema design.
`backlogged`	The work is sufficiently defined and has been accepted into the delivery backlog.

Canonical sequence:

discovery → requirements → affordability → prded → phases → erd → backlogged

Decision and delivery state

Label	Definition
`unsettled`	A decision, scope, requirement, or design is still open.
`settled`	The relevant decision or scope is agreed and no longer an active question.
`sequenced`	The work has an agreed order or place relative to other work.
`parked`	Deliberately held aside for later consideration without being rejected.
`not-now`	Explicitly not planned for the current horizon, but not necessarily rejected permanently.
`dropped`	Explicitly rejected or removed from consideration.
`terminal`	The item is at an end state and should not graduate into another delivery stage.
`never-graduates`	The item is intentionally useful as a permanent reference or state and does not become executable delivery work.
`after-the-lock`	A change raised after the agreed PRD/scope lock; requires explicit change handling.

Artifact and modelling labels

Label	Definition
`domain-model`	Canonical domain language, concepts, relationships, and invariants.
`spec`	A durable statement of what a system, feature, or process is meant to be.
`workbench`	Working material used to investigate, compare, capture, or shape an item before it becomes a settled artifact.
`poc-spike`	A time-boxed experiment or proof of concept intended to reduce uncertainty.
`change-note`	A record of a material change to an already locked or agreed item.
`derived`	Content or work item derived from another canonical source.
`adi`	An ADI artefact or item using the project's ADI convention.

Value and prioritisation labels

Label	Definition
`value-rung`	The item identifies or discusses the value rung it serves: workflow/data capture, user capture, or transaction.
`fit`	The item fits the current product direction, operating model, and intended value.
`fit-not-priority`	The item fits the product direction but is not a current priority.

Classification labels

Label	Definition
`not-a-document-type`	A reminder that the term describes a state, activity, or evidence lane rather than a document type.
`stage-not-a-folder`	A reminder that the term describes a workflow stage and should not be represented as a folder hierarchy.
`never-typed`	The item is deliberately not assigned a formal document/artifact type.

AI tagging rules

When creating or editing a Jira ticket:

Read the summary and description.
Apply the smallest set of labels directly supported by the text.
Apply a delivery-stage label only when the ticket clearly belongs to that stage.
Apply state labels such as unsettled, settled, parked, not-now, or dropped only when the state is explicit.
Apply classification labels when the ticket is correcting taxonomy or documenting the operating model.
Preserve existing labels unless the ticket explicitly changes state; then replace contradictory state labels where appropriate.
Never apply contradictory labels such as settled and unsettled, or parked and dropped, without an explicit explanation.
If the evidence is insufficient, create the ticket without guessing and add a follow-up question to the description or comment.

The Atlassian MCP can apply these labels through Jira issue creation and editing. This is AI-assisted tagging at the point of ticket creation/editing; native Jira Automation rule management is not currently exposed by the MCP.