Event-Time vs Ingestion-Time Reporting for AI Citation Dashboards

AI citation dashboards need a time-accounting contract before a daily rate can be trusted: assign the reporting day by observation time, store ingestion time separately, and label any late-arrival changes as versioned restatements. Raw answer observations should stay immutable. Aggregates can change only under a disclosed cutoff and version policy.

The practical rule is narrow: the answer belongs to the day it was observed, not the day the warehouse received it.

Event-time reporting keeps midnight from moving AI citation rates

A daily AI citation rate is a calendar aggregate over observed answer runs. If an answer is observed at 23:58 in the reporting timezone but ingested at 00:07 after a retry, the answer should still belong to the 23:58 reporting day. Otherwise, collection latency can move a valid answer across midnight and make two daily rates wrong at once.

Data systems already separate these clocks. OpenTelemetry's log data model distinguishes an event timestamp from an observed timestamp, including cases where externally created events are observed later by collection code (OpenTelemetry logs data model). BigQuery ingestion-time partitioning assigns rows to partitions based on when BigQuery ingests them, which is useful for storage operations but not the same thing as an application event timestamp (Google Cloud BigQuery partitioned tables).

AI citation dashboards need the same separation because answer collection has at least two clocks:

Clock	Field	Meaning	Reporting role
Observation time	observation_ts	When the answer run was completed or accepted for citation evaluation	Owns the reporting day
Ingestion time	ingestion_ts	When the row arrived in the analytical store or aggregate builder	Owns pipeline freshness and late-arrival tracking
Publication time	aggregate_published_ts	When the daily metric version was published	Owns version history
Reporting timezone	reporting_tz	The timezone used to convert observation_ts into a calendar date	Must be stated beside the rate

For a public dashboard, the label should be explicit: "Daily citation rate by observation_ts, reporting timezone America/Chicago, late arrivals accepted for 48 hours." Without that label, a reader cannot tell whether a day changed because AI source selection changed or because records arrived late.

A compact event-time ledger for late AI citation observations

The ledger below is illustrative. It is not a provider-defect claim and does not describe a known failure in a vendor system. It shows how one prompt, one domain, and one reporting timezone should be assigned when ingestion happens after midnight.

Assume the dashboard reports in America/Chicago, uses observation_ts for calendar assignment, and allows late arrivals for 48 hours after local midnight. The target domain is example.com.

observation_id	prompt_id	engine	observation_ts	ingestion_ts	reporting_tz	reporting_day	target cited?	Aggregate version effect
obs_001	geo_share_014	Perplexity	2026-09-15 09:14:22-05:00	2026-09-15 09:14:41-05:00	America/Chicago	2026-09-15	true	Included in first publish
obs_002	geo_share_014	ChatGPT Browse	2026-09-15 23:58:10-05:00	2026-09-16 00:07:39-05:00	America/Chicago	2026-09-15	false	Late-arrival restatement for Sept. 15
obs_003	geo_share_014	Gemini	2026-09-16 00:02:44-05:00	2026-09-16 00:03:11-05:00	America/Chicago	2026-09-16	true	Included in Sept. 16
obs_004	geo_share_014	Claude Web	2026-09-15 18:31:03-05:00	2026-09-18 02:10:00-05:00	America/Chicago	2026-09-15	true	Outside cutoff; excluded from headline and retained in exception ledger

Under event-time reporting, obs_002 belongs to September 15 because the answer was observed before midnight in the declared reporting timezone. Ingestion after midnight does not make it a September 16 answer. obs_003 belongs to September 16 because both observation and reporting-day conversion place it after midnight. obs_004 is still an immutable raw observation, but the headline aggregate can exclude it if the report's late-arrival cutoff had already closed.

That distinction lets a dashboard publish a first daily rate quickly without pretending the raw ledger is final forever.

Late-arrival cutoffs should restate aggregates, not rewrite raw observations

