Policy Studio Designer
The Policy Studio Designer is a conversational interface for governance design. You describe what you want to achieve - in plain language - and the Designer drafts candidate policy rules, cites the IEC evidence it is grounded in, and simulates the rule's impact against your organization's actual transaction history before you commit anything.
No rule is created by the Designer. The Designer produces candidates. Candidates move to the Suggestion Inbox. Admins decide whether to apply them.
How a Designer session works
A session is a multi-turn conversation. Each turn the Designer can:
- Ask clarifying questions ("You mentioned VIP customers - how should I identify them?")
- Fetch relevant IEC history ("Let me pull the last 30 days of
contracting.sign.contractcalls...") - Render a candidate rule preview - the same structured view the Inbox uses
- Run a counterfactual simulation against your IEC history
- Refine the candidate based on your feedback
Every session is permanently recorded and auditable.
Starting a session
You can start a Designer session in two ways:
- From a Governance Insight - click "Open in Designer" on any Insight card. The Designer loads with the Insight as context and is already grounded in the relevant IEC pattern.
- From scratch - open the Designer tab and describe what you want. Examples: "All refunds above $500 should require finance approval," "Block outbound messages to competitor domains," "Give the
legal-bot-1agent an exemption from HITL on contract signing."
The Counterfactual Lens
The Counterfactual Lens is the Designer's most important feature. Every candidate rule is accompanied by a simulation report that answers: if this rule had been in effect for the last 30 days, what would have changed?
The report shows:
| Metric | What it tells you |
|---|---|
| Would-have-fired count | Number of IECs in the window where this rule would have matched |
| Verdict deltas | For each affected IEC: the actual verdict vs. the counterfactual verdict |
| False-positive estimate | Of matched IECs that were successful transactions, how many would have been blocked or deferred - the rule's friction cost |
| HITL load delta | Net change in approval queue volume, broken down by domain and approval group |
| Cost delta | Aggregate change in transaction value for blocked IECs |
| Risk-reduction estimate | Sum of avoided risk scores for would-have-denied IECs - a single composite number for comparing rule candidates |
| Most-affected agents | The top 5 agents by counterfactual IEC count, with sample evidence |
The simulation runs against your organization's immutable IEC ledger via the policy simulate endpoint. It is not a model prediction - it is a deterministic replay of your actual history against the candidate rule.
Simulations are cached for 24 hours by candidate rule hash. Editing a candidate and re-simulating uses the cache when the candidate is unchanged.
Iterating on a candidate
The Designer keeps the candidate rule in view throughout the conversation. You can:
- Edit any field of the candidate inline and trigger a re-simulation
- Ask the Designer to narrow or widen the rule ("Restrict this to transactions over $10,000 instead of $5,000")
- Request more evidence ("Show me the three IECs that this rule would have denied")
- Ask for a different formulation ("Instead of denying, defer to the contracting approval group")
Each edit regenerates the counterfactual report. The conversation history stays intact so you can reason about what changed.
Committing a candidate to the Inbox
When you are satisfied with a candidate, click "Commit to Inbox." This creates a pending Suggestion in the Suggestion Inbox - visible to all admins in your organization.
Committing to the Inbox does not create a live rule. It moves the candidate from a private session into a shared review queue where it can be evaluated, refined, or applied by an authorized admin.
The Designer does not have an "apply" button. Applying is a deliberate, separate step in the Inbox.
Designer guardrails
The Designer operates under strict constraints:
- Org-scoped only. Every query the Designer makes is scoped to your organization. Data isolation is enforced at the database level - your organization's data is never accessible to Designer sessions in other organizations.
- PII redacted before grounding. IEC parameters containing PII (email addresses, names, account numbers) are redacted before they are included in the Designer's grounding context. The Designer never sees raw PII.
- Read-only. The Designer can only read your IEC history and policy rules. The only action that produces a record is "Commit to Inbox," which creates a pending Suggestion - not a live rule.
- Session budget. Each Designer session has a maximum budget and step limit. Hitting either gracefully closes the session and preserves the current candidate for Inbox commit.
Evidence panel
Each candidate rule in the Designer includes a collapsible evidence panel listing the citations the model used: specific IEC records, existing policy rules in the same domain, the capability's risk profile, and baseline values. Every citation resolves to a specific, permanent record you can open in the IEC viewer.
This panel is identical to the evidence panel in the Suggestion Inbox. The candidate you review in the Designer is the exact same artifact that reviewers will see in the Inbox.
Related
- Governance Autopilot - overview and prerequisites
- Governance Insights - starting a Designer session from an Insight
- Suggestion Inbox - reviewing and applying committed candidates
- Policy & Governance - the policy engine and rule language the Designer works with