TRUSCOR
Had an AI incident? Get rated
Technology · Rate it. Record it.

We measure and record.

TRUSCOR is the independent AI risk rating: the CIBIL score for AI. It tests an AI system from the inside, issues a private 300–900 score, and records what the system actually does once it is live.

One sentence governs every technology The model does the thinking. The vendor sells the fix. The insurer carries the risk. We measure and record.
The problem it solves

Neutral proof of three things.

Courts, insurers, regulators, banks and merchants increasingly need it. Almost everyone producing that proof today also sells the AI, the guardrail, the certificate or the insurance. TRUSCOR sells none of those things.

Fig. 01Who produces the proof today
1What an AI system actually did.Not what it said it did.
2Whether its controls actually worked.Kill switches, human reviewers, guardrails.
3Whether a rating still describes it.Models change silently.
The family at a glance

Seven technologies, one owl.

Sova is Russian for owl. Each part of the family carries its own owl, drawn for what it does.

Available
SOVA Engine The testing engine. It attacks, UI-tests and stress-tests an AI product, judges it, and writes everything as .sova evidence. Rating team · licensed pentest and security firms
Available
TAFAAR The risk-grading engine. It turns evidence into the TRUSCOR Rating (300–900), the Estimated Financial Exposure and a risk map across rules and regulations. TRUSCOR only · never licensed
Available
SOVA Black Box The 24x7 recorder. It logs every action and failure of a live AI system, signed and checked against effect, so fault can be proven later, in court if needed. Companies running AI in production · OEM partners
Available
.sova format The evidence format. A signed, tamper-evident record of what an AI was shown, what it did and what changed. Developers, auditors, insurers, courts
Available
O.W.L The measurement instrument: TRUSCOR’s hands and eyes on real computers. It operates test environments, observes what really happened, records signed evidence and replays findings. SOVA Engine and Black Box · licensed measurers
Available
SOVA OSS The open-source toolkit for AI security: the format, an early engine you can customise, an arena for clashing agents, and a registry of vulnerabilities and tests. Developers, security researchers, students
Being built
The TRUSCOR corpus The data: what AI systems actually did, how they failed and what it cost, de-identified and consented. Insurers, reinsurers, regulators, risk teams
Available: in use todayBeing built: the TRUSCOR corpus and its data productsComing soon: two sector capabilities that follow their mandates
Fig. 02 · How the pieces fit

All evidence is written as .sova.

Before launch, O.W.L and SOVA Engine test. In production, SOVA Black Box records. TAFAAR grades all of it, and SOVA OSS is the open layer underneath.

The life of a rated AI system

Rate, fix, retest, record.

The client fixes; TRUSCOR never does.

Fig. 03Rate, fix, retest, record
Each step in detail
1Rate O.W.L sets up and observes the test, SOVA Engine attacks and judges, and TAFAAR grades. The client receives the score, the Financial Risk Report, the CISO Technical Report and the Evidence Pack in .sova.
2Fix The client fixes; TRUSCOR never does.
3Retest O.W.L replays each finding exactly. The Retest Report shows which findings no longer reproduce.
4Record SOVA Black Box records the system in production. Continuous Rating watches for drift and silent model changes.
5Re-rate on change When the system’s behavioural fingerprint changes, the rating is flagged “retest due”.
6Investigate If something goes wrong, Black Box’s sealed record and O.W.L’s replay establish what happened and whose fault it was.
7Learn With consent, de-identified results join the corpus, which calibrates TAFAAR and feeds the data products.
01The testing engine

SOVA Engine

SOVA Engine is how TRUSCOR finds out how an AI system really behaves. It pentests the system, runs live UI tests and stress tests to crack the agent or product, judges the results, and records every relevant fact as .sova evidence. It is closed source and proprietary. SOVA OSS is its open, earlier sibling, while the Engine carries TRUSCOR’s private attack intelligence, corpus-tuned test generation and per-client specialisation.

