Fintrieval

Verifiable, point-in-time memory for the financial agentic economy

Prove what an agent knew, that it was allowed to act, and that the money reconciled.

What · Why · Quickstart · Architecture · Surfaces · Tech stack · Status · License

---

What this is

Fintrieval is the verifiable, point-in-time memory substrate for the financial agentic economy: a system-of-record for what an agent knew, that it was allowed to act, and that the money reconciled.

The category is Verifiable Memory Governance. Generic memory infrastructure (Mem0, Zep, Letta) is built to make retrieval useful. Fintrieval is built for what the money layer actually needs: correctness and accountability. Five properties define it, and none of them are retrieval-quality features:

1. Point-in-time / no-lookahead. Every record carries full bi-temporal stamps: valid-time (when the fact is true in the world, open or closed) and transaction-time (when we learned it, and when we learned it was invalidated). An as-of query answers what was knowable at T, structurally look-ahead-free, and a late-arriving invalidation can never retroactively corrupt a historical view. Generic retrieval has no world-time concept and silently injects future data.
2. Cryptographic provenance, with semantics. Every record is content-addressed and linked to what it was derived from by typed edges (derived-from, supports, contradicts, refines, supersedes, cites) plus the transform that produced it, all folded into the hash, so mutating any ancestor or any edge meaning is detectable. A decision binds to the exact data-state it read; taint propagates, so a record resting on an untrusted ancestor is flagged even after laundering through derivations.
3. Governed, poison-resistant writes. Every write passes a policy gate: constraint-pinned (survives compaction), capability-scoped, and blocked or escalated when an untrusted source touches a sensitive field.
4. Deterministic replay. The same query and as-of return the same result set, and a run replays to a signed decision receipt that binds the as-of snapshot, model version, tool calls, overrides, and audit head.
5. Governed lifecycle. Facts carry kill-conditions and importance/temporal decay; a verifiable consolidation pass reconciles, supersedes, and prunes stored records over time; and erasure cascades the derivation closure with a sealed proof, so the right-to-be-forgotten reaches derived artifacts too.

The forcing function is regulatory: EU AI Act Article 12 (automatic event logging and traceability, full high-risk application expected ~Aug 2026), SEC 17a-4 (tamper-evident audit trail), and MiFID II / RTS 6 (algorithm and change repository). Each wants a provable record of what a system knew and did. Fintrieval is that record, made verifiable offline by a third party who trusts neither the issuer nor us.

Why generic memory can't do this

The graph-temporal camp (Zep, Graphiti, Sentra) has the right data model but conversational-time only, mutable audit logs, no finance vertical, and no enforcement. The horizontal memory vendors are uniformly useful-first with no point-in-time model and no provenance. Payment rails sign each transaction but keep no persistent memory. None of them treat memory as something that has to be correct and provable, because their buyer rewards recall quality, not accountability. In a domain where a wrong or unprovable memory moves money, that mismatch is the whole product.

Quickstart

[dependencies]
fintrieval-store = "0.1"

use fintrieval_store::{MemoryStore, SensitiveFieldGuard, DecisionReceipt};

let mut store = MemoryStore::new();

// A governed, bi-temporal write. An untrusted source touching a sensitive field is refused,
// so a prompt-injected "memory" can never overwrite a risk limit or a venue.
let guard = SensitiveFieldGuard::new(["risk_limit", "venue"]);
store.remember(record, &guard)?;

// Point-in-time recall: only what was knowable as of `tx_t`, valid at `valid_t`.
// Nothing learned after `tx_t` can leak in - there is no look-ahead surface.
let snapshot = store.recall_as_of(&valid_t, &tx_t);

// Freeze what the decision actually saw into a signed, offline-verifiable receipt.
let receipt = DecisionReceipt::from_snapshot(&snapshot, "regime=bull", "buy");
let envelope = receipt.seal(issuer, subject, now, &key)?;
assert!(envelope.verify().is_ok());   // a third party verifies it, trusting neither issuer nor us

Everything above runs against the trust-root below: the receipt is a signed fintrieval Statement, the recall order is deterministic, and the record's provenance is content-addressed and tamper-evident.

Architecture

