--- title: "KYE Protocol™ — Assurance Card Profile · system cards become executable" description: "KYE™ Assurance Card Profile™ — turn KYE™ runtime evidence into a living lifecycle assurance record per delegated entity" url: https://kyeprotocol.com/assurance-card/ lang: en source: "KYE Protocol" --- > KYE™ Assurance Card Profile™ — turn KYE™ runtime evidence into a living lifecycle assurance record per delegated entity KYE™ Assurance Card Profile™ · v1.0 # From system cards to runtime assurance. From system card to runtime assurance. Signed evidence. Scoped to your tenant. Replayable in 60 seconds. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Read the docs](https://kyeprotocol.com/docs/) **KYE™ Assurance Card Profile™** turns KYE™ runtime evidence into a living assurance record for AI agents, models, tools, workflows, connectors and delegated systems. **KYE™ makes assurance executable.** Plain take ## Plain take From card to proof. Signed. Scoped. Replayable. - One card per system. One pack per call. - Auditors get OSCAL. Same data. Half the time. - Regulators get scoped evidence. No raw data. - You keep your keys. Always. Why a new layer ## Model cards are not enough. Defence-grade AI assurance work (Alan Turing Institute / Accenture / UK MoD) makes the case directly: model cards are insufficient where models are integrated with platforms, where assumptions change and where multiple models interact. **Agentic systems need more than model cards. They need authority cards, runtime decisions and evidence trails.** KYE™ Assurance Card Profile™ sits above the runtime KYE™ stack. It turns the operating-model journey into a living lifecycle record, automates review-cycle triggering against the authority graph, and enforces the human-involvement plan as a runtime policy gate — not a documentation requirement. 1 · 8-stage lifecycle ## Design → pilot → deploy → monitor → review → decommission. Each stage emits a signed event onto KYE™ Signal Bus™ and is recoverable from the audit ledger. 01 **Design** `KYEAssuranceCard` drafted; intended use, prohibited uses, owner, accountable entity declared. 02 **Pilot** Card moves to `pilot`. Operating-model adoption pack bound; runtime evidence begins flowing. 03 **Deploy** Status moves to `controlled_production` / `production`; cascade-revocation hooks armed. 04 **Monitor** `KYEAssuranceReviewCycle` watches authority-graph + provenance + risk-state for triggers. 05 **Incident review** Trigger `incident` instantiates a review without operator intervention. 06 **Scope-change review** Trigger `scope_change` on capability / gate / commit-boundary updates. 07 **Retention review** Trigger `retention` on data / evidence retention windows. 08 **Decommission** `KYEDecommissioningPlan` orchestrates revoke · quarantine · rotate · archive · notify · remove. 2 · Live assurance-card preview ## Owner. Authority. Human involvement. Provenance. Evidence. Every claim on a KYE™ Assurance Card™ resolves to a runtime artefact a third party can replay offline against a published JWKS. KYE™ Assurance Card™ · preview ### Finance Payment Preparation Agent pilot 3 · KYE™ Human Involvement Plan™ ## Where authorised humans must review, approve, limit or override. Six involvement types · nine lifecycle stages. Bypass attempts are denied at runtime and emit a signed `kye.human_involvement.bypass_denied` event. ### review Periodic review of an AI worker's behaviour and evidence. ### approve Required approval before commit-level action. ### limit Constrain scope or output before execution. ### direct Provide direction or guardrails the AI worker must follow. ### influence Set policy or framing that shapes interpretation. ### override Reverse or change a runtime decision after the fact. 4 · Provenance & supply chain ## Models. Datasets. Tools. Suppliers. Licences. Verified. Every dataset, model, tool, supplier, licence and hardware lineage referenced by an assurance card is bound as `KYEProvenanceEvidence`. Verification status: `verified` / `partially_verified` / `unverified` / `failed`. Verification failure emits a signed `kye.provenance.verification_failed` event onto Signal Bus™. | Element | What is recorded | Verification methods | | --- | --- | --- | | Models | id, version, supplier, licence, checksum | `self_attested` · `third_party_attestation` · `signed_evidence` · `registry_check` | | Datasets | id, version, licence, checksum, data classes | same | | Tools | id, version, supplier | same | | Suppliers | id, verification flag, method | same | | Licences | SPDX identifier or named licence | registry\_check | | Hardware | id, vendor, model, attestation ref | signed\_evidence | 5 · Review cycle (interactive) ## Pick a trigger — we'll show what it produces. Front-end illustration only — no data leaves the page. Real implementations call `POST /v1/assurance-review-cycles/{cycle_id}:trigger`. When does it fire? On the cadence declared by `scheduled_frequency` (weekly / monthly / quarterly / annual). **Reviewer roles:** `ai_governance_lead`. **Evidence captured:** reviewer\_identity, decision, reason\_code, timestamp, state\_snapshot, decision\_map. When does it fire? When the bound `KYEEntityAuthorityRecord` adds or removes a capability, or when the `KYEAuthorityGate` set changes membership. **Reviewer roles:** `ai_governance_lead` + `security_admin`. **Evidence captured:** scope\_diff, decision\_map, state\_snapshot. When does it fire? When an incident signal is recorded (`kye.compromise.reported`, `kye.agency_drift.detected`, etc.) for a descendant of the assurance-card subject. **Reviewer roles:** `security_admin` + `ai_governance_lead`. **Outcome options:** approve / deny / quarantine / escalate. **SLA:** 240 minutes. When does it fire? When `KYEProvenanceEvidence.models[*].version` changes. **Reviewer roles:** `ai_governance_lead` + `data_steward`. **Evidence captured:** model\_diff, evaluation\_refs, performance\_metrics. When does it fire? When `KYEProvenanceEvidence.suppliers[*].verified` changes from `true` to `false`, or a new supplier is added. **Reviewer roles:** `procurement` + `security_admin`. **Evidence captured:** supplier\_diff, verification\_method, signed\_evidence. When does it fire? When a model / dataset / tool licence changes. **Reviewer roles:** `legal`. **Evidence captured:** licence\_diff, registry\_check. When does it fire? When the data / evidence retention window approaches expiry. **Reviewer roles:** `data_steward` + `legal`. **Outcome options:** archive / extend / delete / decommission. When does it fire? When the assurance card transitions to `deprecated` or `revoked`, or the bound `KYEDecommissioningPlan` is executed. **Off-boarding:** revoke\_authority → quarantine\_credentials → rotate\_keys → archive\_evidence → notify\_owner → notify\_supplier → update\_catalog → remove\_from\_runtime. **Cascade scope:** per `cascade_revocation.scope`. 6 · Schemas (Apache 2.0, public mirror) ## Six normative objects. Validated in CI. What it is. Why it matters. What to do next. - `assurance-card-profile.json` — profile manifest - `assurance-card.json` — living lifecycle assurance record - `human-involvement-plan.json` — KYE™ Human Involvement Plan™ - `provenance-evidence.json` — supply-chain + model / dataset / tool lineage - `assurance-review-cycle.json` — scheduled + event-triggered reviews - `decommissioning-plan.json` — retention + off-boarding + cascade revocation 7 · Open / paid boundary ## The contracts are open. The runtime assurance engine is paid. One sentence: a signed, replayable proof of decision. Open source ### Open - Assurance Card Profile™ schema - KYE™ Assurance Card™ schema - KYE™ Human Involvement Plan™ schema - Provenance Evidence schema - Assurance Review Cycle schema - Decommissioning Plan schema - Reason-code dictionary · Signal Bus™ event names - Sample assurance cards · basic conformance fixtures Commercial track ### Paid - KYE™ Assurance Card Builder™ - KYE™ Assurance Card Library™ - KYE™ Human Involvement Planner™ - KYE™ Provenance & Supply Chain Evidence App™ - KYE™ Assurance Review Scheduler™ - KYE™ Governed Use Case Library™ - Sector packs (defence, public-sector, payments, health) - Runtime-evidence binding + review-automation engines - BYOC / on-prem assurance deployment Where to go next ## Adjacent reading. What it is. Why it matters. What to do next. [Operating Model™ →](https://kyeprotocol.com/operating-model/) [Continuity™ →](https://kyeprotocol.com/continuity/) [Discoverability™ →](https://kyeprotocol.com/discoverability/) [Ontology™ →](https://kyeprotocol.com/ontology/) [Glossary — assurance entries](https://kyeprotocol.com/glossary/#assurance-card) [Whitepaper.8](https://kyeprotocol.com/whitepaper/#sec-7-8) ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Authority Graph™](https://kyeprotocol.com/authority-lifecycle/) · [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).