Available Runs the full pipeline end to end against live systems, across browsers, desktop apps and terminals through O.W.L.
Fig. 04Five phases, one test scope
Read the full specification
Five phases
Map Works out what the system can actually touch: agents, tools, MCP servers, permissions, data, egress.
Compose Builds attack chains.
Detonate Live adversarial execution against the real system, under written authorisation.
Observe Reproducible traces and state capture, through O.W.L.
Quantify Scored evidence that feeds TAFAAR.
Standard test scope
Access Identity and authentication, authorisation and least privilege, tool-use boundaries.
Manipulation Prompt injection, instruction hierarchy, memory poisoning and persistence.
Data Sensitive-data exposure, supply chain (MCP servers, plugins, tools).
Consequential actions Approvals, irreversible and financial actions, external communications.
Execution surfaces Filesystem and shell, browser actions, agent-to-agent interactions.
Operations Policy adherence, error recovery, traceability, monitoring.
Frontier New failure classes, logged to the corpus.
New capabilities
Oversight drills Available
Pull the kill switch inside an O.W.L test environment and measure time to halt, whether sub-agents and in-flight tool calls stop, and what state is left behind. Seed known errors into human review queues and measure how often reviewers catch and override them. Why it is needed · RBI’s draft, SEBI’s coming AI rules, Colorado (from 1 Jan 2027) and the EU AI Act all demand working human oversight and kill switches.
Secret, regenerated tests Available
Generate test tasks inside O.W.L environments, rotate test sets, plant canaries in answer keys, and add a contamination statement to every report. Why it is needed · Agents and vendors game tests, and test prompts can leak into vendor logs. It protects every score.
Claim re-verification Available
Re-run a sample of the evaluations a vendor claims, in environments that check effects, for investors, acquirers and directors’ insurers. Why it is needed · Due diligence still relies on vendor-supplied numbers.
Guardrail and AARM effect tests Available
Test guardrail and agent-security products: detection and false-alarm rates on OWASP’s ten agentic risk classes, plus O.W.L checks that each “blocked” action had no effect and each signed receipt matches what changed. Why it is needed · Runtime vendors quote their own block rates, and AARM conformance does not require an independent effect test.
Tool and skill behavioural ratings Available
Run MCP servers, skills and plugins inside instrumented environments, drive them with agents, compare what they claim with what they do, and retest on every version. A second measure rates how easily an agent can be steered toward a malicious tool. Why it is needed · Malicious skills are appearing on public marketplaces, and instruction-only attacks slip past scanners.
Mandate-fidelity tests for buying agents Available
In O.W.L test storefronts, measure how accurately a shopping or payment agent turns an instruction into a cart, whether it respects spending limits, and whether it resists injected offers. Why it is needed · Agent payment rails are live, and no network rule says who pays when an agent misreads.
Production-calibrated fault injection Available
Inject tool failures into tests at the rates SOVA Black Box sees in production. Why it is needed · Tool calls fail less often in tests than in real use.
Sector test batteries Coming soon
Child-safety audits for companion chatbots, AI-labelling conformance, India’s TEC 57050 fairness standard, a security “crash test” of AI app builders, healthcare-pilot outcomes, autonomy-readiness exams before an agent gets more permissions, and a collusion-propensity index for pricing agents. Why it is needed · Mandates arrive 2027–2029; labelling rules already bind in India, China and the EU.
Who uses it and how
Developers and AI startups They never touch the Engine directly. They receive a rating with reproducible findings and a clear statement of what a fix must achieve, use it to unblock enterprise and bank deals, and retest after fixing.
AI experts and security teams They use the CISO Technical Report and the .sova Evidence Pack to reproduce every finding on their own systems. Through SOVA OSS they run the open engine themselves.
Enterprises They commission ratings before giving an agent write access, rate the AI vendors they buy, and run oversight drills to show regulators their controls work.
Pentest firms, Big 4, MSSPs, AI security vendors They license the Engine to test AI systems under their own brand. With the standard licence TRUSCOR issues the score; with white-label they issue their own reports and no TRUSCOR score.
Investors and insurers They commission portfolio ratings and claim re-verification on companies they fund or cover.
What it never does —It never fixes what it finds.—It never issues a pass/fail certificate or a “verified” badge.—It never tests without written authorisation.—It never publishes a named result without consent.
How it is bought Ratings from ₹35,000 per orchestration; Deal-Ready, Portfolio Assurance and Production Assurance packages; the SOVA Engine Licence from ₹1,50,000 a month with 10 TRUSCOR scores included. See pricing →
02The risk-grading engine

