Skip to main content
aifinhub

Playground

Structured Schema Validator for Finance

Structured schema validator finance — paste LLM JSON, see missing fields, type mismatches, enum errors, and plausibility flags. Client-side.

Inputs
Paste + configure
Runtime
1–15 s
Privacy
Client-side · no upload
API key
Not required
Methodology
Open →

Education · Not investment advice. BaFin/EU framework. Past performance does not indicate future results. Editorial standards Sponsor disclosure Corrections

1 · Pick a schema

LLM research note on an investable idea. Must declare a probability, a thesis, and explicit invalidation conditions — every research output that cannot be falsified is just narrative.

Schema definition

FieldType / boundsReq
probabilitynumber [0 … 1]
Subjective probability the thesis plays out. 0..1 inclusive.
required
thesisstring ≥50 chars
Plain-English thesis. Minimum 50 chars — forces substance over one-liners.
required
convictionenum (low|medium|high)
Qualitative conviction bucket.
required
invalidation_conditionsarray ≥1 items
Explicit events that would kill the thesis. ≥1 item.
required
source_citationsarray ≥1 items
URLs or document IDs backing the claims. ≥1 item.
required

Valid example

{
  "probability": 0.62,
  "thesis": "Issuer SYNTHETIC_A's cloud-revenue mix is re-rating vs peers after three consecutive quarters of operating-margin expansion, while the sell-side model still assumes the legacy mix.",
  "conviction": "medium",
  "invalidation_conditions": [
    "Next quarter cloud-revenue growth prints below 20% YoY",
    "Operating margin contracts by more than 150 bps"
  ],
  "source_citations": [
    "10-Q FY2026 Q1, p.14",
    "Earnings call transcript 2026-02-11"
  ]
}

2 · Paste your LLM JSON

Validation runs in your browser as you type. Nothing is uploaded.

Schema validity

100%

5 / 5 fields passed · overall pass

Schema: Research Output

3 · Validation results

FieldMessage
probabilityok
thesisok
convictionok
invalidation_conditionsok
source_citationsok

What gets checked

  • Field presence, JSON type, enum values, numeric bounds, minimum string / array sizes.
  • Cross-field sanity (long stops below take-profit, leverage above retail limits, duplicate peer tickers).
  • Soft plausibility bands drawn from real-world issuer filings — out-of-band values warn, not fail.
  • Missing unit / GAAP-basis heuristics for revenue / EPS / EBITDA field names.

See methodology for why each schema is shaped the way it is.

How to use

Step-by-step

Full calculator guide →
  1. 1

    Pick a reference schema (trade order, risk report, transaction extraction, KPI extraction, earnings summary) or upload your own.

  2. 2

    Paste a sample LLM output to validate.

  3. 3

    Read pass/fail with per-field error details: missing required fields, type mismatches, enum violations, cross-field consistency failures.

  4. 4

    For batch validation, upload a directory of outputs. Read aggregate failure rates and top-3 most common errors.

  5. 5

    Use the failure-mode aggregate to debug your prompt or schema — repeated failures often point to ambiguous prompt language.

For agents

Use in an agent

Same math, same result shape as the UI above — as a static ES module. No HTTP request, no auth, no rate limit.

import { compute } from "https://aifinhub.io/engines/structured-schema-validator-finance.js";

Contract: /contracts/structured-schema-validator-finance.json Full agent guide →

Glossary references

Terms used by this tool

All glossary →

Questions people ask next

FAQ

What schemas does the validator check?

Common finance-domain LLM output schemas: trade orders, risk reports, transaction extraction, KPI extraction, and earnings summary. The validator includes 12 reference schemas pre-built from common production patterns. You can also upload your own.

Why use this instead of plain JSON Schema validation?

Two things plain JSON Schema misses: (1) finance-specific constraints (e.g., 'side' must be 'buy' or 'sell', 'symbol' must match the regex for valid ticker symbols, 'amount' must be positive), (2) cross-field consistency (e.g., 'limit price' should only appear when 'order type' is 'limit'). The validator wraps both.

What does it report?

Pass/fail per output, plus per-failure details: which field, which constraint failed, and a suggested fix. For a batch of LLM outputs, the tool aggregates failure modes — top-3 most common errors, useful for debugging your prompt or schema.

Can it validate streaming outputs?

Partially — it can validate at end-of-stream once the JSON is complete. Mid-stream validation requires knowing whether the partial output is supposed to be an array or object; the tool exposes a 'streaming mode' that does best-effort partial validation but flags incomplete documents.

How strict should I make the schema?

Strict enough to catch real errors, loose enough to not reject legitimate variation. Common pattern: tight validation on machine-consumed fields (numbers, enums, IDs); looser validation on human-readable fields (descriptions, summaries). The methodology page documents this principle.

Complementary tools

Planning estimates only — not financial, tax, or investment advice.