Aarvi AI · Models
Four models, one job each.
Aarvi AI runs its own models for the decisions that need judgement. Retrieval, deduplication, scheduling and delivery stay deterministic, because a model should not be asked to do arithmetic.
| Model | Params | Role | Status |
|---|---|---|---|
| Sentinel V2 | 35B | Log analysis. Reads normalised device and service telemetry and names the behaviour it thinks it sees. | Planned |
| Laya DCO | — | Decision orchestration. Decides whether an observation becomes an alert, stays correlated, or is dropped. | Planned |
| Nano V2.1 | — | Intelligence summaries, alert context and report synthesis. The model writing every report section. | Built |
| Nano V1.2 | ~2B | Query expansion. Turns one analyst phrase into the variants a dark web search actually needs. | Built |
Method
How a model earns a place in the pipeline.
Every model in the table replaced something. If a rule or a retrieval query does the job, the rule keeps the job.
How we test
Each model is evaluated on held-out collection from the same sources it serves, scored against analyst-labelled decisions rather than against itself.
What we publish
Model version, the task it is assigned to, and whether it is built. Numbers that have not been measured are left off the page instead of estimated.
What we will not claim
A built model is not a deployed feature. A deployed feature is not a measured improvement. The status column keeps those apart.
In the product
These models are not a feature list. They are the reason an alert arrives with an explanation and a report arrives with citations.
See where they sit in Aarvi IntelligenceAccess
Ask us to show the reasoning, not the benchmark.
We would rather walk you through one real investigation than hand over a scorecard you cannot verify.