TAFAAR

TAFAAR turns SOVA’s evidence into the numbers people act on. It is never licensed and never open-sourced: it is a trade secret, and its value is the corpus it is calibrated on.

Available Grades every TRUSCOR Rating under the published method. Its calibration deepens as the corpus adds observed losses.
Fig. 05Five inputs, three outputs
Read the full specification
Three outputs
TRUSCOR Rating (TRS) 300–900, the same scale as CIBIL, so an Indian credit committee reads it before opening the report. Versioned and dated.
Estimated Financial Exposure What the findings could cost, in rupees or dollars, that a board or underwriter can act on.
The risk map How far the system’s risk reaches across OWASP Top 10 for Agentic Applications, MITRE ATLAS, NIST AI RMF, ISO/IEC 42001, the EU AI Act, CERT-In, DPDP, RBI and SEBI, mapped without claiming certification.
Five inputs
1 · Behaviour testing The core. Nothing replaces it.
2 · Supply chain and data exposure The tools, servers and data the system depends on.
3 · Existing certifications SOC 2, ISO 27001/42001, AIUC-1 and pentests, verified for validity and scope. A certificate can never offset a behaviour finding.
4 · Operational figures The client’s own figures.
5 · Comparable incidents From the corpus.
New capabilities
Self-expiring ratings Available
Every grade is bound to a behavioural fingerprint of the whole system: model, prompt, retrieval and tools. When the fingerprint changes significantly, the grade flips to “stale, retest due”, like a credit watch. Fingerprints come from cheap probes and passively from Black Box recordings, which a vendor cannot route around. Why it is needed · Outsiders can rarely verify which model a provider serves. RBI and US insurance regulators both ask for change detection.
Statistical grading protocol Available
Fix tasks, trials and configuration in advance. Report grade bands and ties rather than false precision. Treat the scaffold and configuration as part of the rated object. Publish a measurement-error budget with each grade. Why it is needed · Small leaderboard gaps are often noise, and scaffolds can move the same model by many points.
Test-vs-production gap Available
A per-behaviour measure of how well a system’s tested behaviour predicts its live behaviour, from SOVA Engine results and Black Box recordings of the same system. Why it is needed · Frontier models increasingly recognise tests. Only a party holding both test and production data can measure the gap; Indian-language deployments are a known blind spot.
Verifiable scoring Available
Run the judges inside an attested secure enclave and commit hashes of tests and transcripts in each .sova file. The rated party or a regulator can then recompute the grade from the evidence without seeing the secret test items. Why it is needed · It answers the “the company being rated pays” critique with arithmetic anyone can check.
Reconstructability measure Available
Rates how completely an incident could be rebuilt from the records a system keeps, whatever logging tool produced them. Why it is needed · If the causal chain cannot be rebuilt, the risk stays with the organisation, and underwriters can price that.
Who uses it and how
Developers and startups They see where they stand on the 300–900 scale and what moves it.
Enterprises and banks They read the Estimated Financial Exposure and the regulatory risk map in vendor and internal ratings.
Investors They compare portfolio companies on one scale.
Insurers and brokers They use exposure estimates and, later, failure rates for underwriting, through data products under fixed-fee terms.
What it never does —It is never licensed.—It is never open-sourced.—Even under an Engine licence, the score is always issued by TRUSCOR.—A certificate never offsets a behaviour finding.
How it is bought Through ratings and retests, Continuous Rating at ₹8,000 a month, drift-triggered retests and insurer data products. See pricing →
03The 24x7 recorder

SOVA Black Box

SOVA Black Box runs inside the client’s own cloud, VPC or on-premises and records every action an AI system takes. Its purpose is accountability: when something fails, it points to the exact step, the cause and the party responsible, with evidence designed to stand up in court. It was built from TRUSCOR’s earlier execution-and-recording code with the control and approval functions removed. The client controls retention and keys.

Available Runs in your own cloud, VPC or on-premises, with signing, effect checks, custody and court-ready exports. You control retention and keys.
Fig. 06A black box, not a log
Read the full specification
What it records
Actions Tool calls; browser and terminal actions; file and database writes.
Effects External messages, approvals and state changes; errors and outputs.
A black box, not a log
Signed and sequenced Each event is signed and sequenced.
Returned against happened The record separates “the action returned” from “the intended effect actually happened”.
Gaps on the record Dropped events and sensor gaps are recorded rather than hidden.
Stated limits The trace states what it could not see.
New capabilities
Effect-verified recording Available
Read-only O.W.L sensors check each recorded action against the real state of files, processes, network, browser, screen and databases, and mark it verified, failed or unknown. Why it is needed · Agents claim success they did not achieve, and observability tools record only what the agent reported.
Neutral evidence custody and escrow Available
Records are hash-chained from creation, gaps are detected to prove completeness, timestamps are independently anchored, and keys and procedures are ones TRUSCOR can testify about. Escrow terms are fixed in advance and identical for every client. Why it is needed · AI litigation turns on whether records are complete and held by the right party, including under the EU Product Liability Directive from 9 Dec 2026.
Court-ready exports Available
Exports fill the fields of India’s electronic-evidence certificate (BSA s.63: hash, algorithm, Part A custodian, Part B expert) and the US FRE 902(13)/(14) certifications. Retention can satisfy the EU’s 6 months, CERT-In’s 180 days, DPDP’s 1 year and Colorado’s 3 years together. Why it is needed · On 22 May 2026 India’s Supreme Court ruled that a proven private cyber-forensics expert may sign Part B, not only the notified government labs.
Discovery-and-cure ledger Available
Timestamps when TRUSCOR’s testing found a problem, and records an independent retest showing the fix held. Why it is needed · Texas TRAIGA protects companies that find violations through red-team testing and fix them within 60 days; Colorado and EU penalty regimes reward documented cures.
Fault-finding by replay Available
Replays a frozen incident in O.W.L, changing one factor at a time (the injected email, the over-scoped token, the model version) over many samples. It reports how much each factor changed the outcome, with a confidence interval, signed in .sova: the “but-for” test courts and insurers use for causation. Why it is needed · Fault can sit with up to six parties, and insurance exclusions trigger on any “connection to AI”.
Evidence freezer Available
One action captures the full incident state (prompts, retrieved context, model version or fingerprint, memory, tool calls, credentials, approvals and downstream actions), sealed in .sova under TRUSCOR’s countersignature and replayable in O.W.L. Why it is needed · EU AI Act Art. 73(6) forbids altering a system before reporting a serious incident, while agentic systems change constantly.
Agent payment dispute evidence Available
Records prompt, interpretation, mandate and cart for every agent purchase, and produces attribution reports and per-agent error rates for chargeback disputes. Why it is needed · No card-network rule assigns liability for agent misreads, and India’s UPI agent protocol is waiting for auditable rules.
Canaries and memory records Available
Decoy credentials, decoy documents, tools nobody should call and planted memories; any touch is recorded as attributed evidence. Hash-chained memory diffs trace an incident to the memory write that caused it. Detect and record only, never block. Why it is needed · CERT-In’s 15 Oct 2026 advisory says no Indian victim detected the AI agents inside its systems.
Robot event recorder Coming soon
SOVA Black Box for AI-driven machines. Why it is needed · The EU Machinery Regulation covers AI safety functions from 20 Jan 2027.
Who uses it and how
Developers They install it beside their agent to see exactly what the agent did and where it went wrong. The open sova trace in SOVA OSS is the free starting point.
Enterprises They run it on production agents to meet logging duties (EU Art. 12, CERT-In, DPDP, Colorado), to support Continuous Rating, and to have evidence ready for an incident, dispute or regulator question.
Legal teams and courts They receive sealed, verifiable exports and a TRUSCOR expert who can explain them.
Insurers and claims teams They commission forensics to establish whether AI caused a loss and whether submitted logs are authentic.
Merchants, payment providers and banks They use agent-purchase records in chargeback disputes.
Security vendors and agent platforms They embed Black Box recording in their own products (OEM).
What it never does —It never blocks, approves, rewrites or rolls back actions.—A TRUSCOR rating never requires Black Box and never scores higher because of it.—It never wires its alerts into anyone’s kill switch.—Canaries never reach real users or third parties.
How it is bought ₹12,000 a month plus ₹25,000 setup; Enterprise ₹1.5 lakh a month from Month 12. Incident forensics at fixed or hourly fees, never contingent on outcome. Evidence escrow at a fixed annual fee. See pricing →
04The evidence standard

