KriftAI
Own productA governed AI platform: every model call passes through input and output validation, a deterministic compliance gate, and per-call audit logging — and nothing an AI writes reaches a customer without a human approving it.
- Routes every model call through a governed wrapper with input and output validation
- Encodes statutory rules as a deterministic pass/fail gate, with an LLM critic for recall on top
- Enforces a human-in-the-loop state machine — draft, review, compliance, approved, published
- Grounds answers in ingested source documents rather than model memory
- Emits an audit record per call, so any output can be traced back to what produced it
| Item | Stage | Gate |
|---|---|---|
| Service page · rewrite | Compliance review | CASL pass |
| Outreach sequence · draft | Rules gate | Rejected |
| Client FAQ · grounded answer | Published | Cited |
| Retention campaign · copy | Human approval | In review |
- Domain
- Governed AI for regulated work
- Hard part
- Making a language model safe to put in front of a compliance obligation
- Integrations
- Web and SharePoint ingestion connectors, multiple LLM providers
- Constraint
- No AI output reaches a customer without a human approval step
- Built with
- Multi-provider LLM routing · Retrieval-augmented generation · Deterministic rules engine · Document ingestion pipelines
- Specified first
- Functional design document · Rules engine specification · Governance state machine · Data model · Acceptance criteria
- Engagement
- Analysis, then build · Regulated businesses putting AI in front of customers
Why it holds up
The problem
Every business in regulated work wants AI writing its customer-facing content, and most of them should be nervous about it. A language model produces fluent, confident copy whether or not that copy breaches an advertising rule or an anti-spam statute. Fluency is not the scarce thing. The scarce thing is a reason to trust what comes out.
So the interesting requirement was never “can it write.” It was: what stops this publishing something that breaks a rule, and how would anyone prove afterwards what happened?
What the analysis produced
The central decision came out of requirements, not architecture: separate what code must decide from what the model may draft. Code decides; the model drafts. Everything else followed from holding that line.
Rules as a gate, not a prompt. Canadian compliance rules — CICC advertising conduct, CASL anti-spam — were converted from statute into deterministic functional requirements and built as a rules engine with a hard pass/fail gate. An LLM critic sits on top of that for additional recall, catching things the rules miss. It never makes the decision. Deterministic first, AI-assisted second.
Governance as a state machine. Draft, review, compliance, approved, published — with no path around it. This was specified before it was built precisely because “we’ll add review later” is how AI systems end up publishing things nobody approved.
Grounding instead of recall. Document ingestion from web and SharePoint connectors feeds a retrieval-grounded knowledge base, so outputs come from authoritative source documents rather than whatever the model remembers.
Audit as a first-class requirement. Per-call logging of inputs, outputs and decisions was in the specification from the start. Retrofitting traceability onto a system that did not plan for it means rebuilding it.
Outcome
The part worth showing is structural. Because the deterministic layer and the generative layer were separated during requirements, the compliance rules can change without touching generation, the model provider can change without touching compliance, and every output has a record explaining itself. That separation is cheap to specify and expensive to retrofit — which is the whole argument for doing the analysis first.
Building something like this?
30 minutes, free. Bring a problem or bring a spec.