System

Governance runtime

A policy engine over a vector store that sits between AI tools and a company. It takes a piece of text plus its context, finds the rules that apply, runs their checks and returns a structured verdict — ok, warn, block or insufficient_data — with the rules that matched, the checks that failed and concrete steps to fix the text. It has no model of its own for decisions: the caller sends text, gets the verdict and acts on it.

The problem

Rules over free-form text are harder than a regex pass. Which rules apply depends on the context — a rule about card numbers is irrelevant in an internal log line and critical in an outbound e-mail. How strict depends on the place. Tone and contradiction are not keyword problems. And every decision has to be auditable and reversible.

How a consultation works

1. Trigger matching — a closed-operator evaluator (no eval) decides which playbooks apply.
2. Vector retrieval — pgvector with a sentence-transformers embedding pulls the relevant stored chunks and prior cases.
3. Checks — each matched playbook runs its checks: a regular expression, a natural-language inference (NLI) test, or a small sandboxed expression.
4. Verdict — matched playbooks, warnings, steps and references, plus the control level applied.

What it is built on

• Rules as data. Playbooks are YAML files with triggers, checks (each with a severity) and a control level; they are validated and versioned, so the policy changes without a redeploy.
• Three control levels — advise, warn, block. A rule declares the minimum level it needs; a caller can raise strictness, never silently lower it.
• An anchor against drift. A session carries an anchor embedding of its topic; every call reports a drift score and state and asks to re-anchor when the conversation wanders off.
• A gate for outbound actions. Severity is derived from a typed data snapshot by rule — never from the caller's own description — the message is rendered from a template, and the decision is written as an audit record.
• Fail-closed defaults. A playbook without triggers never fires; an unknown operator evaluates to false; a control level can only be raised.
• Schema-per-tenant isolation. Each tenant gets its own Postgres schema; a triple gate (tenant → role → document) keeps one tenant's data out of another's results.

Stack

Python 3.11 · FastAPI · SQLAlchemy 2 (async) · Alembic · Postgres + pgvector · sentence-transformers (BGE-M3, CPU) · Pydantic v2. Unit tests run in CI without a database.

The code is private and shared by invitation — request access.