Skip to main content
This page describes how Vainona is designed to behave: what you can build around, and where the edges are. It is not a warranty or a service level agreement. The only commitments, remedies and limits of liability are those in your agreement with us. The tradeoffs page lists what the design gives up.

​
Answers are judgments, not facts

An answer is an engine’s judgment of your document, with a probability. It can be wrong, and the numbers on an engine’s page, measured on our conformance suite, may not match your data. Measure accuracy on your own documents with outcomes, and keep a person or a check in the loop wherever a wrong answer is costly.

​
Your data

  • Writes. A write is acknowledged only after it is committed to object storage.
  • Reads after a write. After a write is acknowledged, a strong query sees the new revision and its attributes. Eventual queries can lag; see tradeoffs.
  • Partial updates can be lost in one rare case. If a server fails or loses its connection unexpectedly, two servers can briefly handle the same namespace, for a few seconds at most. During that window, two patch or append writes to the same document from different clients can each apply to the same starting point, and the later one wins, dropping the other’s changes. No error is reported, and a later partial update that sets other fields does not restore them: the document stays wrong until its next upsert. Planned restarts and deploys hand over cleanly and are not affected, and upserts never are, because they replace the whole document. To rule it out, send whole documents, and to catch any drift, check both sides now and then (see keep your data in sync).
  • Training. We do not fine-tune the engines we host on your data unless you opt in.

​
Provenance

Every answer names its document revision, judgment version, engine version, and evaluation id. An answer reused because a change left its context the same keeps the id of the evaluation that computed it, which was for an earlier revision. An answer from a judgment that reads related documents also names its watermark, except a failed one, which keeps its last good numbers without it, and its evaluation lists every related document it read, with its revision.

​
Engines

  • Your judgment runs on the engine version you named until you change it. Jev current cannot be pinned: it runs whatever Jev serves now. We detect changes in its behaviour and record them rather than hide them, and each answer’s engine_version names the epoch of model behaviour that produced it. Other third-party engines are pinned as far as the vendor allows.
  • Versions do not change silently. We intend to keep the engine versions we host available. If a version becomes unavailable, requests fail with a named error (engine_version_unavailable) rather than moving to another version.
  • Which subprocessor sees your data depends on the engine you choose, and is written on that engine’s page.

​
When parts of the service are down

The data path is designed to keep working when sign-in, key management, billing or the dashboard is down: acknowledged writes stay durable, strong reads keep working, and existing judgments keep being evaluated. Creating or changing judgments may wait until those services recover.