Field Deprioritization

Field deprioritization is a standing rule, set by a workspace Admin, that says "this data field is not reviewed for now" across the whole review queue. It exists for fields that are correctly flagged by validation but that nobody needs to look at yet: a field your receiving system does not carry, a column a downstream team has not started using, or an attribute you plan to clean up in a later Spec version. Instead of approving the same field hundreds of times, the Admin records one decision with a reason, and Talonic takes every matching item out of the queue.

Deprioritization is deliberately an Admin action (workspace Admin, plus Talonic staff). The ordinary approve, correct, and override decisions in Field Review are open to Members, but a deprioritization rule silences a field for every reviewer in the workspace, so it sits one tier higher. Every workspace member can read the rules, so a reviewer who wonders why a field never shows up can see who demoted it and why.

Creating a rule

An Admin starts from a field in the review queue or from a data product's Review Mode and chooses Deprioritize field. The dialog asks for two things. The Reason is required and is shown on every item the rule takes out of the queue, for example "The receiving CRM does not carry this field yet". The Scope is either every Spec in the workspace or only one Spec; the one-Spec option is unavailable when the group you started from spans several Specs, because there is no single Spec to narrow to. Confirming creates the rule and immediately sweeps the open items it covers.

The first sweep is capped per call (1,000 items by default) so that a field held across a very large backlog does not block the request. When items remain, the dialog reports how many are still open and offers Continue ({count} left); the same action is available later as Continue sweep in the rules panel. Items that could not be demoted are counted separately so nothing is silently dropped.

What a demotion does

A demotion is the same machine resolve Talonic uses for capacity demotion: the item leaves the queue with a decision-log row attributed to the system actor system:field-deprioritization and a resolve reason of field_deprioritized, and its held cell is released so the value continues downstream as extracted. The rule overrides always-review holds and exemptions for that field, because the Admin's written reason is the record of that choice. Demoted items carry a Deprioritized badge and appear in the queue's demoted audit view with the rule's reason.

A rule is standing, not one-off. After it exists, later pipeline runs that land items on the field are demoted on arrival: the pipeline processors, review recreation, stage replay, and retriage all reconcile against the active rules right after they route items to review. The Deprioritized fields panel in the demoted view lists each rule with its field, scope (one Spec or all Specs), author, and an open count of items the rule still covers, which is non-zero after a capped sweep or for a run that has not reconciled yet.

Lifting a rule

When the field matters again, an Admin chooses Lift in the Deprioritized fields panel. Lifting stops future demotions: new items on the field are reviewed again. Items that were already demoted stay demoted and remain in the audit view, because their release was a recorded decision; restoring them to review is a stage replay on the affected runs. Lifting is therefore safe to do at any time and never rewrites history.

• Admin-only standing rule: one field is not reviewed for now, across the queue
• Reason is required and shown on every demoted item
• Scope: every Spec in the workspace, or only one Spec
• Creating a rule demotes open items at once, in capped sweeps with Continue
• Later runs are demoted on arrival after routing
• Demoted items get a decision row, a Deprioritized badge, and a place in the demoted audit view
• Lifting stops future demotions; already-demoted items stay demoted

API

Rules are managed through the platform's session API at /field-review-deprioritizations, the same API the web app uses with a signed-in user. It is not part of the public `/v1` API and does not accept API keys. GET lists the rules (every member), POST creates a rule and runs the first sweep, POST /:id/apply continues a capped sweep, and DELETE /:id lifts a rule; all writes require a workspace Admin.

POST /field-review-deprioritizations
Content-Type: application/json

{
  "fieldKey": "crm_segment",
  "reason": "The receiving CRM does not carry this field yet",
  "userSchemaId": null
}

# Sweep result:
# { "demoted": 1000, "remaining": 240, "errors": 0 }

# Continue the sweep, then lift the rule later:
POST   /field-review-deprioritizations/{id}/apply
DELETE /field-review-deprioritizations/{id}

{
  "id": "5d0c7e1a-2b44-4f1e-9a63-3f8e2c1b7d90",
  "fieldKey": "crm_segment",
  "userSchemaId": null,
  "reason": "The receiving CRM does not carry this field yet",
  "createdById": "2a9f…",
  "createdByName": "Workspace Admin",
  "createdAt": "2026-09-09T10:02:11Z",
  "liftedAt": null,
  "openItems": 0
}