Kebiki | Decision infrastructure

The problem

Your business logic has no home.

Every organisation has rules that govern its decisions: pricing, approval thresholds, eligibility, compliance. Those rules live everywhere and nowhere. AI agents make it worse. Without explicit, governed rules, every decision an agent makes is an improvisation.

Buried in code

Rules are scattered across services and duplicated in every application. Changing a threshold means a code change, a review and a deploy. Nobody can say which version of which rule is in effect.

Locked in documents

Thousands of pages of policy, regulation and procedure exist as PDFs. No system reads them and no agent follows them, until someone gets a decision wrong.

Improvised in prompts

Agents reconstruct rules from their context window. Different prompts give different answers, with no versioning, no audit trail and no guarantee of consistency.

How it works

AI at build time. Zero AI at runtime.

AI helps you build a decision package: it reads the source, drafts the rules and generates the tests. Once the package is published, running it involves no model at all. Every decision is pure, reproducible computation, and your case data is never sent to a model to decide.

Build once

From a document to a signed package

Upload your sourceThe policy, regulation, contract or rate table that governs the decision. PDF, Word or text.
Extract candidate rulesEach proposed rule is mapped to the section and page it came from.
Review and approvePeople check every rule against the source. Nothing ships that a person has not signed off.
Generate and run testsScenarios exercise the compiled package so gaps show up before anything goes live.
Sign and versionThe package is hashed, signed and version-pinned. A tampered package never runs.

Run anywhere

Systems and agents call it. It answers.

Call it over REST or MCPOne request with the case. No SDK required and no model in the loop.
Get a decision, reasons and a traceA status, tags, reason codes, routes, evidence needed and computed facts, plus a trace of every rule that fired and why.

Change with confidence

Rules change. Past decisions don't.

Release with a diff and a simulationCompare a new version with the current one and simulate its effect on real history before you promote it.
Judge each case by the rules in force on its dateA decision made in 2024 replays identically in a 2030 audit.

In the example above, coverage was confirmed but the amount is over the fast-track limit, so the package routed the claim to a senior adjuster and computed the covered amount. Every output is tied to a rule, and every rule to its source clause. The trace_id retrieves the rule-by-rule breakdown.

Every call

An answer your systems can act on.

Each evaluation returns a status, the outputs behind it and a trace. The status is an instruction, not a probability: the same case and the same rules version always return the same result.

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.

failed

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

Raise it with the owning team.

invalid

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

Fix the case and resubmit.

For agent builders

Agents reason. Kebiki decides.

An agent is good at understanding a request and planning the work. It should not be the one deciding whether a refund is allowed. Kebiki gives agents decision APIs they call as tools, over REST or MCP, with any agent framework.

When evidence is missing, Kebiki halts and says exactly what it needs. The agent asks the right question, then evaluates again. It never guesses a field value, and the loop always ends because the schema is finite.

Deterministic

Same case, same rules version, same decision. Pin a version per environment.

Fast and flat-cost

Compiled rules typically evaluate in under a millisecond, with no tokens spent per decision.

The four MCP tools Kebiki exposes
MCP tool	What the agent uses it for
`list_policies`	Discover the packages, versions and effective dates available to it.
`get_schema`	Learn which fields a case needs, their types and allowed values. This drives the questions the agent asks.
`evaluate_case`	Submit the case. Returns the status, the outputs and a trace id.
`get_trace`	Retrieve the rules that fired, the computed facts and the source citations, for audit or a hand-off.

An agent completing a caseexpense_policy

// 1. The agent has only the category so far
evaluate_case({ expense: { category: "MEAL" } })
// status: "halted"
// evidence_needed: expense.amount, expense.merchant_name, expense.date

// 2. It asks the person for exactly those fields, then calls again
evaluate_case({ expense: { ...caseSoFar, ...answers } })
// status: "ok"  tags: ["compliant"]  reason_codes: ["MEAL_UNDER_LIMIT"]

Prompt guardrails are probabilistic. Policy guardrails are deterministic.

Retrieval and runtime AI are good for research and guidance. When an agent has to approve or deny, route or escalate, the rule should be enforced outside the prompt.

Runtime AI compared with Kebiki
	Retrieval and runtime AI	Kebiki
Determinism	Low to medium	Same input, same output
Cost per decision	Scales with tokens and retrieval	Near zero: compiled rules, no inference
Latency	Typically 500 ms to 3 s	Typically under 1 ms to evaluate
Missing data	Filled in, silently and confidently	Halts with `evidence_needed`
Audit	Reconstructed from logs	A trace with source citations on every call
Rule changes	Implicit: a document change shifts answers	Explicit versions, pinned per environment
Best for	Advice, exploration, guidance	Authoritative enforcement

For developers

Business rules, out of your code.

