Blueprint 02 · AI governance
Governed AI: Deterministic-First, Advisory Intelligence
The fastest way to make an AI feature trustworthy is to keep the model out of the critical path. A deterministic core makes the decision and takes the action; the language model narrates, suggests and drafts — always behind provenance, guardrails, and a human who can say no.
Intelligence you can audit
Large language models are fluent, useful, and occasionally, confidently wrong. In a regulated or safety-relevant system, "occasionally confidently wrong" is disqualifying — unless the wrong answer can never reach the world unchecked. This blueprint is the discipline that makes that guarantee structural rather than aspirational.
The move is to separate two questions that teams routinely conflate. What should the system do? is answered by deterministic, testable logic. How should it be explained, drafted, or enriched? is where the model earns its keep. By holding that line everywhere, AI availability, latency and accuracy stop being correctness risks and become quality-of-experience details.
If the language provider is unreachable, slow, or hallucinating, the system must still reach a correct, safe outcome. That single constraint — written down and enforced — is what turns "an app with AI in it" into "a system that is robust to AI."
Four guardrails that travel together
Deterministic core decides
Scoring, eligibility, control and workflow decisions are computed by pure rules. The model's output is advisory metadata attached to a decision the system already made on its own.
Deterministic stub by default
The shipped default is a rule-based implementation that runs offline. Demos, tests and air-gapped deployments never depend on a paid network call — and a real provider is opt-in, not assumed.
Provenance on every output
Each AI response records who produced it: provider, model, whether it was deterministic, and a hash of the input. An AI suggestion is never anonymous, and is always reconstructable after the fact.
Human gate before it counts
Generated advice, plans and content move through an explicit lifecycle — draft → under review → approved → shared. Downstream consumers only ever see approved output, with the approver's identity recorded.
Where the model must be factual, it is given the facts and forbidden to invent. Prompts are assembled from retrieved passages or live schema; a citation guard drops any reference that doesn't map back to a supplied source. The model rephrases what it was given — it does not reach into its own memory.
The model sits beside the decision, not inside it
flowchart LR
REQ["Request / event"] --> CORE["Deterministic core
rules · scoring · FSM"]
CORE --> ACT["Action taken
(safe, correct, logged)"]
CORE -. "context" .-> GW["AI gateway"]
subgraph ai["Advisory layer"]
GW --> PROV{"Provider strategy"}
PROV -->|default| STUB["Deterministic stub
(offline)"]
PROV -->|opt-in| LLM["Hosted / local LLM"]
STUB --> GUARD["Guardrails
grounding · citation guard"]
LLM --> GUARD
GUARD --> PRv["Provenance record
provider · model · input hash"]
end
PRv --> DRAFT["Draft artifact
status = draft"]
DRAFT --> REVIEW["Human review"]
REVIEW -->|approve| SHARED["Approved & shared"]
REVIEW -->|reject| DRAFT
ACT --> SHARED
Surfaces the advisory layer typically powers
| Surface | What the model contributes | What stays deterministic |
|---|---|---|
| Narrative summaries | A short, human-readable explanation of a result or record | The underlying numbers and the decision being explained |
| Drafting & authoring | First-draft content, notes, or plans for a human to edit | Whether the draft is ever published (approval gate) |
| Suggestion / triage | Ranked options, risk flags, predicted outcomes | The action taken, which a person or rule confirms |
| Quality scoring | A note on completeness or coherence of human input | Acceptance criteria and any hard validation |
From request to approved output
sequenceDiagram
participant U as User / trigger
participant S as System (deterministic)
participant G as AI gateway
participant P as Provider (stub or LLM)
participant H as Reviewer
participant E as End consumer
U->>S: Request
S->>S: Compute decision (pure rules)
S->>G: Ask for advisory text (context only)
G->>P: Grounded prompt
P-->>G: Candidate output
G->>G: Guardrails + citation check
G-->>S: Output + provenance
S->>S: Store as DRAFT
H->>S: Review draft
alt Approved
H->>S: Approve (identity recorded)
S->>E: Share approved artifact
else Rejected
H->>S: Reject / edit
S->>S: Back to draft
end
Five alternate use cases
Claims adjudication assistant
Rules engine decides coverage and payout; the model drafts the explanation letter and flags missing evidence. An adjuster approves before anything is sent to the claimant.
Clinical note & care-plan drafting
The model summarises an encounter and proposes a plan, but it is advisory only — the clinician must review and approve, and the patient sees nothing until they do.
Citizen-grievance triage
Deterministic routing assigns the case; the model suggests category, priority and a draft acknowledgement. Provenance makes every AI-touched decision reviewable by an ombudsman.
Candidate screening notes
Structured criteria score candidates; the model writes a narrative rationale. Because hiring is high-stakes, the score is deterministic and the prose is clearly labelled AI-generated.
Contract clause review
A rule set checks for required clauses; the model summarises deviations and drafts redlines grounded in the actual document, with a citation guard preventing invented clause references.
The failure modes — and the controls
| Risk | What it looks like | Control |
|---|---|---|
| Hallucination | The model states something plausible but false in a summary or draft | Ground prompts in supplied sources; citation guard; keep the model off the decision; mark output as draft pending review |
| Prompt injection | Hostile content in the input steers the model to ignore instructions or exfiltrate context | Treat all retrieved/user content as untrusted; never let model output trigger privileged actions; strip system context from what the model can echo |
| Data leakage | Sensitive data flows to an external provider | Deterministic/offline default; send only the minimum needed (e.g. retrieved passages, not whole records); per-tenant provider choice incl. local models |
| Automation complacency | Reviewers rubber-stamp AI drafts, eroding the human gate | Surface provenance and confidence prominently; sample for audit; measure edit/override rates as a health metric |
| Silent quality drift | A provider or model update changes behaviour unnoticed | Provenance with model version on every output; log inputs/outputs; A/B compare providers before switching |
Making AI auditable by construction
Every AI output should be reconstructable: which provider and model produced it, whether it was deterministic, and a hash of the exact input. Combined with the approval record (who approved, when), this answers the question every regulator and incident review eventually asks — "why did the system say that, and who signed off?"
- Make the deterministic stub a first-class, shipping implementation — not a placeholder. It is your fallback when the provider is down and your baseline when you evaluate a new model.
- Keep provider credentials and endpoints in configuration, ideally per-tenant, so a customer can route to a local or sovereign model without a redeploy.
- Never let model output cross a trust boundary unmediated: it does not get to choose what action runs, what query executes, or what data is returned.
- Log token usage, latency and a cost estimate per call — governance includes not being surprised by the bill.
When to reach for it — and when not to
Use it when
- Wrong output has real consequences — money, health, safety, legal exposure, reputation.
- You operate in a regulated domain where decisions must be explainable and attributable.
- Some deployments are offline, sovereign, or cost-sensitive and can't assume a hosted model.
- A human is, or should be, accountable for the final output.
Reconsider when
- The task is genuinely low-stakes and fully reversible — full guardrails may be over-engineering.
- There is no deterministic answer to fall back on and the model is the product (e.g. open-ended creative generation).
- Latency budgets can't absorb a review step and the cost of an occasional error is trivial.
- You cannot articulate what "correct" means — then fix that before adding AI, not after.
Want this pattern applied to your build?
These are the structures we reach for. Tell us the system you're trying to build.