Skip to main content
Vainona is a judgment layer for your data, next to the database you already have. You define what your software needs to know about every record: does this ticket need a human?, what is this message about?, how severe is this incident? We compute the answer when the record changes, keep it queryable, calibrate it as you report outcomes, and never charge you for a record that sits still. Answers come from decision models, not from calls to a general-purpose LLM. You get them without building or running the pipeline that usually goes with it: the queue, workers, retries, cache, schema, versioning, cron and evaluation. You keep documents in sync through one write API.

​
How it fits together

  • A namespace holds documents, usually one per tenant per environment.
  • A document has filterable attributes and a JSON state that judgments are made about.
  • A judgment is a typed question (bool, choice or score) attached to a namespace, pinned to one engine version.
  • An answer is the current result of a judgment for a document: a probability distribution with its freshness and provenance. Queries filter and sort on answers.
  • An evaluation is the immutable record of one computation. Every one is kept.
Start with the quickstart. Before you build on Vainona, read how it behaves and its tradeoffs.

​
When you need it, and when you don’t

The simplest version of this is a trigger in your own database that calls a model whenever a row changes. If you need one label per row, can live with an occasional wrong answer, and never need to explain one later, that is often enough, and you may not need Vainona. It stops being enough when:
  • You need to know how often an answer is wrong. A trigger stores whatever the model said. Here every answer is a probability, and from 100 labelled outcomes it is calibrated to your data, with an accuracy report per judgment version and thresholds chosen on your own labels.
  • The answer depends on more than one record. “Is this account at risk?” changes when any of its tickets changes. On row triggers that becomes fan-out code, and costs that grow with every related write. Here a judgment reads its related documents directly, and debounce, re-judge scope and confirmed estimates keep the cost in check.
  • The model changes underneath you. Hosted models change without notice, and a trigger’s answers shift silently. Here every answer records the engine version and the epoch of model behaviour that produced it. When a change is detected, quality is re-checked against the conformance suite.
  • You have to explain a decision later. Every computation is kept as an evaluation: the exact context the engine saw, the answer, and the versions that produced it.
  • Cost has to be predictable. A document whose relevant content did not change is not judged again, backfills show their cost before you confirm, and budgets cap spend per namespace.
  • You serve many tenants. Template judgments define a question once for every tenant’s namespace, with budgets per tenant.

​
What you pay for

Judging is priced by the tokens of context each answer reads, and a record that has not changed is not judged again. Beyond the answers, Vainona is the pipeline you no longer build and run, one API across engines, probabilities calibrated to your outcomes, and a versioned history of every answer. To compare it with what you run today, price your own traffic on the pricing page.