Architecture
Deterministic Compilers vs. RAG in Financial Diligence
// SEARCH IS NOT VERIFICATION
The short answer
Retrieval-augmented generation fetches the passages most similar to your question and hands them to a language model, which writes an answer. The answer is still generated, so it can drift between runs and can smooth over a contradiction between two documents. A deterministic compiler evaluates the claims against business physics and preserves the contradiction, returning the same score for the same recorded variables. RAG is search; this is verification.
Retrieval-Augmented Generation is a genuinely good piece of engineering. If your job is to chat with a data room — find the clause, summarize the section, pull the quote — RAG is the right tool. The category of excellent search engines built on it earns its keep.
But search is not verification. RAG fetches the passages that look most relevant and hands them to a probabilistic model that still generates the answer. It cannot cross-examine a mathematical formula, because it never leaves the neural network. It retrieves text; it does not evaluate physics.
askOdin is built the other way around: a deterministic compiler that turns claims into logic and evaluates them. The only Verification Engine in private-market diligence.
The Doctrine
Retrieval retrieves. Analytics aggregates. Workflow automates.
We compile judgment.
// WHERE THE ANSWER ACTUALLY COMES FROM
RAG never leaves the neural network
Walk the pipeline. RAG embeds your documents into vectors, retrieves the chunks nearest your query, and stuffs them into a prompt. Then a language model reads that prompt and writes the answer. The retrieval step is deterministic enough; the answer step is not. The verdict is still a generation — sampled token by token, sensitive to model version, chunk boundaries, and the order the passages arrived in.
For "what does the contract say about exclusivity," that is fine. For "do these unit economics mathematically scale," it is the wrong machine entirely. You do not want the most probable-sounding sentence about the math. You want the math evaluated.
$ embed dataroom/ → vector store
$ retrieve top_k(query) → 6 chunks
! chunks passed to LLM — answer is GENERATED, not computed
- run 1: "Unit economics appear healthy."
- run 2: "CAC payback looks elevated."
// same data room, different chunks retrieved, drifting verdict
// SEARCH ENGINE vs. VERIFICATION ENGINE
Six dimensions that separate retrieval from verification
A deterministic Verification Engine on the left. A retrieval-augmented generation pipeline on the right. The gap is not model quality — it is architecture. One fetches text for you to read; the other compiles claims into a verdict you can audit.
| Dimension | askOdin — Verification Engine | RAG — Retrieval + Generation |
|---|---|---|
| Core Operation // OPERATION | askOdin — Verification Engine COMPILE Compilation. Claims are parsed into a typed logic graph and routed to an engine that evaluates them against business physics. | RAG — Retrieval + Generation RETRIEVE Retrieval. The most semantically similar passages are fetched and handed to a model. Fetching is not judging. |
| The Verdict // VERDICT | askOdin — Verification Engine DETERMINISTIC Deterministic evaluation. A statically-typed Go engine computes the answer outside the neural network — the same logic path every time. | RAG — Retrieval + Generation PROBABILISTIC Probabilistic generation. The retrieved text is still passed to an LLM that samples the answer token by token. The verdict is generated, not computed. |
| What You Get // OUTPUT | askOdin — Verification Engine VERDICT A cross-examined verdict. Each claim is checked against the corpus and against every other document in the room. | RAG — Retrieval + Generation "CHAT WITH DOCS" A chat answer. Fluent summary of what the documents say — never an interrogation of whether the math holds. |
| Provenance // AUDIT-TRAIL | askOdin — Verification Engine HASH-ANCHORED Hash-anchored, time-stamped Defensible Audit Log™. Every figure traces to the exact source cell or paragraph. | RAG — Retrieval + Generation UNVERIFIABLE Unverifiable text. Citations may point at a chunk, but the reasoning that produced the answer is sampled and unrepeatable. |
| Reproducibility // REPRODUCIBILITY | askOdin — Verification Engine REPRODUCIBLE Same recorded variables, same Framework version → same Clarity Score. Every total is computed in Go, never sampled from a model; a past result is checked from its record. | RAG — Retrieval + Generation NONDETERMINISTIC Nondeterministic. Re-embed, re-retrieve, re-generate — the chunks shift, the answer drifts. Nothing to re-run against a standard. |
| Contradictions // FAILURE-MODE | askOdin — Verification Engine PRESERVES CONFLICT Preserved. RAVEN Protocol™ triangulates across documents and holds the conflict between the deck and the data room. | RAG — Retrieval + Generation HALLUCINATED RECON Smoothed. The generator reconciles the deck and the data room into one tidy paragraph, dissolving the discrepancy you needed. |
// Market-search platforms built on retrieval (e.g. AlphaSense, Hebbia) are excellent search engines. The contrast here is architectural — search vs. verification — not a product-quality claim.
// THE VERIFICATION ENGINE
U.S. PATENT PENDING 63/948,559The RUNE Protocol™ compiles; it does not retrieve
RAG retrieves text into the judgment path. RUNE retrieves nothing into it. A language layer reads the documents and extracts typed claims — read-only, never evaluating. Those claims are compiled into a logic graph and routed entirely outside the neural network, where a statically-typed Go engine evaluates them against business physics. The separation is the audit trail.
That is why the score is reproducible from its record. The verdict never touches a probabilistic model, so the same recorded variables under the same Framework version return the same Clarity Score™. Extraction runs on a model that can change, so two years from now an LP checks the result by reading its record — variables, version, file fingerprints — not by re-running it.
// LLM layer — extraction only, read-only
extract(claims) → typed logic graph
// claims routed OUTSIDE the neural network
+ Go engine evaluates against business physics
+ Clarity Score: 0–100 deterministic, hash-anchored
// same recorded variables → same version → same score
// Benchmark corpus built on public deal data. Every askOdin verdict is scored against this standard.
// FAILURE MODE
RAG reconciles the contradiction. askOdin preserves it.
The most dangerous thing a generative pipeline does in diligence is smooth. Hand RAG a deck claiming 140% net revenue retention and a data room whose cohorts say 88%, and the model will fetch both, then write a confident paragraph that quietly splits the difference. The discrepancy — the single most important signal in the room — gets generated away.
RAVEN Protocol™ does the opposite. Its cross-document triangulation is a verification layer for heterogeneous data rooms: it holds the deck and the data room side by side and preserves the conflict instead of resolving it for you. The contradiction is the output.
// source A — investor_deck.pptx, slide 14
CLAIM: net revenue retention = 140%
// source B — finance_export.xlsx, cohort tab
DERIVED: net revenue retention = 88%
! CONTRADICTION PRESERVED — delta 52 pts, not reconciled
// flagged for IC review, both sources cited
The architectural mechanics of RAVEN's triangulation engine are protected under U.S. Provisional Patent No. 63/994,876 and are not publicly disclosed.
RAG gives you a paragraph you have to trust.
askOdin gives you a verdict you can audit.
// OBJECTION HANDLING
Architecture FAQ
Why it isn't an LLM wrapper
Isn't this just a ChatGPT wrapper with a nicer UI?
No. A wrapper passes your prompt to a language model and formats the reply. askOdin restricts the language model to non-generative extraction, then compiles the extracted variables through a deterministic Go engine that enforces business physics. The model is the CPU; askOdin’s deterministic compiler is the operating system.
How is this different from RAG (retrieval-augmented generation)?
RAG retrieves text into a probabilistic model that still generates the answer — the verdict remains a generation. askOdin retrieves nothing into the judgment path: the RUNE Protocol compiles claims into a logic graph and a deterministic engine evaluates them. Retrieval retrieves; we compile judgment.
What exactly does the language model do versus the deterministic engine?
The language layer reads and extracts claims only — read-only and isolated. It never evaluates. A statically-typed Go engine performs every calculation and renders the verdict. The separation is the audit trail.
Determinism and proof
Can’t you just set temperature to 0 to make an LLM deterministic?
Temperature 0 only forces the model to emit its single most-probable token — it makes the output stable, not the reasoning mathematical, and model-version drift, tokenizer changes, and floating-point effects still move the result. More fundamentally, the verdict never touches the model: a deterministic Go engine evaluates the extracted claims outside the neural network. Reproducibility is a property of the architecture, not a sampling flag — the same recorded variables under the same Framework version return the same Clarity Score. Extraction still runs on a model, so a past result is checked from its record, not by re-running it.
Is the output reproducible — same input, same score?
The compiled graph is. Once a document's variables are bound, the deterministic engine returns the identical Clarity Score every time it evaluates them — the logic path is invariant, not sampled. What we do not claim is that the extraction step is frozen forever: it runs on an external model, and model-version changes can move which variables come out of a document months later. That is why every audit is hash-anchored to the exact files and the Defensible Audit Log reconstructs any verdict down to the source cell or paragraph. You verify a past result by reading its record, not by hoping a re-run matches.
Are the patents granted or just provisional?
Four U.S. provisional patent applications are filed: RUNE (63/948,559), RAVEN (63/994,876), NORN (64/011,252), JUDGE (64/017,488). Stated plainly: filed and provisional, not granted.
For Allocators
Stop searching your data room. Verify it.
Request an institutional instance and compile the documents from a live deal into a Defensible Audit Log™ your committee can read and verify.
Book an Institutional Strategy Session