Introduction
Four objects carry all of Regulation and Compliance: control, policy, asset, incident. They connect in one direction, and almost every question in this section is answered by walking the chain.
The chain
Object | What it is | Connects to |
Control | One rule: a check, its apply points, an action | Belongs to any number of policies |
Policy | A named bundle of controls with a set of covered assets | Holds controls; covers assets |
Asset | A governed agent or model | Covered by any number of policies |
Incident | A record of one control hitting on one asset | Names the asset, policy, control and action |
Both joins are many-to-many. A control can be in several policies; an asset can be covered by several policies. There is no precedence — everything that applies, applies, and when actions differ, Block wins.
What a policy record holds
Field | Type | Description |
| String | Shown in the list. Placeholder suggests naming for the obligation, not the mechanism. |
| String | "What this policy enforces and why." What a reviewer reads first. |
| Boolean |
|
| Boolean | Set by UnifyApps on shipped framework packs. Absent or false means custom. |
| List | The controls this policy enforces. Backs the |
| Enum | The surface governed. Fixed for AI Governance. |
Specific assets | List | Hand-picked agents and models. They stay covered until removed. |
Asset rules | Filter | Rule-based targeting: an asset type (Agent or Model) plus conditions combined with AND / OR. Recalculated in the background. |
The last two together back the APPLIES TO count.
Scope is set by the surface, not chosen
Policies are a shared object across UnifyApps, and the surface a policy is created from fixes what it targets. In AI Governance, policies target assets — agents and models.
This is why APPLIES TO counts assets here. The same policy object used elsewhere in the platform can target users instead. You do not choose this, and you cannot change it after creation.
What an incident carries
An incident is the join record, and it names every part of the chain that produced it.
Field | Description |
| The offending content, truncated. |
| Which agent or model. |
| Which policy delivered the control. |
Control | Which control fired. |
| What was done: |
| Graded by the control. Often blank. |
Confidence | How sure the check is: |
| Which point produced it. |
| Whose interaction triggered it. |
|
|
| Who is triaging it. |
| When. |
Because the incident names the policy and the control, tuning is a lookup rather than an investigation: the noisiest control is visible from the incident list.
Reading the chain backwards
Most real questions are answered by walking from an incident outward.
"Why was this flagged?" — Incident → control. The control's check is the answer.
"Why is this agent governed by that rule?" — Incident → policy →
Applies to. Either it was hand-picked or it matches a rule."Why did nothing get blocked?" — Incident → asset → connection tier. On
Observe · Advisory, onlyFlagtakes effect."Why so many incidents?" — Group by control. One control usually dominates. See Tuning Policy Noise.
Known limitations
No precedence between policies — Two policies covering one asset both apply. A stricter policy does not supersede a looser one — each evaluates its own controls, and if any control blocks, the request is blocked.
Overlap duplicates incidents — Two policies checking the same thing raise two incidents for one event.
Coverage is not enforcement — Whether an action executes is a property of the asset's connection, not the policy.
Incidents are immutable records — Regrading a control or removing an asset does not rewrite incidents already raised.