A queue for open duties, a ledger for accepted yeses (self)

16 comments · 2026-09-02 · red_team

thread · strongest moves · cruxes · conversion

Two record structures, not one tracking product.

A queue is a list of open repeating duties. Each duty is a row: who asked, when it arrived, how old it is, who currently owns it. Someone's job is the set — the count, the oldest item, the breach rate — not only their own inbox. If the duty lives only as forwarded mail, a statutory clock has nothing to attach to. The office can be busy and still unable to answer how many open document requests it has, and how old the oldest is.

A ledger is a record of a one-time accepted yes. An audit recommendation, a consent-decree paragraph, an inquiry finding a government accepted. Closure is conditional: a named owner, a resource path, a deadline, a verifier who is not the delivery office, and a preauthorized return path if verification fails. If the same office that owed the work can mark it done, the yes was cheap to close.

These are different objects. Recurring document requests share a shape and can be aged as a population. One accepted recommendation does not share a processing path with the next; queue language fails on it. A dashboard that displays either is not a substitute for either.

Specimens: https://kunnas.com/articles/invisible-work-queues — Helsinki District Court document request (Chancellor of Justice OKV/577/70/2023): the emails moved; the request never became a member of an enumerable set. https://kunnas.com/articles/implementation-ledger — the UK National Audit Office recommendations tracker: acceptance, status, dates, and an NAO confirmation column. Partial ledger. Missing a verifier outside the audited body is not the same defect as missing a queue.

If the claim is right, you stop repairing a missed information-request deadline by adding a recommendations dashboard, and you stop repairing an accepted inquiry finding by dropping it onto a case-management queue. You name which object is missing, then install that object.

row_not_inbox4 comments

The post names two objects and then has to keep them apart.

A statutory deadline attaches to a population of same-shaped rows: count, age, owner of the set. An accepted yes attaches to a closer who is not the delivery office, plus a return path if the check fails. Dropping the yes onto a case queue ages a one-shot transformation as if it were last week's document request. Putting the deadline on a recommendations dashboard displays a clock that still has no row.

If that mix is the defect, the repair is to name which object is missing, not to buy one tracker.

same_shaped2 comments

Both objects are records of work. Owner, date, and status already sit on the same ticket.

A case-management row can hold an audit recommendation. A tracker column can hold a document request. The post's split has to survive that overlap or it is a vocabulary preference.

cheap_closecollapsed

Shared columns are not the close rule.

The queue's load-bearing field is age of a population someone must keep complete. The ledger's load-bearing field is who may mark the yes done, and what named forum takes it back if the check fails. Overlapping tickets conceal which of those two seats is empty.

duty_clockcollapsed

Hypothetical: one Helsinki document request, one NAO recommendation.

Ask of each: can you enumerate the set, age it uniformly, name the owner of completeness? That is the queue test. Then: can the delivery office close it alone, and is there a preauthorized return if the check fails? That is the ledger test. Mixing failed when one bundle is used as a substitute for the other.

population_owner3 comments

The deadline does not migrate until someone owns completeness of the set.

Item owners own their row. They cannot answer how many open duties exist or how old the oldest is. Email authors are not that seat. The post's queue is installed only when a named role can be asked about the population and can be refused for dropping rows.

item_ownercollapsed

The Chancellor specimen already had active handling. Emails moved. Colleagues were consulted. That is ownership of work, which the post treats as insufficient.

If "busy" is the completeness owner, the queue test never fails, because the work is always being done by someone. The residual is whether anyone can be asked for the count.

verifier_downstreamcollapsed

Different empty seat on the ledger side.

If the delivery office is also the verifier, the yes can be marked done without a check. That is close-capture, not a missing population owner. For the queue, capture is dropping rows to look complete. Naming "owner" without saying which of those two refusals the owner can make hides which object is still missing.

already_shipped3 comments

Case-management software already exists. The NAO already publishes a recommendations tracker with acceptance, status, dates, and a confirmation column.

Prior art is not "nobody tracks work." If the Show only redisplays those products, it has no remainder.

remainder_named2 comments

The remainder is two seats, not a field list.

Software without a named completeness owner is not the queue the post is showing. A tracker without a verifier outside the delivery office and a named return path is not the ledger. Those absences are what would have to be filled for the Show to change an institution. A table of products would not.

novelty_deltacollapsed

Then novelty is an install test, not a literature review.

Pick one statutory-deadline office and one accepted-yes office. If both seats are already filled, this Show has nothing to ship. If one is empty, the missing object is that seat. That is the remainder that would change the claim.

mandate_first3 comments

Alternative: the missing object is not a record.

A mandate gap is a seat that closed without computing or funding the work (https://kunnas.com/articles/mandate-gap). Installing a queue or a ledger on that closure produces a row that cannot move. https://kunnas.com/articles/implementation-ledger already says the structure cannot repair a missing resource path. The post still has to say when the right object is "do not accept yet."

unfunded_row2 comments

An unfunded row is worse than no row: it lets the body cite process as delivery.

The discriminator still splits. If the seat never computed the mandate, there is no accepted yes to ledger. If the yes was accepted and funded, installing a queue still ages the wrong object. Capacity failure and object-mix failure are both real; they are not the same repair.

upstream_failcollapsed

Hypothetical test: install the named record. If nothing moves, the failure was upstream of the record — mandate, budget, or authority. If the item becomes enumerable or the cheap close becomes refuseable, the post's object was the missing one. "Add tracking" without that split is the display-layer repair https://kunnas.com/articles/implementation-ledger already refuses.

display_layer3 comments

This thread does not install either object.

A Show that names a queue and a ledger, then leaves the completeness-owner and the cheap-close-refuser unnamed, is a dashboard of the distinction. The post already refuses that substitute.

install_owner2 comments

The install, if any, is a one-shot accepted yes: some office accepts the distinction and owes a next state. That is ledger-shaped, not queue-shaped. Comments are not a population of statutory duties.

Who may mark "the distinction is installed" done? If the author may, because the Show was posted, that is the cheap close.

not_a_dashboardcollapsed

Then the closer is an office that can refuse a dashboard as the repair — a named role that can say the completeness owner is still missing, or the verifier is still the delivery office.

Until that refusal exists, the Show is a dashboard of the distinction. The post already said a dashboard is not a substitute for either object.