Rules are written in BDL, an open, readable format that lives in version control and is testable without Kebiki. Most teams never start from a blank file: convert a source document and the rules and tests are generated together.

The command-line tool covers the whole loop on your machine: create a package, convert a document, run unit tests and real-world cases, then publish. Kebiki hosts the runtime, versions, traces and audit. If you can send an HTTP request, you can integrate.

The five BDL statement types
Statement	What it does
`derive`	Computes facts from the case, such as a per-person amount or a risk score.
`classify`	Emits a tag with a reason code, such as compliant or non-compliant.
`require`	Demands fields or evidence, and halts cleanly when they are absent.
`route`	Sends the case to a named destination: a person, a queue or another agent.
`select`	Picks a value from a decision table.

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

Response for 185.00 across 3 attendeesok

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

Versioning

When the rules change, past decisions shouldn't.

Every source, version and release forms an immutable lineage. Each case is judged by the rules in force on its business date, so any decision can be reproduced exactly, even years later in an audit.

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.

Editions and corrections

A retired edition stays valid history: the rules changed, but its decisions were right. A withdrawn version was wrong, and everything it touched is flagged.

Replay and remediation

Mark a version wrong and Kebiki replays every decision it made, then gives you the list of affected cases and people.

Diffs and contract checks

See exactly which rules were added, removed or changed. Each change is classed as breaking, additive or internal before it ships.

Simulation before promotion

Run historical cases against a new version and see how many decisions would change, and why, before it reaches production.

One-step rollback

Promote a prior version back into force. Nothing is overwritten, and the rollback itself is dated and traceable.

Enterprise and security

Governed, auditable and inside your boundary.

Kebiki is a dedicated decision layer between business intent and execution. It works alongside your ERP, CRM, claims and payment systems rather than replacing them, and runs wherever your compliance posture requires.

Deployment

Managed multi-tenant, with per-tenant isolation
Dedicated single-tenant runtime
In your own cloud account (VPC)
On-premises or fully air-gapped
Embedded as a sidecar, function or library in your services

Governance and audit

Role-based access with environment-scoped permissions
SSO with SAML and OIDC, and SCIM provisioning
Approval workflows and promotion gates from development to production
Every decision logged with its input, output and trace
Signed audit exports for regulatory submission

The questions security teams ask

Security questions and answers
Question	Answer
Is case data sent to a model at runtime?	No. The runtime is a deterministic engine with no model inference.
Is our policy or data used to train models?	No. We never train on your content, and our AI subprocessors are contractually prohibited from doing so.
Can we use our own AI provider?	Yes. Bring your own credentials for build-time AI, under your own contract with the provider.
Are packages signed and versioned?	Yes. Every published package is hashed, signed and version-pinned.
Can past decisions be replayed?	Yes. The trace is immutable and any decision can be replayed exactly.
How is data protected?	AES-256 encryption at rest and TLS in transit, in every deployment model.
What is the SOC 2 status?	SOC 2 Type II audit in progress. We will walk your team through current controls.
Is a DPA available?	Yes, with GDPR-aligned data handling. The subprocessor list is available on request.

Validated or certified

Validated: bring your own rules

Upload rules you wrote by hand or generated elsewhere. Kebiki checks the syntax, schema and determinism, and runs them with a full trace. Their origin is declared rather than traced to a source.

Certified: backed by the source

Compiled from your source documents through the guided pipeline. Every rule traces to a section and page, from document to extraction to compiled package. The highest assurance for regulated work.

Not another rules engine

Decisions as infrastructure.

Traditional rules engines embed logic inside an application. Kebiki runs decisions as a shared, governed layer that every application, workflow and agent can call.

Traditional rules engines compared with Kebiki
	Traditional rules engines	Kebiki
Where rules live	Inside application code or a database	An independent decision layer
How rules are written	Coded by engineers	Extracted from documents, then reviewed by people
Governance	Code review	Approval workflows, access control and audit trails
Deployment	Rules ship with the application	Rules ship independently, version-pinned
Traceability	Application logs	A trace per decision, with source citations
Past decisions	The latest version wins, so history shifts	Judged by the rules in force on the case's date
Agent readiness	Not designed for agents	REST and MCP, evidence requests and action gates

Use cases

Built for decisions that have to hold up.

Kebiki is for anywhere a wrong decision has real consequences, and anywhere someone will one day ask why a decision was made.

Eligibility determination

Benefits, coverage and programme eligibility. Deterministic determinations, structured evidence requests and a signed trace for every appeal.

Government · Healthcare · Insurance

Claims adjudication

Coverage, limit and authorisation checks, with every approval or denial carrying reason codes that cite the clause that produced it.

Insurance · Healthcare

Tax determination

Credits, indirect tax and withholding, computed against the code in force for the period and reproducible in any examination.

Government · Banking

Healthcare

Prior authorisation, formulary rules and billing compliance, enforced before a claim leaves your system.

