Governance and Policy Studio¶
Target architecture — not the current operating contract
This page includes the broader governance product. The current release has no policy language: administration uses eight role presets and bounded custom roles at Organization/Team scope, inference uses catalog ∩ Team allowance ∩ key policy, and every gateway decision is recorded as a Request. See Access and Roles and permissions.
Policy Studio externalizes enterprise authority from Agents, Workflows, AI Applications, Connectors, gateways, and module code. The Control Kernel owns the versioned policy interface and durable decisions; OPA/Rego is the reference runtime so effective policy remains open, testable, and independent of application implementation.
Decision contract¶
Every policy evaluation receives five standard input groups:
| Input | Required context |
|---|---|
| Principal | Human or workload identity, customer, environment, roles, groups, grants, delegation, and authentication context |
| Resource | Stable identity, resource type, immutable version, owners, lifecycle, environment binding, risk tier, and data class |
| Operation | Requested capability, target, typed action, Connector class, value or scope, and idempotency context where applicable |
| Context | Time, location or network posture, purpose, business references, operating window, provider or server health, and request channel |
| History | Relevant prior decisions, approval state, usage, budget, exceptions, outcomes, incidents, and separation-of-duties participation |
Evaluation returns exactly one outcome:
allow— the requested operation may proceed under the returned obligations.deny— the operation must not proceed; the decision includes an explicit, safe reason and matching rule references.approval_required— the operation pauses and a durable Governance Approval is created with its scope, route, evidence requirements, expiry, and resumption obligations.
Every result identifies the policy bundle and version, evaluated inputs or governed references, matching rules, decision time, reason, obligations, and Decision identifier. A missing or indeterminate decision never defaults to allow.
Components¶
| Component | Responsibility |
|---|---|
| Policy Templates | Provide business-readable controls for access, environment, data class, purpose, risk, value, time, operating window, and separation of duties |
| Policy Editor | Configure templates, compose rules, validate types, and expose the effective technical policy for review |
| Binding Manager | Attach versioned policy to resources, environments, teams, risk tiers, Connector classes, and operations |
| Fixture and Simulation Lab | Compare expected and actual allow, deny, and approval_required outcomes across representative inputs and policy versions |
| Review and Promotion | Version, review, approve, publish, schedule, roll back, and attribute policy changes using the shared lifecycle |
| Decision Explainer | Show evaluated input references, matching rules, policy version, outcome, obligations, and safe reason |
| Approval Routing | Define authorized customer groups, quorum, separation of duties, deadlines, escalation, delegation, and expiry |
| Policy Analytics | Analyze denials, approvals, overrides, exceptions, stale rules, unused bindings, outcome correlation, and proposed-change impact |
Connector-class defaults¶
Tool-level Connector classification supplies a baseline that policy can strengthen but cannot silently weaken:
| Class | Default decision considerations |
|---|---|
| Data | Caller and source access, environment, data classification, declared purpose, lineage, citation, volume, freshness, and content handling |
| Decision | Caller and resource access, approved input and output types, decision version, confidence or validation, reproducibility, materiality, and outcome linkage |
| Action | Strong authorization, explicit target and scope, risk and value threshold, idempotency, operating window, separation of duties, approval, rate or volume limit, and recovery or compensation readiness |
Data and Decision Connectors must be side-effect-free from the caller's perspective. A tool with any externally meaningful effect is governed as Action even when a server or owner describes it as a read, recommendation, message, or request.
Model inference has its own policy inputs for Virtual Model, deployment eligibility, data class, purpose, guardrail profile, budget, quota, region, and route. Models never inherit Connector classification.
Policy lifecycle¶
Policy definitions follow the shared draft, in_review, approved, active, suspended, and retired states.
- An author creates or updates a draft from typed templates and testable rules.
- Fixtures cover expected allows, denials, approval routes, boundary values, and failure cases.
- Simulation compares the candidate with the active version against representative or governed historical references.
- Review checks ownership, affected resources, separation of duties, rule explanation, performance, and change impact.
- Promotion publishes an immutable version and activates it for declared environments and bindings.
- Monitoring detects unexpected decisions, approval load, exceptions, stale rules, regressions, and outcome changes.
- Rollback activates an earlier approved version and appends an attributed lifecycle event.
An active decision always records the exact policy version. A delayed or approval-required operation is re-evaluated against current identity, policy, resource version, Connector availability, and time-sensitive context before execution.
Explanation and analytics¶
Decision explanation is based on explicit policy facts, not generated speculation. For each decision the product shows:
- Principal, resource, operation, context, and relevant-history references that were evaluated.
- Policy bundle, immutable version, binding, matching rules, outcome, obligations, and safe human-readable reason.
- Approval route and expiry when the outcome is
approval_required. - The resulting execution, typed failure, exception, evaluation, incident, and business Outcome links when they exist.
Analytics aggregate by policy, version, resource, owner, environment, Connector class, operation, principal group, outcome, reason, approval route, latency, exception, and business Outcome. Proposed-policy analysis must keep simulated results separate from production decisions and must preserve access controls on historical inputs.
The operating objective is not to maximize allows or minimize approvals. It is to make authority consistent, testable, explainable, and measurable against safe business outcomes.
Current governance mapping¶
The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.