A late-arrival policy has two jobs: keep operational reports timely and keep historical evidence reproducible. It should never mutate the raw answer record to make an old aggregate look as if it was always complete.

Apache Beam's model is a useful analogy because it treats event time, watermarks, windows, and allowed lateness as explicit parts of streaming computation; late data can produce later panes after an event-time window first emits (Apache Beam programming guide). AI citation reporting does not have to implement Beam, but it should adopt the accounting habit: define the event-time window, define allowed lateness, and label the output that changed because late data arrived.

A practical AI citation dashboard can use this contract:

Policy field	Recommended starting value	Why it exists
reporting_tz	America/Chicago or the customer's contractual timezone	Prevents UTC/local date ambiguity
daily_window	[00:00:00, 23:59:59.999] in reporting_tz by observation_ts	Defines which day owns an answer
late_arrival_cutoff	48 hours after local day end	Allows delayed retries without endless headline churn
raw_observation_policy	Append-only, never edited in place	Preserves auditability
aggregate_version_policy	v1 initial, v2 restated, v3 final	Explains why a published rate changed
closed_day_policy	Headline frozen after cutoff; exceptions remain queryable	Stops old charts from silently shifting

The transferable lesson from mature analytics systems is not that AI citation dashboards should copy another product's timing. It is that report consumers deserve to know when data is fresh, when it is late, and when a daily aggregate is still subject to change.

A versioned restatement log makes changed daily rates defensible

A previously published daily rate can change if the methodology says it can. The problem is not restatement. The problem is an unlabeled restatement that looks like silent history editing.

For the illustrative ledger above, suppose the first September 15 aggregate was published at 00:05 on September 16 before obs_002 arrived. The version history could read:

aggregate_id	reporting_day	version	published_ts	eligible observations	cited observations	citation rate	Status	Reason
acr_2026_09_15	2026-09-15	v1	2026-09-16 00:05-05:00	1	1	100.00%	initial	First publish after day close
acr_2026_09_15	2026-09-15	v2	2026-09-16 00:15-05:00	2	1	50.00%	restated	obs_002 arrived inside 48-hour cutoff
acr_2026_09_15	2026-09-15	v3	2026-09-18 00:00-05:00	2	1	50.00%	final	Late-arrival cutoff closed

The raw observation ledger did not change. The aggregate changed because a valid September 15 answer arrived inside the declared cutoff. obs_004 remains stored, but if it arrived after the cutoff, the public headline rate stays final and the record appears in an exception report instead of rewriting the chart.

This is similar to financial and operational reporting practice: a restated number is not inherently untrustworthy when the restatement reason and version are visible. It becomes untrustworthy when the dashboard gives no way to distinguish the original publication from the revised aggregate.

Observation time and ingestion time are separate from citation-rate denominator rules

This article covers calendar assignment and restatement policy. It does not replace the existing Paralax denominator rules.

The base Paralax definition says AI citation rate measures how often an answer engine cites a source when a relevant question is asked. The prompt-cohort bridge explains that a rate cannot trend cleanly when the monitored prompt basket changes without a retained-cohort bridge (prompt cohort migration). The retry-accounting note keeps collector attempts and repeated URLs out of the numerator and denominator (citation retry accounting). The zero-citation ledger separates successful uncited answers from missing measurements (zero-citation measurement states).

Event-time reporting is the next boundary. It assumes the answer is already eligible under those rules, then asks which calendar day owns it and how the report should behave if the eligible row arrives late.

A complete daily metric therefore needs all four controls:

Control	Question answered	Prevents
Prompt cohort version	Did the monitored question set change?	False trend from denominator migration
Retry and URL accounting	Is the row an answer, an attempt, or a repeated citation link?	Attempts or duplicate URLs becoming metric units
Missingness ledger	Is the answer valid, uncited, failed, or not scheduled?	Missing collection being counted as zero citation
Event-time contract	Which reporting day owns the valid answer, and can the day restate?	Midnight ingestion drift and silent historical changes

The Machine Relations Index shows why source windows need clock discipline