Fintrieval is two layers over one boundary. The lower is the attestation trust-root (the fintrieval-core / finance / predicates / verify crates); the upper is the memory engine (fintrieval-store and the governance, decay, and retrieval crates built on it). The attestation layer attests; the memory layer remembers.

                        the memory engine  (remember · recall(as_of) · govern · decay · consolidate · retrieve)
   fintrieval-store ─── bi-temporal store, typed Merkle-DAG provenance + taint, durable append-log, deterministic recall
     ├── fintrieval-policy ────── governed-write engine: capability-scope · constraint-pinning · poison-resistance
     ├── fintrieval-decay ─────── decay planner (kill / TTL / importance) + cascade ErasureProof (GDPR Art 17)
     ├── fintrieval-consolidate ─ verifiable reconcile / supersede / prune over stored records + signed proof
     ├── fintrieval-compact ───── context-window compaction: constraint-pinned, token-budgeted, L0-stub degrade
     └── fintrieval-retrieval ─── hybrid BM25 + vector + provenance-graph + entity, RRF-fused, deterministic rerank
                        │
                        └── depends on ↓   the "prove it" trust-root

   fintrieval-core ────── neutral crypto kernel: deterministic CBOR, ed25519/COSE envelope, did:key, RFC 6962 Merkle log
     └── fintrieval-finance ──── Money, PointInTime + ClockSource, Identity, MandateRef, Statement<P>
           └── fintrieval-predicates ── typed decision claims + validate() + type-URI registry
   fintrieval-verify ──── the offline receipt verifier (signature · predicate · log inclusion)

The boundary rule: the kernel knows nothing about finance, the predicates know nothing about cryptography, and the finance vocabulary is the deliberate middle both meet in. The memory layer imports the point-in-time type, the signing and Merkle log, and the no-lookahead predicate from the attestation crates rather than reimplementing any of them.

The trust-root: attestation layer

Reinvents no cryptography (RFC 8949 deterministic CBOR, ed25519 in a COSE-style envelope, an RFC 6962 Merkle log); the part that is its own is the finance vocabulary and the typed decision predicates above them. It answers three questions a verifier checks independently: who signed, what was claimed (a typed predicate with a validate() that rejects an incoherent claim regardless of signer), and whether it was recorded.

Crate	Role
fintrieval-core	deterministic CBOR, the ed25519 COSE-style Envelope with the algorithm pinned, did:key identity, the RFC 6962 Merkle log. No domain knowledge. #![forbid(unsafe_code)].
fintrieval-finance	the shared vocabulary every predicate composes from: exact fixed-point Money, PointInTime tagged with its ClockSource, Identity, MandateRef, and the generic Statement<P>. No floats.
fintrieval-predicates	the typed decision claims (no-lookahead, forward-commitment, deflated-performance, payment-mandate, delegated-authority, settlement-finality, result-attestation), each with a stable type URI and a validate() semantic check.
fintrieval-verify	checks a receipt on independent legs (signature, predicate coherence, log inclusion, optional recompute). Depends on no product, so its trusted base stays small.

The memory engine

The genuinely new layer: the queryable, governed, bi-temporal record of many claims over time.

Crate	Role
fintrieval-store	append-only four-timestamp bi-temporal store (valid-from/valid-to world-time, plus created and invalidated transaction-time, invalidate-not-delete, recall_as_of), content-addressing, a typed Merkle-DAG provenance graph (relation + transform hash-bound) with tamper-evidence, ancestor / derivation-path queries, trust-taint propagation, inclusion proofs, a Store trait with an in-memory and a crash-safe durable append-log backend, cascade trace-free erase, and deterministic recall order.
fintrieval-policy	the governed-write engine: CapabilityScope, ConstraintPinning (constraints that survive compaction), PoisonResistance, and PolicyChain (Deny > Escalate > Allow).
fintrieval-decay	a pure decay planner (kill-conditions, TTL, importance floor) plus a sealed, residual-trace-free ErasureProof that asserts the erased set is the full derivation closure (GDPR Art 17).
fintrieval-consolidate	the maintenance layer: a pure planner that reconciles duplicates, supersedes stale records, and prunes over the stored set, applied through typed edges and edge-driven temporal invalidation, sealed as a signed ConsolidationProof; relative-to-absolute reference rewrite; an opt-in offline (sleep-time) job.
fintrieval-compact	context-window compaction distinct from decay: a token-budgeted, constraint-pinned packer that degrades non-pinned overflow to an L0 stub before dropping it, with a dependency-light char estimator and an opt-in exact-BPE tokenizer.
fintrieval-retrieval	hybrid retrieval over an as-of snapshot: BM25 + vector cosine + provenance-graph proximity + named-entity overlap, reciprocal-rank-fused, then a deterministic feature reranker over the shortlist. Serde WhereFilter algebra (crosses the wire), provenance-scoped and capability-scoped filters. Deterministic throughout.

