Deterministic enforcement & audit for AI coding agents

A rule that’s probably followed isn’t a rule

Kete (Māori: bag, kit) — pronounced "keh-teh"

Every AI coding tool has an instruction file. Claude Code has CLAUDE.md. Cursor has .cursorrules. Copilot has its own. And the tools keep getting better at keeping those rules in front of the model — re-injection, contextual rules, memory.

All of it improves the odds a rule is followed. None of it is a guarantee.

For rules that must hold, odds are the wrong unit.

Kete is the runtime reliability platform we’re building to fix this — the extended platform that Ārai, our open-source guardrail layer, plugs into.

It extracts your rules into queryable facts, pre-computes a structural map of your codebase, and enforces the rules as a pre-flight gate on every tool call — violations are blocked before they execute, whether the model remembered the rule or not, and every firing is logged.

Status — in active development, closed alpha. Want rule enforcement today? Start with Ārai — it’s free, open source, and runs locally.

The problem: your rules are probabilistic

Instruction files get loaded, then buried. Modern harnesses fight this — rules get re-injected after compaction, attached contextually per request, resurfaced by memory tools — and agents still drift, because everything the agent does piles fresh tokens on top of the rules.

The model's attention to those rules degrades. This is not a quality issue with any particular model, and every model generation shrinks it — but attention is probabilistic by nature. A rule that is probably followed is not a rule. It's a suggestion with good odds.

The consequences are real:

  • Documented rules are violated — migrations hand-written instead of auto-generated, destructive commands run without safeguards
  • Architectural constraints ignored after enough context accumulates
  • Developers forced to restart sessions to "reset" rule adherence
  • Hours lost to manual rollbacks of work the agent was told not to do

Bigger context windows don't fix this. Measured across frontier models, long-context accuracy degrades well before the window is full. Re-injection and compaction improve the odds — but odds are the wrong unit for rules that must hold.

How Kete works

Kete is three layers, each independently valuable:

1. Rule enforcement

Your rules are extracted into structured, queryable facts. A pre-flight gate fires on every tool call and checks the action against them — prohibitive rules block the action outright, deterministically; advisory rules inject the relevant constraint at the moment it applies. Enforcement runs on Ārai, our open-source guardrail core.

2. Audit trail

Every firing is logged: which rule, which prompt, which tool call, allowed or blocked. The log is hash-chained and tamper-evident locally; the Kete platform adds retention, query, and export for teams that have to produce it.

3. Structural map

Kete pre-computes a knowledge graph of your entire codebase — every definition, call relationship, import chain, and dependency. When the AI agent needs to understand what a change affects, it consults the map instead of reading dozens of files.

The direction

Deterministic, and auditable

Frontier models keep getting better at remembering your rules. That's the point: better odds is the ceiling of what model-side memory can offer. Kete and Ārai sit on the other side of that line — a pre-flight gate that fires on every tool call, deterministically, whether the model remembered or not. A blocked destructive command is blocked at hour twelve exactly as it was at hour one.

And every firing is logged: which rule, which prompt, which tool call, allowed or blocked. That trail is what turns agent behaviour from an anecdote into an audit — the kind of evidence emerging AI-governance frameworks increasingly call for. Regimes like the EU AI Act and voluntary programmes like NIST's AI RMF are pushing organisations to document how automated systems are governed and what actions they took; exactly what applies depends on your organisation, system, and jurisdiction.

And because the gate sits outside any one vendor, it’s one policy model across every agent — with the guarantee stated honestly per integration. Where a tool exposes a blocking hook, the gate enforces; where it only exposes MCP, the gate advises; where it only ingests instruction files, the gate is limited to what that file can carry. The platforms built the hook surface; none of them will ship cross-vendor policy. A neutral layer can.

Enforced — Claude Code, Grok TUI native blocking hooks
Advisory — Cursor, Windsurf MCP — injects, cannot block
Observed — Copilot instruction ingestion only
Extensible — Anything with a hook or MCP surface classed as it lands

