Managing tracks (admin)

In the admin: Tracks — the screen this page documents (opens in the running app).

What/why: Guided selection tracks — what this screen manages and why it exists.

The Tracks screen under /admin/tracks manages buyer-facing variants of the guided flow. A track has a name, a URL slug, an ordered subset of the selection factors to ask, and pre-seeded answers for factors the buyer is never shown — so a "homeowner patio" track can skip the Interior/Exterior question entirely and lock in "Exterior". Published tracks serve buyers at /select/<slug>. The screen is restricted to the data editor capability (edit_data); see admin-access.md.

Tracks build on the factor model — manage the factors and their options themselves in managing-factors.md.

The tracks list (/admin/tracks)

The list shows every track with its slug, status (Draft / Published), and factor count, with retired tracks in their own section below. Lifecycle actions run from here:

• Publish makes a draft live at /select/<slug> and permanently locks its slug (see below).
• Retire takes a published track offline. If sessions reference the track you'll be asked to confirm first — the URL has been used by real buyers. The configuration and the sessions are preserved.
• A retired track can be re-published as-is, or revived to draft to edit before going live again.

Creating a track (/admin/tracks/new)

A new track is always born a draft — editable and not yet reachable by buyers.

1. Name it. The slug derives from the name automatically (kebab-case); override it only if you want a different URL. Reserved words (select, compare, admin, api, health) and slugs already taken by another track are rejected. Optionally add a description — one or two sentences of buyer-facing card copy (max 300 characters) shown on entry surfaces like the home page's persona cards. A track without a description still gets a card; it just renders name-only.

2. Pick the factors asked in this track and order them with the arrows — this is exactly the question order buyers see. Only enabled (non-retired) factors are offerable. A new track's ask-list starts pre-seeded with every factor in the global factor order (factor ordering, #470) — the admin's canonical arrangement — so you trim and reorder from that starting point rather than an empty list. Reordering the global list later never changes this or any other existing track; each track owns its saved order.

3. Set pre-seeded answers for factors you left out of the ask-list. Each pre-seed is chosen from the factor's real options, so a track can never bake in an answer the flow couldn't produce. A left-out factor with no pre-seed is simply skipped.

   A pre-seed stores the option's stable identity, not its name (#1868) — so renaming an option's value never breaks a track that pre-seeds it. Before this, a rename silently stopped the pre-seed applying, which changed which questions buyers on that track were asked with nothing shown to the operator who renamed it. Deleting an option is a different matter: that is refused outright while any track pre-seeds it (see managing factors).

4. Create draft track lands on the edit screen; publish from the list when ready.

Editing a track (/admin/tracks/<id>)

The edit screen carries the same form. Two things change once a track has been published:

• The slug is locked, forever. Published URLs may be shared in emails and printed material; there is no redirect layer, so a live URL must never rot. Renaming a track after publish changes only its display name. This holds even for a retired or revived-to-draft track — once published, always locked.
• A Live buyer URL card appears (published tracks only) showing the full /select/<slug> link with a Copy button.

Factor subset and pre-seeded answers stay editable in every status; edits to a published track change the live flow on save.

Conditional display rules

Which layer do I use? Track rules vs factor dependencies

Two surfaces can hide a question, and they are deliberately different layers:

	Track display rules (this tab)	Factor dependencies (factor's Dependencies tab)
Scope	This track only	Everywhere — every track and the cold-open /select flow
Effect	Display-only — never affects scoring	Gates scoring too (a hidden factor's answer is ignored)
Direction	May only test earlier-asked factors in this track	Order-independent (fixpoint evaluation)
Use for	Per-track curation — trimming one audience's flow	Domain truth — facts that hold regardless of track

Rule of thumb: should this rule apply on every track? Then it is domain truth — author it on the source factor's Dependencies tab (managing-factors), not here. The editor shows the same steer inline. Both layers combine as a union of hiding; the tab also lists (read-only) the global dependencies touching this track's factors.

The Track display rules tab lets a track hide a later question — or a single answer within one — based on how the buyer answered an earlier question. Everything shows by default; each rule only ever subtracts. For example: hide the "heavy snow" climate option, or the whole acoustic-control factor, once Geography is answered a certain way.

Each rule reads: Hide the factor / the option X — when factor Yis any of / is none of the checked options. A rule may only test a factor asked before its target; the editor's save surfaces a per-rule message if a rule points forward, gates itself, or tests options that don't belong to its source factor. A factor with no rules, or whose rules don't all match, stays visible — so adding rules never changes an existing track's behavior until a buyer trips one.

Hiding is display-only: a hidden factor sets no answer, it just drops out of the flow (and out of the recommendation's inputs). The precise data model, match semantics (including how multiple rules on one target combine with AND), and the runtime evaluation are in the track conditional-display reference.

What buyers see (/select/<slug>)

A published track serves buyers at /select/<slug>: only the track's factors, in the track's order, with pre-seeded answers feeding recommendations invisibly. Bare /select always remains the full default flow — existing links are unaffected by any track work. A retired track's URL shows a friendly "no longer available" notice linking to /select; an unknown or draft slug shows a "no flow here" notice (a draft's URL does not reveal that the track exists). A buyer mid-flow keeps the track configuration they started with — your edits apply to new sessions, not in-progress ones. Full routing reference: guided-selection-stepper.md.

Right-sizing coverage

Scoping a track means hiding factors — and the right-sizing rules engine listens to factor answers. A rule whose conditions reference a factor the track neither asks nor pre-seeds can never fire for buyers on that track, silently degrading its recommendations. Coverage is the check that keeps that gap visible:

• The edit screen always shows a coverage card: Coverage OK (green) when every factor referenced by active rules is asked or pre-seeded, or a coverage gap warning (amber) naming each missing factor and the rules that depend on it.
• Publishing an uncovered track asks you to confirm first — a one-click "Publish anyway". Coverage never blocks publishing; a deliberately narrow track is a legitimate choice.
• The verdict is recomputed on every view, never cached — so editing a rule so that it references a new factor immediately flags any published track that doesn't cover it.

To resolve a warning, either add the named factor to the track's ask-list, or pre-seed an answer for it (right for factors your audience shouldn't be asked — the pre-seeded option decides which of the dependent rules can fire). Disabled and retired rules don't count toward coverage; disabling a rule also clears any warning it caused.

Lifecycle at a glance

From	Action	To	Notes
Draft	Publish	Published	First publish locks the slug permanently.
Published	Retire	Retired	Usage-guarded: confirms when sessions exist.
Retired	Re-publish	Published	Goes live again as-is, same URL.
Retired	Revive to draft	Draft	Edit before re-publishing; slug stays locked.

Every action is validated before writing and recorded in the audit trail.