.sova format

.sova records what the AI was shown (prompts, pages, documents, tool outputs), what it did, and what changed in the world, linked by causal parents. The cause is then established by replay: re-running the moment with one factor removed. It does not rely on the model’s own explanation of itself, because reasoning traces are not reliable evidence of why a model acted.

Available .sova-trace 0.1 is specified and implemented in SOVA OSS. The .sova v1.0 preprint was published in August 2026 (CC BY 4.0, not peer-reviewed).
Fig. 07Capsule, trace and verifiers
Read the full specification
Two parts
A .sova capsule Binds a declared behaviour, a context envelope, evidence requirements, and trials and limitations. Opening it never authorises execution. A portable, re-runnable AI exploit or test: what the CVE identifier did for traditional security, applied to agents.
A .sova-trace A canonical stream of observable events and evidence that keeps identity, actor, sequence, causal parents, redaction state and integrity linkage.
Integrity
Canonical JSON No floating-point ambiguity.
Hash chain A per-event SHA-256 hash chain.
Signed manifest DSSE and in-toto, Ed25519.
Independent verifiers In Python and Node, agreeing on every digest.
Completeness, kept apart
Six separate facts Package continuity, event-chain continuity, recorder drops, sensor coverage, source completeness, and whether the evidence is enough for a named claim.
New capabilities
Claimed and observed layers Available
Ingests AARM receipts, IETF agent-action-receipt drafts and OpenTelemetry AI spans as the claimed layer, and adds the observed layer: what O.W.L and Black Box saw actually change. Why it is needed · As receipt standards spread, every receipt becomes a claim someone neutral can check.
Court-evidence profile Available
Carries the fields India’s BSA s.63 certificate and US FRE 902(13)/(14) need, natively.
Containment profile Available
Records that a test run had outbound network blocked by default, scoped credentials, and touched only sandbox state.
Incident profile Available
A measurement-only incident record mapped to the EU Art. 73 template, California SB 53 and the OECD’s 29-criterion incident framework, released through SOVA OSS so it can become the common format.
ISO/IEC 24970 mapping Available
Aligns the trace with the international AI logging standard, now at final draft.
Who uses it and how
Developers They record their own agents with sova trace, verify traces offline, and share redacted traces with teammates or vendors.
Security researchers They publish an exploit as a .sova file anyone can re-run, with a reproduction rate (for example “reproduced 8/10”) that separates structural flaws from flukes.
Enterprises They keep evidence archives in one format that every tool and auditor reads.
Auditors, insurers, regulators and courts They verify a record offline with a public verifier, without trusting whoever handed it over.
Tool vendors They make their products emit .sova and prove it with the Format Conformance Test.
What it never does —Opening a capsule never authorises execution.—It never relies on a model’s explanation of itself.—The format, spec and reference verifiers stay free.
How it is bought The format, spec and reference verifiers are free. The Format Conformance Test and the SOVA SDK commercial licence are priced on request. See pricing →
05The measurement instrument

O.W.L

O.W.L is TRUSCOR’s hands and eyes on real computers: the instrument SOVA tests with and Black Box sees with. It works on Mac, Windows, Linux and Raspberry Pi, across desktop apps, browsers and terminals. It never acts for a client’s AI. It acts as the examiner.

