The same check, written five times
Whether an action is available is computed in the interface, the API, the workflow and the batch job, each from slightly different data.
Teban
Business affordances
Given this state of affairs, what can happen next?
Teban turns written policy into a governed action space. Give it an actor, a resource and the current state, and it answers which actions are available now, why, within what limits, and what evidence would change the answer. Every answer traces back to the sentence in your policy it came from.
REST and MCP Deterministic at runtime Versioned, tested packages
What may this manager do next?
expense_payments v3
actor.roles: manager
claim.status: submitted
claim.amount: 7,250
approve_claim
Not permitted
The claim's resolved approval route requires finance director approval; a manager may not approve it alone.
return_for_correction
Available
Ready: return_for_correction
The approval route came from a Kebiki decision. Two further actions are not open to a manager in this state.
The problem
"Why can't I do this?" has no single answer.
Real policies say what people and systems may do in a given situation: who may approve a claim, when payment may be released, what an agent may refund. In most systems those rules are re-implemented wherever a decision is needed, and each copy drifts on its own.
Buttons the backend refuses
The screen enables an action the server then rejects, or hides one that should be open. The person on the other end gets an error with no reason.
Agents that guess
An AI agent has no reliable menu of what it may do right now. It tries, fails, and reports the refusal as if it were a fact about the business.
Four answers
Not just yes or no. What it would take.
Every action comes back in one of four states. The three blocked states tell the caller something different to do next, so a person, an application or an agent always knows whether to stop, gather evidence, or wait for someone else.
The action can be taken now. Limits still come back with it, and so do advisory evidence requests.
release_paymentPolicy forbids it in this state, and more data will not change that. The caller should stop.
release_paymentThe acting user is the claimant and may not release payment on their own claim.
Supply the listed inputs, then evaluate again. Each request says exactly which field is missing and whether it blocks.
release_paymentEvidence required: Receipt exception approval
A person or an upstream decision service has to resolve it. If a delegated decision fails or times out, Teban fails safe and routes the action to review.
approve_claimManual review required for approve_claim (delegated decision unavailable).
Examples are real engine output from one expense payments policy, evaluated in four different situations.
How it works
From a policy document to a callable action space.
Teban builds a package: one policy, many actions, one scope, such as expense payments. People own every step. AI proposes; nothing becomes policy until someone has reviewed it, tested it and approved it.
Understand
Read the policy
- SourceUpload or connect the policy document. It is chunked and indexed.
- AnalyseProposes the governed action spaces in the document: the actions, actors, states and signals, each linked to its passage. Determinations that belong in Kebiki are handed off.
- RequirementsExtracts atomic requirements, each linked to its source sentence, for people to review and correct.
Prove
Build it and test it
- BuildCompiles the requirements into the package's UCL policy, checked by the engine's validator.
- TestGenerates and runs scenarios: a context and the affordances it should produce.
- ReviewShows what changed in the action space, then records approval or sends it back.
Run
Publish and call it
- PublishA versioned, immutable endpoint with its input schema and MCP access, promoted from draft to test to production.
- EvaluateAny application or agent sends the context and gets back the full menu of actions, deterministically.
UCL
A policy language for what is possible.
Teban packages are written in UCL, the Universal Control Language. A UCL policy declares actions, and for each one the conditions that allow it, the conditions that forbid it, the evidence it requires and the limits that apply.
Every rule carries the requirements it came from, and every requirement carries its section and page. From any reason on screen you can get back to the exact sentence in the policy, and forward again.
Source · Travel & Expense Policy, 7.4, page 15
"An employee may not release payment on their own claim."
REQ-4Segregation of Duties
becomes a forbid rule on
release_paymentand answers with
self_release_not_permittedOne action in UCL
expense_payments.policy.ucl.yaml- action: release_payment source_ref: document: travel_and_expense_policy.pdf section: "7.3 Payment Release" page: 14 allow: - is_ap_operator - approvals_complete forbid: - condition: is_claimant code: self_release_not_permitted requirement_ids: [REQ-4] - condition: claim.status == "paid" code: claim_already_paid requirement_ids: [REQ-3] require: - path: claim.receipt_exception_approval label: Receipt exception approval when: receipt_required && !claim.receipts_complete requirement_ids: [REQ-2] - path: claim.cost_center label: Cost center blocking: false requirement_ids: [REQ-7]
What if, and what changed
Change one fact. Watch the action space move.
Supply the missing evidence, switch the actor to the claimant, or evaluate the same situation against a draft. Teban shows exactly which answers change. Versions are compared as changes to what people may do, not only as a text diff.
What if the receipt exception is on file?
release_payment
Available
Draft v4 against production v3
release_payment
Needs evidence
Evidence required: Cost center
The 2026.3 policy draft says payment may not be released without a cost center. Review shows the consequence before anyone approves it.
For AI agents and applications
A menu of what may happen, not a guess.
Teban gives an agent the full set of actions open to it right now, each with a machine-readable reason, the limits that apply, and precise evidence requests it can act on. The agent collects what is missing, asks again, and never has to infer policy from a prompt.
Applications use the same answer. The screen shows the button, the tooltip and the limit that the server will enforce, because both read one evaluation.
- A versioned endpoint per package, with its input schema
- MCP access, so agents discover and call it as a tool
- Parameterised actions: one answer per step, item or value
- A trace of every evaluation, for debugging and audit
Response
POST /ucl/packages/{id}/afford"release_payment": { "reachable": false, "reason": "Evidence required: Receipt exception approval", "code": "missing_receipt_exception_approval", "blocked_by": "evidence", "evidence_needed": [ { "path": "claim.receipt_exception_approval", "label": "Receipt exception approval", "blocking": true }, { "path": "claim.cost_center", "label": "Cost center", "blocking": false } ] }
Who it's for
One answer, read by everyone who needs it.
The same evaluation serves the people who write policy, the engineers who wire it in, the agents that act on it and the auditors who check it afterwards.
| Role | What they get |
|---|---|
| Policy owner | Confidence that the rules match the written policy, readable reasons, and an approval step. |
| Policy author | A fast path from document to governed actions, a way to correct what analysis got wrong, and tests that prove it. |
| Integration engineer | A stable endpoint and schema, predictable responses, versions and environments. |
| Agent builder | A menu of what the agent may do right now, with machine-readable reasons and evidence requests. |
| Reviewer | What changed in the action space between versions, before approving or sending it back. |
| Auditor | Why an action was allowed or blocked at a given time, down to the source clause. |
A clear boundary
Teban defines the action space. Others act inside it.
Humans, applications, workflows and AI agents all operate inside the space Teban defines. Teban stays out of their way.
| Teban does not | Because |
|---|---|
| Perform actions | It says whether an action is available. Your systems carry it out. |
| Orchestrate workflows | It answers what may happen now, not "step one, then step two". |
| Make judgement calls at runtime | Evaluation is deterministic. No model decides at runtime. |
| Decide what is true | Determinations such as an approval route belong in Kebiki, which Teban calls. |
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.
Teban is a commercial implementation of the reference architecture set out in Policy Engineering, applied to permitted actions: what an actor, application or agent may do next. Its seven principles are the design rules Teban 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.
| Principle | In the book | In Teban |
|---|---|---|
| The Source Principle | The authoritative source remains the source of truth throughout the lifecycle. | Every action carries a reference to the document, section and page it governs. |
| The Compilation Principle | Executable policy is compiled from authoritative sources rather than independently authored. | Requirements are extracted from the source and compiled into a UCL policy, checked by the engine's validator. |
| The Provenance Principle | Every outcome should be traceable to the requirements and source passages that governed it. | Every reason traces to a requirement, and every requirement to the sentence it came from. |
| The Determinism Principle | Repeatable policy decisions should execute deterministically, even when AI assists with their creation. | Evaluation is deterministic: the same context and version always return the same action space. |
| The Verification Principle | Policy implementations should be tested against explicit requirements, boundaries, and scenarios. | Scenarios pair a context with the affordances it should produce, and run before publication. |
| The Regeneration Principle | When policy changes, affected implementations should be regenerated instead of manually patched. | A policy change becomes a new draft version, compared with production as a change in the action space. |
| The Structural Integrity Principle | Ambiguity, contradiction, incompleteness, and hidden assumptions should be exposed before deployment. | Analysis surfaces open questions and provisions it left out, for people to resolve before anything is built. |
Part of Archiveris
Teban answers what can happen next.
Teban works on its own, and it works with the other Archiveris products. When an action depends on a determination, such as which approval route a claim takes, Teban delegates it to a Kebiki decision and records the call in its trace. Jiwari holds the shared model of the enterprise that the context describes. Archiveris composes all three into governed Business Operations, so a caller can ask one question and get the determination and the permitted actions together.
How is Teban different from Kebiki?
Kebiki answers what is true: whether a claim qualifies, which route it takes, what the covered amount is. Teban answers what is possible: which actions an actor may take now, given that state. Kebiki packages are written in BDL. Teban packages are written in UCL. They work together, and Teban can delegate a determination to Kebiki.
How is this different from roles and permissions?
Roles say who someone is. Teban says what they may do with this resource, in this state, right now: taking account of amounts, statuses, segregation of duties and missing evidence, with a reason for every answer and a path back to the policy.
What happens if a delegated decision is unavailable?
Teban fails safe. If a delegated decision errors or times out, the actions that depend on it come back as Awaiting review with the code delegated_review_required, rather than being allowed by default.
Can we test a policy change before it goes live?
Yes. A package is tested with scenarios before it is published, and any context can be evaluated against a draft and production side by side. Review shows the change as a change in the action space, such as "release_payment now needs a cost center", before anyone approves it.
What are UCL and Conduit?
UCL, the Universal Control Language, is the policy language Teban packages are written in. Conduit is the name the language was developed under, and you may still see it in earlier material.
Does Teban call a language model when it evaluates?
No. AI helps build a package: analysing the document, extracting requirements and generating tests, always under review. Evaluation is deterministic: the same context and the same version return the same answer.
Bring a policy. See its action space.
Bring one of your policy documents. We will show you the actions it governs, the reasons and limits behind each one, and the evidence that would change the answer.