Naive approach to temporality

[rivettp]

This issue is based on what's documented here https://github.com/danielcamposramos/Knowledge3D/blob/main/docs/openai_temporal_agents_cookbook.md.
Specific problems:

• just because a fact is ingested on a certain date does not mean it's claimed to be true as of that date. Often facts have more specific temporal information provided with them. For example the GLEIF registry of legal entities (at gleif.org) requires only annual re-registration - and facts in it cannot be assumed to remain valid much beyond the renewal date. And it's important to be able to capture historical information that one knows is no longer true.
• often it's more useful to have both a (known) start and end date as opposed to time stamps.
• events in particular are often useful to track, and often mark the start or end of a fact being true e.g. someone being appointed, an acquisition, someone dying.
• it is also useful, for auditing purposes, to know when a fact was ingested (as opposed to when it was true) (also called bi-temporality).
• it's not always the case that more recent claims should take precedence and cause older facts to be deleted. For example facts from legally mandated and audited sources such as SEC reports are more likely accurate than more recent hearsay from a social media site.

[danielcamposramos]

Hi Pete,

Great set of requirements—thanks for documenting them so clearly. Here’s how we’re thinking about each of your points for the K3D core and extensions:

Claimed‑vs‑effective dates
We agree that ingestion time is not a proxy for truth. The schema will separate effectiveStart, effectiveEnd (when the fact is known to be true) from assertedAt (when it was observed/ingested), enabling bi‑temporal queries.

Explicit intervals
The node metadata will allow both start and end timestamps, stored as ISO‑8601 or a generalized interval object. An omitted effectiveEnd means “still believed true.”

Events as first‑class nodes
We’re considering an event facet where appointment, acquisition, or death events are modeled as nodes that can trigger or terminate facts via links (e.g., fact.validFrom = appointment.id).

Source trust and precedence
Instead of deleting older facts, nodes keep a source facet with provenance (e.g., SEC filing vs. social post) and optional confidence weights. Consumers decide precedence.

Auditing / bi‑temporal provenance
Every fact carries both assertedAt and observedIn (dataset/document URL). A future extension could capture retraction or supersession events.

If you have existing schemas or best practices (GLEIF, SEC, etc.) that map well to this approach, we’d love to see examples. Happy to schedule a working session or include you in the next spec call—your experience with Graph RAG and legal entity registries would be invaluable.

Thanks again for pushing on temporal rigor!

—Daniel

[danielcamposramos]

We've just addressed this issue in the last commit. We are now using version control + alpha channel to represent objects that are not up-to-date (they'll still be there, but transparent)