Deterministic Grouping vs. Letting AI Structure Your Update
Why the organizing step of a product update should be rule-based and the writing step should not — and what goes wrong when a language model decides both.
Soobrief Team — Product & Engineering, Sooapps ·
In short
A language model asked to organize and write will produce a different organization each run from identical input. For a weekly record that is disqualifying, because two consecutive updates stop being comparable. The durable split is: deterministic rules decide structure, the model writes prose on top of it. This keeps output stable week to week, keeps errors correctable at the rule level, and reduces how much source data has to reach the model at all.
There are two jobs inside every generated product update, and they have almost nothing in common.
Organizing is a classification problem. This card belongs to that product, in that category, inside this date window. There is a correct answer, it is derivable from data the tracker already holds, and the same input should always yield the same output.
Writing is a language problem. Turn PROJ-4412: invite bug into a sentence someone outside the team can use. There is no single correct answer, and judgment about tone and emphasis is exactly what makes it hard.
Language models are genuinely good at the second job. Handing them the first one causes a specific, predictable set of problems.
The instability problem
Run the same set of fifty completed tasks through a model twice with the instruction "organize these and write a weekly update." You get two different documents. Not just different prose — different section names, different groupings, different decisions about what deserves its own heading.
For a one-off summary, that is harmless. For a weekly document, it is disqualifying, because the value of a weekly update comes substantially from comparison:
- Did the Integrations section grow or shrink relative to last week?
- Is that area still getting attention?
- Was something dropped, or just renamed by the model this run?
When headings drift week to week, none of those questions can be answered by reading. The reader cannot tell the difference between "the team stopped working on integrations" and "the model called it Platform this week." A document that cannot be compared to its own previous edition is a much weaker artifact than it appears.
The correction problem
This one matters more over time.
Suppose an item lands in the wrong section. With deterministic rules, the diagnosis is direct: some rule mapped this board or label to the wrong category. You change the mapping. Every future update is fixed, and you know exactly which past updates were affected, because the same rule produced all of them.
With model-decided grouping there is no rule to fix. You can adjust the prompt and re-run, but you have no guarantee the same misclassification will not reappear, and no way to identify which previous updates contain it. Errors are not correctable in any systematic way — only re-rollable.
That difference compounds. A rule-based system converges: each correction is permanent. A prompt-based system oscillates: each fix is a nudge with uncertain durability.
The data exposure problem
This one is easy to overlook and it has real consequences.
If a model is deciding structure, it needs enough context to classify — which in practice means task descriptions, comments, sometimes attachments. All of that has to leave your system and reach the provider.
If structure is decided before the model is involved, the model's job shrinks to writing prose over an already-grouped outline. It needs the grouped titles. It does not need descriptions, comments, or internal discussion. That is a much smaller surface, and it is a deliberate design lever rather than an accident.
Soobrief exposes this as an explicit deployment setting. Task descriptions are gated behind a flag that stays off by default: with it disabled the model receives only redacted titles plus product and category groups. Enabling it is a decision a deployment makes knowingly, after verifying the data terms of the LLM provider in use — not a default that quietly ships internal content to a third party.
What the split looks like in practice
Source (Trello / Jira)
│
▼
┌─────────────────────────┐
│ Deterministic grouping │ Rules only. Same input → same
│ board → product │ structure, every single run.
│ label → category │
│ timestamp → window │
└─────────────────────────┘
│
▼ already-organized document
┌─────────────────────────┐
│ Narration (LLM) │ Prose only. Never reorders,
│ titles → sentences │ never regroups, never invents
│ groups → summary │ a section.
└─────────────────────────┘
│
▼
┌─────────────────────────┐
│ Human review │ Final edit before publish.
└─────────────────────────┘
Each stage has one responsibility and a checkable output. When something looks wrong, the stage is immediately identifiable: wrong section is a rules problem, awkward sentence is a narration problem, wrong emphasis is a review problem.
Compare that with a single prompt that does everything. When the output is wrong, there is nothing to inspect — only the prompt to adjust and another roll of the dice.
Where the model genuinely earns its place
None of this is an argument against using a language model. The narration step is real work that models do well:
- Rewriting terse ticket titles as outcomes a non-participant can parse.
- Finding the through-line across thirty items and stating it in three sentences.
- Adapting register for the audience — leadership summary versus team record.
- Producing the same update in Turkish and English without a separate translation pass.
That is a substantial amount of value, and it arrives without the model touching structure at all.
The principle generalizes past product updates: let rules decide what is true, and let the model decide how to say it. Anywhere output needs to be comparable across time, the classification step wants to be deterministic.
Frequently asked questions
Why not just let a language model organize the update too? Because identical input produces a different organization each run. For a document readers compare across weeks, unstable structure destroys the comparison and makes errors impossible to correct systematically.
Does deterministic grouping mean no AI at all? No. The model still writes the prose, which is the part that genuinely benefits from language ability. It receives data that is already organized rather than deciding the organization.
What happens when an item is grouped incorrectly? With rules, you fix the rule and every past and future update with that pattern is corrected. With model-decided grouping there is no rule to fix — only a prompt to adjust and a re-run to hope on.
Does this approach send less data to the LLM? Yes, meaningfully. Because structure is decided before the model is involved, the model only needs grouped titles — descriptions and other sensitive fields can be withheld entirely.
Related reading: How to write a weekly product update · Turning a Trello board into a changelog · Running a team without status meetings