---
title: "KYE™ GovernedUI™ — Seven governance modules"
description: "The seven OPS-suite modules of KYE™ GovernedUI™: Action Approval, Entity Passport, Authority Scope, Critical Point Review, Evidence Timeline, Approval…"
url: https://kyeprotocol.com/governed-ui/modules/
lang: en
source: "KYE Protocol"
---

> The seven OPS-suite modules of KYE™ GovernedUI™: Action Approval, Entity Passport, Authority Scope, Critical Point Review, Evidence Timeline, Approval…

Seven OPS modules

# Every consequential AI-agent action passes through one of these.

All eleven KYE™ GovernedUI™ modules are declared canonically in `internal` and verified by the `governedui-manifest-alive` blocking reconciler. Constitution locks the contract every module MUST satisfy.

### 2. Entity Passport

What an entity is + what it's allowed to do: verification status, authority profile, allowed capabilities, restricted actions, approval-required actions, connected systems, recent activity, trust posture. Visible at-a-glance identity for any agent / human / system / external app. **Envelope:** `kye.governedui.entity_passport.v1` **API:** `GET /v1/entities/{id}/passport`

### 3. Authority Scope

Three-way _can / cannot / needs-approval_ breakdown for any entity. Computed from the entity's authority profile + active delegations + applicable policies. Visualises cross-agent handoffs (Agent A delegated to Agent B) with the full `kye.delegation_chain.v1` hop list — scope can never widen at a hop. **Envelope:** `kye.governedui.authority_scope.v1` **API:** `GET /v1/entities/{id}/authority-scope`

### 4. Critical Point Review

Heavy-weight review for irreversible / regulated actions. Two-person or two-person-with-legal approval modes; captures alternative paths the agent considered, policy rationale, dual-control approvers, evidence references. The required surface for SR 11-7 four-eyes compliance and EU AI Act Article 14 human oversight. **Envelope:** `kye.governedui.critical_point_review.v1` **API:** `POST /v1/critical-reviews` · `POST /v1/critical-reviews/{id}/{approve,reject}`

### 5. Evidence Timeline

Replay-proof chain of events from proposal to execute-or-block. Every step (proposed → authority-checked → policy-evaluated → approval-requested → human-decided → executed-or-blocked → audit-sealed) carries a signed envelope hash. A regulator with the timeline + the public verification key can re-derive every verdict offline. **Envelope:** `kye.governedui.evidence_timeline.v1` **API:** `GET /v1/actions/{id}/timeline`

### 6. Approval Queue

Multi-reviewer queue with pending / high-risk / escalations / second-approval-pending / SLA-breached / evidence-gap views. Routes to managers, compliance, risk, legal, security, or operations based on the action's risk level + the approval mode. **API:** `GET /v1/approvals/{pending,escalated,sla-breached}`

### 7. Authority Drift Detector

Surfaces live drift events from the `kye-drift-detector` Worker — when an agent's behaviour subtly diverges from its declared authority profile (scope creep across small approvals, frequency drift, target drift, semantic drift, etc.). Ten drift dimensions tracked. Critical drift recommends revocation; lesser drifts recommend approval-gating going forward. **Envelope:** `kye.agency_drift.event.v1` **API:** `GET /v1/drift/events`

## GTM suite — ecosystem-side discovery

Four surfaces for partner / consultant / trainer / auditor discovery + onboarding. Distinct from the OPS suite (those are the sellable critical-action gates) — these are the network effects.

- **Consultants Surface** — discovery, onboarding, certification, attribution. `kye-consultant-agent` backed.
- **Trainers Surface** — cohort management + completion attestation. `kye-trainer-agent` backed.
- **Auditors Surface** — Replay-Proof verification console for external auditors / regulators.
- **Partners Surface** — partner registry, deal registration, attribution windows.

## Approval modes (LOCKED, constitution )

| Mode | When | Constitution |
| --- | --- | --- |
| `none` | Policy auto-allowed, no human gate | PDP admission |
| `single_approver` | Default for `risk_level: medium` |  |
| `two_person` | `risk_level: high` (SR 11-7 four-eyes) | banking-grade |
| `two_person_with_legal` | `risk_level: critical` + regulated data | + Data Governance |
| `delegated` | Approval delegated to a downstream role | delegations |
| `auto` | Reserved; forbidden at `risk_level: high` + |  |

## Meta-governance gate (, LOCKED)

Any `action_proposal` with `action_type` in `{delegate_authority, modify_own_authority}` where `actor_id == grantee_id` (or the target authority profile is the actor's own) is rejected at the PDP gate with `reason_code: meta_governance_violation`. No human approval can override this; the operator must invoke the explicit break-glass flow which is itself audited separately.

## How to engage

- [Apply for a paid pilot →](https://kyeprotocol.com/pilot-apply/)
- [See the five-tier pricing ladder →](https://kyeprotocol.com/governed-ui/pricing/)
- [Back to KYE™ GovernedUI™ overview →](https://kyeprotocol.com/governed-ui/)

Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/).