FinUties Study · Calendar · Twenty-three row shapes behind one endpoint

Updated at 25 August 2026.

FinUties Study · Calendar · Twenty-three row shapes behind one endpoint

By FinUties · organization byline · The organization reports no position in any instrument named. Informational only — not investment advice, and no claim is made about domains outside the P0 surface.

Scope

P0 domain: calendar. The question in one sentence: should an integrator parse
/api/v1/calendar/events rows or filter them? This study measures schema heterogeneity,
enrichment coverage, and whether the documented filters discriminate. It does not forecast any
release, does not interpret any scheduled event, and does not treat any non-P0 domain as covered.

The reading it arrives at: the endpoint is a union of provider-native row shapes, so parsing
is the wrong instinct — but the filters work server-side, so filtering is the right one.

Question

This is answerable from P0 data because both halves are directly observable: row shapes are the
key sets of returned rows, and filter behaviour can be tested by comparing a real value against
a nonsense value on the same parameter. It would become unanswerable if the question shifted to
whether the schedule is correct, which requires checking each publisher's own calendar rather
than FinUties.

Evidence manifest

This study rests on 8 pulls from the calendar domain between 19:43 and 19:52 UTC on
2026-08-18. Every row below is re-runnable.

#	Pulled (UTC)	Domain	Endpoint	Query	Rows	Freshness	Replay
1	2026-08-18 19:48	calendar	/api/v1/calendar/events	limit=100, offset=0…900 (10 pages)	1,000	not recorded — probe resolved no table	REST GET /api/v1/calendar/events?limit=100&offset=0 · MCP {"domain":"calendar","resource":"events","limit":100}
2	2026-08-18 19:52	calendar	/api/v1/calendar/events	country=US, limit=100	100	as row 1	REST GET /api/v1/calendar/events?country=US&limit=100
3	2026-08-18 19:52	calendar	/api/v1/calendar/events	country=ZZZZ, limit=100	0	as row 1	REST GET /api/v1/calendar/events?country=ZZZZ&limit=100
4	2026-08-18 19:52	calendar	/api/v1/calendar/events	importance=high, limit=100	100	as row 1	REST GET /api/v1/calendar/events?importance=high&limit=100
5	2026-08-18 19:52	calendar	/api/v1/calendar/events	importance=notreal, limit=100	0	as row 1	REST GET /api/v1/calendar/events?importance=notreal&limit=100
6	2026-08-18 19:52	calendar	/api/v1/calendar/events via MCP query	limit=2	2 returned; total 401,348	as row 1	MCP {"domain":"calendar","resource":"events","limit":2}
7	2026-08-18 19:46	calendar	/api/v1/resources/calendar/events/query-options	none	1 contract document	not applicable	REST GET /api/v1/resources/calendar/events/query-options
8	2026-08-18 19:43	system	/api/v1/status/p0	none	8 domain rows	calendar red; no age measured — over budget by verdict	REST GET /api/v1/status/p0

Study study-calendar-schema-heterogeneity-2026-08 · manifest v1.

Sources in this study

• Economic and official release calendar — Provider: Eight named upstream publishers via
  FinUties, led by Statistics Austria (631 of 1,000 sampled rows), the ECB statistics calendar
  (67), the Swiss National Bank events feed (27), the Bank of Canada (21 across two feeds), the
  BEA release schedule (12), the Bank of England (6) and the Federal Reserve FOMC calendar (5);
  231 rows carry no source_url. Geography: Multi-country, publisher-dependent. Frequency:
  Continuous, with far-forward scheduling. What it measures: Scheduled official releases and
  central-bank events, retaining each publisher's native fields. FinUties path:
  /api/v1/calendar/events.
• Resource query contract — Provider: FinUties query layer. What it measures: Which
  filters, ranges and sorts the endpoint accepts. FinUties path:
  /api/v1/resources/calendar/events/query-options.
• P0 claim-surface status — Provider: FinUties freshness probe. What it measures: Calendar
  fill and freshness against the 12-hour budget. FinUties path: /api/v1/status/p0.

Findings

Finding 1 — One path returns 23 different row schemas (manifest row 1). Each upstream
publisher exposes its schedule differently and FinUties retains the native fields: Statistics
Austria as table cells (raw_cells, category, status_label), the ECB as raw_date plus a
details object, the Federal Reserve as a year and a date_range string such as
"October 26-27", the SNB as an RSS raw_title. There is no single field readable on every row
to answer "when is this event?".

Figure 1 — Distinct row shapes in 1,000 sampled rows (manifest row 1).
Metric: count of rows by key set, excluding the _finuties_ingest_meta block attached to every row; units = rows out of 1,000. 23 shapes in total; the eight largest are shown.

Row shape (keys present)	Rows	Share
category, raw_cells, source_url, status_label	463	46.3%
the above plus importance_enriched_at, metadata_enriched_at	168	16.8%
importance_enriched_at, metadata_enriched_at, raw_dtstart	109	10.9%
date, description, title, type, url	56	5.6%
details, raw_date, source_url plus enrichment stamps	39	3.9%
date, description, title, type, url plus enrichment stamps	38	3.8%
details, raw_date, source_url	28	2.8%
raw_dtstart only	25	2.5%
15 further shapes	74	7.4%

