Use Case · Operations

Human review queue on the Software Lifecycle Cloud

A human review queue on KERNSTACK is where automation’s uncertainty goes to be decided once: items that scoring, extraction, or rules could not settle pause as titled steps in workflows, reviewers work them from one queue with the evidence attached, and every verdict is recorded beside the machine’s original scores — the dataset that steadily shrinks the queue itself.

Approval WorkflowsNoSQL TablesCollaboration Board
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Reviewers work a queue the workflow improvised for them: a spreadsheet tab, a flagged folder, an inbox label. Assignment is whoever notices first, the machine’s reason for flagging is lost, and nobody can say whether the queue is shrinking because quality improved or because people started rubber-stamping at 4 p.m.

Architecture on the Software Lifecycle Cloud

Any automated step can end at a human step carrying the item’s context: the record, the machine’s scores, the rule that fired. The run waits; the queue shows age and reason across sources, because moderation, extraction exceptions, and approval requests share the step mechanism. Verdicts write back onto the source record, so downstream steps resume with the human’s answer as ordinary data.

Verdicts are training data with a day job

Every decision pairs the machine’s judgement with the human’s, timestamped. Monthly, that pairing answers the only tuning questions that matter: which threshold produces work humans always overturn, which rule never fires usefully, where reviewers disagree with each other. Queue design here is a feedback instrument disguised as an inbox.

  • One queue across sources: items arrive with their reason and evidence, not as naked rows
  • Reviewer, verdict, and machine score stay together — overturn rates are a query
  • Ageing items are visible and remind owners; nothing rots in a folder nobody owns

Staffing honesty

A queue does not reduce the need for judgement; it concentrates judgement where it is scarce. Sizing the automated band so the queue matches the reviewers’ real hours is an operational decision the recorded data informs — including the honest option that some item types should stop being auto-flagged at all.

FAQ

Frequently asked questions

Any step’s judgement: a confidence below threshold, a rule match, a model’s uncertain band. The item arrives with the scores and the rule that fired, so the reviewer starts from the machine’s reasoning, not from zero.

They wait as titled workflow steps, visible as one queue with age and reason; teams route by step type or let reviewers pull. Assignment policy — pull versus push — is an operational choice the queue supports either way.

Through you: verdict-versus-score records show exactly where thresholds should move, and moving them is a reviewed change to the workflow or worker. The queue’s history is the evidence base for needing fewer humans on the easy band.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · OrchestrationWorkflowsDurable workflows with human pausesService · DataTablesServerless key-value and document tablesService · PeopleCollaborationBoards and conversations on the projectIndustry SolutionLogistics Cloud SolutionsLogistics products on KERNSTACK give every shipment one timeline and every exception an owner: carrier scans and status callbacks are stored raw, normalised into canonical states per shipment, reconciled against orders by workers, and surfaced — to dispatchers as an exception queue, to customers as a tracking page reading the very same rows. The fog between “the carrier says” and “our system says” is where this architecture earns its keep.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.Use Case · AgentsAgent operations consoleThe raw material already exists in the project: hosted git lists branches including agent/<id>, each agent branch maps to its environment, and every deploy begins as a plan a person approved. The console view arranges that material — branch, environment URL, plan summary, approval state — into the board engineering managers actually ask for, with conversations and board topics carrying the discussion around each run.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →