PRODUCT
A verification engine first. A platform by design.
Tusiro is built around one permanent core and three product surfaces. One is built. Two are designed on the same core and labeled exactly that way.
THE CORE
One core, five components.
Specification language
Correct behavior written down in machine-checkable form: “a risk check must complete before an order is sent,” “every execution must be confirmed back to the customer.”
Canonical event model
One normalized vocabulary that every broker’s and exchange’s messy records get translated into.
Compiler
Turns authored rules into executable checks.
Evaluation engine
Runs events against rules and produces verdicts.
Evidence ledger
An append-only, typed memory where every fact, contradiction, and verdict is recorded with its evidence pointers. Not a blockchain.
VERDICT SEMANTICS
An engine that refuses false certainty.
Where conventional tools output “pass” or “alert,” Tusiro’s evaluator treats unknown, inadmissible (the evidence itself is not trustworthy enough to judge), and contradictory as first-class outcomes. Its binding design rule: unknown must never silently collapse into pass.
Auditors and regulators distrust systems that always say everything is fine. A system that can say “these two records contradict each other, and here is the gap” is a fundamentally more credible witness.
A system this honest will sometimes tell you that your records cannot prove you behaved correctly. That answer is the product working.
In customer-facing reports, these engine states surface as three plain labels on every claim: proven, missing, or conflicting.
SOURCE HONESTY
Every broker lies differently. Source profiles make that explicit.
Broker and venue records differ in which order IDs can be trusted, which acknowledgment counts as the real submission, and which timestamps are honest. Tusiro encodes those decisions per source: governed source profiles with strict schema discipline, conformance fixtures, and golden replays. It does not pretend one adapter fits all. The in-progress IBKR FX connector forced exactly these decisions, and every new source repeats that discipline.
THE PLATFORM, HONESTLY STAGED
Three surfaces. One is built.
A · Execution correctness verification
BUILTAfter the fact: did the system behave according to its declared rules? Output: an evidence-backed verification report.
Validated on 581,030 real NASDAQ order-book events (LOBSTER, academic data); second source (IBKR FX) in implementation.
B · Adversarial resilience testing
DESIGNED, NOT BUILTBefore production: can the system survive hostile but protocol-valid scenarios derived from the same correctness contracts?
C · Bounded runtime protection
DESIGNED, NOT BUILTDuring incidents: contain live danger with bounded, evidence-backed actions. No AI in the critical path.
The correctness contract a customer writes once for verification becomes the attack oracle for testing and the eligibility condition for runtime containment. Trust is staged deliberately: read-only value first, operational authority last.
WHERE TUSIRO SITS
After monitoring. Before expensive manual investigation.
Monitoring (alerts + raw logs) → Tusiro (evidence report) → Risk / Ops (shared review) → Management (decision + response)
Real-time monitoring (Pico/Corvil, ITRS, Beeks)
live telemetry while it happens; not an offline evidence report after a dispute.
Reconciliation (Duco, Gresham)
finds that two datasets disagree; does not rebuild the incident story or judge correctness.
Surveillance & TCA (Nasdaq SMARTS, Eventus)
hunts market abuse and measures execution quality; not correctness proof for one disputed order.
Internal scripts & LLM log tools
scripts rot after one incident; LLM assistants summarize plausibly but cannot produce a deterministic, evidence-linked verdict that stands up to a customer or a regulator.
Tusiro does not replace logs, reconciliation, or monitoring. It uses their evidence to answer the correctness question they can’t.
BOUNDARIES
What Tusiro is not.
Not a trading strategy engine or alpha generator.
Not an OMS/EMS replacement.
Not market-abuse surveillance.
Not a blockchain.
Not an AI agent with authority over orders. There is no LLM in the verification core or in any critical path.
NEXT STEP
Start with one incident.
Send the records around one real past incident, tokenized if you prefer, and receive the actual artifact: a verification report on your own order, your own systems, your own unresolved dispute. No imagination gap to bridge.