Review Primitives
Summary
Review primitives are the reusable pieces that make human-in-the-loop work auditable instead of ad hoc: queues, artifacts, timelines, issues, approvals, repair actions, actor context, and workflow resumption.
Reader Question
When a domain workflow needs human judgment, which primitives should it reuse instead of inventing a one-off page or status flag?
Surface Or Workflow
The entry surface is usually a queue or case view. Marketing review assets, POA repair screens, identity resolution, payroll time review, and precon repair jobs all need the same core shape: show evidence, record a decision, preserve history, and unblock later automation.
Lifecycle
Automation emits an issue or review item. A queue prioritizes it. An artifact viewer shows source evidence. An audit timeline explains what happened before the item reached a human. The human chooses a repair action or approval. The system records actor, tenant, reason, and result. Workflow state then resumes through a service or job.
Child Threads
- Review Workflow Foundations: how shared cases, issues, artifacts, decisions, locks, and resumption compose.
- Workflow Repair Methodology: how failures become issues, pauses, retry attempts, resumes, and auditable repair state.
- Identity Resolution Methodology: how source rows, topology cases, review, decisions, transfer execution, and supersession determine customer/prospect identity.
- Cases Issues Events: how stateful operational records are modeled.
- Review Queues: how work becomes visible and prioritized.
- Artifact Viewers: how source evidence is inspected.
- Audit Timelines: how history is made legible.
- Repair Actions: how humans change workflow state safely.
- Approval And Actor Context: how decisions remain auditable.
- Workflow Resumption: how later jobs continue after correction.
- Issue Taxonomy: how ambiguity is classified.
Implementation Boundaries
The shared boundary is services/workflow and libs/workflow, with domain surfaces linking in from POA, precon, marketing, payroll, and identity resolution. Review primitives should expose capabilities rather than require each domain to duplicate queue, timeline, or repair mechanics.
Tradeoffs
Reusable review primitives take more design effort than a bespoke form. They avoid the long-term cost of hidden manual state, one-off repair scripts, and untraceable operator decisions.
Visual Notes
The target visual is a review lifecycle map: issue to queue to artifact to decision to audit event to resumed work.
Source Evidence
services/workflowlibs/workflowdocs/domains/poa.md