Build evidence timelines with separate effective and observed timestamps

An announcement can describe an event that happened yesterday and be collected today. Putting both timestamps into one generic date column hides a useful distinction. A chronology should preserve when the submitted record says an event took effect and when someone observed that record. Keeping those clocks explicit makes a review packet easier to inspect, especially when records arrive late or contain incomplete timing.

I maintain the us-brand-evidence-chronology-builder Actor. This walkthrough describes its published build 0.3.1, inspected on 16 October 2026. The example below is synthetic and reviewed against that contract; it was not executed for this article. AI-assisted drafting was followed by a separate factual and editorial review.

The Chronology Builder takes a fixed asOf and a bounded collection of evidence rows. It uses those supplied dates; it does not fetch the source URL or consult the current clock. The published build in this walkthrough accepts input schema 1.0. Do not change that field to 1.1 just because another Actor in the same family supports a newer envelope. This invented example includes the complete six-field row.

{
  "schemaVersion": "1.0",
  "asOf": "2026-10-01T09:00:00Z",
  "rows": [
    {
      "evidenceId": "ev-1",
      "eventType": "offer",
      "effectiveAt": "2026-10-01T07:00:00Z",
      "observedAt": "2026-10-01T08:00:00Z",
      "sourceUrl": "https://example.com/e1",
      "fact": "Synthetic offer observation."
    }
  ]
}

Here the effective time is 07:00, observation is 08:00, and the review cutoff is 09:00 UTC. Those values describe the example packet, not a verified real event. Every row needs its effectiveAt key, although its value may be null. Null means the input does not provide an effective timestamp; it does not authorize replacing that timestamp with observation time.

The chronology sorts non-null effective times first in ascending order, then observation time, then evidence ID. Rows with null effective time come last. Same-time groups use both effective and observation timestamps, so two records sharing just one date do not necessarily form the same group. This ordering is deterministic and useful for review, but it establishes no causal relationship between adjacent events.

Inspect timestampWarnings, futureDatedEvidenceIds, and partial before presenting the ordered list as a complete narrative. Timestamp anomalies can remain visible as warnings in a delivered report. A structurally delivered packet can therefore still need human follow-up. The Actor accepts 1–30 rows with unique evidence IDs, a 64 KiB canonical input limit, and a report no larger than 32,767 UTF-8 bytes. It does not solve an oversized chronology by clipping rows.

The report carries input, chronology, and report digests. These bind different representations. Input rows are canonicalized by evidence ID, while the chronology follows its date ordering. Archive the schema version with those digests rather than treating any SHA-256 string as an interchangeable assertion of provenance.

A practical handoff can include the ordered chronology, a separate unresolved-timing list, and links back to the supplied evidence IDs. Ask the reviewer to resolve missing effective dates against primary material and to keep the original observation dates intact. If a date is corrected, submit a new explicit packet and retain the earlier report; the Actor does not maintain your investigation history for you.

The output's confidence fields describe the bounded validation, ordering, and digest computation. They do not measure whether a statement is true or whether a cited page is authoritative. This distinction is particularly useful when the final audience is a lawyer, analyst, or operations team: an orderly timeline can support their review, while legal conclusions, factual acceptance, and source freshness still require their own evidence.

On the observed FREE pricing tier, one result-found event costs $0.01 for the complete useful report or plan, rather than each input row. FREE is the tier name, not a promise of free execution. Automatic Actor-start pricing is also present at $0.005 per GB, with a minimum of one event. Check the Actor page and your account tier before running; this is not a fixed total invoice, and a failed or repeated run may still incur applicable charges.

To try this deliberately, open the Actor page, select build 0.3.1, and submit the JSON as input. Set an explicit spending ceiling appropriate to your account; for example, $0.05 is a ceiling, not a quoted run price or a guarantee of a delivered report. Save the returned run ID and verify its immutable build ID. A local timeout does not cancel the remote run: inspect that same run before considering another attempt. On success, this build writes the report to both the Dataset and OUTPUT; OUTPUT is not a separate delivery receipt. A terminal failure can instead write a smaller failure record. Inspect the run status and the actual stored value; structural output is not independent source verification.