PolicyEngine enforces named policies against recorded decisions, returning True if the decision satisfies all policy rules. Use it to gate AI decisions at runtime — attributions requiring dual-source confirmation, escalations requiring senior approval, or any decision category where compliance must be verified before the outcome is recorded. Policies are versioned graph nodes, so every check, exception, and approval chain is part of the permanent audit trail.
The Policy Engine sits above
AgentContext and ContextGraph. Policies are stored as nodes in the same graph as decisions, giving them the same causal tracing, provenance, and temporal validity as any other knowledge graph entity. PolicyEngine and Policy import from semantica.context. Decision imports from semantica.context (it is a dataclass defined in semantica.context.decision_models). DecisionRecorder imports from semantica.context.decision_recorder.Defining the policy
APolicy is a dataclass with a free-form rules dict — encode whatever your domain requires.
rules dict that the compliance checker will read when evaluating decisions against it.
Checking a decision for compliance
check_compliance takes a Decision object and the policy ID and returns a boolean.
False. The decision has not been rejected — it has been flagged. What happens next depends on your workflow. In some organisations, a non-compliant result simply blocks the write to the authoritative graph. In others, it triggers an exception process where a human approver reviews the evidence and signs off.
Recording a policy exception
record_exception permanently links a decision, the policy it violated, the approver identity, and the justification.
Building a multi-level approval chain
For the highest-stakes decisions — formal attribution reports that will be shared with government partners — a single approver is not enough. Three people need to sign off: the team lead, the department head, and the CISO.DecisionRecorder.record_approval_chain captures all three in a single call, linking each approver to the communication method and context of their sign-off.
What-if impact analysis before changing a policy
Six months on, your threat intelligence lead wants to tighten the policy: raise the minimum confidence threshold from 0.85 to 0.92 to reduce false-positive attributions. Before she updates the policy, she wants to know how many past decisions would have been blocked under the stricter rule.analyze_policy_impact runs a what-if simulation over the historical decision record — no permanent changes are made.
Updating the policy and finding affected decisions
The lead decides to proceed with the threshold increase. She updates the policy to version 1.1.0, recording her reason. The old version is preserved in the history.Reviewing the full audit trail
At any point — for an Inspector General review, a board report, or an incident investigation — you can retrieve the complete version history of a policy.Domain Examples
- Defense — CTI/Threat
- Security — SOC/Incident
- Life Science — Clinical/Pharma
- Banking — Risk/Compliance
TLP:RED intelligence must never be shared outside the originating organisation without commander-level approval. The policy is enforced on every information-sharing decision that touches classified threat reporting. Violations are routed to the J2 officer for exception review rather than silently logged.
Related Guides
- Decision Intelligence —
record_decision(), causal chains, and precedent search — the decisions thatcheck_compliance()evaluates - Reasoning & Rules — complement policy rules with formal inference for logical conflict detection
- SHACL Validation — enforce structural constraints on policy nodes themselves
- Change Management — version-snapshot the policy graph alongside the knowledge graph
- Provenance — W3C PROV-O lineage for every policy decision and exception
- MCP Server — expose
record_decisionandfind_precedentsas MCP tools for AI agents
