One timeline across two saved captures

Investigations rarely fit in one lookup. You capture a wallet today and a transaction it sent tomorrow, or you capture the same transaction twice a day apart. Then you want to read both together without losing track of which capture said what.

There are also two different clocks in play. One is when something happened on the blockchain. The other is when Forensia collected the record of it. A transaction from June that you captured in October has both dates, and mixing them up is an easy way to write a wrong chronology.

A saved investigation that holds two results now offers one timeline across both. It orders the recorded transactions by block within each network, lists each capture’s view of a transaction as a separate observation, and labels the two clocks differently. It is limited to two captures, and it only reads what those captures already contain.

#Plain languageTwo witness statements in one folder

Imagine two witness statements about the same week. You can lay the events from both on one calendar. A careful clerk still writes, next to each event, which statement it came from and the date that statement was taken. If both witnesses mention the same event, that is two mentions of one event, not two events, and not proof that either witness is right.

The saved timeline follows that practice. Each entry is one transaction. Under it sits one line per saved result that recorded it: "Result 1" and, if applicable, "Result 2", each with its own capture time and its own counts. The counts are never added together.

The time shown next to the block number is marked "reported": it is the transaction time taken from the records. The time on each observation is marked "Captured": it is when the source was retrieved.

#How it worksBuilding and opening the combined timeline

1. Run a lookup and choose Save result in the left rail.
2. Run a second lookup. Open Saved, choose Details on the investigation, and choose "Add current result". An investigation holds up to two results, and an identical capture cannot be added twice.
3. In Details, open "Timeline across saved results".
4. Read each network section separately. Entries run from the oldest known block; unknown or conflicting positions come last. The first eight transactions per network are shown, with "Show all saved transactions" for the remainder.
5. Under an entry, choose "Read result 1 record" or "Read result 2 record" to open the exact Activity or Source record inside that original capture. "Read result 1 block source" appears when that capture holds the block-position record.
6. Choose "Return to saved timeline" to come back with the timeline still open.

An investigation with a single saved result can open the timeline as well. There it is titled "Saved timeline & review links" and shows that result’s entries. The record-by-record comparison between captures appears only when the investigation holds two results. In both cases the timeline includes Your review links, which lists your saved notes beside the activity records they cite.

The same timeline is written into the Markdown report prepared from the saved investigation, with capture IDs, capture times and snapshot digests for every observation. In the report, recorded times are in UTC.

#Technical detailHow two captures become one ordered view

Inputs and identity

A saved investigation stores each result as a capture with an ID, a SHA-256 snapshot digest and the full original result. The capture time is the retrievedAt field on the result’s source block. The limit of two captures is a constant in the notebook code, and adding a capture whose snapshot digest already exists in the investigation is refused.

For each capture, the timeline first runs the same single-result derivation described in the activity timeline post: rows and permission events grouped by transaction hash, with a block, a time and a heading per group. The combined view then merges those groups without discarding any of them.

Network lanes

A capture is assigned to a network only when its chain key, chain ID, chain family and network ID all match one known public network. Each network is a lane. A capture whose network cannot be resolved gets its own lane, named as unresolved with its result number, so it is not merged with anything. Lanes are listed in a fixed order by identifier. There is no implied time or causal order between lanes, and equal block heights on different networks are unrelated.

Observations

{
  captureId, resultNumber, capturedAt, snapshotDigest,
  title,               // heading derived for this capture only
  item,                // this capture’s own block, time, rows and sources
  target?: { captureId, kind: "activity" | "source", recordId }
}

Within a lane, entries are keyed by transaction hash. Each capture that recorded the transaction appends an observation. The link target is the first non-internal activity row, or the first available source record when the capture has only permission events for that transaction.

When the combined entry gets a block, an index and a time

Block hashes get extra scrutiny. When a capture is a lookup of that exact transaction, its subject block number and block hash are an inclusion claim. Two such claims with different hashes are a conflict. The check also runs across different transactions in the lane: if any two transaction captures name the same block height with different block hashes, every entry observed at that height loses its combined position and time. An address capture’s subject block is never used this way, because it is the height of the lookup, not of the activity.

Timestamps are compared across transactions too. Different valid instants reported for the same known block withdraw the combined time for every entry at that block. A missing time is not treated as a contradiction. Where a capture is a lookup of that exact transaction and its execution context passed its own checks, the block time recorded in that context is included in the same comparison. It can expose a disagreement, including one between the two captures, but it is never used to fill in a missing time.

An observation that lacks a transaction index does not borrow one from the other capture. This keeps an older capture, taken before position context was recorded, from being silently upgraded.

Ordering

Lane entries are sorted by block number. Within one block, the transaction index decides only when every entry at that block has a unique index from one block hash. If not, each entry reads "Other transactions share this block. Their order is not established here." and the on-screen order falls back to the transaction hash, which is a display rule and not chronology. Unknown and conflicting positions sort last.

This path was checked with a real pair. Two Ethereum transactions from block 23,176,991, at index 90 and index 89, were captured separately and saved in reverse order. The combined timeline and the Markdown report placed index 89 first, and each observation still pointed at its own capture with the original time and digest.

The two clocks in practice

In a reviewed example, a transaction with a June event date and a transaction with an October event date were saved together. Both had been captured on 5 October, at different times. The timeline kept the June and October reported dates on the entries and the two 5 October capture times on the observations.

#LimitsWhat a combined timeline does not add

• It fetches nothing. History missing from both captures stays missing, and an empty timeline does not establish inactivity.
• Two observations of one transaction are not independent corroboration. Both may come from the same provider.
• Grouping two results in one investigation does not show that their subjects are connected.
• Block order is not causation, and the timeline does not join funds across networks.
• It does not reconstruct call-by-call execution or place events inside a transaction on a clock.
• A capture time records when Forensia collected a response. It says nothing about when the event happened.
• Only two captures fit in one saved investigation.
• Saved investigations live in this browser, unencrypted and not synced. A backup file carries metadata, and matching digests do not prove who produced it.