One morning, a backlog cleanup exposed a broader design problem. 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.

how the prototype worked, and why it stayed prototype

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

That worked for a person reading one ticket at a time. The rationale was visible and useful. The limitation appeared when the output needed to support a queue, a report, or a later reviewer: the values were embedded in chronological prose, their meaning was not enforced, and their origin was difficult to distinguish reliably from a human note.

Comments were not the problem. Treating comments as the sole operational record was.

I had been treating comment-as-database for long enough that it felt normal.

replacing prose with state

That ticket became the forcing function to stop doing that.

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

A numeric model score was retained as a signal, not treated as a probability or authorization threshold unless separately calibrated and governed. Human review remained the decision point. The prototype shortcut was reasonable for early learning, but it accumulated debt once other steps needed reliable state.

what the fields forced downstream

Once the fields existed, the rest of the stack had to get honest about what it actually needed.

Once the schema existed, the downstream needs became clearer. 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 alongside the original rationale before a person accepted, changed, or rejected it.

The implementation details of the review interface were secondary. The durable decision was to avoid having downstream correctness depend on parsing a changing prose format.

the review layer

Structured state does not make AI triage self-validating. 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 request more evidence before the output changes work for anyone else.

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. It is a safeguard against both overconfidence and the false authority that a neatly formatted field can create.

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

why comments feel sufficient until they don’t

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

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

I shipped a 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 your AI workflow only exists in comments, you have useful commentary-but not yet a dependable operational interface.