How Kebiki works

The division

Two clocks, and only one of them has AI in it.

Almost every question people ask about Kebiki — cost, latency, determinism, data residency, whether a regulator will accept it — is answered by which side of this line the thing happens on.

Build time compared with run time
	Build time	Run time
How often	When a policy changes. Weeks or months apart.	Every case. Thousands a minute, if that is what you need.
What AI does	Reads the source, proposes rules, drafts tests, maps each rule to the clause it came from.	Nothing. There is no model in the path.
Who decides	A person. Nothing is published that a reviewer has not approved.	The compiled package, the same way every time.
Where your case data goes	Nowhere — the source document is the input, not your cases.	Into the engine and back out. Never to a model.
Cost	Tokens, once, per policy change.	No tokens. A decision costs what a function call costs.
Latency	Minutes, and nobody is waiting.	Typically under a millisecond to evaluate.
If you ran it twice	You might get two drafts. That is why a person reviews them.	The same answer, to the same trace, for as long as the version exists.

Why this matters more than it sounds. A system that calls a model to decide has to defend every answer as a sampled output: it can be governed, documented and monitored, but it cannot be reproduced. Moving the model to build time turns the hard problem into an ordinary one — reviewing a document, which is work your organisation already knows how to do.

Phase one · Build once

From a document to a signed package.

Five steps. The first four are a drafting loop you can run as many times as you like; the fifth is the one that makes an artifact nobody can quietly change.

Step one

Upload your source

The policy, regulation, contract or rate table that governs the decision — PDF, Word or text. This is the document your organisation already maintains and already treats as authoritative. Nothing about that changes: it stays the system of record, and the package built from it is a disposable artifact that can be rebuilt from the document at any time.

The source is stored with the package, not referenced from somewhere else. A package whose source has wandered off is a package nobody can check.

Step two

Extract candidate rules

This is the step the AI does. It reads the document and proposes rules in BDL, the open rule format, together with the input schema they need and a first set of tests. Every proposed rule carries the section and page it came from.

They are called candidate rules deliberately. At this point nothing is true yet: it is a reading of a document, offered for checking, in a format a person can read and argue with. A rule you disagree with is a rule you can edit or delete, not a weight you have to retrain.

Most teams never start from a blank file. You can also skip this step entirely and bring rules you wrote by hand — see validated and certified packages under Enterprise.

Step three

Review and approve

People check every rule against the source clause beside it. Nothing ships that a person has not signed off, and the sign-off is recorded against the rule rather than against the release as a whole.

This is the step that decides whether the package means anything, and it is the one most automated-policy projects skip. The reviewer is not checking that the AI worked; they are reading a rule and the clause it claims to implement, side by side, and saying whether those are the same thing.

Compliance owns the constraints, product owns the intent, engineering owns the integration. The review is where the first two meet.

Step four

Generate and run tests

Scenarios exercise the compiled package so gaps show up before anything goes live. Tests come from three places: generated alongside the rules at extraction, written by hand for the cases you already argue about, and replayed from real history once you have some.

Because BDL is a file format rather than a product feature, the test suite runs on a developer's machine and in your CI, with or without Kebiki in the loop.

Step five

Sign and version

The package is hashed, signed and version-pinned. A tampered package never runs — the runtime checks the signature before it evaluates anything, so a package that has been edited in place fails closed rather than quietly deciding.

What gets signed is the whole artifact: the rules, the input schema, the tests, the provenance map from each rule back to its clause, and the identity of whoever approved it. That bundle is what a version is, which is why a version can be replayed years later rather than described from memory.

The artifact

What a decision package actually contains.

Everything above produces one thing. It is worth being precise about what that thing is, because every claim on this page is a property of it rather than of the service that hosts it.

The contents of a decision package
Part	What it is for
Input schema	The fields a case needs, their types and allowed values. This is what lets the engine halt with a list of what is missing instead of guessing.
Rules in BDL	The decision itself, in five statement types, readable by a person and testable without Kebiki.
Tests	Scenarios that must pass before the package can be published, and that keep passing as it changes.
Provenance map	Each rule back to the section and page of the source it came from. This is what a citation in a response resolves against.
Effective dates	The window in which this version is the one in force.
Approvals	Who signed off each rule, and when.
Hash and signature	Proof that what is running is what was approved.

A rule in BDLrules/meal_limit.bdl.yaml

- id: derive_per_person
  kind: derive
  when:
    eq: [expense.category, MEAL]
  set:
    calc.per_person: expense.amount / expense.attendees_count
- id: classify_meal_limit
  kind: classify
  when:
    lte: [calc.per_person, 75]
  emit:
    tag: { tag_set: disposition, value: compliant }
    reason_code: MEAL_UNDER_LIMIT

Five statement types and no more: derive computes a fact, classify emits a tag with a reason code, require demands evidence and halts cleanly without it, route sends the case somewhere, select picks from a decision table. A format small enough to read in an afternoon is a format a compliance officer can audit.

BDL and the command-line tool

Phase two · Run anywhere

Systems and agents call it. It answers.

