KLOOM
Book a demo
PLATFORM
Morphic Identity EngineImmutable Evidence APIPoint-in-Time InvestigationsAgent Identity Layer
SOLUTIONS — BY INDUSTRY
National Security & IntelFinancial Intelligence & BankingCrypto & Web3 Compliance
BY MISSION
Sanctions & SDN ScreeningAdverse Media MonitoringOSINT Subject ResolutionContinuous Due Diligence & KYC
COMPANY
CareersContact
Book a demo
Platform/ Point-in-Time Investigations
Platform

Every investigation pins to a graph version. Reproducibility is a guarantee.

Sessions address a specific graph version deterministically. Every query inside resolves against that version — no matter how the graph has evolved since. When you choose to advance, a migration report shows what changed for the entities in scope.

Book a technical walkthrough
session · sess_9201 · sanctions review
pinned 2026-05-12 09:14
graph v41
current 2026-05-21 11:30
graph v51
queries 14 run
all at v41
TIMELINE
May 12
Session opened, pinned at v41
14 queries run
May 14
Ingest batch — v41 → v47
ent_2201 split
May 21
Resumed — still resolving at v41
current: v51
MIGRATION REPORT
ent_2201 split → ent_4821 + ent_9904
relevant
ent_6688 attr updated → dob
relevant
+ 4 entities unchanged
queries
14
pinned at
v41
graph delta
+10 versions
01 · Where reproducibility fails

"Re-run and hope"
is not reproducibility.

Three failure modes that make investigation workflows non-defensible under regulatory or legal scrutiny.

01

Snapshot-based reproducibility

Making a point-in-time query reproducible usually means copying the full index at that moment. The storage cost scales with the graph, and "restore the snapshot" is a multi-step procedure — not an API call. For long-running investigations, the snapshots accumulate faster than they are reviewed.

// restore snapshot_20260512.tar.gz // ETA: unknown
02

Live graph drift

An investigation started on Monday finishes against a different graph on Friday, with no record of what changed in between. Two analysts working the same case against the current graph may reach different conclusions. There is no mechanism to prove which graph version produced which answer.

session.graph_version = "live" // pinned_at: undefined
03

Non-auditable clearances

When a sanctions clearance is challenged, you need to reproduce the exact evidence basis the analyst saw at decision time. Without session pinning, re-running the query gives you today's graph — not the one that drove the decision. The evidence basis is gone.

decision: "cleared" // evidence_version: null
02 · What the session model provides

Reproducibility as architecture.
Not as procedure.

Deterministic session pinning

A session pins to a graph version at open time. Every query inside the session — regardless of when it runs — resolves against that pinned version. No configuration, no snapshot trigger, no separate archive step. The version is addressed by the session; the session is addressed by the API caller.

version-pinned at open all queries consistent no config required

Addressing scheme — not snapshot copy

The pinned version is reconstructed from a base snapshot plus incremental deltas, with periodic full checkpoints bounding reconstruction cost — not a copy of the graph. Holding a session open prevents compaction of the deltas needed to reconstruct the pinned version; overhead grows with the delta history between the pin and the present, not with a full graph copy per session.

snapshot + deltas no snapshot copy minimal storage overhead

Migration reports on session advance

When session_refresh is called, it atomically advances the pin and returns a migration report — a structured record of which clusters in the working set split, merged, or changed attributes since the pinned version. The decision is whether and when to call session_refresh, not whether to adopt a separately previewed diff.

structured diff relevant clusters flagged investigator decides

Alerts hand off to sessions cleanly

When an alert fires, its webhook payload carries the graph_version at which the triggering event occurred. The recipient opens a session pinned to that version and investigates in the exact graph state that produced the alert — not the live graph as it now stands. Sessions are downstream of alerts, not configured in advance of them.

version in payload investigate the exact state no pre-config
03 · Deterministic session model

A guarantee — expressed in the architecture.

The pinned version is reconstructed from a base snapshot plus incremental deltas, with periodic full checkpoints bounding reconstruction cost — it is not a copy of the graph. The same query, run against the same session, returns the same result however many ingest batches have arrived since the pin. Holding a session open prevents compaction of the deltas needed to reconstruct the pinned version; overhead grows with the delta history between the pin and the present, not with a full graph copy per session.

Calling session_refresh atomically advances the pin and returns the migration report — a structured record of which clusters in the working set split, merged, or changed attributes since the pinned version. The decision is whether and when to refresh, not whether to adopt a separately previewed diff.

differentiation

"'Reproducibility' usually means 're-run the query and hope.' Here it means a guarantee — and a deterministic address is what makes it one."

worked example · sanctions review
Mon, May 12 Session opened
└─ sess_9201 pinned at graph v41
└─ 14 queries run, all resolved
└─ evidence basis: v41
Wed, May 14 Ingest batch
└─ 3 document batches ingested
└─ graph v41 → v47 (+6 versions)
└─ ent_2201 split (not yet visible to session)
Fri, May 16 Ingest batch
└─ 2 further batches
└─ graph v47 → v51 (+4 versions)
└─ 1 attribute update (not yet visible to session)
Wed, May 21 Session resumed
└─ All 14 queries re-run — identical results
└─ Evidence basis: still v41
└─ Migration report available
GUARANTEE
sess_9201 resolves at v41 — deterministically, indefinitely.
Platform

Relevant platform capabilities

Immutable Evidence API

Foundational provenance layer for all graph state. Every evidence record is written once and never overwritten, providing the permanent audit trail that makes investigation results reproducible. Version-pinning machinery builds on top of this immutable record.

Read the page

Morphic Identity Engine

The cluster layer whose state the session preserves. When clusters split or merge in the live graph, the session surfaces a migration report without adopting the change.

Read the page

Continuous Due Diligence & KYC

The primary use case for point-in-time pinning: onboarding decisions that must survive replay months later, pinned to the graph version current at adjudication time.

Read the page
Ready when you are

Book a technical walkthrough.

Thirty minutes with engineering. We open a live session, pin it, run ingest against the live graph, then replay the original queries — identical results, identical evidence basis, with a migration report showing what changed.

Book a demo