Available Operates and observes browsers, desktop apps and terminals on macOS, Windows, Linux and Raspberry Pi. Every run writes a signed .sova-trace that SOVA’s own verifier accepts.
Fig. 08Four jobs inside a contained run
Read the full specification
Four jobs
Operate Drives any desktop app, browser or terminal the way a user or attacker would, to run SOVA’s UI tests, stress tests and attacks. It sets the stage: plants bait (a poisoned email, a malicious web page, a fake invoice), creates test accounts, stands up test storefronts and resets machines between runs.
Observe Reads what really happened through channels the AI under test doesn’t control: files, processes and network calls; browser state, the screen and the accessibility tree; database rows and inboxes. That produces “it claimed X, it actually did Y”. It writes down the expected result before each action, grades each piece of evidence and reports what it could not see.
Record Everything is written to signed .sova evidence: facts only, never a verdict.
Replay Re-runs any finding exactly, with no AI model in the loop, for the Retest Report: “We find. The client fixes. We retest.”
Containment proof comes first
Signed containment record Before O.W.L touches any live-connected system, every run produces a record: outbound network blocked by default, scoped credentials, and only sandbox state touched. TRUSCOR attests the containment; it does not sell sandboxes.
Its own memory App layouts, test accounts in a secure vault and long test campaigns, so retests are fast and identical. This memory serves the instrument; it is never sold as agent memory.
What O.W.L makes possible
Basic open O.W.L Available
A basic version in SOVA OSS sets up arena environments and referees what each agent actually did.
Read-only effect checks Available
Its sensors check SOVA Black Box recordings against real state in production. The “operate” part never runs there.
The claim-versus-effect check Available
Seven new capabilities depend on it: effect-verified recording, fault-finding by replay, agent payment evidence, secret regenerated tests and claim re-verification, oversight drills, guardrail and AARM effect tests, and tool and skill ratings. That makes the instrument TRUSCOR’s core technology.
Who uses it and how
SOVA Engine It operates and observes every live test across desktop, browser and terminal.
SOVA Black Box Its read-only sensors check effects in production.
SOVA OSS A basic open version sets up the arena and referees matches.
Pentest firms, QA companies, Big 4, MSSPs, auditors, insurers’ risk engineers They license it to test AI systems for their clients, alongside the SOVA Engine.
AI agent companies They may license it only to test their own agents, the same way they use SOVA OSS. Never as their agent’s hands.
What it never does —It never runs as a client’s AI’s hands in production.—It never blocks, approves, undoes or fixes anything.—It never gives pass/fail or a score: SOVA judges, TAFAAR grades.—It never makes anyone’s score better.—It never appears as a contestant in any ranking TRUSCOR runs.
How it is bought Included in the SOVA Engine Licence, and as a standalone instrument licence for measuring firms at a fixed fee. Licensees get no rating advantage. See pricing →
06The open-source toolkit

SOVA OSS

A free, open-source security platform for AI agents and the system of record for agent security. It maps every agent, MCP server, skill, tool, permission and egress path you actually have, attacks them, records everything as a signed .sova-trace, reconstructs what happened, packages any attack as a portable .sova file, and watches continuously. Adoption is its only metric, so nothing in it protects a sale.

Available About 60,000 lines of Python. All the verbs, the arena, the registry and forensics are in the release, with live execution through O.W.L.
Everything in SOVA OSS
Fig. 09Seven verbs, one signed record
Read the full specification
Seven verbs
Record sova trace
Discover sova map
Test sova check · detonate · compose · arena · rehearse
Explain sova forensics
Prove sova evidence · verify · replay
Watch sova sentinel · diff
Share sova registry · adjudicate · disclose
New capabilities
Basic open O.W.L Available
A basic version of the instrument that sets up arena environments and referees what each agent actually did.
“CVE for tool behaviour” Available
Registry entries for tool and skill behaviour, fed by behavioural tool testing.
Open incident profile Available
The .sova incident profile published for anyone to adopt.
Who uses it and how
Developers npx sova check on a component before installing it, sova trace on their agent, and sova rehearse before letting an agent loose on real work.
AI experts and security researchers They write and share .sova exploits, hunt sleeper components, run arena matches, and extend the engine with their own attackers and judges.
Students CTF mode.
Enterprises They run it internally as a free first line of evidence, then come to TRUSCOR when someone else must rely on the result.
What it never does —Its results are self-assessments, never an independent attestation.—TRUSCOR never rates SOVA OSS, and never ranks its own products.—No user ever has to depend on TRUSCOR’s servers.
How it is bought Free under Apache-2.0. A metered hosted tier for heavy test generation is possible, always alongside a fully local option. See pricing →
07Data on how AI fails

The TRUSCOR corpus

The corpus is TRUSCOR’s long-term moat: a de-identified, consented record of what AI systems actually did, how they failed and, over time, what it cost. A rating can be copied in a quarter. A failure corpus started years earlier cannot.

