Collections and temporal

Regulated corpora rarely stay still: a MiFID II filing gets superseded by MiFID III, a price list updates weekly, a policy takes effect on a future date. Knowledge Graph treats these as first-class concerns rather than something you work around with folder naming conventions.

Three kinds of time

Time kind	What it captures	Where it lives
Ingest time	When Fontana processed the file	Job timestamps; always present, regardless of source content
Document time	When the source claims validity (a report date, an effective date, an “as of” line)	Optional documentDate and effectiveFrom / effectiveTo properties, extracted from filename, frontmatter, or the EXTRACT stage
Fact time	When a typed relationship holds true in the world	Optional validFrom / validTo on a REL edge; your ontology declares which relation types carry temporal validity

Default retrieval always shows the latest ingest view: your current source files mapped to their current derived subgraph. As-of retrieval is something you opt into per query.

Collections

You tag a folder or an upload batch with collection metadata: a collection name (for example mifid-2 or mifid-3), an effective window, and any free-form key-value pairs you need. That metadata stamps onto every file, chunk, and outline node in the batch, and is inherited by the mention evidence those chunks produce.

• Retrieval scoping: both the hybrid and tree-walk lanes accept a collection filter and prune to matching subgraphs. A query scoped to mifid-3 never silently pulls in mifid-2 chunks.
• Entities are shared across collections, deliberately: ESMA is one entity node regardless of which collection mentions it, because its mentions and typed relationships each carry their own collection provenance. This means “what does MiFID III say about ESMA” filters the edges you see, not the entity itself.
• Supersession: an optional relationship between file versions, or collection-level ordering, lets “give me the latest” queries prefer the newest collection when scopes overlap.

Why keep old collections instead of overwriting them

Regulated retrieval often needs to answer both “what does the current rule say” and “what did the rule say on this transaction’s trade date.” Keeping every collection queryable, with collection and as-of filters doing the narrowing, answers both without maintaining two separate corpora.

As-of retrieval

When you or an agent supplies an as-of constraint, Fontana filters chunks and files by their document or effective dates, and prefers REL edges whose validity window contains that as-of date. Edges with no temporal properties at all are treated as unscoped: they are included unless your retrieval preferences say otherwise, so ordinary corpora without temporal metadata are not penalized for lacking dates they never claimed.

Conflict policy per relation type

For fact types your ontology marks as latest-wins (prices, ratings, statuses), the EXTRACT stage stamps an asOf value from document context, and the default retrieval view resolves conflicting same-pattern edges by picking the newest asOf or document date, while still keeping older edges available for as-of queries. You declare this behavior per relation type: latest_wins, accumulate, or window, so a price override and an accumulating list of subsidiaries behave correctly without special-case retrieval code.