Prompt catalog & AI policies
A prompt is production logic: change one sentence and the agent behaves differently. So prompts get the treatment code gets. They are versioned, approved through maker-checker, and sealed on the ledger. Your house AI policies live alongside them, bound to the specific models and agents they govern, so you can show an examiner exactly which rules cover which systems.
Every production prompt is versioned as a governed asset, with the author, the approver, and the exact difference between versions.
Maker-checker applies to prompt changes, so an unapproved edit never serves.
House AI policies covering permitted uses, restricted data, and escalation rules are written once and bound to the models and agents they govern.
Coverage lives on the graph: for any policy you see every agent it binds, for any agent you see every policy that applies, and gaps surface as findings.
Serving-version checks compare what runs in production against the sealed approved version, and any mismatch is raised as a finding.
Every approval and version change is sealed on the hash-chained ledger.
Catalog
Prompts and policies land as versioned assets on the knowledge graph.
Approve
Changes pass maker-checker through one decision door before they can serve.
Bind
Each policy attaches to the assets it governs, so coverage and gaps are both visible.
Verify
The serving version is checked against the approved one, and any drift between them is flagged and sealed.
“Who approved the prompt this agent is running, and when?”
Every production prompt is versioned with its author and approver on the record, and every approval is sealed on the hash-chained ledger. You open the asset and read the approval, the person, and the timestamp directly.
“What changed between the version that worked and the one that broke?”
Each prompt version records the exact difference from the version before it, along with who made the change and who approved it. Comparing the two versions shows you precisely what text changed.
“How do you know production is running the approved prompt and not an edited one?”
Serving-version checks compare what runs in production against the sealed approved version, and any mismatch is raised as a finding. Maker-checker also ensures an unapproved edit never serves in the first place.
Start with proof, not a promise.
There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.
A 60-minute working session
Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.
A two-week guided sandbox
Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.
A six-week proof on your systems
We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.