Three calls, and you have a verdict

Prefer a machine-readable reference? openapi.yaml — every field checked against the running service, not written from memory.

Base URL https://api.kirelta.com. 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.

Send outputs too. Add the predictions your model made on those same rows and Kirelta learns its normal behaviour as well — so it can later catch a model that has collapsed while the data going into it still looks completely ordinary. That failure is invisible to any tool watching inputs alone.

POST /fit?model=NAME

curl -X POST "https://api.kirelta.com/fit?model=credit-risk" \
  -H "X-API-Key: kir_your_key" \
  -H "Content-Type: application/json" \
  -d '{"rows": [[0.8, 1.2, 0.4], [1.1, 0.9, 0.6]]}'

import requests

requests.post(
    "https://api.kirelta.com/fit",
    params={"model": "credit-risk"},
    headers={"X-API-Key": "kir_your_key"},
    json={"rows": healthy_rows},   # [[0.8, 1.2, 0.4], [1.1, 0.9, 0.6], ...300 healthy rows]
).json()

await fetch("https://api.kirelta.com/fit?model=credit-risk", {
  method: "POST",
  headers: {
    "X-API-Key": "kir_your_key",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ rows: healthyRows })
}).then(r => r.json());

Returns

{
  "status": "fitted",
  "model": "credit-risk",
  "n": 300,
  "features": 3,
  "baseline_fit": "clear"
}

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

curl -X POST "https://api.kirelta.com/assess?model=credit-risk" \
  -H "X-API-Key: kir_your_key" \
  -H "Content-Type: application/json" \
  -d '{"rows": [[0.9, 1.0, 0.5], [1.3, 0.8, 0.7]]}'

r = requests.post(
    "https://api.kirelta.com/assess",
    params={"model": "credit-risk"},
    headers={"X-API-Key": "kir_your_key"},
    json={"rows": recent_rows},   # [[0.9, 1.0, 0.5], [1.3, 0.8, 0.7], ...recent rows]
)
verdict = r.json()["verdict"]   # TRUSTED | DEGRADED | UNTRUSTED | INSUFFICIENT_EVIDENCE

const r = await fetch("https://api.kirelta.com/assess?model=credit-risk", {
  method: "POST",
  headers: {
    "X-API-Key": "kir_your_key",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ rows: recentRows })
});
const { verdict, action } = await r.json();

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,

  "martingale": 2203.05,
  "alarm_threshold": 20.0,
  "drift_started_at": 1,

  "feature_importance": [
    { "feature": 2, "importance": 0.3770 },
    { "feature": 1, "importance": 0.3561 },
    { "feature": 0, "importance": 0.2669 }
  ],
  "top_features": [2, 1, 0],

  "output_stability": {
    "active": true,
    "drift": true,
    "shifted": true,
    "n": 80
  },

  "notes": ["The data this model was trained on may itself contain anomalies..."],
  "note_codes": ["baseline_may_contain_anomalies"],

  "input_collapsed": false,
  "typicality_median": 0.4913,

  "temporal": { "elevated": false, "note": "..." }
}

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 = "https://api.kirelta.com"
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"] in ("DEGRADED", "INSUFFICIENT_EVIDENCE"):
    # degraded, or no conclusion either way: act, but flag it
    log_for_review(verdict)
    serve(predictions)
else:
    serve(predictions)                  # TRUSTED

Same shape in JavaScript:

const KIRELTA = "https://api.kirelta.com";
const KEY = "kir_your_key_here";

async function canITrust(model, rows) {
  const r = await fetch(`${KIRELTA}/assess?model=${model}`, {
    method: "POST",
    headers: { "X-API-Key": KEY, "Content-Type": "application/json" },
    body: JSON.stringify({ rows })
  });
  if (!r.ok) throw new Error(`assess failed: ${r.status}`);
  return r.json();
}

const verdict = await canITrust("credit-risk", recentFeatureRows);

if (verdict.verdict === "UNTRUSTED") {
  escalateToHuman(verdict);             // don't act on the model's output
} else if (["DEGRADED", "INSUFFICIENT_EVIDENCE"].includes(verdict.verdict)) {
  // degraded, or no conclusion either way: act, but flag it
  logForReview(verdict);
  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, predictions used this month, and 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 /events · GET /alerts · POST /alerts

Trust events — what changed. Kirelta POSTs an event to your webhook when a model’s verdict changes, not on every reading: a model assessed a thousand times while broken sends one event, not a thousand. An escalation from degraded to untrusted always gets through, cooldown or not — hearing "degraded" and then silence is the most dangerous thing this system could do to you. Kirelta notifies; it never acts on your systems. It only sees what you send it. There is no scheduler. If your service stops calling /assess, Kirelta goes quiet, and no event will tell you that you have gone blind — keep that check in your own uptime monitoring. GET /alerts tells you whether the channel is working, not just what is configured. Alongside the URL and the format it returns delivery — how many of your recent alerts were actually accepted by your endpoint, when the last attempt was, and why it failed if it did. If consecutive_failures is non-zero the response also carries a plain-English delivery_warning. Poll it, or watch it in the console: a webhook that has silently stopped accepting deliveries is a monitoring tool you no longer have.

GET /health

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

When something fails

A model exists only after /fit. If /assess answers 409, fit the baseline first.