One request with the case, over REST or MCP. No SDK required and no model in the loop. What comes back is an instruction your systems can act on, plus everything needed to explain it later.

RequestPOST /api/public/v1/packages/expense_policy/evaluate

{
  "case": {
    "expense": {
      "category": "MEAL",
      "amount": 185.00,
      "attendees_count": 3,
      "date": "2026-03-11"
    }
  },
  "as_of": "2026-03-11"
}

as_of is the business date of the case, not the date you are asking. Omit it and you get today's rules, which is right for a decision being made now and wrong for every reprocessing job ever written.

Responseok

{
  "status": "ok",
  "outputs": {
    "tags": ["compliant"],
    "reason_codes": ["MEAL_UNDER_LIMIT"],
    "facts": { "calc.per_person": 61.67 },
    "routes": []
  },
  "package_version": "EXPENSE-2026.1",
  "trace_id": "tr_8f2a...c3d1"
}

Four fields do the work downstream. tags and reason_codes are what you act on and what you show a person; package_version is what makes the answer reproducible; trace_id retrieves the rule-by-rule breakdown, with the source clause behind each one.

Four statuses, and what each one asks of you.

The status is an instruction, not a probability. Every integration should branch on exactly these four, and the one that distinguishes Kebiki from a model is the second.

ok

The case was valid and the rules ran. Read the tags, routes and facts.

Act on the decision and log the trace.

halted

A required field or piece of evidence is missing. evidence_needed lists exactly what.

Collect it, then evaluate again. The loop always ends, because the schema is finite.

failed

An engine error or contract violation stopped the run. The cause is in execution.errors.

Raise it with the owning team. This is a bug, not an outcome.

invalid

The case did not match the package's input schema. The offending fields are listed.

Fix the caller and resubmit.

halted is the one worth designing for. A model asked to decide on incomplete facts produces an answer anyway, confidently, and you find out later. A package stops, names the fields it is missing, and waits. That single difference is most of what makes a decision defensible — and for an agent it turns an open-ended conversation into a finite list of questions to ask.

Phase three · Change with confidence

Rules change. Past decisions don’t.

Every source, version and release forms an immutable lineage. This is the phase that makes a decision answerable in an audit years later, and it is the one application code almost never has.

Out of date is not the same as wrong

Most systems have one way to change a rule, so the distinction gets lost and every change becomes a small crisis. Kebiki has two, and choosing between them is the most consequential thing a policy owner does.

Retire an edition

The rules changed. A limit moved, a regulation was amended, a product was repriced. The old version is retired and stays valid history: every decision it made was right when it was made, and replaying one still reaches the same answer.

Nothing downstream is affected. Nobody is contacted.

Withdraw a correction

The rules were wrong. A clause was misread, a threshold transposed, a case the tests never covered. The version is withdrawn, and everything it touched is flagged — because those decisions were not right at the time either.

Kebiki replays every decision the version made and hands you the list of affected cases and people.

What happens before a version reaches production

A diff, classified

Exactly which rules were added, removed or changed, with each change classed as breaking, additive or internal before it ships. A threshold move is not the same kind of event as a new required field, and the release should not pretend otherwise.

A simulation on real history

Run historical cases against the candidate version and see how many decisions would change, which ones, and why. A policy change whose blast radius is 4,000 cases is a different conversation from one whose radius is nine.

A promotion gate

Development to production is an approval, not a deploy. Environments are pinned to versions, so promoting is an explicit act with a name against it rather than a side effect of merging.

And after

Effective-dated releases

A release binds a version to a date window. Each case is routed to the version that was live on its business date — so a reprocessing job run today against 2024 cases uses the 2024 rules, without anyone remembering to arrange it.

One-step rollback

Promote a prior version back into force. Nothing is overwritten and nothing is deleted; the rollback is itself a dated, traceable event in the lineage.

The test for all of this. Someone arrives in 2030 holding a decision made in 2026 and asks why. The answer should be: here is the version in force on that date, here are the rules that fired, here is the clause behind each one, here is who approved it — and here is the same case re-run, reaching the same answer. Not a reconstruction. The thing itself.

Boundaries

What this pipeline does not do.

Kebiki settles which rule applied to which facts. Two questions sit either side of that, and answering them inside a decision engine is how decision engines turn into the thing they replaced.

It does not hold your factsA case arrives with its fields already filled in. Where those values came from, whether they were current on the date of the event, and who may see them, is Jiwari’s question.

It does not decide who may actA package can route a case to a senior adjuster. Whether this particular person is permitted to settle it, today, at this amount, is Teban’s question.

It is also not a workflow engine. Kebiki answers a question in under a millisecond and returns; it does not hold a case open for three days waiting for a human step. Orchestration stays in whatever already does your orchestration, and calls Kebiki whenever it needs the answer to be the same as last time.

Bring one document and one decision.

The fastest way to understand the pipeline is to watch it run on a policy you already argue about. We will compile your wording, run a real case, and show you the citation, the version and the trace it produces.

Request a demo Back to Kebiki

What happens between the document and the decision.