Models write better code every year, and linters never went away. Guarantees aren't probabilities — Kete is the CI gate for agent behaviour.

Grounded retrieval, not keyword grep

Most AI coding tools discover your codebase by reading files one at a time. They grep, open a file, read it, follow an import, open another file. This works for small changes but breaks down for anything that touches multiple parts of the system.

Kete takes a different approach: it ingests your entire codebase once and builds a structured knowledge graph. Every function definition, every call relationship, every import chain is extracted and indexed.

When the AI agent asks "what breaks if I change this function?", the answer comes from the graph in milliseconds:

  • Direct callers and their locations
  • Transitive dependents — what calls the callers
  • Import chains across the project
  • All affected files, ranked by impact

The agent still reads source code. But Kete tells it which source code to read, and why.

Rules that actually get followed

Instruction files are passive. They sit in context and hope the model pays attention. Kete makes rules active.

Here's how it works:

  • Your CLAUDE.md (or equivalent) is parsed into structured rules — not just text, but typed constraints with subjects and predicates
  • A hook fires before every tool call and checks the action against those rules
  • Prohibitive rules block the action outright — deterministically, at hour twelve exactly as at hour one
  • Advisory rules inject the relevant constraint at the point of action; corrections accumulate as high-trust rules that outrank auto-extracted patterns

This is a pre-flight check, not documentation. The difference matters: documentation is read once and forgotten. A pre-flight check runs every time.

The system learns from your corrections.

When you fix a mistake the AI agent made, that correction can be promoted into a durable, higher-authority rule. Future actions that touch the same area are checked against it automatically — so the same class of action is caught next session, not left to memory.

Understanding code, not just indexing it

Static analysis tells you that function A calls function B. That's useful, but it's not enough for effective rule enforcement.

When your rule says "database migrations must be auto-generated", the system needs to connect "this prompt is about creating a migration" to "migration creation has constraints." That's a semantic link, not a keyword match.

Kete uses a two-layer extraction approach. The structural layer is the backbone; the semantic layer is additive — use it when you want richer guardrails, skip it when you don't.

Primary

Structural layer

Deterministic AST parsing extracts definitions, imports, types, and call relationships. Free, instant, and verifiable from source. This is what you get on day one, and it already makes rule enforcement work.

Optional

Semantic layer

LLM analysis extracts what code does — what functions delegate to, what data they modify, what constraints they enforce, what patterns they follow. Runs in parallel and can be disabled for air-gapped or cost-sensitive setups.

Both layers produce structured facts stored in the same knowledge graph. Start with the structural layer; add the semantic layer when you want guardrails that reason about intent, not just shape.

Getting started

Kete works as a CLI tool that integrates with your existing AI coding workflow.

$ kete ingest

Scans your codebase and builds the knowledge graph. Static extraction runs instantly; semantic enrichment runs in parallel via a fast, cheap LLM.

$ kete impact Agent.perceive

Query the knowledge graph directly. "What breaks if I change this function?" Returns affected files, callers by depth, and transitive dependencies — in milliseconds.

$ kete ask "how does the auth flow work?"

Ask questions about your codebase. Kete retrieves relevant facts from the graph, reads the actual source code for the most relevant definitions, and synthesizes an answer with citations back to file and line number.

Kete integrates with AI coding agents via hooks. When configured:

  • Every tool call passes a pre-flight gate checked against your rules — violations are blocked before they execute
  • Relevant advisory rules and structural context are injected at the point of action
  • Corrections and feedback accumulate as high-trust rules across sessions

The knowledge graph is persistent across sessions. Rules, corrections, and structural knowledge survive session restarts — the agent starts informed, not from scratch.

Powered by the Taniwha Engine

Kete eats its own dog food

Kete isn't designed as a static index. The architecture we're building spins up five domain-specialist agents per repository — engine, backend, frontend, world, and a meta-agent that knows Kete itself — each one a full instance of the Taniwha cognitive engine with its own belief graph, trust ledger, and working memory.

Around every query, each specialist runs the engine's three-part loop:

  • Perceive — the subsystem map lights up and candidate intents are scored against the prompt
  • Ground — related beliefs, contradictions, and trust are attached, so the specialist knows what the prompt is actually asking
  • Sleep — repeat patterns are consolidated into stronger beliefs so the map sharpens the longer you use it

No extra LLM calls per specialist — the loop is headless. When engine, backend, and kete-itself all land on the same intent for a query, that's a consensus signal. When they split, the question is ambiguous and the answer reflects that.

Your codebase becomes a living graph that matures with use — not a snapshot that went stale the moment it was built.

Use cases

Kete is valuable anywhere AI agents operate on codebases with rules that matter.

Architectural guardrails

Enforce patterns your team has agreed on — database migrations must be auto-generated, API responses must follow a specific shape, certain modules must not import from certain others. Rules are checked before the agent writes code, not after.

Change impact analysis

Before the AI agent modifies a function, Kete shows every caller, every dependent, every file that will be affected. The agent starts with the full blast radius instead of discovering it file by file.

Onboarding acceleration

New team members (and their AI agents) can query the knowledge graph to understand how the codebase is structured, what depends on what, and what the established patterns are — before writing a single line.

Safety-critical codebases

In codebases where certain operations must never be run without specific safeguards, Kete provides a structural guarantee — not a hope that the model read the right paragraph in the instruction file.

Audit & compliance

Every rule firing is logged, hash-chained, and exportable. When an AI-governance review asks how agent behaviour is controlled in your codebase, the answer is a verifiable log — not an anecdote about what the agent usually does.

What Kete is — and is not

Kete is:

  • A deterministic enforcement layer — rules that block, not suggestions that drift
  • An audit trail of every rule firing — allowed or blocked, hash-chained, exportable
  • A pre-computed structural map of your codebase
  • One policy model across every agent — enforced where there is a blocking hook, advisory where there is MCP

Kete is not:

  • A code search tool — it provides grounded truth, not text matching
  • An IDE or editor replacement
  • A linter — linters check code after it’s written; Kete gates agent actions before they run
  • A replacement for your AI coding agent — it makes your existing agent more reliable

Your instruction file is documentation. Kete turns it into enforcement.

Kete or Ārai?

Ārai (Māori: barrier, shield) — pronounced "ah-rye"

Ārai is Kete’s enforcement core, shipped as a standalone open-source tool (Apache-2.0 / MIT). Both run the same gate: rules derived from prohibitive language block the tool call outright; advisory rules inject constraints at the point of action; every firing is logged. The difference is how much platform you want around it.

Ārai

Open source · Apache-2.0 / MIT · Local

Pick Ārai if you want:

  • Deterministic blocking via native hooks (Claude Code, Grok TUI) and MCP advisory (Cursor, Windsurf)
  • Hash-chained local audit log — tamper-evident, verifiable offline
  • Fully local — no hosted service, no telemetry, no LLM cost
  • Apache-2.0 / MIT dual licence — internal and commercial use free
github.com/taniwhaai/arai →

Kete

Platform · Audit & org policy · Closed alpha

Pick Kete if you also want:

  • Org rulesets pushed to every agent — one policy model, enforced or advised per tool, across every machine
  • Audit retention, query, and export — SIEM-friendly, hash chain verified on ingest
  • Semantic enrichment and impact analysis over the structural graph
  • Hosted platform with auth, team features, and support

In closed alpha — not taking signups yet.

Rule of thumb: start with Ārai. Move to Kete when rules need to be managed for a team, or when the audit trail has to leave the laptop.

Where Kete is at

Kete is in closed alpha — we're dogfooding it on our own codebases and hardening the approach. We're not taking signups yet; when that changes we'll announce it on the blog. Meanwhile, Ārai ships today: free, open source, and it enforces your instruction files right now.