Insurance

Underwriting triage, claims adjudication, and rate and eligibility rules across jurisdictions.

Banking

Credit decisioning, KYC and AML enforcement, and rate and fee rules with examiner-ready trails.

Government

Benefits, licensing and grant eligibility, with reason codes linked to statute and defensible on appeal.

Built on Policy Engineering

An open discipline, implemented.

Policy Engineering is the discipline of turning legislation, regulation, contracts and enterprise policy into trustworthy, testable, explainable and deterministic software. It is an open body of knowledge, stewarded by the Institute for Policy Engineering, and it belongs to no single company or product.

Kebiki is a commercial implementation of the reference architecture set out in Policy Engineering, applied to decisions: whether something qualifies, which route it takes, what it is worth. Its seven principles are the design rules Kebiki is built to.

The book

Policy Engineering

Building Trustworthy Software from Human Policy

Dr. Mat Pollard · First edition, 2026 · The Institute for Policy Engineering

The principles, lifecycle, vocabulary and technology for turning human policy into dependable software. Free to read.

Read the book The Institute

The seven principles of Policy Engineering and how Kebiki applies each one
Principle	In the book	In Kebiki
The Source Principle	The authoritative source remains the source of truth throughout the lifecycle.	Certified packages are compiled from your documents, and every rule keeps its section and page.
The Compilation Principle	Executable policy is compiled from authoritative sources rather than independently authored.	Rules are extracted from the source and compiled into BDL, then reviewed and approved by people.
The Provenance Principle	Every outcome should be traceable to the requirements and source passages that governed it.	Every decision returns a trace of the rules that fired, with citations back to the source.
The Determinism Principle	Repeatable policy decisions should execute deterministically, even when AI assists with their creation.	AI helps at build time only. At runtime there is no model: the same case always gets the same answer.
The Verification Principle	Policy implementations should be tested against explicit requirements, boundaries, and scenarios.	Generated scenarios, local tests and simulation against real history run before anything ships.
The Regeneration Principle	When policy changes, affected implementations should be regenerated instead of manually patched.	A policy change becomes a new effective-dated version, with a diff and a simulation before release.
The Structural Integrity Principle	Ambiguity, contradiction, incompleteness, and hidden assumptions should be exposed before deployment.	Structural analysis surfaces contradictions, undefined terms and missing edge cases at compile time, and stops for a human decision.

Part of Archiveris

Kebiki decides what is true.

Kebiki works on its own, and it works with the other Archiveris products. Jiwari holds one shared model of your enterprise, so every decision reads the same world. Teban answers what an actor or agent may do next, and hands the decisions it depends on to Kebiki. Archiveris composes all three into governed Business Operations that your workflows, applications and agents invoke as one call.

See how the three work together

Jiwari

Enterprise world infrastructure. Many schemas. One World.

Explore Jiwari

Teban

Affordance infrastructure for enterprise AI. Given this state of affairs, what can happen next?

Explore Teban

FAQ

Common questions.

Something else on your mind? Ask us

Kebiki used to be called Sertainly. What changed?

Only the name. Sertainly is now Kebiki, one of three products from Archiveris. The engine, the BDL format, your packages and your integrations carry on as they are.

How is this different from a rules engine or BPM tool?

Tools like Drools or Pega execute decisions inside a particular system. Kebiki defines decisions as a portable, governed source of truth that every system, team and channel shares.

It also keeps decisions aligned across time. Every version is effective-dated, so a case is judged by the rules in force on its business date, and that outcome stays reproducible.

What happens when a policy or regulation changes?

You publish a new version and bind it to an effective date. The previous version doesn't change. It is retired, and it remains valid history for every decision it already made.

If the old version was wrong rather than out of date, you withdraw it as a correction. Kebiki replays the decisions it made and gives you the list of affected cases to remediate.

Can't AI handle this on its own?

AI can propose a decision, but it cannot guarantee the decision is allowed. Policy inside a model is opaque, hard to version and hard to audit. Kebiki keeps policy explicit, testable and enforced outside the model, so AI can explore while the rules define what is allowed.

Do we have to migrate everything at once?

No. Start with one high-risk decision area, run it alongside your existing logic, and compare the outputs before you cut over. Nothing existing has to change up front.

Who owns the rules?

Kebiki gives each function a clear part of one shared contract. Product owns the intent, compliance owns the constraints, and engineering owns the integration. Changing a threshold no longer needs a code release.

How do we buy Kebiki?

Kebiki is sold to enterprises through an order form and master services agreement. There is no self-serve sign-up. Start with a conversation about your use case, scope and deployment model. Onboarding covers provisioning, SSO and your first governed decision area.

Business logic is infrastructure.

Bring one of your policy documents. We will show you the path from source to a signed, callable decision API, with a full trace.

Request a demo Talk to us about security

Turn policy into decisive action.