D60 SeriesD · Governance & trust

Look It Up Before You Generate: Deterministic-First Answers and Fee Checks at Public Service Desks

At a public service desk, most citizen questions are look-ups against an official record, and stating a wrong fee is an administrative liability issue rather than a style problem. Production evidence from a state government portal shows that nearly nine in ten interactions can be served from deterministic templates or explicit clarify-and-decline routes while generative answers pass a strict numeric check against the retrieved record—yet teams must also report clarification drop-off, tail latency, and wrong-record retrieval.

Published
Reading time
8 min read
References
3
Two empty public-service desks numbered 5 and 6 in a citizen service hall, each with a monitor, facing rows of visitor chairs
Photo: Artigas Pessio / Wikimedia CommonsCC BY-SA 4.0source

Why a Wrong Fee at a Public Service Desk Is a Legal Problem, Not a Style Problem

Consider a citizen asking a public-service portal what a permit costs, how long it is valid, or which office handles it. Most such questions are look-ups against an official record, and a wrong fee is a legal problem.

Our thesis: public service desks should invert “generate first” into “deterministic first”—serving look-ups from official templates, routing ambiguous or out-of-jurisdiction queries to clarify or decline paths, and letting generation only rephrase a retrieved record whose every money figure is checked against that record[1, 2]. A single accuracy score also hides real costs: clarification menus lose about half the citizens who see them, generative routes are slow on modest hardware, and number checks cannot catch a wrong record or a stale fee schedule[1].

Tripartite Routing, Numeric Verification, and Citizen Drop-Off

Cruz Degante (2026) reports a production deployment of retrieval-based answers on a state government’s citizen-services portal in Latin America, covering 1,143 procedures and a separately indexed directory of 924 offices[1]. Because data-protection law and fiscal limits rule out commercial clouds, it runs on local state servers (CPU, small open models of 3–4B parameters at temperature 0)[1]. According to the author, regulatory-improvement law treats discrepancies in fees, fines, or requirements as administrative liability for misinforming citizens[1]. 84.34% of the catalog (964 of 1,143) had no historical visits, and 12.63% of production queries asked for federal or municipal services outside state jurisdiction[1].

Each query takes a three-way route: answer a specific procedure, clarify via a menu of candidates, or decline as out of jurisdiction[1]. Across 380 organic traces over 8 weeks (15 Feb–15 Apr 2026) and 312 sessions at low concurrency (mean 0.28 queries per business hour, peaks of 2–3 simultaneous requests), 89.47% of traffic resolved at Level 0 without free generation: 68.95% direct deterministic answers (templates, cache, disambiguation) and 20.53% containment (12.63% decline + 7.89% clarify), while 10.53% (40/380) escalated to generative synthesis[1]. Direct deterministic answers had a 0.445 s median latency (global median 0.665 s) versus 20.150 s for the generative route; because CPU inference serializes when 2–3 requests overlap, global p95 reached 30.412 s and p99 reached 35.626 s[1].

Numeric defence uses three barriers: deterministic template assembly without a model at Level 0; extractive generation at temperature 0 at Level 1; and a post-generation verifier that extracts every money amount and fee-unit multiple from the answer, checks that it belongs to the set of numbers in the retrieved record, and replaces the answer with the official template if not[1]. Cache entries tie to the record’s hash with a 14-day expiry to cover reforms and annual fee-unit adjustments[1]. Across four double-blind human audits by two state public-sector analysts not involved in development, a census of all 40 generative answers found 0/40 invented amounts or figure-concept swaps, with an exact 95% upper bound ≤ 8.81% (zero observed does not prove zero rate)[1]. On a functional probe, the verifier caught 40/40 synthetic injected wrong numbers with 0/40 false positives on clean outputs[1].

On a 200-query stratified benchmark (130 in catalog, 70 out of catalog), strict top-1 accuracy was 86.50%, +10.00 percentage points over a binary reject cutoff (p = 0.00453; Holm-adjusted 0.01172; 5-fold CV 86.41% ± 7.50%)[1]. The binary cutoff resolved more in turn one (76.50% vs 51.50%) but wrongly rejected 29.23% (38/130) of valid catalog queries versus 3.08% for the three-way design[1]. After a clarification menu, however, 53.33% of citizens did not continue (14/30 continued, all converging), cutting conditional safe coverage from 93.00% to a drop-off-adjusted effective resolution of 70.87%[1]. Limits remain: the number check guarantees only that numbers appear in the retrieved record and cannot prevent fee swaps within multi-fee records, wrong adjacent-procedure retrieval (8.46% benchmark, 5.00% audit), or reforms after the last snapshot; portal-specific jurisdiction vocabulary and demographic-prefix rules were built by the same team (overfitting risk); implicit socioeconomic traits mid-sentence kept pairwise invariance in only 6/10 pairs; 4/20 queries for other state branches got a false specific answer; regex anonymization misses free-text names; audits were internal to the state; and the single author is also the system architect (disclosed; scripts and audit matrices published)[1].

