Not the Model Name, the Serving Route: The Evaluation Record MBG Digital Tools Need

MBG Watch · 2026-09-10

The premise

The public question around digital tools in MBG should not begin with a vendor name or a model name. It should begin with the route in which the tool serves.

That sounds narrow. It is the useful narrowness. A portal that tells a parent what menu was served today is not the same public-risk object as a tool that recommends a kitchen suspension, closes a complaint, validates a beneficiary list, or changes meal dispatch after a forecast. The same underlying model, dashboard, scoring system, or rules engine can be low-risk in one route and high-risk in another.

BGN’s own public materials already show MBG moving into digital operating records. On 13 August 2026, BGN said Radar MBG would let the public see participating schools, daily menus, nutritional content, food photos, and the SPPG that produced the meal; it also said about 85 percent of SPPG had filled digital reports, with a push toward more consistent digital production reporting. On 27 July, BGN described a broader transparency system for parents, using student identity to access real-time program information, plus a public dashboard on operating SPPG, served schools, and national implementation. In February, BGN said SAGI 127 would operate 24 hours a day for complaints, input, and clarification, with reports verified and followed up through an applicable mechanism. In August, it opened a dedicated teacher channel by email for complaints, findings, and school-level input.

None of that proves BGN is using artificial intelligence in these routes. It does prove something quieter and more immediate: MBG now has enough digital routes that evaluation must be attached to the route, not to the software label.

What the evidence supports

The evidence supports four claims.

First, MBG has public-facing information routes. Radar MBG is described as a portal for menu visibility, nutritional content, meal photos, schools served, and the SPPG responsible for production. BGN frames this not only as publicity, but as shared oversight.

Second, MBG has complaint and witness routes. SAGI 127 is a national 24-hour complaint channel for students, parents, schools, partners, and the public. The teacher channel adds a school-based witness route: teachers can send complaints, findings, and other relevant information from the place where children actually receive meals.

Third, MBG has validation routes. Local government reports from January 2026 describe BGN-led verification and validation of beneficiary data and SPPG location data. Bondowoso’s report says standardized forms cover recipient identity, initial nutrition status as a baseline, and logistics/distribution points. Banjarnegara’s report quotes BGN’s emphasis that beneficiary data must be accurate and that SPPG location data should be verified against field conditions.

Fourth, MBG has operating-control routes. BGN press materials describe 47 SPPG suspended during a February 2026 evaluation, and then 49 SPPG under temporary suspension, with operation resumption only after standards were met. Even if those actions are human-led, the route itself is a gate: the difference between meal service continuing tomorrow and stopping tomorrow.

AI evaluation practice is moving in the same direction. NIST’s AI Risk Management Framework says AI risk management should be incorporated into the design, development, use, and evaluation of AI products, services, and systems. Openlayer’s 2026 audit guide usefully separates the evidence an audit trail must preserve: what was running, what it did, where humans intervened, what tests were run, what thresholds applied, and who signed off. Dataiku’s enterprise-agent evaluation guide makes the production point plainly: trust depends on governance, audit trails, RBAC, approval gates for high-stakes actions, and monitoring once tools meet real data and real organizational complexity.

For MBG, the lesson is not “use AI” or “ban AI.” The lesson is: evaluate the deployed route.

The route map MBG should publish

A public evaluation record could separate MBG digital tools into at least seven routes.

1. Parent and public information route. This includes Radar MBG menu visibility, nutrition labels, food photos, school/SPPG matching, and operating dashboards. The main failure modes are stale information, wrong school-to-kitchen mapping, misleading nutrition display, missing photos, and a false sense that visibility equals safety. The remedy is timestamped provenance: when the record was created, by whom, from what SPPG, and whether the meal was actually served.

2. Complaint intake route. This includes SAGI 127, digital complaint forms, call-center records, and teacher email. The main failure modes are lost reports, duplicate reports merged too early, retaliation risk, hoax filtering that suppresses true complaints, and complaint closure without field verification. The public record should show aggregate counts, category, district, response stage, and closure reason. It should not expose complainant identity.

3. Complaint triage route. If software ranks complaints by urgency, credibility, duplication, or likely food-safety relevance, that route needs stronger evaluation than intake. A false negative can leave a dangerous kitchen operating. A false positive can wrongly damage a kitchen and interrupt meals. The route record should disclose triage purpose, inputs used, human owner, escalation threshold, false-negative testing, and appeal path.

4. Beneficiary validation route. Recipient identity, NIK matching, school lists, pregnancy or breastfeeding status, child age, and baseline nutrition status are sensitive. This route should not be evaluated only for deduplication accuracy. It should be tested for exclusion error: which children, pregnant women, breastfeeding mothers, or households are most likely to be wrongly left out when records are missing, stale, or inconsistent.

