> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Baseline Tracking
> A checklist that only ever shows its *current* state has a fundamental limitation for audit and compliance work: it cannot prove what the checklist looked like at a specific moment in the past.
export const LastReviewed = ({date}) => {
if (!date) return null;
const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", {
year: "numeric",
month: "long",
day: "numeric",
timeZone: "UTC"
});
return
Last reviewed on {formatted}
;
};
The best mental model is a photograph album next to a whiteboard. The whiteboard (the live checklist field) is always current — anyone can erase and rewrite it. A baseline is a photograph of that whiteboard taken at a specific moment. You can take as many photographs as you like over time, and none of them change when the whiteboard is later erased and rewritten. What baseline tracking gives you is the album of those photographs, in order, each one linked back to the moment it was taken.
## Why baselines exist
In regulated processes, it's often not enough to show that a Definition of Done checklist is complete *today* — you need to show it was complete *at the time a specific release, revision, or review was approved*, and that the checklist's content at that point matched what governance required. A live-only checklist can't answer "what did this look like when version 3 was approved," because by the time someone asks, the checklist may have moved on. Baseline tracking exists specifically to answer that question.
## What a baseline actually is
The gathered code context shows that a baseline is represented as a lightweight record — not a duplicate copy of the checklist's data, but a reference to a **work item that represents the baseline/revision**, carrying:
* an **ID** (typically the revision or baseline value, e.g. a version tag) — used to build baseline links and match a checklist to a specific revision
* a **label** (human-readable, typically combining the ID and the associated work item's title, falling back to just the ID if no distinct title exists)
* a **date** (the baseline work item's creation date, pre-rendered from the work item's `created` field)
* a **URL** linking to the document at that specific baseline revision
* a **status** (the underlying baseline work item's workflow status, e.g. Open, Approved — rendered with its normal status icon)
* the underlying work item's identifier
In other words, "creating a baseline" in this system means creating (or having Polarion create) a work item that stands in for a document revision, and Nextedy CHECKLIST's baseline machinery finds that work item and uses it as an anchor point to reconstruct the checklist as it existed at that revision.
## The two configuration properties behind baseline lookup
Baseline lookup is driven by document-scoped configuration, resolved via two properties:
* `nextedy.checklist.baselines.itemType` — specifies which work item type represents a baseline record for checklist history. **Default: `btask`.**
* `nextedy.checklist.baselines.baselineField` — specifies which custom field on that baseline item type stores the baseline/revision identifier. **Default: `baseline`.**
These two properties are what let the system build Lucene queries to find either a single baseline item matching a specific revision, or the full set of baseline items associated with a document. If your project uses a different work item type or field to represent revisions, these are the properties to adjust — but note that, unlike the four-level type/field/status hierarchy described in [Configuration Property Hierarchy](/checklist/concepts/configuration-property-hierarchy), these two are read per-document rather than resolved through that broader precedence chain.
**Verify in application**
The gathered context confirms these two properties and their defaults but does not describe any narrower per-type or per-field scoping for them, unlike most other Checklist configuration properties. Treat them as document-scoped settings rather than assuming they participate in the same four-level hierarchy used elsewhere.
## Two ways a document's baseline history renders
The baseline view for a document behaves differently depending on whether you're looking at a *specific* revision or browsing the *history* as a whole:
1. **General listing mode** — queries all baseline work items associated with the document (via the configured item type and baseline field), sorts them by the baseline field, and renders each as a row showing its label, date, status, and a link to that revision. This is the "photo album" view.
2. **Revision-scoped rendering mode** — when a specific revision context is active, the view looks up the matching baseline work item for that revision and renders the checklist *as it existed at that baseline* rather than the live checklist. This is opening a single photograph instead of browsing the album.
The view also automatically adapts when a document is being exported or rendered as a PDF, switching its render mode based on that context.
**Verify in application**
A flag exists to mark the baselines view as hidden when a document is exported to PDF, but the gathered code context notes the render logic does not appear to visibly branch on this flag in the reviewed implementation. Confirm in the live application whether setting this flag actually suppresses the baselines list in PDF output before relying on it for a compliance document that must not show baseline history in its exported form.
## Baselines are read-only history, not editable state
A critical distinction: baseline tracking is a *reporting and traceability* feature, not an editable one. You don't check or uncheck items against a historical baseline — you view what was recorded. The live, editable checklist lives on the current document; baselines only ever look backward at frozen work-item-anchored snapshots.
This is why baseline tracking pairs so naturally with [Workflow Gates](/checklist/concepts/workflow-gates): a gate enforces that a checklist is complete *before* a transition (for example, before a document is approved or a revision is finalized), and a baseline captured at that same point in time gives you durable, queryable evidence that the gate's requirement was actually satisfied when the transition happened — not just that it happens to be satisfied whenever someone looks at it later.
## Common misconceptions
**A baseline is not a copy of the checklist's data**
It's tempting to assume a baseline stores its own independent copy of every checklist item and result. Based on the gathered context, a baseline is better understood as a *pointer* — a work item representing a revision, located via a Lucene query against a configured item type and field — from which the checklist as it existed at that document revision is reconstructed. The baseline mechanism depends on the underlying document revision actually being preserved (a standard Polarion document versioning capability); the baseline work item itself does not duplicate the checklist content independently of that revision.
**Changing the baseline item type or field affects lookup, not history**
Reconfiguring `nextedy.checklist.baselines.itemType` or `nextedy.checklist.baselines.baselineField` changes which work items the system searches for when building the baseline list — it does not migrate or relabel work items that already exist under the old type/field. If you change these properties after baselines are already in use, previously created baseline work items under the old type/field will no longer be found unless they're also updated to match.
## Object scope
The gathered context describes baseline tracking specifically in terms of **documents** — the baseline view is built and queried per-document, and the baseline work item's URL links to "the document at the specific baseline revision." Work item, test run, and plan checklists are covered elsewhere by templates and workflow gates, but the baseline/history mechanism as described in the gathered context is a document-level capability.
**Verify in application**
If your process requires historical snapshots of work item, test run, or plan checklists (rather than document checklists), confirm in the live application whether an equivalent baseline mechanism exists for those object types, since the gathered context only substantiates document-level baseline tracking.
## Related guides
* [Your First Checklist](/checklist/getting-started/your-first-checklist)
* [Set Up a Plan Checklist (Tutorial)](/checklist/getting-started/setup-plan-checklist)
* [Set Up a Test Run Checklist (Tutorial)](/checklist/getting-started/setup-test-run-checklist)
**KB Articles**
* Checklist workflow functions and conditions
**Support Tickets**
* [#235](https://support.nextedy.com/helpdesk/tickets/235)
* [#325](https://support.nextedy.com/helpdesk/tickets/325)
* [#4514](https://support.nextedy.com/helpdesk/tickets/4514)
**Source Code**
* `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/baselines/Baseline.java`
* `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/Checklist.java`
* `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistItem.java`
* `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistSettings.java`
* `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/baselines/BaselinesView.java`