# Two questions. Two clocks.

“What applied then?” and “What did we know then?” are different questions. Temri keeps both answers.

## Applied at: as_of

Valid time describes the world the memory refers to. A valid interval is [valid_from, valid_to): it includes the start and excludes the end. A null end is unbounded.

## Known at: known_at

Recorded time describes what the ledger knew. A recorded interval is [recorded_at, recorded_until), with the same exclusive-end rule. The server owns recorded time; ordinary clients cannot backdate it.

## An exact example

Boston applies from time 0 and is recorded at time 100. At time 200, a correction says New York applies from time 50. These numbers are illustrative UTC Unix seconds.

| as_of | known_at | Result | Why |
| --- | --- | --- | --- |
| 70 | 150 | Boston | The correction had not been recorded |
| 70 | 200 | New York | The correction is known and applies |
| 20 | 200 | Boston | The correction does not apply yet |

## Preserve precision and boundaries

API times are finite UTC Unix seconds as JSON numbers, including fractional seconds. Do not round imported Python float timestamps to integer milliseconds. A bounded correction preserves the valid-time suffix at its exclusive end. Re-embedding changes the search projection, not the fact’s revision or clocks.

## Corrections and invalidation

Correcting requires authority and the expected generation. It preserves unaffected valid-time intervals and invalidates transitive derivations. Derived memories initially stay inside one namespace. Historical invalidation is evaluated according to when it was recorded.

## Deletion applies to history too

Purged content is absent even from historical reads. A deletion fence prevents later search work or a restore from making that content readable again. Content-free receipts remain to track cleanup.

> Evidence and verification explain why a claim was accepted. Temporal precision alone cannot establish that a claim is true.

## Continue reading

- [Temri · Memory with a sense of time](https://temri.ai/): Shared temporal memory for products and agents. Keep source-backed facts in protected namespaces and distinguish what applied then from what was known then.
- [How Temri works · From evidence to memory](https://temri.ai/how-it-works): Follow a memory from its source to a candidate, verification, historical retrieval, correction and deletion receipt.
- [Developer documentation · Temri](https://temri.ai/docs): Connect to Temri through REST and MCP. Learn workspace permissions, evidence, temporal queries and bounded retrieval.
- [Create your first memory · Temri quickstart](https://temri.ai/docs/quickstart): Use an enrolled Temri workspace to create a namespace, record evidence, save a candidate and recall it with explicit time controls.
- [REST API · Temri developer docs](https://temri.ai/docs/api): Authenticate Temri REST requests, select authorized workspaces, use mutation idempotency and handle pending, denied and partial results.
- [Connect an agent · Temri MCP docs](https://temri.ai/docs/mcp): Connect to Temri’s authenticated MCP resource with narrowed scopes. Discover operations and verify your client before sharing memory.
- [Privacy, retention and deletion · Temri](https://temri.ai/privacy): What Temri stores, which services process it, how namespace access works and what a deletion receipt does and does not cover.
- [Pilot terms · Temri](https://temri.ai/terms): Terms for Temri’s admin-managed pilot, responsible use, source-backed claims, service limitations and account access.

[OpenAPI](https://temri.ai/openapi.json) · [Workspace](https://temri.ai/app)