Continuous Intelligence — Overview

Owner	Classification	Status	Verified against code
Kris (product) · Raj (architecture)	Internal	Living	2026-09-15 — blitz/src/

What this section is. The canonical, code-verified account of how Finaisse's intelligence actually works today — the layered decision model, the per-app inventory of what's shipped, the Finni runtime, and the Finaisse Intelligence Graph (FIG). It consolidates four Z-drive working docs (FINAISSE-INTELLIGENCE-STRATEGY-v2, FINAISSE-INTELLIGENCE-IA, FINNI-PRODUCTION-ARCHITECTURE, FINAISSE-FIG-DESIGN + FINAISSE-FIG-DATA-SETUP) into one maintained home. Where those docs and the code disagree, this section — verified against code — wins.

Reading discipline. Every claim here carries a status tag (below). Unqualified prose describes what is in code today. Anything design-only or roadmap is marked and quarantined — do not present ◯ items as present.

---

The claim-safety legend

Adopted from the IA doc because a public Cash App page once over-claimed. It governs every downstream surface (this portal, the website, decks):

Tag	Meaning	How to talk about it
✅	Shipped — verified in code, runs in a real flow	Claim freely
⚠️	Partial / demo-gated — exists but narrow, batch-only, or unwired	Claim carefully, with the caveat
◯	Roadmap / design — spec exists, no running code	Never show as present

---

The model — 9 faculties × 3 layers

Intelligence = what the platform does (faculties) expressed through how it decides (layers). The formula is deliberate: the autonomy lives in the deterministic layer, and the LLM never sits in the decision path.

The three layers

Layer	What it is	Role	Autonomy
Layer 1	Rules + statistics (libs/rulesengine, matching_config / matching_rule, CID handlers)	The only autonomous decider. Computes candidates, scores, thresholds.	Acts
Layer 2	LLM-as-Judge (cid-judge, match-judge, remittance-judge, gl-coding-judge, po-match-judge, collection-judge)	Advises, never decides. Scores ambiguous candidates in human-review surfaces only.	Advises
Layer 3	LLM exploration — Finni chat + native agents	Conversation, narration, param extraction. Numbers come from code.	Explores

The load-bearing principle — "no LLM in the autonomous decision path" — holds in code. The matching engines post on Layer-1 scores; judges only rank candidates a human then confirms; Finni's graph short-circuits toolNode → formatResponse → END so the model narrates tool output rather than computing it (see Finni Architecture).

The nine faculties

From the IA model — "how Finaisse thinks", mapped to the layer that carries each and its overall maturity. Per-app detail lives in the Intelligence Inventory.

Faculty	What it does	Primary layer	Maturity
Decide	Rules/stat matching & identification (CID, matching legs)	L1	✅
Connect	Cross-entity graph — the FIG Connect faculty	(projection)	◯ design (FIG)
Judge	LLM-as-Judge scoring of ambiguous candidates	L2	✅ (6 judges)
Predict / Detect	Classical ML (classicml) + rule-based anomaly detectors	L1/ML	⚠️ ML dormant; rule detectors shipped on invoice
Converse	Finni chat across 6 domains + FinHub supervisor	L3	✅
Route / Orchestrate	Native agents (routing, planning, categorization…)	L3	✅ (planning skeletal)
Explain	Provenance / reasoning via intelligencelog	(substrate)	⚠️ partial (log often sparse)
Learn	Learning Fabric over intelligencelog (alias write-back)	(substrate)	⚠️ cash alias write-back only
Prioritize	Materiality tiers + worklist ranking	L1	⚠️ per-module

intelligencelog is the unifying primitive. finbase.intelligencelog is both the audit trail (every decision's trace / candidates / decision / layer2*) and the Learning Fabric substrate. Every faculty writes to it — it is the one table the whole model shares. Caveat: sampled payment-matching rows have been found with an empty {} decision JSONB, so the log enriches provenance, it does not yet reliably contain it.

---

FIG vs ML — a correction worth internalising

A common misread (carried by the older strategy doc) is that ML lives "inside" FIG. It does not. FIG is the Connect faculty; ML is the Predict/Detect faculty. They are siblings. FIG assembles the features ML trains on; ML scores decorate FIG nodes. Keep them distinct.

Likewise, "the anomaly engine" is not a single per-transaction service. The shipped anomaly work is a set of rule-based detectors running in the invoice BPD chain (roundamount, newsupplierhighvalue, materialityjump, bankchange, duplicatesimilar → fraudriskscorewriter). The genuine system-level anomaly engine — velocity spikes, structuring, concentration rings — is the FIG + classicml node layer, which is design-stage. See FIG Design.

---

The single biggest latent asset — classicml

apps/classicml is a Python Temporal worker with 12 scikit-learn services (anomaly, classification, multiclass, regression, ranking, timeseries, clustering, survival, changepoint, dimreduction, profiling, recommendation), each with a train.py + inference.py. It is fully scaffolded and completely dormant — no finance flow invokes it; the only reference in packages/ is a dead comment in casha/.../finni.service.ts. Wiring one flow into it is the highest-leverage move to flip the ◯ predictive items to ✅.

Note: the older strategy doc's "only anomaly has train/inference" is wrong — all 12 do.

---

Where each piece is documented

Page	Answers
Intelligence Inventory	What exists, per app, and how real — the authoritative claim-safety status
Finni Architecture	Who runs the work with you — Finni runtime, the CFO co-pilot, the model/provider map, governed execution
FIG Design	How the connective brain is built — the graph engine (design-stage)
FIG Data Setup	The data under FIG — master-data ownership & demo-data currency

Doc hierarchy (kept distinct, no overlap): the Inventory is how Finaisse thinks; FinHub is what you see; Finni is who runs the work with you.

Revision history

Date	Change
2026-09-15	Initial consolidation of the Z-drive intelligence corpus into the portal; code-verified; corrections applied (classicml count + dormancy, FIG≠ML, anomaly framing, model defaults).