AutoSifu

VERDICT · AI TARA ENGINE

Same item.Same numbers.Every run.

Verdict turns a component description into an ISO/SAE 21434 threat analysis and a UN R155 Annex 5 evidence pack — drafted by a model that runs on your own hardware, with risk and CAL computed from fixed matrices instead of generated.

Request a walkthroughHow the determination works
DETERMINATION · TS-021Computed

Attack feasibility · §15.7

Elapsed time
≤ 1 month
4
Expertise
Proficient
3
Item knowledge
Restricted
3
Window
Easy
0
Equipment
Standard
0

Σ 10High

Impact · damage scenario

S3
F2
O3
P1

max 3Major

Risk value4
Assurance levelCAL 3

No model output in this panel — every value is a table lookup

  • ISO/SAE 21434
  • UN R155
  • UN R156
  • AIS-189
  • AIS-190
  • EU CRA

01 — The clock

The analysis stopped being optional.

Three regimes, three dates, one consequence: an approval file now has to carry a defensible threat analysis. None of these dates is arguable.

UN R155 / R156

In force

Applied to new vehicle types from 6 July 2022 and to all new vehicles produced from 7 July 2024, through GSR (EU) 2019/2144.

AIS-189 / AIS-190

Draft, phased from Oct 2026

MoRTH draft G.S.R. 503(E) of 17 June 2026 inserts CMVR Rules 125-T and 125-U — Level-3+ new models from 1 October 2026, reaching all software-update-capable vehicles by 1 October 2029. Not yet final. The running status →

EU CRA

11 Sep 2026

Reporting obligations under Regulation (EU) 2024/2847 begin, with the main body of obligations from 11 December 2027.

02 — The wedge

Speed was never the assessor's question.

Every tool in this market now claims the same thing: a TARA, 70 to 90 per cent faster. Take the claim at face value and it still leaves the question an assessor actually asks unanswered — run this twice, do you get the same determination, and can you show me why?

Generative models drift. Same component, different run, different risk value. An analysis whose assurance level moves with a sampling temperature is not evidence, and the engineer reviewing it cannot tell which half to trust.

Verdict splits the problem in two. The narrative — the threat scenarios, the reasoning, the wording an engineer would have written — is drafted by the model and reviewed by a human. The determination — feasibility, risk, CAL — is arithmetic over fixed matrices, and the model has no vote in it.

03 — The run

Five steps, and you can audit each one.

A worked example: a connected telematics unit with cellular, GNSS, an OTA client and a CAN gateway.

1.0

Describe the component once.

Interfaces, connectivity, update path, the boundary of the item under analysis. Verdict reads what you already wrote — it does not infer a network you never mentioned.

ITEM · TCU-014Boundary set
Cellular
LTE Cat-4 · carrier APN
GNSS
receive only
OTA client
signed bundles
CAN gateway
2 × CAN-FD
USB-C
service port, disabled in field

5 interfaces · 1 item boundary · read from your description

2.0

Every Annex 5 category, decided and recorded.

The seven UN R155 Annex 5 categories are screened against the item, each decision written down with its reason. A category ruled out is as much a work product as one ruled in.

ANNEX 5 · SCREENING7 of 7 screened
  • Back-end servers6
  • Communication channels11
  • Update procedures5
  • Unintended human actions2
  • External connectivity8
  • Vehicle data and code4
  • Un-hardened vulnerabilities3

Every decision recorded with its reason — including the ones ruled out

3.0

Threat scenarios, with the evidence attached.

The model drafts each scenario against retrieved evidence — the regulatory catalogue, the domain corpus, a local threat-intelligence mirror — and every claim carries the source it came from.

SCENARIO · TS-021Drafted · unreviewed

Spoofing · communication channels

An attacker with access to the vehicle bus injects forged status frames on the CAN gateway interface, causing the telematics unit to report and forward fabricated vehicle state to the back end.

UN R155 Annex 5ISO/SAE 21434 §15.6corpus · 3 passages

Every claim carries the source it was drafted from

4.0

Feasibility, risk and CAL from fixed matrices.

Attack feasibility over the ISO/SAE 21434 §15.7 factors, impact from your S/F/O/P ratings, risk from the matrix, CAL from the rules. Arithmetic — reproducible, inspectable, and identical on the next run.

DETERMINATION · TS-021Computed

Attack feasibility · §15.7

Elapsed time
≤ 1 month
4
Expertise
Proficient
3
Item knowledge
Restricted
3
Window
Easy
0
Equipment
Standard
0

Σ 10High

Impact · damage scenario

S3
F2
O3
P1

max 3Major

Risk value4
Assurance levelCAL 3

No model output in this panel — every value is a table lookup

5.0

The pack an assessor opens.

Threats, determinations, clause mapping and an attestation block carrying the tool version, the model and adapter identifiers, and the corpus snapshot the analysis ran against.

EVIDENCE PACK · TCU-014Ready for review
Item definition
1
Threat scenarios
39
Feasibility ratings
39
Risk determinations
39
Cybersecurity goals
12

Attestation

Toolverdict · build recorded

Modelfine-tune rev · adapters pinned

Corpussnapshot 2026-08-01

Reviewer— awaiting signature

04 — The mechanism

The determination is arithmetic.

One sentence no competitor in this market can sign, and the reason it holds.

A language model is used where language is the work: reading the item, drafting scenarios, writing justifications an engineer can edit. It is kept out of the place where a number decides an outcome.

Feasibility factors resolve through the §15.7 table. Impact comes from the damage ratings you set. Risk is a lookup in a 4×4 matrix. CAL follows published rules. Change nothing about the item and every one of those values is identical on the next run — not because the model was consistent, but because no model was involved.

Where the model stopsA left-to-right flow in four stages: item definition, threat narrative, determination, evidence pack. The threat narrative stage sits inside a dashed enclosure labelled model, language — the part a language model drafts and an engineer edits. The determination stage sits inside a solid enclosure labelled fixed matrices, arithmetic — attack feasibility, risk value and cybersecurity assurance level, each resolved by table lookup with no model involvement. The final stage, the evidence pack, is signed by a qualified engineer.MODEL · LANGUAGEFIXED MATRICES · ARITHMETICITEM DEFINITIONwhat you wroteTHREAT NARRATIVEdrafted, citedDETERMINATIONfeasibility · risk · CALEVIDENCE PACKsigned by an engineer
FIG. 05 — WHERE THE MODEL STOPS · REF. ISO/SAE 21434 §15.7–15.8

Two engineers running the same component get the same numbers. The narrative is drafted and reviewed; the determination is computed.

05 — The agents

Two agents. One model. Neither of them votes.

Verdict is not one prompt doing everything. It is two specialised agents sharing an owned model, a governed corpus and a single boundary — one that produces the file, one that answers for it.

AGENT 01

The TARA agent

Produces the analysis

Runs the assessment end to end: reads the item definition, screens every UN R155 Annex 5 category, drafts each threat scenario against retrieved evidence, and hands the ratings to the matrices. It works to a fixed procedure rather than a conversation — the same item enters the same steps in the same order every time, which is what makes one engineer's register comparable to another's, and this quarter's comparable to last year's.

Specialised on

  • ISO/SAE 21434 clause structure and the shape of its work products
  • UN R155 Annex 5 — the threat categories and their listed mitigations
  • UN R156 and the software-update lifecycle
  • AIS-189 and AIS-190 as written, not as a translation of the UN text
  • Automotive architecture — bus topologies, gateways, telematics, OTA and diagnostic paths

What it cannot do

Decide a number. Feasibility, risk and CAL leave the agent and go to the matrices; whatever comes back is what the evidence pack records. There is no prompt that changes a determination.

AGENT 02

The cybersecurity consultant

Answers the question behind it

The agent an engineer actually talks to. Ask why a scenario scored the way it did, what §15.7 means by window of opportunity, whether adding a diagnostic interface changes the screening, or what AIS-190 asks for that R156 does not. It answers against the same corpus the analysis was drafted from and returns the passage with the answer — so a reviewer can check it rather than believe it.

Specialised on

  • The same standards corpus the analysis is drafted against
  • The reasoning behind a determination — which factor moved a band, and why
  • India's approval route: CMVR, the AIS series and where they diverge from UNECE
  • The questions an assessor asks, and the form of answer that satisfies them

What it cannot do

Edit the analysis. It reads the register; it has no write path to it. A determination changes by editing the item or the damage ratings and re-running — never by persuading the assistant.

Both agents run on the same owned model inside your network, and they share the host — so the consultant is scheduled against the assessment rather than quietly competing with it. Same boundary, same corpus snapshot, same attribution in the record.

06 — Deployment

The assessment runs on your hardware.

For most programmes this is the first question, not the last. It has an architectural answer, not a policy one.

Local inference

The model runs on a GPU inside your network. Assessment work does not call out to a third-party API, because there is no third-party model in the path.

An owned model

A fine-tuned model with automotive-cybersecurity adapters, trained and versioned by AutoSifu — not an orchestration layer over someone else's endpoint, and not subject to their retention policy.

Your corpus, your snapshot

Retrieval runs against a corpus you hold, pinned to a snapshot ID that is recorded in the evidence pack — so an analysis can be reproduced months later against exactly what it saw.

A boundary you can put in a diagram

Every outbound path is named at deployment and off unless you switch it on, so the answer to your security team is a network diagram rather than a paragraph in a contract. That is the difference between an architectural guarantee and a data-governance policy.

07 — Coverage

Including the two standards nobody else lists.

Every global tool covers R155 and 21434. AIS-189 and AIS-190 decide whether a vehicle is approved in India — and Verdict treats them as first-class, not a localisation.

08 — Built for

Three people, three reasons.

OEM homologation manager

The analysis goes into a submission you sign. You need it complete against Annex 5, consistent across suppliers, and defensible when the assessor asks how a number was reached.

Tier-1 product security

Every programme restarts the spreadsheet from a copy of the last one. You need the mechanical work done the same way twice, and your engineers spending their hours on the judgment, not the formatting.

Tier-2 supplier

You have been asked for a 21434 TARA for the first time and handed a template that explains nothing. You need a defensible first analysis without hiring a team to produce it.

09 — In practice

Where Verdict earns its place.

Four moments in a programme where the analysis is the thing standing between you and the next milestone.

The first analysis on a new item

Concept phase, no register exists, and the architecture is still moving. Verdict produces a complete first draft against the item you describe — every Annex 5 category screened, every scenario scored — so the engineer opens a populated register on day one and spends the week on scope and judgment instead of enumeration.

The re-analysis after an architecture change

An interface is added, an ECU merges into a domain controller, a supplier changes. Re-run the item and the register regenerates with the determinations recomputed. You review a delta — what appeared, what changed band, what fell away — instead of reworking a spreadsheet and hoping nothing was missed.

Supplier analyses that do not agree

Three suppliers deliver three registers in three formats with three risk philosophies, and comparing them is archaeology. Run each item through one method and the outputs become comparable — same factors, same matrix, same assurance rules — so a difference in the numbers means a difference in the vehicle.

The weeks before an assessment

The evidence pack assembles clause by clause with its citations and the attestation block attached, so the document handed to an assessor is the same shape every time. When a question comes back on one scenario, the factors and the sources behind that determination are one click away.

10 — What you get

Every run leaves the same artefacts.

Threat registerScenarios per Annex 5 category, each cited
DeterminationsFeasibility, risk value and CAL per scenario
Attack pathsEntry to target across the modelled architecture
Evidence packClause-mapped, with the attestation block
Machine-readable exportStructured, for your own tooling
Reproduction recordTool, model, adapter and corpus snapshot

11 — Questions

The ones that actually get asked.

What does it need to run?
A GPU host inside your network. Verdict is delivered as a self-hosted deployment, sized to the concurrency you need; we specify the hardware against your programme rather than publishing a number that would be wrong for half of readers.
What leaves our network?
Nothing for the assessment itself — the model, the corpus and your item definitions stay on your hardware. Optional components that would communicate outward are named at deployment and off by default.
Is the model really yours?
Yes. It is a fine-tuned model with automotive-cybersecurity adapters, versioned by AutoSifu, and its identifier is recorded in every evidence pack. That is what makes an analysis reproducible against a specific model state.
How is the risk value actually reached?
Attack feasibility resolves through the ISO/SAE 21434 §15.7 factor table, impact comes from the damage scenario ratings, risk is a lookup in a fixed matrix, and CAL follows published rules. Every step is inspectable and none of it is model output.
Does it replace our TARA engineer?
No, and a tool that claimed to would be the wrong tool. Verdict does the mechanical work — enumeration, scoring, formatting, evidence assembly — so the engineer spends their time on scope, judgment and the arguments an assessor will probe.
When does AIS-189 actually apply to us?
It depends on your vehicle category and whether the model is new or existing. MoRTH draft G.S.R. 503(E) proposes Level-3+ new models from 1 October 2026 through to all software-update-capable vehicles by 1 October 2029 — but it is a draft, not a final gazette notification. We keep the running status on the Insights timeline.

See Verdict run on your ECU.

Bring one component you already have a TARA for. We will run it through Verdict alongside your existing analysis and show you both — including wherever ours is weaker.

Request a walkthrough

09 — Start here

Bring us the file you are least sure about.

Most conversations start with a gap assessment, or a type approval submission that is closer than it feels. Either is a good place to begin.

Direct

Jaipur · registered office

Plot No. 8, ABS Plaza, Chanakya PuriJagatpura, Jaipur – 302017, RajasthanAUTOSIFU Pvt Ltd · India

Required