What Kirelta actually does

No item on this page is aspirational — everything here is running code you can test yourself, right now, with your own data.

From reading to record

What happens to a batch you send, in order. Each stage is a call you make or a record you can read back.

  1. 01

    Fit a baseline

    Send rows from a window when the model was healthy. Kirelta learns their shape and keeps a model of it, not your rows.

    POST /fit
  2. 02

    Assess a batch

    Send recent rows. Every row is held against the baseline, and the batch gets a flagged share and a typicality score.

    POST /assess
  3. 03

    Weigh the evidence

    Evidence of drift builds across the batch and is held against a calibrated alarm line, 20 by default, with a false-alarm rate bounded over the whole run.

  4. 04

    Give a verdict

    Trusted, degraded or untrusted with a recommended action, or no conclusion when the data cannot support one.

    • Trusted
    • Degraded
    • Untrusted
    • No conclusion
  5. 05

    A person decides

    Every verdict that is not trusted opens a decision. Someone on your team approves or overrides it, with a reason, in the decision journal.

    GET /decisions
  6. 06

    Keep the record

    The decision keeps its evidence sealed by hash and exports as a PDF; account and key actions are signed at checkpoints you can verify offline.

    GET /audit/export

The engine

A drift alarm with a bounded false-alarm rate

The alarm threshold carries a real, provable false-alarm bound over the whole run, however long you watch — not a tuned-until-it-looked-right one. The measured rates are published on the calibration page.

Three verdicts, and an honest abstention

UNTRUSTED
the drift alarm fired, or a large share of the batch was flagged.
DEGRADED
more of the batch is falling outside the trained range than a healthy stream should produce, but no alarm yet — the state most tools miss entirely.
TRUSTED
neither of the above.
INSUFFICIENT_EVIDENCE
the engine had too little to go on, so it declined to judge — an abstention, never a tier between the others.

Feature attribution

Every UNTRUSTED or DEGRADED verdict comes with which specific inputs moved and by how much — not just "something changed."

Independent evidence layers

Input drift, output stability (when you send your model’s own predictions), and baseline-quality suspicion are tracked separately and shown separately — a healthy input layer doesn’t hide a suspect baseline.

The decision workflow

Decision Journal

Every verdict change writes a permanent, evidence-backed entry — not just a log line. Review, approve, reject, or archive, with a note that’s recorded against your name.

Tamper-evident evidence

Each decision’s evidence snapshot is sealed with a content hash at write time and re-verified on every read. If the stored record had been altered, the page says so.

History & trends

Per-model trust-over-time charts: every batch you send, with its verdict, evidence and flagged share.

Real audit log

Key creation, revocation, team changes, sign-ins, and account deletion are all recorded per tenant, append-only.

For developers

Three calls, no framework required

/fit once, /assess per batch, branch on the verdict. Full reference and copy-paste examples in the docs.

Official clients, one file each

Zero dependencies beyond the standard library: kirelta_client.py for Python, kirelta.mjs for JavaScript. Drop the file into your project.

Webhooks

Get notified the moment a verdict changes, instead of polling.

For teams

Real team seats

Invite teammates by email; seat limits scale with plan.

Complete, self-serve deletion

Account deletion removes the account, its models, its keys, and its decision history. An automated test proves it leaves nothing behind: it finds every table that holds workspace data in the live schema, so a table added later is covered too.