HERO Query Reliability: Overview

HERO Query Reliability protects staff reports from incomplete, misleading, or blank structured results.

For SQL-backed tables, the database result now determines the available columns. HERO may choose readable labels, but it cannot invent or rename the underlying keys. Before a result is saved or displayed, URBI confirms that every declared column exists in the actual rows.

If that contract cannot be satisfied, HERO does not show or export a table that looks successful. It returns an honest failure state and records the issue in Hero Health for internal review.

What changed

• Critical HERO report orchestration uses Opus.
• The first SQL generation attempt uses Sonnet; retries use Opus.
• Haiku is not used by current runtime work.
• Tables display 50 rows per page from a validated set of up to 1,000 loaded rows.
• CSV and Build Excel use the complete loaded validated set.
• A single supported record may include a deterministic link to its real URBI page.
• Repeated failures cluster in Hero Health so internal admins can prioritize common problems.

What this prevents

The original incident returned correct database rows but paired them with model-authored column names that did not exist. The table and exports therefore showed blank Unit, Floor, Name, and Email fields. That mismatch is now rejected mechanically at multiple boundaries.

Availability

The user-facing protections are part of the HERO query path. Hero Health is an internal platform-admin surface and is not visible to ordinary staff or residents.