financial semantic validation infrastructure
Platrixa sits between AI-generated financial understanding and deterministic financial execution. Every result carries the evidence and the reason it was reached — and anything the runtime cannot prove becomes REVIEW_REQUIRED instead of a confident guess.
input: Purchased furniture for cash Rs. 15,000
INPUT
Purchased furniture for cash Rs. 15,000
SEMANTIC IR
18-field candidate, model-proposed
EVIDENCE
every claim tied to the input
GROUNDING
schema + evidence checks
AUTHORITY
ACCOUNTING_KERNEL
✓ VERIFIED
deterministic execution passed
Static example shown for illustration — run your own input in the live workspace below.
Validate financial meaning before it reaches execution. Text and documents run through the real deterministic runtime — nothing on this page is simulated.
POST /api/v1/kernel/processEnter a narration the way it appears in your records. The deterministic runtime — not this UI — decides the outcome.
waiting for input
How one transaction moves through Platrixa — from raw language to a deterministic decision.
example: Purchased furniture for cash Rs. 15,000
product walkthrough — illustrative, not a live response
Stage 01 — raw input
“Purchased furniture for cash Rs. 15,000”
Raw financial language enters Platrixa. Nothing is normalized, paraphrased, or completed — the model must work with exactly what was written, and every downstream claim must trace back to this text.
The walkthrough advances on its own until you click a stage; then it stays where you put it.
VERIFIEDdeterministic execution passed
REVIEW_REQUIREDevidence insufficient — flagged, not guessed
UNSUPPORTEDno authority accepts it — refuses openly
The architecture in three steps — the model proposes, the runtime disposes.
01
A language model reads messy financial language and proposes a structured interpretation. It is fast, flexible — and untrusted.
02
Strict schemas, evidence grounding, conflict checks, and capability lookup decide whether the interpretation can be trusted — or must fail closed.
03
Registry-registered deterministic authorities produce the accounting result. The same input and registry state always produce the same result.
the model never computes the result
When evidence or capability is missing, Platrixa fails closed. These are safety states, not errors.
10,000 + 5,000 ≠ 12,000 — these values do not reconcile.
The runtime records the discrepancy and flags the input for review. It does not pick a number, average the totals, or invent the missing correction.
“Model a portfolio hedge using an interest-rate swap”
No registered capability covers this operation, so no authority accepts it. The system refuses explicitly and records the boundary instead of improvising an answer.
Illustrative examples of documented runtime behavior — the status contract is defined by the backend, never by this UI.
Every journal entry and every formula comes from a registry-registered authority. Counts below are the live registry, not marketing.
ACCOUNTING_KERNEL
The deterministic journal-entry engine for supported book-keeping transactions — executes only what validated semantics and grounding support.
loading live registry…
FORMULA_AUTHORITY
Deterministic financial ratios and formulas — each a registered capability with an implementation reference and a proving test.
loading live registry…
FINANCE_KNOWLEDGE
Versioned finance-knowledge records with explicit sources — terminology served from records, not generated.
loading live registry…
The homepage workspace is a thin view over the versioned /v1 API. Same runtime, same six-state contract, same evidence — deterministic and replay-safe.
Request
POST /v1/process
curl -X POST "$PLATRIXA_HOST/v1/process" \ -H "X-Platrixa-API-Key: YOUR_API_KEY" \ -H "Idempotency-Key: YOUR_IDEMPOTENCY_KEY" \ -H "Content-Type: application/json" \ -d '{"raw_input": "Purchased furniture for cash Rs. 15,000"}'
Your key authenticates the request; the idempotency key makes retries safe.
Response
200 VERIFIED{ "request_id": "req-4f2a91c7" "status": "VERIFIED" "api_status": "VERIFIED" "success": true "retryable": false "reason_codes": [] "interpretation": { transaction_type: PURCHASE, … } "evidence": [ { page, text_span, … } ] "accounting_result": { debit_lines, credit_lines, … } "metadata": { engine_status, processing_time_ms, … }}
Phase 5D result contract — the exact envelope the workspace above renders, sync and async.
Contract example — six states, structured errors, capability discovery, async jobs.
Validation infrastructure, not an adviser — and explicit about the difference.
VERIFIED means the input satisfied Platrixa's implemented validation, grounding, capability, and deterministic-authority requirements. It does not mean legally compliant, tax compliant, factually guaranteed, or financially advisable. Full details on Trust & Safety.