---
title: "KYE™ Agentic Governance Lifecycle™ — ten governed stages, every act to finality · KYE Protocol™"
description: "The KYE™ Agentic Governance Lifecycle™ — the ten-stage governance spine an agentic act traverses, from Intent to Renewal/Revocation, each stage bound to its canonical surface, schema and engine. Plus a cited map of where adjacent players sit on the spine."
url: https://kyeprotocol.com/agentic-governance-lifecycle/
lang: en
source: "KYE Protocol"
---

> The KYE™ Agentic Governance Lifecycle™ — the ten-stage governance spine an agentic act traverses, from Intent to Renewal/Revocation, each stage bound to its canonical surface, schema and engine. Plus a cited map of where adjacent players sit on the spine.

Agentic Governance™ Lifecycle

# The agentic governance lifecycle, end to end.

An agentic act is not one event. It is a chain of ten governed stages, from the moment intent is declared to the moment authority is renewed or revoked. KYE Protocol™ governs the whole spine — and each stage below links to the canonical surface that owns it.

[Execution architecture](https://kyeprotocol.com/execution-architecture/) [Signed-state timeline](https://kyeprotocol.com/authority-lifecycle/)

Agentic Governance ™ with Authority Finality ™ .

## Ten governed stages

Each stage carries its **boundary verb** — what KYE™ does at that point — and links to the one canonical surface that owns it. This is a projection of the canonical registry, not a second definition. The on-the-wire signed-state sequence lives on the [authority lifecycle](https://kyeprotocol.com/authority-lifecycle/) page.

| # | Stage | KYE™ | What happens, and where it is owned |
| --- | --- | --- | --- |
| 1 | **Intent** | Decides | A principal declares a purpose-scoped intent before any action, binding it to a [Purpose Permission](https://kyeprotocol.com/glossary/#kye-permission) grant so the act inherits a standing rule. |
| 2 | **[Action Admissibility™](https://kyeprotocol.com/action-admissibility/)** | Decides | Before any authority or formal-rule check, KYE™ decides whether the proposed action is admissible into the pipeline at all. |
| 3 | **Authority Resolution™** | Owns | KYE™ resolves the chain of authority behind the act to a single authoritative answer at the point of action. See [execution architecture](https://kyeprotocol.com/execution-architecture/). |
| 4 | **Delegation and Scope** | Owns | KYE™ attenuates authority down the [delegation](https://kyeprotocol.com/glossary/#delegation) chain and pins the [scope](https://kyeprotocol.com/glossary/#scope) each hop may spend. |
| 5 | **Execution Control** | Decides | At the gateway, KYE™ issues the verdict that admits or denies the action and records the Decision Map™ linking inputs to outcome. |
| 6 | **[Evidence Pack™](https://kyeprotocol.com/evidence-pack/)** | Emits | KYE™ seals the signed, replayable bundle an auditor verifies offline from public keys alone. |
| 7 | **[Authority Finality™](https://kyeprotocol.com/authority-lifecycle/)** | Owns | KYE™ resolves the act to a sealed, non-repudiable end state. Every act has authority; every authority has finality. |
| 8 | **[Reality Coupling™](https://kyeprotocol.com/solutions/reality-coupling/)** | Decides | KYE™ detects stable drift — when a still-valid authority has decoupled from the reality it was granted against — and decides whether to revalidate. |
| 9 | **Contestability** | Enables | KYE™ enables a contest by providing the evidentiary substrate. It does not adjudicate. See below. |
| 10 | **[Renewal and Revocation](https://kyeprotocol.com/authority-lifecycle/#lifecycle)** | Emits | KYE™ decides and emits the revocation; the enforcement rail acts on it. Revocations propagate down delegation chains. |

## Partner journey board — the lifecycle as a governed path

Each stage below is a governed checkpoint. Up-arrows show advancement through the lifecycle; dashed exit arrows show downgrade and revocation paths. This board is a **projection** of the canonical lifecycle registry — add a stage there and it appears here automatically. Phase groupings: **Intake** (1–2) · **Authority** (3–5) · **Evidence** (6–7) · **Continuity** (8–10).

The board reads from the canonical stage registry. Stages link to their canonical surface — the one authoritative page that owns each stage definition.

## Contestability — evidentiary, not adjudicated

When a governed party contests an automated decision, KYE™ supplies what makes the contest provable rather than a matter of opinion: the signed [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) and the Replay Proof any third party re-derives from public keys alone.

- **KYE™ enables the contest.** It hands the decision-map and replay-proof references to whatever appeal body, regulator or court already holds jurisdiction.
- **KYE™ is not a dispute-resolution system.** It does not weigh testimony, rule on merits, or settle outcomes. The adjudicator does that; KYE™ makes the record incontestable.
- **The record outlives the runtime.** A sealed pack is replayable years later from the published key set alone — so a contest raised long after the act still has ground truth to stand on.

This is the canonical surface for the Contestability stage. Its structured record is the dispute registry; the appeal rights that apply are jurisdiction-specific.

## Decision Rationale — the why, in contestable terms

A signed [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) proves **what** happened and **who** authorised it. It does not, on its own, explain **why** the decision was reached in terms a citizen, regulator or tribunal can meaningfully contest. The Decision Rationale™ record closes that gap — and it is what an EU AI Act™ Article 13 (transparency) and Article 14 (human oversight) obligation reads.

| Record | Question | What it carries |
| --- | --- | --- |
| **[Evidence Pack™](https://kyeprotocol.com/evidence-pack/)** | What & who | The signed, replayable bundle — inputs, signed state, signals, signatures — an auditor verifies offline from public keys alone. |
| **Decision Rationale™** | Why | Which rule fired, which authority was resolved, which inputs were consumed, the purpose and scope in force, any human-oversight intervention, and the contest path — each in plain language. |
| **Contest path** | How to challenge | The route an affected party takes, and the external body holding jurisdiction. Once a contest is raised it becomes a dispute record, described above. |

### The boundary we hold

- **KYE™ explains the governance decision.** It records which rule was decisive, on whose authority the act stood, what inputs it consumed, the purpose and scope, and how to contest it.
- **KYE™ does not interpret the model.** A model's output is consumed as a governed input signal, not opened up — KYE™ does not produce post-hoc statistical interpretability such as feature-attribution scores. The Decision Rationale™ states this boundary in every record it emits.
- **KYE™ does not adjudicate.** It hands the rationale and the replay-derivable evidence to whatever appeal body, regulator or tribunal already holds jurisdiction. KYE™ enables the contest; the adjudicator decides it.

This is the canonical surface for the Decision Rationale™. Its structured record is `kye.decision_rationale.v1`, mapped to EU AI Act™ Articles 13, 14 and 86.

## Category contrast — execution integrity versus authority lifecycle

Execution-integrity protocols protect the **commit boundary** — they verify that the action executing now matches the action that was authorised. KYE™ governs the **full authority lifecycle** — from intent through admissibility, authority, delegation, execution, evidence, finality, reality-coupling, contestability, and revocation.

Execution replay may be bounded; **authority replay is deterministic** — who acted, on whose authority, under which scope, policy, evidence, and finality state.

## Authority-governance conformance ladder

KYE Protocol™ defines five levels of authority-governance conformance, each corresponding to a set of lifecycle stages an implementation governs. An implementation advances the ladder by covering progressively more of the spine.

| Level | Name | Stages governed | What it means |
| --- | --- | --- | --- |
| **L1** | **Schema-valid Evidence Pack™** | Stage 6 — Evidence Pack™ | The implementation emits a schema-valid [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) (`kye.evidence.decision_map.v1`) for every governed act. The minimum evidentiary floor; offline replay is possible. |
| **L2** | **Authority chain captured** | Stages 3–4 — Authority Resolution™ + Delegation | The authority chain (grant → delegation → attenuation) is captured in every Evidence Pack™ and independently verifiable from published key material. Chain-of-custody provable on demand. |
| **L3** | **Runtime Action Admissibility™ enforced** | Stages 1–5 — Intent through Execution Control | Action Admissibility™ is enforced at runtime — out-of-scope action is refused before the side effect commits. Includes Intent binding, admissibility gate, authority resolution, delegation scope, and execution verdict. |
| **L4** | **Authority Finality™ replayable** | Stages 6–7 — Evidence Pack™ + Authority Finality™ | Every act resolves to a [sealed, signed, non-repudiable end state](https://kyeprotocol.com/authority-lifecycle/). The Replay Proof is derivable from public keys alone — no vendor cooperation needed. Finality is the property regulators and auditors cite. |
| **L5** | **Full spine — Reality Coupling, Contestability, Revocation** | All ten stages | [Reality Coupling™](https://kyeprotocol.com/solutions/reality-coupling/) detects stable drift; Contestability provides the evidentiary substrate for challenge; [Renewal/Revocation](https://kyeprotocol.com/authority-lifecycle/#lifecycle) propagates down delegation chains. The complete authority governance lifecycle, end to end. |

The [certification program conformance ladder](https://kyeprotocol.com/certification/) (L0 Declared → L4 KYE™ Certified™) governs implementation programme tiers. This authority-governance ladder governs which lifecycle stages an implementation covers. The two ladders are independent and complementary.

## Where the other players sit

Adjacent categories each cover a slice of the spine. KYE™ spans all ten stages; each named player below covers one or two, sourced from its own public positioning. For the category-level narrative, see [who's in AI governance](https://kyeprotocol.com/learn/articles/players-in-ai-governance/) and the [analyst competitive landscape](https://kyeprotocol.com/analyst-briefing/competitive-landscape/).

| Player | Category | Stages covered | Public positioning (cited) |
| --- | --- | --- | --- |
| **KYE Protocol™** | Agentic Governance™ | All ten stages | Governs the authority behind every act and resolves it to finality across the whole spine. |
| [Datadog](https://www.datadoghq.com/product/llm-observability/) | Observability | Execution Control | LLM Observability monitors, traces and evaluates LLM applications in production. |
| [Arize AI](https://arize.com/llm-evaluation/) | Model eval | Execution Control · Reality Coupling™ | AI observability and LLM evaluation for tracing and troubleshooting agent performance. |
| [Cisco AI Defense (Robust Intelligence)](https://www.cisco.com/site/us/en/products/security/ai-defense/index.html) | Model eval | Action Admissibility™ | Automated AI validation and runtime safety — red-teaming and guardrails for models. |
| [Credo AI](https://www.credo.ai/product) | GRC | Intent | AI governance platform for use-case registration, policy management and framework mapping. |
| [OneTrust](https://www.onetrust.com/products/ai-governance/) | GRC | Intent · Evidence Pack™ | AI inventory, risk assessment and policy management against regulatory requirements. |
| [Cerbos](https://www.cerbos.dev/product-cerbos-pdp) | Policy authoring | Authority Resolution™ · Execution Control | Stateless decoupled authorization layer evaluating policy-as-code to allow or deny actions. |
| [Temporal](https://temporal.io/product) | Enforcement gateway | Execution Control · Renewal/Revocation | Durable execution platform orchestrating reliable, recoverable workflow state transitions. |
| [Lakera](https://www.lakera.ai/lakera-guard) | Pre-authorization | Action Admissibility™ | Lakera Guard screens prompts and agent inputs for injection, jailbreak and data-leak risk. |

Each row's claim is drawn from the linked vendor's own public site. KYE™ consumes these signals as inputs to an authority decision — it does not compete at their altitude.

## Keep reading

- [Execution architecture](https://kyeprotocol.com/execution-architecture/) — the ten-layer stack KYE™ owns and the eight it integrates.
- [Authority lifecycle](https://kyeprotocol.com/authority-lifecycle/) — the on-the-wire signed-state timeline to finality.
- [Competitive landscape](https://kyeprotocol.com/analyst-briefing/competitive-landscape/) — why the category sits at a different altitude.

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