An AI capability execution platform governed by executable business policies.
AI can initiate real enterprise operations. It cannot decide them alone.
flowchart LR
I[Intent] --> P[Propose action]
P --> D[Decide with<br/>business rules]
D -->|Allow| X[Execute]
D -->|Deny| S[Stop with reasons]
X --> E[Evidence]
S --> E
AI proposes. Policy decides. Deterministic systems execute. Everything is explainable.
Policy Pilot is a reference implementation of that control model, demonstrated on the cash leg of Standard Settlement Instructions (SSI) — maker–checker payments under segregation of duties, line-of-business boundaries, and amount clubs.
Enterprises want AI that can do work: create a payment, submit for funding, approve a trade. They also want AI that can investigate: who can approve a payment or instruction, and harder SoD and control questions such as Are there any instances of approving each other's payments?, Are there instructions approved by someone who reports directly to the creator?, or Are there active instructions sharing the same creditor account and currency?
What they cannot accept is AI that bypasses business decisions — four-eyes rules, ownership, limits, compliance — because those rules lived in a prompt, a spreadsheet, or a service the agent never called.
Today those decisions are scattered across application if statements, BPM diagrams, directories, and tribal knowledge. When AI enters the stack without a shared decision layer, governance becomes hope.
Every enterprise action is the execution of a business decision. Every business decision is the evaluation of executable policies.
In Policy Pilot:
- Intent — a human (or system) asks in natural language, or invokes a capability.
- Propose — AI helps select the capability and parameters. It prepares a proposal, not a fait accompli.
- Decide — executable business policies (Rego / OPA) evaluate segregation of duties, approvals, LOB ownership, amount clubs, and lifecycle rules. Identity supplies facts; policy supplies meaning.
- Execute — application services change state only after policy allows — and they re-evaluate themselves. Chat preflight is never the sole gate.
- Evidence — the decision and the outcome are written together, then kept available for investigation.
That is a controlled ecosystem: AI is inside the perimeter of governance, not outside it with a privilege escalation path labeled “tool call.”
| Outcome | What it means |
|---|---|
| Governed automation | High-stakes actions run through the same decision layer for humans, APIs, and AI-initiated capabilities. |
| Fail-closed control | Deny or abandoned confirmation stops the work. There is no soft “best effort” write after policy says no. |
| Explainable decisions | Allow/deny comes with why — durable on the audit event, not lost in a chat transcript. |
| Consistent rules | SoD, reporting-line inversion, LOB scope, amount clubs — encoded once, reused on every mutation. |
| Investigable evidence | What was proposed, who acted, what policy said, and what changed — available afterward for supervisors and compliance. |
This is not “prompt the model to be careful.” Policy is software that runs before execution.
| Typical AI agents | Policy Pilot |
|---|---|
| Model plans and often steers tool use | Model proposes; policy decides |
| Governance bolted on in prompts | Governance is the decision layer |
| Permission ≈ “can the agent call the API?” | Permission = business decision (SoD, limits, ownership, approval) |
| Success = task completed | Success = task completed under enforceable rules, with evidence |
If you land here wondering “why not LangGraph / AutoGen?” — those optimize agent loops. Policy Pilot optimizes enterprise control when AI is allowed to touch real operations.
The working vertical is cash SSI: instructions and payments, front office / middle office / funding / compliance / technology-auditor personas, live eligibility, scripted create → submit → approve → cancel capabilities, conversation over graph + audit events, and a dedicated Technology Auditor Console for source Mongo evidence.
The pattern generalizes: any high-stakes capability that must obey intent → decide → execute → evidence. SSI is the worked example that makes the claim falsifiable.
Business rule vocabulary in this reference: OPA policy controls.
- True: Side-effecting capabilities cannot complete without passing executable policy (chat preflight and authoritative service evaluation). AI does not own a private write path.
- True: Investigation answers from governed records under entitlement — not an unscoped dump of the enterprise.
- Not claimed: The language model never errs on routing or wording. Control is on execution and decisions, not on verbal perfection.
- Reference posture: Local identity, demo credentials, and compose-up ops are intentional for a runnable reference — not a bank production packaging claim.
Architecture review (adversarial): docs/architecture-review-2026-07-18.md.
policy-pilot.mp4
./scripts/clean-slate.sh
open http://localhost:8096Prerequisites and GCP Vertex setup: How it works — Quick start.
| Document | Contents |
|---|---|
| How it works | Integration picture, data flow, intent pipelines, graph model, ETL, quick start |
| OPA policy controls | Four-eyes, reporting-line inversion, LOB boundaries, amount clubs |
| SoD: Mutual Approval | Showcase — instruction mutual SoD vs payment FO-submit path |
| ssi-chat-j plan | Historical A/B plan (cutover complete — chat is Java-only) |
| ssi-chat-j todo | Living tracker; golden bank under ssi-chat-j/eval/ |
| Authorization audit trail | Who / when / why on past approvals; live eligibility |
| OBO call paths | Service JWT + on-behalf-of matrix across chat and domain APIs |
| Architecture review | Adversarial review (score and residual risks) |
| Sample questions | Demo prompts by path (graph, tools, skill, vector) |
| Domain models and demo users | Instruction / payment models and persona logins |
| Technology Auditor Console | Inspect governed evidence — auditor logins, security events, Create Payment audit executions, linked OPA evaluate request/response |
| Document | Contents |
|---|---|
| Architecture decisions | Why ZITADEL, OPA, MongoDB, Kafka, Neo4j, Vertex, cypher_builder |
| Data flow | Mutation → Mongo transaction → Kafka CDC → indexer → Neo4j → chat |
| Intent determination | Route → Retrieve → Synthesize; RouterDecision |
| Neo4j graph model | Shared graph schema, writer roles, example Cypher |
| Indexer Mongo DLQ | DLQ-before-commit, pause-on-failure, replay, integrity banner |
| OPA policy seed | Rego package layout and local evaluation |
| ZITADEL seed | Demo users, groups, amount clubs |
| Document | Contents |
|---|---|
| Create-payment skill | Draft payment: OPA CREATE preflight, Go / No Go |
| Submit-payment skill | Desk submits DRAFT for funding approval |
| Approve-payment skill | Funding approve of SUBMITTED payment |
| Cancel-payment skill | Middle-office cancel of DRAFT or SUBMITTED |
| Document | Contents |
|---|---|
| Local development | Run services, logs, regression, URLs |
| GCP / Vertex setup | Credentials, smoke test, embeddings / Gemini |
| Observability | OTLP → Prometheus / Loki / Tempo; OpenSLO catalog, Sloth rules, Grafana |
| Directory | README | Port |
|---|---|---|
| Policy Pilot chat (Java) | ssi-chat-j | 8096 |
| Technology auditor console | audit-service | 8097 |
| Demo harness | ssi-demo-harness | 8091 |
| Indexer | ssi-indexer | 8090 |
| Instruction service | instruction-service | 8000 |
| Payment service | payment-service | 8093 |
| Authorization service | authorization-service | 8094 |
| Sequence service | sequence-service | 8095 |
| Kafka Connect | kafka-connect | 8083 |
| Cypher builder (indexer Search Console) | shared/cypher_builder | — |
| Authz client | shared/authz_client | — |
| ZITADEL directory | shared/zitadel_directory | — |