The objections, answered.

The deterministic verification layer for private capital. Unlike information infrastructure (which retrieves and organizes data), judgment infrastructure interrogates the logical coherence of an investment thesis — auditing every claim against the structural physics of a 110,000+ Clarity Score benchmark corpus before capital is deployed.

Due diligence whose verdict is reproducible and audit-defensible months later, because identical inputs always produce identical findings. It is the opposite of a probabilistic LLM summary, which can change on every run and cannot be defended to an investment committee or a regulator.

Yes — that is askOdin’s role. Credit has Moody’s; public markets have GAAP; private capital now has the Clarity Score, a deterministic 0–100 standard backed by a Defensible Audit Log.

ChatGPT summarizes what a deck says (probabilistic). askOdin compiles whether the physics are sound (deterministic) and emits a reproducible Clarity Score and a Defensible Audit Log — not prose.

Those are retrieval, CRM, and market-intelligence layers. askOdin is the judgment layer above them: retrieval retrieves, analytics aggregates, workflow automates — we compile judgment.

Three deterministic stages: the RUNE Protocol extracts claims into a logic graph, the RAVEN Protocol triangulates them across documents, and a deterministic engine emits a Clarity Score with a Defensible Audit Log — every verdict reconstructible to its source.

Yes. askOdin Pte. Ltd. is headquartered in Singapore, founded by YekSoon Lok. It is built on four U.S. provisional patents — RUNE, RAVEN, NORN, and JUDGE — and is a member of the NVIDIA Inception Program.

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.

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.

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.

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.

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.

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.

No. Extraction runs against an external model API under a paid-tier agreement that prohibits training use; the deterministic engine does the analysis. Raw documents are held no longer than 30 days under a documented retention ceiling. What persists beyond that is derived — the verdict, the judgment analysis, and structural data in the Judgment Graph benchmark corpus. That structural record can include identifying details such as founder names, so it remains subject to your erasure rights; systematic de-identification is on the roadmap, not shipped. No customer document enters any training corpus.

Processing region is configurable per deployment; the default jurisdiction is Singapore under PDPA, with EU and US residency available for dedicated instances.

Cloudflare for edge security and object storage, and the Google Gemini Developer API for document extraction, behind a swappable adapter layer. Extraction is the model's only role — it maps unstructured documents into typed variables, and the deterministic engine does the analysis. The full sub-processor list is provided under NDA.

Not yet. Implemented controls: AES-256 at rest, TLS 1.3 in transit, stateless API orchestration, a documented 30-day retention ceiling on raw documents, and PDPA compliance. In progress: SOC 2 Type I, a GDPR Data Processing Agreement, and automated enforcement of the retention policy. On the roadmap: SOC 2 Type II and ISO 27001. We distinguish a stated policy from an implemented control and will tell you which is which — documentation is available under NDA for your security review.

A Data Processing Agreement with Standard Contractual Clauses for cross-border transfers is in preparation and is not yet available for signature. Contact the security team and we will tell you where it stands rather than quote a date we cannot evidence.

Yes. Institutional deployments run as dedicated instances under strict data sovereignty, and raw documents are held no longer than 30 days; the derived judgment record persists so the audit trail survives the document. Tenant isolation on the shared processing cache is being hardened and is not yet complete — if strict isolation is a gating requirement for your firm, talk to us before you upload anything, and we will tell you exactly where that work stands.

Yes. askOdin is a deterministic compiler, not a probabilistic black box. Every verdict produces a Defensible Audit Log with cross-document provenance — reconstructible under fiduciary inquiry or regulatory examination.

No — it strengthens it. Duty of care requires an explainable, validated process. The Defensible Audit Log gives every verdict a reconstructible, click-to-source evidence trail — the opposite of an unexplained black box.

No. The compiler reads underlying physics, not founder polish — it overrode Airbnb’s weak 2009 framing and surfaced the category-creation structure. It penalizes physics violations, not unconventional narratives.

That is the core use case. Cross-document triangulation surfaces the contradiction — the cap table that mathematically contradicts the projection, the hardware claim the physics forbids — at compile time, before the term sheet. See the Terminal Audits.

It is not a probabilistic prediction to be 'accurate'; it is a deterministic compiler check that is reproducible across analysts and across years. The same data room returns the same verdict — calibration, not accuracy.

Yes — that is the reason it exists. Each finding traces to the document and line that produced it, and the engine is deterministic, so re-running the same inputs on the same engine version returns the same result. Two years later, when someone asks how the committee got comfortable with an assumption, the record answers rather than a recollection.

Then you have located the disagreement, which is the useful outcome. The score is not a vote and does not overrule anyone. Because every input is traced, a partner who disputes it can go to the specific claim and the specific document behind it and argue with that. Disagreeing with a number is unproductive; disagreeing with a sourced finding is diligence.

Those retrieve, aggregate, and summarize faster. askOdin sits above them and compiles judgment deterministically: retrieval retrieves, analytics aggregates, workflow automates — we compile judgment. We do not compete; we consume.

A summary compresses what the documents say. Verification tests whether what they say holds together. A summariser reading a deck claiming 40% margins and a model showing 24% will usually produce fluent prose containing both numbers. Verification treats the gap between them as the output. One saves reading time; the other changes the decision.