5. Kitchen evaluation and suspension route. This is a gate route. Whether the input is an inspection checklist, SLHS status, incident report, complaint pattern, kitchen photo, lab result, or score, the route can stop meal production. The record should distinguish recommendation from decision, list required evidence, preserve override history, and require post-error correction when a kitchen was wrongly suspended or wrongly allowed to continue.

6. Forecast and dispatch route. MBG Watch has already argued in “When the Forecast Becomes a Meal Decision” that weather or risk forecasts need provenance when they change meal timing, routing, or kitchen operations. Here the serving-route standard adds a simple rule: the same forecast can be informational when it appears on a dashboard, advisory when it recommends a delivery change, and high-impact when it automatically changes dispatch.

7. Local or edge guidance route. “When Guidance Runs Locally” covered the promise and limits of offline support. The route question is again decisive. A local tool that reminds a worker of handwashing steps is one risk class. A local tool that says a batch is safe, a complaint is not credible, or a route can proceed after a cold-chain break is another.

This route map also links earlier MBG Watch work without repeating it. “When the Validator Can Act” asked who authorizes a validator to act. “When the Score Becomes a Gate” asked what reliability tests are needed before scores change operations. “When the Log Is the Evidence” asked whether the audit trail itself can be trusted. “The Community Witness Layer” asked how public records can invite oversight without turning families into inspectors. The serving-route standard is the layer above those: it decides which record each tool owes before it touches children, kitchens, money, or public trust.

What the public evaluation record should contain

For each route, BGN should be able to publish a plain record without exposing private data. The record should answer:

• Purpose: what decision or information need the route serves.
• Route status: informational, advisory, gate, or automatic action.
• Inputs: what categories of data enter the route.
• Exclusions: which protected data are not used.
• Output: what the tool produces and who can see it.
• Human owner: the named role accountable for action and correction.
• Test population: where the route was tested, including remote, low-connectivity, small-school, high-volume, and incident-heavy settings.
• Failure modes: false reassurance, false alarm, exclusion error, delayed response, duplicate suppression, stale records, and misuse by unauthorized users.
• Reliability threshold: what must be true before the route can recommend action or become a gate.
• Audit trail: timestamp, source, version, input category, output, human intervention, override, and sign-off.
• Reversal path: how a parent, teacher, kitchen, school, district, or worker can correct a wrong record.
• Post-error correction: how children, kitchens, workers, and complainants are made whole after a route fails.

The word “public” matters, but it has a boundary. MBG should not publish child identity, NIK, health status, pregnancy or breastfeeding status, household location, complainant identity, worker health, exact private addresses, or raw complaint text that can identify a person. Public accountability can live at the route, district, SPPG, category, timestamp, and outcome level. Private vulnerability should stay private.

What the evidence does not support

The record does not support saying BGN is using a named AI model in Radar MBG, SAGI 127, beneficiary validation, kitchen grading, or complaint triage. It also does not support treating every digital record as an AI system. Many important controls are ordinary databases, dashboards, forms, checklists, and workflow systems.

That distinction is protective. If critics call every digital route “AI,” BGN can dismiss the critique as imprecise. If BGN says “we are not using AI” while route decisions still depend on scoring, ranking, matching, filtering, or automation, the public can be reassured about the wrong thing. The better question is not whether a model is glamorous enough to count as AI. It is whether the route can affect meals, safety, remedy, payment, suspension, public alert, or exclusion from service.

The least-harm path

The least-harm path is a route register before an automation fight.

BGN could publish a simple MBG Digital Route Register with three columns the public can understand: route, consequence, and evaluation record. Radar MBG menu display may need freshness and provenance checks. Complaint triage needs false-negative tests and human escalation. Beneficiary validation needs exclusion-error review and correction paths. Kitchen suspension support needs evidence thresholds and appeal. Forecast-triggered dispatch needs source provenance and route-change logging. Local guidance needs offline version control and a boundary around what it may never decide alone.

This approach is proportional. It does not demand that BGN reveal sensitive datasets or freeze useful digital tools. It also does not allow a national child-feeding program to hide behind model names, procurement labels, or “digital transformation” language. The route is where harm or benefit reaches the child.

What I am uncertain about

I am uncertain how much of MBG’s current digital stack uses automation beyond ordinary dashboards, forms, and reporting workflows. The public record reviewed here shows digital touchpoints; it does not show a named AI deployment.

I am also uncertain which routes already change operations in practice. A portal can begin as information and slowly become a gate if officials, schools, or kitchens start treating its score or status as decisive.

That is why route-specific evaluation should come early. It is easier to publish the boundary while a tool is still a record than after the record has quietly become the decision.