askOdin — AI Judgment Infrastructure for Capital Allocation

Architecture

Deterministic Compilers vs. RAG in Financial Diligence

// SEARCH IS NOT 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.

rag_pipeline.trace PROBABILISTIC

$ 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.

Core Operation

// OPERATION

COMPILE

Compilation. Claims are parsed into a typed logic graph and routed to an engine that evaluates them against business physics.

RETRIEVE

Retrieval. The most semantically similar passages are fetched and handed to a model. Fetching is not judging.

The Verdict

// VERDICT

DETERMINISTIC

Deterministic evaluation. A statically-typed Go engine computes the answer outside the neural network — the same logic path every time.

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

VERDICT

A cross-examined verdict. Each claim is checked against the corpus and against every other document in the room.

"CHAT WITH DOCS"

A chat answer. Fluent summary of what the documents say — never an interrogation of whether the math holds.

Provenance

// AUDIT-TRAIL

HASH-ANCHORED

Hash-anchored, time-stamped Defensible Audit Log™. Every figure traces to the exact source cell or paragraph.

UNVERIFIABLE

Unverifiable text. Citations may point at a chunk, but the reasoning that produced the answer is sampled and unrepeatable.

Reproducibility

// REPRODUCIBILITY

REPRODUCIBLE

Same inputs → same Clarity Score, byte for byte, same hash. Calibrated against 100,000+ benchmarked scores.

NONDETERMINISTIC

Nondeterministic. Re-embed, re-retrieve, re-generate — the chunks shift, the answer drifts. Nothing to re-run against a standard.

Contradictions

// FAILURE-MODE

PRESERVES CONFLICT

Preserved. RAVEN Protocol™ triangulates across documents and holds the conflict between the deck and the data room.

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,559

The 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, isolated, 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 output is reproducible. The verdict never touches a probabilistic model, so identical inputs return an identical Clarity Score™ and an identical hash — the same standard an LP can re-run two years from now.

rune_compile.go DETERMINISTIC

// LLM layer — extraction only, read-only, isolated

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 input → same verdict → same hash, every time

100,000+ Benchmarked Scores
40+ Forensic Dimensions
0–100 Clarity Score Scale

// Calibration 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.

raven_triangulation.log CONFLICT HELD

// 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

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.

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 — identical inputs return an identical Clarity Score and an identical hash.

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.

Is the output reproducible — same input, same score, byte for byte?

Yes. Every audit is hash-anchored; re-running the same data room returns an identical Clarity Score and an identical SHA-256. The Defensible Audit Log makes any verdict reconstructible to the exact source cell or paragraph.

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.

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) — and the JUDGE Protocol holds IPOS Section 34 National Security Clearance, issued 2026-03-26. Stated plainly: provisional, filed, and in the case of JUDGE, cleared.

For Allocators

Stop searching your data room. Verify it.

Request an institutional instance and compile a live data room into a Defensible Audit Log™ your committee can re-run and verify.

Book an Institutional Strategy Session