The Machine Relations Index is useful here as a public example of why reporting windows and observation counts must be named. The September 16 release evidence for the AI Visibility and GEO category counted YouTube citations in 179 of 698 observed category runs, or 25.64%, across a May 10-September 16 source window and six engines. Those are observed-run rates inside a declared source window, not ingestion-day rates and not exclusive market shares.

The public Machine Relations Index also uses observation floors before publishing source-segment rates. That method matters because a source-domain percentage is only interpretable when the reader can see what was observed, which dates were in scope, and which aggregation unit produced the denominator.

An AI citation dashboard should make the same clock lineage visible for every daily rate:

1. Convert observation_ts into reporting_day using the declared reporting_tz.
2. Store ingestion_ts as pipeline evidence, not calendar ownership.
3. Compute the denominator only from eligible valid answer observations.
4. Publish aggregate_version and aggregate_status with every daily rate.
5. Retain late records outside the cutoff in an exception ledger rather than deleting them or silently changing final charts.

NIST describes metrological traceability as connecting a measurement result to the documentation chain that produced it (NIST metrological traceability). AI citation dashboards are not laboratory systems, but the reporting claim still needs a traceable chain from the published daily percentage back to the raw answer observations, timestamps, timezone, cutoff, and aggregate version.

A minimal implementation schema for event-time AI citation reporting

A compact schema is enough for most dashboards.

Field	Required?	Example	Notes
observation_id	Yes	obs_002	Immutable row identity
answer_id	Yes	ans_8f91	Links to answer evidence and citation extraction
prompt_id	Yes	geo_share_014	Must connect to the active prompt cohort version
engine	Yes	chatgpt_browse	Engine/model label used by the report
observation_ts	Yes	2026-09-15T23:58:10-05:00	Calendar owner
ingestion_ts	Yes	2026-09-16T00:07:39-05:00	Arrival and freshness evidence
reporting_tz	Yes	America/Chicago	Converts timestamp to day
reporting_day	Yes	2026-09-15	Derived from observation time, not ingestion time
eligible_for_rate	Yes	true	Comes from denominator rules, not time policy alone
target_cited	Yes when eligible	false	Numerator input
arrival_class	Yes	on_time, late_inside_cutoff, late_after_cutoff	Drives restatement behavior
aggregate_version	Yes on published output	v2	Makes rate changes visible

That schema preserves raw facts and gives report users the information they need to reproduce a daily number.

FAQ

Should AI citation dashboards report by observation time or ingestion time?

They should report daily AI citation rates by observation time in a declared reporting timezone. Ingestion time should remain visible as pipeline evidence, but it should not decide which calendar day owns a valid answer observation.

Can a previously published daily AI citation rate change?

Yes, if the dashboard publishes a late-arrival cutoff and versioned restatement policy. A late row that belongs to the prior reporting day can update an initial aggregate inside the cutoff. After the cutoff, the headline should freeze and later rows should move to an exception ledger.

What timezone should an AI citation dashboard use?

Use one explicit reporting timezone per report, such as America/Chicago, UTC, or the customer's contractual timezone. The key requirement is not the specific timezone; it is that every daily rate states the timezone used to convert observation_ts into reporting_day.

Does ingestion after midnight mean the answer belongs to the next day?

No. If the answer was observed before midnight in the reporting timezone, it belongs to that observation day. Ingestion after midnight should be labeled as a late arrival, not treated as a new-day answer.

Does this imply an AI provider or citation vendor is defective?

No. Late arrivals can come from retries, warehouse schedules, batching, network latency, parser queues, or ordinary reporting delays. This is a transparent accounting method for AI citation dashboards, not a defect allegation against any provider.

Where does event-time reporting fit inside Machine Relations measurement?

Event-time reporting sits in the measurement layer of Machine Relations. Share of citation is useful only when the denominator, reporting window, timezone, and aggregate version are reproducible. Teams can benchmark the broader visibility gap with the AuthorityTech AI visibility audit.