Decision Ontology
Automatic Ontologies structure the operating model behind each workflow: entities, policies, exceptions, approval paths, authority limits, and outcomes.
Decision Runtime governance
Govern AI agents at the decision boundary
Governance becomes concrete when a team can name the write-action, required evidence, approval owner, unsafe scenarios, and expected allow, escalate, or block outcome.
Agents are crossing the decision boundary
A copilot can suggest. A production agent can close a ticket, modify an account, advance a finance dossier, isolate a server, or merge code. Once an agent can change state in enterprise systems, governance cannot stay in prompts, dashboards, or quarterly reviews.
- Prompt instructions describe authority but do not enforce it
- Monitoring observes incidents after the action has already propagated
- Policies live across documents, APIs, IAM data, workflow logs, and exceptions
- Audit teams need reproducible decisions, not approximate explanations
Governance starts with a reviewable Safety Case
Rippletide does not ask the model to govern itself. It makes the applicable facts, rules, limits, exceptions, and approval path explicit, then tests representative actions offline. Runtime control follows after that boundary is proven.
Context Graph
The live facts layer gives each proposed action the context that is applicable now: valid data, provenance, scope, temporal constraints, and relationships.
Decision Runtime
The Decision Runtime evaluates the proposed action and applies Continue, Needs a person, or Must stop, with a trace for each outcome.
Without a Decision Runtime
- Authority boundaries are scattered across prompts and SOPs
- Contradictions surface only after agents hit production
- Human escalation depends on the model judging its own uncertainty
- Audit logs describe what happened, but not why it was valid
With Rippletide
- Evidence and rules are explicit outside the prompt
- Unsafe scenarios are tested before production access
- Allow, escalate, and block previews share one trace format
- Production owners review the boundary before activation
Example: a support ticket closure
A support agent proposes closing an escalated production ticket. The action looks routine, but the linked incident and resolution evidence are missing. Rippletide previews the expected decision against the explicit boundary.
| Decision check | Evidence used | Decision outcome |
|---|---|---|
| Is the ticket ready to close? | Ticket status, resolution note, linked incident, SLA state | Required evidence missing |
| Is human approval required? | Escalation policy, production severity, owner assignment | Incident owner approval required |
| What should happen next? | Escalation rule, correction path, review requirement | Preview: escalate |
The result is not a vague explanation. It is a decision trace: proposed action, applicable facts, policy version, rule evaluated, outcome, and reason. That trace is what makes the agent governable.
Mapping governance to reviewer questions
Requirements vary by company and jurisdiction. Rippletide does not replace a compliance assessment. It makes the evidence for four recurring review questions explicit.
| Reviewer question | Evidence needed | 10-Day Proof output |
|---|---|---|
| What can the agent change? | Tool inventory, write-action classification, worst credible outcome | Risky write-action map |
| What evidence supports the action? | Required records, provenance, validity, contradiction checks | Evidence requirements and source links |
| Who approves an exception? | Named owner, thresholds, escalation and correction paths | Approval and escalation rules |
| Can the outcome be reconstructed? | Action, evidence, rule version, outcome, and reason | Decision preview trace |
From one Safety Case to the Runtime path
Start with one action boundary that a production owner can review. Once the evidence, rules, scenarios, and preview traces are accepted, the same boundary can be activated in Runtime.
- Start with the 10-Day Proof on one high-value action.
- Resolve policy, process, IAM, and data contradictions before runtime.
- Review the Safety Case and decision previews with the owner.
- Activate shadow observation, approval, or block mode according to the workflow.
Frequently asked questions
How is AI agent governance different from AI governance in general?
AI governance usually covers model selection, training data, risk review, and organizational policy. AI agent governance covers the action itself: what the agent is allowed to do, with which context, under which authority boundary, and with which trace. For acting agents, governance must sit at the decision boundary.
What is available now, and what belongs to Runtime?
Business validation and runtime enforcement are available now. The integration point and production activation are scoped to the agent and workflow.
Do we have to rewrite our existing policies?
No. Rippletide starts from the sources your business already uses: policies, SOPs, APIs, workflow logs, IAM data, existing vector stores, and evaluated traces. Automatic Ontologies structure those sources into decision logic and surface contradictions for human validation before Runtime expansion.
Who needs AI agent governance
Governance becomes operational when teams can review the action boundary before production access. Rippletide serves teams accountable for the validity of agent actions, not only the quality of agent answers.
- AI and platform leaders standardizing how agents decide, escalate, and act
- Risk, compliance, and legal teams turning policies into explicit decision rules
- Operations teams deploying support, finance, healthcare, cyber, or coding agents
Explore enterprise use cases and learn how AI agent auditability supports decision governance at scale.
Free Risk Review
Make one decision boundary explicit
Map the write-action, evidence, and approval gaps in one 30-minute working session. No live production access required.
- One risky write-action scoped first
- Allow, escalate, or block previews
- Evidence linked to every preview outcome