API

Three calls, and you have a verdict

Kirelta takes rows of numbers — the same feature vectors you feed your model — and tells you whether they still look like the data the model was trained on. Everything below is copy-paste ready.

ⓘ Base URL . Authenticate data calls with the header X-API-Key. Get a key on the account page.

Train a baseline

Send a batch of rows that represent healthy behaviour — data from a period when the model was working well. Kirelta learns the shape of that data and picks its own monitor for it. Every row must have the same number of features.

POST/fit?model=NAME

Returns

{ "status": "fitted", "model": "credit-risk", "n": 300, "features": 3, "variant": "static", "reason": "baseline looks unimodal (BIC favours K=1) -> calibrated single-Gaussian Kirelta", "variant_confidence": "high" }

Assess a batch

Now send recent rows — the ones you actually want a verdict on. Kirelta compares them against the baseline and answers in one object.

POST/assess?model=NAME

Read the verdict

This is the whole product. Everything the console shows you is built from these fields — nothing else is computed anywhere.

{ "model": "t_e573d9984466::credit-risk", "verdict": "UNTRUSTED", "action": "BLOCK / escalate to a human", "flagged_rate": 1.0, "drift_alarmed": true, "n": 80, "top_features": [2, 1, 0], "variant": "static", "temporal": { "ac1": 0.024, "thinning_k": 1 } }

verdict	TRUSTED · DEGRADED · UNTRUSTED — the call itself. Branch on this.
action	The engine's recommendation in words, e.g. ALLOW, REVIEW (elevated abstention), BLOCK / escalate to a human.
flagged_rate	Fraction of rows in this batch that fell outside the trained range. 0.0–1.0.
drift_alarmed	true when the sequential test fires. This is the anytime-valid alarm — its false-alarm rate is bounded over the whole run, not per batch.
n	How many rows were assessed.
top_features	Column indices that contributed most to the deviation, most unusual first.
temporal.ac1	Lag-1 autocorrelation measured in this batch. The drift alarm assumes your rows are exchangeable; when ac1 climbs above 0.3 that assumption weakens and the alarm becomes less reliable — the per-row flags stay valid. Kirelta measures this and tells you, rather than letting you over-trust the alarm.
trend	Present only when applicable: {"state":"recovering","window":8} means this model was alarmed recently and is now improving. It never replaces verdict — read both.

Wire it into your service

The usual shape: assess the batch before you act on the predictions, and branch on the verdict.

import requests KIRELTA = "" KEY = "kir_your_key_here" def can_i_trust(model, rows): r = requests.post(f"{KIRELTA}/assess?model={model}", headers={"X-API-Key": KEY}, json={"rows": rows}, timeout=10) r.raise_for_status() return r.json() verdict = can_i_trust("credit-risk", recent_feature_rows) if verdict["verdict"] == "UNTRUSTED": escalate_to_human(verdict) # don't act on the model's output elif verdict["verdict"] == "DEGRADED": log_for_review(verdict) # act, but flag it serve(predictions) else: serve(predictions) # trusted

Everything else

The rest of the surface, in one place.

GET/models

Every model in your tenant, and how many features each expects.

GET/model/meta?model=NAME

Which monitor Kirelta chose for this model and why — useful when you want to justify a verdict.

GET/usage

Your plan, checks used today, models against your limit.

POST/keys POST/keys/revoke

Create and revoke API keys. Session auth (Authorization: Bearer), not key auth — or just use the account page.

GET/account/export DELETE/account

Download everything held about your account, or erase it completely.

GET/health

No auth. Returns {"status":"ok"} when the engine is up.

When something fails

400	The body wasn't what the endpoint expected. The message says what was wrong.
401	Missing or revoked API key.
404	That model hasn't been fitted in your tenant yet.
429	Rate limited. Back off and retry.

A model exists only after /fit. If you get a 404 on /assess, fit the baseline first.