Being built Being built. With consent, de-identified results from every rating and recording join the corpus, which calibrates TAFAAR and feeds the data products.
Fig. 10From consented records to data products
Read the full specification
Rules
Quiet, never covert Telemetry only where a client permits it.
De-identified and aggregated One client’s findings never leave that client.
Equal terms Contributors get access on equal terms. Insurer contributions flow under data-sharing terms, never commission.
Products built on it
SOVA Threat Intelligence Feed Being built
De-identified failure patterns for security teams and licensees. Why it is needed · Attack techniques change weekly.
India AI Incident Index Being built
A structured record of AI incidents in India. Why it is needed · India has no confirmed national AI incident database.
Failure rates with denominators Being built
Published failure rates per 1,000 consequential actions, by agent class, version and autonomy level, from consented Black Box and SOVA data. The format is ready now. Why it is needed · Incident databases count incidents, not rates, and insurers are excluding AI risk instead of pricing it.
Dependency map Being built
Shows which AI systems really depend on which models and frameworks, observed from fingerprints and aggregated: the “model-exposure schedule” reinsurers need. Why it is needed · Reinsurers call concentration on a few foundation models the AI risk they can least price.
AI system history report Being built
A consented timeline per system covering detected model swaps, score history, retests, incidents and ownership changes, plus a machine-readable score reference an agent can carry in its identity credentials. Why it is needed · Agent identity is crowded, but nobody holds behaviour history.
AI event designation Being built
After an upstream model change or failure, retests a consented panel and publishes the event’s footprint, so reinsurance contracts can define an “AI event”. Why it is needed · An AI event would be harder to size than a large IT outage.
Who uses it and how
Insurers, reinsurers and brokers Failure rates, the dependency map and exposure estimates: evidence they can price.
Regulators and bank risk teams Rates rather than anecdotes.
Security teams and licensees The Threat Intelligence Feed.
What it never does —Named data never leaves without consent.—One client’s findings never leave that client.—No commission from any contributor.
How it is bought Data licences and subscriptions to insurers, reinsurers, catastrophe modellers, regulators and bank risk teams, at fixed fees. Priced on request. See pricing →
The rules every technology follows

The rules are the moat.

They go into the articles of association, not just the website. Credit bureaus exist because competing lenders share default data only with a party that lends to no one. TRUSCOR is that party for AI.

TRUSCOR sells TRUSCOR never sells
The score and the reports AI agents, applications or frameworks
Retesting Remediation of its own findings
Verification of certifications Certifications (until a TRUSCOR standard exists with its own governance)
SOVA Black Box recording and forensics Guardrails, policy enforcement or runtime blocking
Data on how AI systems fail Insurance cover or risk on its balance sheet
Licences of its measurement technology Commission from anyone it rates or refers
The four neutrality rules 1No product in any category TRUSCOR rates.2No referral economics.3No certification today.4No insurance on the balance sheet.
The licensing rules —Fixed fees and per-unit royalties only, never a share of a partner’s sales to a client TRUSCOR rates.—Systems built with SOVA technology score exactly like any other.—Licensees may say “Powered by SOVA” but never claim a TRUSCOR score or endorsement.—Any rating of a licensee’s own product discloses the licence.
For every feature —Every feature measures, tests, records, attributes, rates or supplies data. None of them blocks, approves, fixes, certifies or insures.—TRUSCOR measures controls and never operates them. It tests whether a kill switch works but never supplies or pulls one.—TRUSCOR’s own products are never contestants in its rankings, and O.W.L and SOVA OSS are never rated by TRUSCOR.—No score is published without consent, and a rating never requires a TRUSCOR product.
Vision

TRUSCOR is the score. SOVA is the record.

Every damaging technology eventually needed three things: a rating, a record and a price. TRUSCOR builds the first two now. The third, pricing, comes from the corpus.

By 2030, these should be normal
Neutral evidence for every consequential AI actionIt separates what was claimed from what happened, and anyone can verify it without trusting the party that produced it.
Ratings that stay currentA rating expires when the system silently changes, shows its arithmetic, and resists being gamed.
Failures become dataRates rather than anecdotes, priced by insurers rather than excluded.
Controls measured, not assumedKill switches, human reviewers and guardrails, tested by someone who sells none of them.

Rate it. Record it.

Five fields and a short call. We reply within one working day.