Finding 2 — Title parsing fails for 97.3% of rows (manifest row 1). Only 27 rows carry
raw_title at all. Where the field exists it is well formed — all 27 begin with an ISO date, and
they span 2026-10-22 to 2028-01-13, every one of them in the future. Parsing works exactly where
it is least needed.

Finding 3 — The filters discriminate (manifest rows 2–5). country=US returned a full page
and country=ZZZZ returned zero; importance=high returned a full page and importance=notreal
returned zero. The filters are applied server-side against real columns, not accepted and ignored.

Finding 4 — Those same columns are absent from the default projection (manifest rows 1 and 7).
country, currency, event_type, importance, source and status are accepted as equality
or IN filters, and scheduled_at / scheduled_date as ranges, yet none appear as keys in the
returned rows of Figure 1. Normalised columns exist in storage and are not projected into the list
response, so a client cannot verify locally what the server filtered on.

Figure 2 — Population and filter behaviour (manifest rows 1–5).
Metric: presence rate by field and returned row count by filter value, provider FinUties calendar surface, units = rows and percent of 1,000.

Property	Result in sample	Read
raw_title present	27 rows (2.7%)	Title parsing is not viable
ISO date prefix where raw_title exists	27 of 27 (100%)	Parsing works if the field exists
importance_enriched_at present	392 rows (39.2%)	Importance enrichment is partial
forecast_consensus present	3 rows (0.3%)	Consensus forecasts are pilot scale
country=US / country=ZZZZ	100 rows / 0 rows	Filter discriminates
importance=high / importance=notreal	100 rows / 0 rows	Filter discriminates

Finding 5 — Enrichment is partial and says so (manifest row 1). 39.2% of rows carry an
importance_enriched_at stamp and 0.3% carry a forecast_consensus. The timestamps are useful
precisely because they are explicit: a row without the stamp has not been through importance
enrichment, and a client can branch on that rather than guess.

Finding 6 — Calendar was the weakest P0 domain in this window (manifest row 8). The budget is
12 hours, the second tightest on the claim surface after equities and system. At 19:43:35 UTC the
probe reported calendar red, with fill_ok false, freshness_ok false, and no probed table
or age returned. A probe ten seconds earlier reported the same fields as unknown. The endpoint
itself answered every query in this study, so the failing check is the freshness probe's table
resolution, not the data path.

Limits and what the data does not say

• The sample is 0.25% of the corpus and default-ordered. 1,000 rows out of 401,348 (manifest
  row 6). The publisher mix in Sources reflects this window and would shift under a different
  range filter.
• Filter discrimination is demonstrated, not quantified. Manifest rows 2–5 show that real
  values return rows and nonsense values return none. They do not establish that the returned rows
  are correctly filtered, because the filtered columns are not projected (Finding 4).
• Nothing here validates any schedule. This study does not check a single date against the
  publisher's own calendar.
• The freshness reading is unstable and is recorded rather than resolved. Two probes seconds
  apart disagreed (Finding 6); nothing here should be read as a timeliness guarantee.
• 23 shapes is a floor, not a ceiling. A larger or differently ordered sample could surface
  shapes this window did not.

Try this query

The headline finding is Finding 4 — filter, do not parse. Reproduce the contrast:

GET /api/v1/calendar/events?limit=100&offset=0
GET /api/v1/calendar/events?country=US&scheduled_at_from=2026-08-01&scheduled_at_to=2026-09-30&limit=100

MCP query tool arguments for the filtered form:

{"domain": "calendar", "resource": "events", "limit": 100,
 "filters": {"country": "US"},
 "ranges": {"scheduled_at": {"from": "2026-08-01", "to": "2026-09-30"}}}

Confirm the accepted filter set before coding against it:

GET /api/v1/resources/calendar/events/query-options

Freshness callout. Calendar budget: 12 hours. Observed at 2026-08-18 19:43:35 UTC:
status red, fill and freshness checks failing, observed age not recorded — over budget by
verdict. Verify at your own read time before depending on calendar timeliness.

Method and confidence discipline

A "row shape" is the sorted tuple of top-level keys present in a row, excluding the
_finuties_ingest_meta block attached to every row. Filter discrimination was tested by holding
the parameter constant and varying only the value between a real and a nonsense entry, then
comparing returned row counts. Corpus total was read from the query layer in the same window as
the sample.

High confidence in Findings 1–5: shape counts and presence rates are exact counts on returned
rows, and Finding 3 rests on a direct experiment rather than an inference. Low confidence in
Finding 6, recorded as an observation about probe instability rather than a verdict on the data
path. Not established: the correctness of any scheduled date, or whether server-side filtering
returns the right rows as opposed to a discriminating subset.

What would overturn these findings. A pull in which scheduled_at and country appear as
keys in the default projection overturns Finding 4 and collapses most of the normalisation work
implied by Finding 1. A raw_title presence rate materially above 2.7% overturns Finding 2.

Replies with evidence

Reply with evidence (replies open when forking ships. Every reply cites its own query.)

No evidence replies yet. Re-run the query in this note — if your pull disagrees with ours,
the reply will appear here with the query it cites.

Every reply cites its own query: endpoint, parameters, and pull time. Replies without a
citation are not published.

FinUties data sources

• /api/v1/calendar/events
• /api/v1/resources/calendar/events/query-options
• /api/v1/status/p0
• MCP query tool, domain: calendar, resource: events