The facade: fintrieval-sdk

Crate	Role
fintrieval-sdk	one ergonomic Fintrieval API composing store, policy, decay, retrieval, and verify: remember / recall_as_of / recall_ranked / receipt / verify / decay / forget, with a JsonFintrieval concrete alias. Consumers depend on this crate alone.

Surfaces

One core, spoken through every surface GL's products already use (the proven house pattern: a Rust core plus thin bindings and surfaces). The SDK, CLI, MCP server, and both language bindings are built; a hosted gateway is later.

Surface	What it is	Status
SDK (fintrieval-sdk)	the primary developer surface: remember / recall_as_of / recall_ranked / receipt / verify / decay / forget.	built
Compliance CLI (fintrieval)	the human / regulator surface: remember, recall --as-of, receipt --seal, verify, forget, decay, over a durable store.	built
Governed MCP server (fintrieval-mcp)	memory-as-MCP so any harness consumes it with zero glue, governed and poison-resistant at the boundary. "The memory MCP that can't be poisoned."	built
Node / TS binding (@general-liquidity/fintrieval)	a napi-rs binding exposing the governed facade to JavaScript and TypeScript.	built
Python binding (fintrieval)	a PyO3 abi3 binding exposing the governed facade to Python.	built
HTTP gateway	optional, later, for hosted multi-tenant managed memory.	deferred

The Rust SDK is the source of truth; the Node and Python bindings wrap the same JsonFintrieval facade, and both build as standalone crates outside the main workspace so the core's cargo build --workspace stays lean.

Tech stack

Technology	Role
Rust 1.96+	the whole substrate, #![forbid(unsafe_code)] across every crate, determinism as a contract
CBOR (RFC 8949)	deterministic canonical encoding via ciborium, so a signed byte string is reproducible anywhere
🔑 ed25519 / COSE	signing in a COSE-style Envelope with the algorithm pinned (ed25519-dalek)
#️⃣ SHA-2 / RFC 6962	content-addressing + the append-only Merkle log with inclusion and consistency proofs
GitHub Actions	CI: fmt · clippy -D warnings · the full test suite · Node + Python binding builds · cargo-deny

The substrate is deliberately best-in-class external crates (CBOR, ed25519, SHA-2): Fintrieval reinvents no cryptography. The novel layer is the finance vocabulary, the typed predicates, and the bi-temporal governed memory above them.

Status

Early and pre-1.0, in active development. Honest state of the tree:

• Attestation trust-root: built. fintrieval-core / finance / predicates / verify are implemented, tested, and CI-green.
• Memory core: built. fintrieval-store (four-timestamp bi-temporal store + typed Merkle-DAG provenance + taint + cascade erasure + deterministic recall), fintrieval-policy, fintrieval-decay, fintrieval-compact, and fintrieval-retrieval (hybrid + entity channel + deterministic rerank + WhereFilter).
• Maintenance layer: built. fintrieval-consolidate reconciles / supersedes / prunes stored records with a signed proof, plus an opt-in offline job.
• Facade + surfaces: built. fintrieval-sdk, the compliance CLI (fintrieval), the governed MCP server (fintrieval-mcp, enriched with per-record lineage + taint), and the Node and Python bindings are implemented. 187 tests pass, clippy -D warnings clean, fmt clean.
• Deferred by design: the per-product vertical adapters, the tri-publish release pipeline, a hosted HTTP gateway (and its crypto-shredding erasure), and a governed memory-injection SDK adapter. Fintrieval is the generalized substrate; it does not yet wire into any specific product.

Nothing here is a released product yet. The wire format and the store schema will move before 1.0. A guaranteed deterministic result set under a live, growing store (beyond the deterministic recall order already shipped) is the one genuinely open research item.

License

Dual-licensed under either MIT or Apache-2.0, at your option.

---

_{© General Liquidity. A General Liquidity product - the system-of-record for what an agent knew, that it was allowed to act, and that the money reconciled.}