A policy engine should show its unanswered questions.
Before a policy system produces a decision, it should make the missing context visible: what it knows, what it still needs, who can answer, and what must remain on hold.
Dr. Benjamin Harvey
Watch the 48-second policy-engine explanation
The first useful output may be a question
When teams imagine a policy engine, they often picture a machine that receives a rule and returns an answer: allow, block or escalate. That is attractive because it looks decisive. It is also where governance software can become brittle. A rule rarely arrives with every fact needed to apply it responsibly.
The system may still need to know the intended use, the affected people, the data involved, the operating environment, the accountable decision maker, the applicable authority, or the acceptable level of risk. If those gaps are hidden, a confident decision can be built on assumptions no one reviewed.
My building principle is simple: before a policy engine answers, it should show its unanswered questions.
Context is part of the control
This principle aligns with the NIST AI Risk Management Framework without being a NIST requirement or product design. NIST MAP 1.1 calls for the intended purpose, users, expectations, potential impacts, assumptions, limitations and deployment settings to be understood and documented. The AI RMF Core also calls for documented roles, lines of communication and context-specific oversight.
That means a policy cannot be treated as a sentence floating above the work. The same instruction may require different controls when the system moves from drafting internal text to releasing information, from analysis to an external action, or from a low-impact workflow to a consequential decision.
A good implementation therefore carries context with the control—and marks context that is absent, stale or disputed.
Build the question path into the policy contract
I would make the open-question path a first-class part of a policy contract. The record should distinguish known facts from assumptions, identify the source and freshness of each answer, name who has authority to resolve a gap, and state what the system may do while the question remains open.
Some gaps should lead to a bounded request for information. Others should require human review. A few should keep the action on hold because guessing would create unacceptable exposure. The point is not to ask endless questions. It is to ask only what can change the decision—and to remember why the answer mattered.
This is an original product and research synthesis, not an official NIST schema and not a report of measured performance.
Evaluate whether questions improve decisions
The proposed evaluation is straightforward. Give reviewers and policy systems the same set of cases. In one condition, provide a static rule and the available context. In another, allow a structured question path that exposes missing information before a decision.
Measure incorrect approvals, unnecessary blocks, legitimate task completion, escalation quality, review time, question burden and the rate at which unresolved assumptions later become incidents. Keep resources and case difficulty comparable.
The goal is not a system that delays every action. It is a system that knows when an answer would be an unsupported guess—and can make that boundary visible to the people responsible for the outcome.