No. It replaces the part of their week spent checking whether numbers reconcile across documents — mechanical work that is easy to do badly at volume and offers no judgment premium. What it does not do is decide. Which risks are acceptable, which founder is worth backing, what the deal is worth: those stay with the people you hired to make them.

Underneath them. Those systems store documents, track relationships, and supply comparables — none of them evaluate whether the reasoning in a deal holds. We do not compete with that stack; we consume it. The data room stays where it is, the CRM keeps the pipeline, and the verification layer runs across whatever they contain.

A forensic pass runs in minutes. Run the interactive Sample Audit in the sandbox, or compile a single live deal in a scoped pilot before committing.

Yes, and the gaps become part of the output. Missing documents are reported as unverifiable rather than silently skipped, so an absent cohort file or a missing bank statement is visible to the committee instead of disappearing into a confident-sounding summary. In early diligence, knowing what you could not check is often more valuable than what you could.

A memo the committee can read without you in the room. Every material claim carries the document and page it came from, contradictions between sources are stated rather than reconciled away, and the reasoning behind the score is visible. The point is that a partner who was not in the meeting can follow how the conclusion was reached, and check it.

Check each claim against a source that was not written to persuade you. A revenue figure in a deck should reconcile to the model; a growth rate should survive being recalculated from the underlying numbers; a number appearing in three documents should appear identically in all three. Where they disagree, the disagreement is the finding — regardless of which document turns out to be right.

Both. For IDD, the Clarity Score benchmarks a manager’s decision quality against a 110,000+ benchmark corpus. For ODD, the Defensible Audit Log gives a reconstructible record of how each decision was reached. It is the evidence layer beneath your diligence, not a replacement for it.

It extends DDQ 2.0. The standard captures what a GP says; askOdin adds a deterministic, auditable measure of how they actually decide — four drop-in questions your committee can require.

Both models work. Run a Clarity audit on a prospective manager’s representative deals during selection, or embed a Clarity Score minimum in side-letter terms so the GP reports it each quarter.

Yes — the NORN Protocol (U.S. Provisional Patent 64/011,252) detects temporal semantic drift: divergence between a manager’s stated thesis and their actual decisions across chronologically sequential funds.

A human ODD report is a point-in-time snapshot. askOdin produces a deterministic, re-runnable score and a cryptographically anchored audit log — continuous, and machine-comparable across your entire manager roster.

That is the design goal. Every verdict is hash-anchored and click-to-source, so the basis for an allocation is reconstructible under fiduciary inquiry.

Crucible is a free pitch deck audit — a forensic pass over the reasoning in your deck. It compiles the reasoning in your deck — the claims, the unit economics, the way the numbers relate to each other — and returns a Clarity Score out of 100 with the specific structural problems named and located. It is the same standard institutional investors apply, run before you pitch rather than after.

Most deck tools evaluate the presentation: layout, story arc, whether the narrative flows. Crucible evaluates whether the underlying business logic holds — whether the revenue model closes, whether the growth assumption survives its own maths, whether two slides contradict each other. Design feedback tells you how the deck reads. Crucible tells you what an investor will find when they check.

ChatGPT tells you whether your deck reads well — it optimizes for persuasion. The Crucible compiles whether the underlying physics hold, catching the structural kill shot a probabilistic model glosses over. That is the difference between flattery and diligence.

Same engine, opposite side of the table. The Crucible is free and built for founders auditing one deck — your own — before you pitch. Clarity is the institutional product investment firms run across a pipeline of deals, with the committee memo, provenance record and team workflow that context requires. The score means the same thing in both.

A Clarity Score is a 0–100 measure of how well the reasoning in a deck holds together. It comes from five scored pillars and three audit checks — problem, solution, business model, deal structure and the evidence behind them — not from design, wording, or how convincing the story sounds. The same score means the same thing for every deck, which is what makes it comparable.

The engine returns a verdict alongside the number. 85 and above is PRIORITY — high clarity, the logic holds. 70–84 is INVESTIGATE — adequate, with real questions left to answer. 50–69 is WATCH — low clarity. Below 50 is PASS. A kill shot is separate from the bands: a single terminal contradiction that floors the score to 0 regardless of every other strength.

Aim to clear 70, which is where the engine stops returning WATCH and starts returning INVESTIGATE. Below 50 it returns PASS. There is no separate bar by stage — the floors are identical for every deck — but what a band means does shift: a seed deck in WATCH usually has assumptions still to evidence, while a Series A in the same band has evidence that does not reconcile.

A 0 is not an error — it is a FATAL verdict from the JUDGE Protocol, triggered when the engine finds irreconcilable data it cannot compile around: revenue that contradicts itself across slides, a model that violates its own narrative, a claim with no support. Generative tools smooth these over to keep you happy; the Crucible exposes them, flagged to the exact page and cell, so you fix the fracture before an investor does. The score is the proof the engine works, not a sign it is broken.

No. Crucible does not predict outcomes, replace investors, or guarantee funding. It measures whether your investment reasoning holds together under the standard applied before capital is committed. Timing, market conditions, and fit with a particular fund all remain outside it. Investment outcomes stay uncertain; investment reasoning does not have to.