Why a backlog cleanup turned a triage prototype into a field schema

One morning, a backlog cleanup exposed a design problem bigger than the backlog. By the end of the work, a quick triage prototype had grown into a field schema, a review queue, and an editorial layer. The cleanup became infrastructure.

The prototype that stayed a prototype

The original triage prototype was simple. An AI assistant read a ticket and added a comment with a suggested recommendation, a score, and a rationale.

For one person reading one ticket at a time, that worked. The rationale was visible and useful. The trouble showed up once the output had to feed a queue, a report, or a later reviewer. The values sat inside chronological prose, nothing enforced what they meant, and a comment from the assistant was hard to tell apart from a human note.

Comments themselves were fine. The problem was treating them as the only operational record. We had done that for long enough that it felt normal, and this ticket forced us to stop.

Replacing prose with state

The replacement was a small documented schema: recommendation, rationale, review status, source/provenance, and any quantitative signals triage needed. The operational fields were typed and queryable. The human-readable note stayed around for context.

We kept the numeric model score as a signal. It is not a probability or an authorization threshold unless someone separately calibrates and governs it. A person stayed the decision point. The comment shortcut was reasonable for early learning, but it piled up debt as soon as other steps needed reliable state.

What the fields forced downstream

Once the schema existed, the downstream needs got specific. A queue could select and batch tickets by documented field values. A refresh process could flag stale recommendations for reconsideration. A review surface could show the structured recommendation next to the original rationale before a person accepted, changed, or rejected it.

The details of the review interface mattered less than one decision: downstream correctness would no longer depend on parsing a prose format that could change under it.

The review layer

Structured state does not make AI triage validate itself. A recommendation, score, or reach estimate is only as good as the context and definition behind it. The review layer is where a person can accept, adjust, reject, or ask for more evidence before the output changes anyone else’s work.

That layer should make uncertainty visible: what sources informed the suggestion, what is missing, when it was generated, which model or rule produced it, and who reviewed it. A neatly formatted field can carry false authority, and this is the guard against that, as much as against plain overconfidence.

Whether a review surface saves time depends on the quality of its inputs and the decisions it supports. Its job is to make automated recommendations inspectable and accountable, not to make them look official.

Why comments feel sufficient until they don’t

Comments feel like real output. They are visible, readable, and they show up in the JIRA activity feed, which gives the sensation of work being done.

They fall short when the workflow needs repeatable downstream behavior. A comment can stay as a valuable audit note, but a score buried in prose cannot safely serve as a sort key, a routing rule, or a durable interface contract.

We shipped the comment-based prototype because it optimized for learning speed. Once the workflow needed handoffs and repeatable review, it needed a field schema and an explicit review layer.

If an AI output will drive sorting, routing, or review, ask where it is stored. Keep the comment as the audit note, add typed fields for the values the workflow depends on, and keep a person as the decision point. A workflow that lives only in comments gives you useful commentary and no dependable operational interface yet.

dxdev LESSON · paste into your AI coding agent
LESSON: AI output in comments is not a data model
SOURCE: dxdev.com/blog/jira-comments-arent-data-model
WHAT HAPPENED: An AI triage step wrote scores, recommendations, and rationale into ticket comments. The output was readable, but downstream routing and review could not rely on prose parsing. A cleanup effort introduced a documented field schema, a review queue, and a human decision point so automation outputs could be queried and audited without treating a language-model comment as a database.
THE RULE: When an automated output will drive a downstream operational decision, define a structured field or record for the value and its provenance. Keep comments or notes for rationale and context; do not use prose parsing as the primary control plane.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any operational automation output that affects routing, prioritization, or state but lacks a documented schema, owner, provenance, and review status.
  2. Any downstream control that extracts a decision from free-text comments instead of using a validated structured record.
  3. Any queue, filter, or sort that treats an uncalibrated model score as a final decision rather than a review signal with documented limits.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.