promptdojo_

Status from artifacts — the roll-up that can't lie, and the not-ready call — step 2 of 8

Derive the RAG

Run it. Five tasks, five statuses, zero opinions consulted. Walk the interesting ones:

  • T-2 — bounced once at the acceptance gate, back in the build lane with a named-check rework note. Amber is exactly right: not in trouble, worth a glance. Nobody had to decide to disclose the bounce. The record disclosed it.
  • T-3 — second bounce, so red before it's overdue. This is the early-warning trade you're making: vibes-status goes red when the date slips, which is weeks after the trouble started. Rework-count status goes red the moment the pattern appears. On an AI-speed project the gap between those two moments might be the whole margin you have.
  • T-4 — nothing bounced; it's just late. Overdue-and-unaccepted is red no matter how good the excuse in standup was. The function didn't attend standup.
  • T-5 — the redemption arc: two rough rework cycles, then acceptance. Green. History doesn't haunt a task that got through the gate; accepted short-circuits everything below it. Status measures where the work is, not how bumpy the ride was.

The fields are the contract

Notice what task_rag never reads: percent complete, builder self-reports, developer confidence, "should be done by Friday." It reads three fields, and all three are facts with provenance — accepted comes from the gate verdict, rework from the attempt counter, overdue from a date comparison. If a field can't be traced to an artifact, it doesn't get to influence the color. That's the whole discipline, and it's why lesson two had to come first: you can't derive status from acceptance records you never created.

One design note before the drills. The thresholds here — one bounce for amber, two for red — are this course's defaults, not physics. Your PMO might set them differently, and that's fine. What's not fine is the thresholds living in someone's head. In a function, the rule is arguable, versionable, and applied identically to the workstream run by your best lead and the one run by the contractor nobody's met. Consistency is most of what a roll-up is for.

Next: aggregation. A workstream full of these tasks needs one color, and the only honest aggregate is worst-of — which you'll build in two steps, because it's one line, and then you'll never trust an averaged status dashboard again.