The night run and the morning after

What an assignment technically does

JiCo does not work exclusively in direct conversation with a person who asks question after question and waits for every answer. It can also run as an assignment: triggered individually, as a queue of several tasks one after another, or on a deliberately readable schedule such as "weekdays at 06:00" — expressly not as a cryptic cron notation that one would first have to look up in a table to understand when something actually happens.

Such a run reads tickets, checks them against the stored rules and conventions, formulates concrete proposals — and ends, as a matter of principle and without exception, in the state "waiting for approval", never in "done". An assignment that had actually changed something on its own would, strictly speaking, no longer be an assignment in JiCo's sense. It would be precisely the unsupervised automation that JiCo expressly does not want to be at this one point — not even when the assignment ran overnight and nobody was watching live.

Why 400 raw proposals in the morning would be no relief

Clicking through 400 individual, unsorted proposals one after another the next morning would be no real relief. It would be a new, subtler form of the same work — only harder to read than the original ticket itself, because the actual connection between similar cases would be lost and every line would have to be considered in isolation.

That is why the findings of a run are not simply lined up but grouped and condensed by topic: similar things are presented together, with the option of unfolding each group individually where needed, if one wants to follow a particular decision more closely instead of blindly trusting the summarised assessment. In this way 400 individual lines become a manageable, genuinely workable number of thematic groups — not because less was checked, but because recognisably similar things are presented in bundles rather than every single case in isolation.

Open questions are named, not silently guessed

One detail that makes the real difference between a trustworthy and a merely impressive system concerns the handling of uncertainties: if a model comes across something ambiguous during a run — a field that could be interpreted in different ways, a piece of information that is simply missing from the ticket, a connection that cannot be established unambiguously — it ends up as its own, clearly marked category in the finished approval folder: as an open question, plainly named, instead of being silently processed into an assumption and hidden inside a proposal that sounds finished.

A guessed answer that appears confidently phrased inside a proposal would in the end be considerably harder to discover than an honestly named gap that is marked as such from the outset. That is exactly why this separation is not an optional detail but a fixed part of every folder: what the system knows for certain stands as a proposal. What it does not know for certain stands as a question.

What can remain open after an approval

A change that has been approved is not necessarily the end of the story, even if one might assume so at first. Some decisions have consequences in an entirely different place in the system, which at first glance seem to have nothing to do with the original change — a changed status that, according to the stored conventions, should pull a second field along with it, a comment that ought to update a piece of information elsewhere in the ticket so that the record stays consistent as a whole.

These follow-up duties end up in a separate follow-up list of their own, rather than simply hoping that somebody on the team happens to remember them, or that the responsible person notes them down by hand. The night run therefore does not simply end with a folder full of yes and no decisions, but with three cleanly separated categories: what is now concretely to be decided, what has remained unclear in the process, and what necessarily follows from a decision already taken earlier.

A readable schedule instead of a cryptic notation

A small detail that is surprisingly effective in everyday use concerns the way such a run is planned in the first place. Many comparable systems require a cron notation at this point — a terse sequence of numbers and asterisks that is powerful, but for most people barely readable without looking it up. A single misplaced character there can mean that a run happens at the wrong time or not at all, without anyone noticing until the expected folder is missing the next morning.

JiCo deliberately does without this notation in favour of a sentence that anybody understands immediately without prior knowledge: "weekdays 06:00". Whoever reads that sentence knows at once when the run takes place, without having to consult a table — a small example of the fact that professional language instead of technical shorthand applies not only to approval proposals, but consistently to setting up the system itself.

Why this effort is worth it at all

One could object that all this condensing, grouping and tracking is itself effort — and that is undoubtedly true. The difference lies in where that effort falls: once, in the system, automated and traceable, instead of every morning anew in the head of a single person who is trying to remember yesterday and keep track of hundreds of individual cases. That shift is the actual benefit of assignment operation — not that less is checked, but that the checking happens in the right place and that its result comes in a form a person can actually work with.