Bi-Temporal Indexing

EvidentSource indexes every event along two time dimensions:

• Transaction time — when the event was recorded in the system.
• Effective time — when the event took effect in business terms.

They are different things. An interest accrual posted today might be effective as of last week. A correction recorded this morning might be effective as of a date three months ago. A fraud reversal recorded now might be effective as of the moment the fraudulent transaction happened.

Standard databases only index transaction time. EvidentSource indexes both, natively, as first-class queryable dimensions.

The questions this answers

• “What was the account balance at 3:47 PM yesterday?” — read the state view as of a specific transaction time.
• “What did we think the account balance was at 3:47 PM yesterday, as of this morning?” — read the state view as of a specific (effective time, transaction time) pair.
• “When did we first discover this error?” — query by transaction time of corrective events.
• “Show me the ledger as it stood before the reversal.” — read as of the transaction time just before the reversal event.

For regulated systems and AI-audit workflows, these aren’t optional — they’re the actual questions. Bi-temporal indexing is how you answer them without staging tables and manual forensics.

Transaction time vs. effective time

	Transaction time	Effective time
What	When the event was recorded	When it took effect in the business
Who sets it	EvidentSource, monotonically	The decide function, per event
Can it be in the past?	No	Yes (backdated events)
Can it be in the future?	No	Yes (scheduled/pending)
Answers	”When did we know?"	"When did it happen?”

How to query

See REST API and gRPC API for the query surface. The short version: every read of an event stream or state view takes optional as_of_transaction_time and as_of_effective_time parameters.