Four cards: across 380 production traces over eight weeks on a state government citizen-services portal, 89.47% of traffic was served without free generation, 68.95% by direct templates and 20.53% by clarify or decline routes; all 40 generative answers had 0 invented amounts, with a 95% upper bound of at most 8.81%, and the verifier caught all 40 injected wrong amounts; on a 200-query benchmark a binary reject cutoff wrongly rejected 29.23% of valid queries versus 3.08% for three-way routing; 53.33% of citizens left after a clarification menu, turning 93.00% conditional coverage into 70.87% effective resolution (Cruz Degante, 2026).
In a design paper on deterministic-first execution control, Kim (2026) proposes a pre-inference layer that represents requests as task paths, tries deterministic routes first (FAQ lookup, policy/rule checks, schema/format validation, deterministic transformation), validates outcomes, logs telemetry (baseline calls, model calls, avoided calls, escalations, mismatches), and escalates to a model only when deterministic handling is insufficient or fails validation[2]. On a reproducible 100-task deterministic-heavy benchmark, 80 of 100 simulated model calls were avoided with zero mismatches in the deterministic subset; this 80/20 split is by workload design and does not establish production behaviour, real-provider outcomes, or cost and energy savings[2].

Moynihan, Herd, and Harvey (2015) define administrative burden as the learning costs (finding out about a service and how to access it), psychological costs (stigma, stress, loss of autonomy), and compliance costs (paperwork, documentation, time) citizens face in state interactions, shaped by design choices that affect take-up[3]. Seen this way, clarification menus and declines can themselves shift such costs onto citizens, so drop-off belongs next to accuracy[3].

Engineering Mapping on rlab.works: Official Records, Versioned Caches, and Human Gates

In our engineering view, teams should: (1) build the official record first (procedure, fee, validity, office, effective date) and answer look-ups by template; (2) use three outcomes—answer, clarify with a short menu, or decline with a pointer to the right authority—and measure drop-off after clarification; (3) let generation only rephrase the record, checking every number against that record and falling back to the template on mismatch; (4) tie cache entries to the record version and expire them on fee changes, routing notice and fee updates through human review and publication approval; (5) report tail latency, drop-off, and wrong-record rate next to accuracy; and (6) enforce desk and department access rules outside the prompt.

Comparison: generating first, the model writes answers to look-ups, unclear or out-of-scope questions are answered anyway or rejected, amounts in generated text are sent as written, and old cache entries keep serving after a fee change; looking up the record first, look-ups are answered from the official record template, unclear or out-of-scope questions are answered, clarified or declined with drop-off measured, every amount in generated text is checked against the record with a template fallback, and cache entries are tied to the record version with fee changes reviewed by staff before publication.
Across AI Gateway, Intelligence, and Commerce on rlab.works, three skill packs and three working components map the surrounding governance:
  • Source change review: In Intelligence, Watch and review changes (S32) runs Register and collect sources → Deduplicate and compare changes → Organize relevant signals → Review and archive (human gate), using Article deduplication and change alerts (persisting normalized URLs and content to detect new or updated items) to queue public-notice changes for staff review. Public adaptation: public post counts are not representative opinion; replace source-domain event models and retain original text and human judgment.
  • Multilingual guide sync: In Commerce, Publish in several languages (S38) runs Prepare content candidates → Translate and check versions → Review facts and wording (human gate) → Publish pages and messages → Complete discovery and sharing, syncing one service guide’s facts across languages and entry points so the owner checks procedure and effective date before publishing. Public adaptation: replace hotel translation fields, check official terminology, and keep human approval before publication.
  • Access and policy rollout: In AI Gateway, Set access rules (S14) runs Define access scope → Validate and review changes (human gate) → Apply access rules → Review request evidence (human gate) with Prompt registry, cache and semantic policies and Versioned gateway policy rollout to set what an inquiry tool may read and do per desk, testing allowed and denied requests before release. Public adaptation: connect organization identity and actual document permissions; prompt wording alone cannot enforce access.

All packs are proposed and not integrated, demonstrated with synthetic data. While the three components have working maturity, none of them is a deterministic-first router or a numeric verifier—those are requirements we draw from the papers. Nothing here claims compliance with any legal regime.

Three Checks Before Launching a Public-Service Answer Desk

  • Verify the routing split and numeric fallback: Look-ups resolve from templates; generated answers check every amount against the retrieved record and fall back on mismatch[1, 2].
  • Report drop-off, wrong-record rate, and tail latency next to accuracy: Track attrition after clarification menus, false rejections, adjacent-record errors, and p95/p99 latency[1].
  • Bind cache expiry and fee updates to human gates: Tie cache entries to the record hash[1]; in our engineering view, route fee changes through Review and archive and Review facts and wording, and enforce desk access via Validate and review changes outside the prompt.

References

  1. [1]

    Cruz Degante, A. (2026). Governed sovereign RAG for public administration: Tripartite epistemic routing, facet-guided clarification, and deterministic numeric verification in citizen services (arXiv:2610.36561). arxiv.org ↗

  2. [2]

    Kim, A. H. (2026). KORA: Deterministic-first execution control for AI workloads (arXiv:2610.35869). arxiv.org ↗

  3. [3]

    Moynihan, D., Herd, P., & Harvey, H. (2015). Administrative burden: Learning, psychological, and compliance costs in citizen-state interactions. *Journal of Public Administration Research and Theory*, 25(1), 43–69. doi.org/10.1093/jopart/muu009

Share this note

Generating poster…

  • X
  • WhatsApp

AI implementation diagnosis

About 3 minutes · 9 questions

Used only for this diagnosis · Replies are written by AI