Skip to main content
DoneThat

AI Adoption GuideGovernmentPlan

Resource allocation optimizer

Reinforcement learning recommends budget distribution across competing plan elements given fiscal constraints and outcome targets.

Government processPlanFundAuthorizeDeliverInspectEnforceReportClose

By Don, DoneThat’s AI coach · updated

Freeze the envelope and the target list before any run

Do not run an allocation optimizer until the fiscal envelope and the outcome target list are locked artifacts, not working guesses. The useful output is a recommended split across competing plan elements that cites those two sources. It is not a new ceiling, not a savings claim, and not the budget Finance will table.

Inventing an envelope is the first failure. Someone feeds last year's outturn plus a hoped-for increment, the model returns a tidy distribution, and the packet looks finished. If the envelope was invented, every amount in the split is invented with it.

Lock the envelope from the constraint table the rest of the plan already uses. That table should name the total you may distribute, the floors you may not breach (debt service, grant matches, statutory minimums), and the rules that bind individual lines (personnel caps, restricted funds, one-time versus ongoing). Lock the target list from the adopted outcome set for this cycle. A program is in scope for a recommendation only when it has a target on that list.

Reinforcement learning, here, is a search over distributions that stay inside those constraints while moving toward those targets. It does not discover a better envelope.

OpenGov, Palantir, Microsoft, and Anaplan-class planning tools are the usual homes for the table, the chart of accounts, and the planning workspace. Treat them as the class of systems that already hold constraints and lines. A complete-looking grid can still be last year's structure with this year's wishes typed in. Do not skip the lock because the grid looks finished.

If two offices disagree about the ceiling, resolve that before the run. Write the lock in the packet: date, source document, and the names of the constraint table and target list.

What a quality recommendation must cite

A quality recommendation is a proposed split plus citations, not a split alone. Each recommended amount should point to the constraint-table row that authorizes or caps it and to the target-list item it is trying to serve. If a reader cannot walk from a recommended amount to those two citations, the output is not ready for Finance.

Point to the envelope row, the restricted-fund rule, the match requirement, and the named target. "Aligns with strategic priorities" is not a cite. Neither is a model confidence score.

Do not attach a savings figure. The model is distributing a locked envelope. A savings claim is a different question: cut this envelope, compare to last year, or score a reduction. Mixing it in smuggles a second decision into the first.

When the search cannot improve a line without breaking a floor, say so in the cite. The constraint binds, the target may remain unmet, and the recommendation holds at the floor. Silence about a bind is how a rec later gets treated as discretionary room.

Keep this packet next to the scenario comparison matrix when leadership is still choosing among plan shapes. The optimizer recommends a split inside one locked frame. The matrix compares frames.

Leave a program blank when it has no target

Empty stays empty. If a program has no target on the locked list, the recommendation for that program is blank. Do not infer a target from last year's activity, from a neighboring program, or from a narrative in the budget book.

The model wants a complete vector, and a complete vector looks professional in a work session. So the run fills library hours, a small grants line, or a pass-through as if an outcome had been adopted. That fill is a policy invention. It will be read as if the board had asked for that result.

Blank is the honest state. Finance can still table a number for that program by statute, by prior policy, or by the human table. The optimizer's job stops at the edge of the target list.

If staff argue that a target exists "in practice," send them back to the lock step. Either the target is added to the adopted list before a later run, or the line stays out of the recommended split. A footnote is not the target list.

A statutory transfer can belong in the constraint table as a floor and still have no outcome target. The floor binds. Do not glue on a fake target so the row looks populated.

Use the proposal scoring assistant when the real question is whether a new element should enter the plan at all. Scoring a proposal is not allocating to a line that has no target.

One walkthrough: three plan elements on a locked envelope

Take a county plan cycle with three competing elements on the same operating envelope: jail diversion, road resurfacing, and library hours. The constraint table already locks the envelope and names a match requirement on a transportation grant plus a statutory floor on detention operations. The target list includes diversion completions and lane-miles restored. Library hours sit in the chart of accounts with no adopted outcome target for this cycle.

The officer does not invent a fourth amount "to give the model room." The envelope is the table. The run may only move amounts among in-scope elements inside that envelope and those binds.

A usable recommendation in the packet looks like this:

  • Jail diversion: a recommended amount that cites the envelope row, notes the detention floor it must not cannibalize, and cites the diversion-completion target.
  • Road resurfacing: a recommended amount that cites the same envelope, the grant-match constraint, and the lane-miles target.
  • Library hours: blank. No target, no recommended split. The line remains for the human table.

There is no savings line and no optimized surplus. If someone wants to cut library hours to feed diversion, that cut is not this optimizer's output, because library hours were never in the recommended vector. A cut is a separate Finance decision, documented as such.

This is a packet shape, not a result. Copy the citation pattern and the blank. Do not fill it with invented amounts.

If leadership wants to know what happens to completions or lane-miles if the envelope itself changes, that is not a second run with a made-up ceiling. Use a policy impact simulation on an explicit alternate constraint, or a new scenario in the comparison matrix, then a fresh allocation run only after the alternate envelope is locked.

Finance tables the budget; the model does not

The recommended split is an input to the budget table, not the table. Finance still prepares the instrument that goes to council or the board. Staff still reconcile funds, positions, and restricted sources. Elected officials still vote.

Treating the rec as the voted budget is the second classic failure. It shows up as "the model already decided" in a work session, or as a packet that omits the human table because the export looked complete. The rec belongs in an appendix or a decision memo with its cites. The tabled budget is the human document, including blanks the model left alone and any political adjustments Finance is willing to defend.

Label the memo: recommended split, not adopted allocation. Date the lock on the constraint table and the target list. If either artifact changes after the run, the rec is stale. Run again or throw it out. Do not patch a few lines by hand and keep the old cites.

After adoption, when actuals diverge, use a variance explainer against the tabled budget, not against the model's last vector. Explaining variance to a recommendation that was never voted trains the organization to treat the model as the budget of record.

Planning suites, data platforms, and productivity tools will export a grid that looks like a budget. Your control is refusing to run without a lock, refusing to fill a line with no target, and refusing to let the export replace the table. If a run cannot cite both the constraint table and the target list for every recommended amount, send it back.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first