How it works

From definition to number

1. Definitions. metrics/leads.yml defines every number once, in MetricFlow's style: a measure, a time basis (which date puts a lead into a month), structured filters, an owner and a certified flag. The app checks it when it starts.
2. Compiler. Turns "number × month × filter" into parameterised SQL. Names come only from the checked definitions; every value is a parameter. "How it's calculated" shows the same query with the values written in.
3. Postgres. Runs the SQL over read-only connections.
4. Charts. The server picks one of 5 chart types (kpi_sparkline, ranked_bar, trend_line, bridge_waterfall, table), checks the spec and builds the ECharts option. The browser only draws it; nobody writes chart JSON by hand.

The referee

For two counts and a month, one SQL query decides for every lead whether each side counts it, and if only one does, why: the other side's date is missing or in another month, or its filter leaves the lead out. The steps go from A, minus each reason, plus each reason, to B. The app checks on every request that the steps add up and that both ends match the numbers on the overview; if not, it shows an error instead.

SQL computes everything. The step labels are written from the two definitions by fixed templates; no AI model is involved. A model could later add a short written summary, but it would only see the definitions and these totals, never rows.

Speed

Pages take 30 ms on the server for a typical request (p50) and 53 ms for the slowest 5 % (p95), over the last 16 requests.

Built with

TypeScript on Node 22, Hono, node-postgres, yaml and ECharts 6. Pages are rendered on the server; a little browser script draws the charts and adds the interactions. Page changes use View Transitions (off with reduced motion), and trend lines are never animated.

Earlier SQL-only prototype: v0