Technology & AI Transformation · Decision record

Which AI request should a city pilot first?

A city operations team has three AI requests and budget for one pilot. The decision has to be explainable to the city manager before anything is bought or built.

Illustrative work sample. Built on a synthetic organization with invented figures to show how we think and what a deliverable looks like. It is not client work and describes no achieved result.

The organizational challenge

The operations division of Millbrook (synthetic city, about 300 employees) has three AI requests in one quarter and budget for one pilot: an automated monthly update for the city manager, a policy finder for staff, and resident-facing answers on the website. A vendor has demonstrated all three. The IT manager has capacity for exactly one and no framework for choosing between them.

Two constraints narrow the field: most of what the city produces is a public record, and anything resident-facing has to be verified before it is published.

The decision to be made

The division must select one of three AI pilots to fund this quarter, with explicit conditions and stop points attached before any purchase. The decision record has to survive a council question and a public-records request, so the reasoning carries as much weight as the choice.

The approach

Clarified the useful purpose of each request with the people who made it. Two of the three turned out to be requests for a working process, not for AI.
Checked the dependency each candidate rests on: approved inputs, a named reviewer, verified content, document ownership. Two of the three failed the check immediately.
Set stop conditions before starting: the discovery finding that would end each candidate, so the pilot is a test, not a commitment.
Recorded the decision in a form the department can carry to leadership, with the acceptance checks a pilot would have to pass.

Deliverable preview

Three requests, one pilot, explicit stop conditions.

Textstone LabsDecision record · Example G-01

Candidate	Useful purpose	Dependency to check first	What would stop it	Disposition in this example
Internal monthly-update draft	Assemble approved department summaries into one draft for the city manager	Consistent inputs and an accountable reviewer	Summaries are not consistently approved; no reviewer has capacity	Begin discovery for a limited pilot
Staff policy finder	Point staff to the approved source of guidance on a question	Current documents, access rules and named document owners	Ownership of policy documents is unclear; outdated versions circulate	Resolve source ownership first, then reconsider
Resident-facing answers	Help residents find service information without a phone call	Verified content, records-law review and a staffed escalation route	No verified content set; no one to answer what the tool cannot	Defer pending content and review design

Decision

Investigate the internal update first.

Its inputs and reviewer can be bounded, and a failure surfaces internally before it reaches a resident. Discovery still has to confirm that the source summaries are approved and that the draft actually saves time.

What would change the decision

The source summaries are not consistently approved

Pause the pilot. Establish who owns each department summary, which version is approved and the period it covers. Automating an unresolved process carries its uncertainty forward.

No one can take responsibility for reviewing the draft

Do not release the draft automatically. Assign the review responsibility and confirm capacity, or choose a different first scope. A fluent summary is not evidence of an approved report.

The current manual process is already simple and reliable

Compare the cost of a new workflow with the effort actually being spent. A short process improvement may be the better next step than an AI pilot.

Pilot acceptance conditions

Each substantive statement in the draft points to an approved source.
Missing evidence produces a flag, never invented content.
The reviewer can reject and revise before anything is released.
The manual process stays usable throughout the pilot.
Run records show what was drafted, from which sources, and who approved it.

How success would be evaluated

What we would measure.

Time returned: hours the city manager’s office spends assembling the update, before and during the pilot.
Source traceability: share of draft statements that link to an approved summary. Anything below full traceability is a defect, not a rounding error.
Reviewer burden: time to review and approve a draft, and the count of rejected drafts. A draft that takes longer to check than to write has failed.
Stop conditions triggered: logged and reported, with the decision taken.
Records handling: confirmation with the records officer that run records and drafts are retained under the applicable schedule.

The engagement output is the decision record, a source register, an open-questions log and a pilot scope with owners and acceptance checks.

Practice area

Technology & AI Transformation

Next step

Facing a decision like this one?

Bring the situation and the constraints. The first conversation is about whether and how we can help.

Discuss your priorities Email us