Every KYE Protocol™ term, in plain English.

EntityAnything the protocol can name and reason about. a human, a service, an AI agent, a model, a tool, a workflow. Every entity has a URN.

URNThe canonical identifier format. kye:<class>:<trust-domain>:<subclass>:<local>. Stable, namespaced, human-readable. Defined in public/id-format/.

ActorThe entity actually performing an action. For an AI agent paying a merchant, the actor is the agent.

PrincipalThe entity on whose behalf the actor is acting. For the same payment, the principal is the customer or business that delegated authority.

on-behalf-ofThe relationship between actor and principal. A first-class object in the protocol — not a header, not a claim, an object with its own schema and endpoint.

DelegationA signed grant from one entity to another. Carries the authority being delegated, the scope it can be exercised under. And any constraints. Delegations form chains.

AuthorityThe protocol's noun for "what an entity is allowed to cause to happen." Authority binds a capability + scope + state to an actor + principal pair.

CapabilityThe named verb in the action vocabulary — e.g., payment.initiate, data.read. Capabilities are first-class with their own schemas.

ScopeThe constraint set bounding an authority — amount cap, currency, corridor, time window, beneficiary allowlist, etc. Children inherit parent scope (attenuation rule).

AttenuationThe rule that a child authority's scope must be a subset (⊇) of its parent's. The chain only narrows. it never broadens.

StateThe current lifecycle status of an entity / authority / payload — e.g., active, quarantined, suspended, revoked. The protocol enforces transitions.

Authority Graph™The protocol's view of entities + delegations + authorities + capabilities + scopes as a typed graph. Every relationship is a typed edge.

KYE Chain of Authority™The structural artefact. the linked, attenuating delegation chain from root principal down to the actor. Each link is a signed delegation that attenuates the parent's scope and hash-links into the audit chain. The narrative parallel to chain-of-custody for documents. Authority Finality™ is the *property*. KYE Chain of Authority™ is the chain itself.

Audit chainThe append-only, hash-linked sequence of audit events the runtime emits. Every entity creation, delegation, authority grant, decision. And state transition lands here.

Evidence Pack™A signed bundle of audit-chain entries + Decision Maps™ + signatures + public-key set, replayable end-to-end with public keys alone. The artefact a regulator or auditor verifies.

Evidence Graph™The graph view across multiple evidence packs — how decisions, authorities. And audit events relate. Used for incident reconstruction and dispute resolution.

Blast Radius Map™The view of which downstream authorities and active sessions a single revocation or quarantine signal will reach. Pre-emit. helps operators choose the right action.

Proof bundleThe transport format for an evidence pack. signed JSON over JWS, or COSE-Sign for embedded contexts.

Payload stateThe lifecycle status of a single payload. signed, verified, replayed, tampered. Defined in public/vocabulary/payload-states.md.

CanonicalisationJCS (RFC 8785) canonical JSON form, used for hashing and signing. Ensures bit-exact reproducibility across implementations.

Ed25519The default signing primitive across credentials and proof bundles. Specified by the spec. alternatives are enumerated, not extensible.

Terms introduced by KYE Discoverability Profile™ (kye-discoverability-v1). Names only. graph-traversal mechanisms and pruning rules are proprietary and are not published.

KYE Discoverability Profile™The runtime profile that turns a cryptographically-bound authority graph into a queryable surface, with role-and-purpose discovery policy, row-level masking, federation-trust traversal. And signed audit emission per query.

Discovery modesThe standard set. directory_lookup, path_finder, graph_walk, risk_discovery, connector_discovery, evidence_finder.

Risk-discovery typesThree non-mutating traversals. stale (under-exercised authority), over_permissioned (granted scope exceeds observed exercise), pre_revocation_blast_radius (downstream set that would be quarantined if a target authority were revoked).

KYE Authority Directory™The directory index of cryptographically-bound authority records. The first-class object discoverability queries traverse.

KYE Discovery Console™The operator surface over the directory + path finder + risk discovery. Issues a signed audit event per query.

KYE Authority Path Finder™The path-resolution engine over the authority graph — given (principal, actor, capability), returns one or more delegation paths with edge-by-edge scope intersection.

KYE Evidence Finder™The resolver over audit-event and evidence-pack indexes. returns the evidence pointers bound to a target decision.

KYE Connector Discovery Hub™The discovery surface for Connector Profile™ implementations and their conformance state.

Discovery policyThe selection rule on (role, purpose, requester-tenant, target-tenant) that determines which authority records appear in a result set and which fields are masked.

Federation trustThe cross-trust-domain trust signal that gates whether a discovery query may traverse an edge into another tenant's authority graph.

Terms introduced by KYE Operating Model Profile™ (kye-operating-model-v1). Names only. readiness scoring, risk tiering, side-effect classification, commit-boundary detection, authority-gate recommendation and runtime gate-enforcement internals are proprietary and are not published.

KYE Operating Model Profile™The enterprise adoption layer of KYE™. Defines the journey from use-case intake to runtime authority control plus the schemas, gates, review paths and evidence required at each stage.

Journey stagesTen ordered stages. intake, assess, classify, map_authority, place_gates, configure_runtime, execute, evidence, review, improve.

Use-case intakeInitial proposal for a delegated AI worker. Records actor type, expected actions, systems, data classes, external effects, commit actions and an initial risk assessment. Schema. use-case-intake.json.

Readiness assessmentMulti-dimension assessment plus a readiness score plus the required profiles, gates and evidence for the assessed entity. The scoring construction and dimension set are proprietary. Schema. readiness-assessment.json.

Entity Authority Record™Living governance record per delegated actor — owner, accountable entity, purpose, lifecycle state, risk tier, approved + prohibited capabilities, authority grants, required gates, commit boundaries, current state, evidence, review, revocation. Schema. entity-authority-record.json.

KYE Authority Gates™Runtime gate placed before high-impact delegated actions. Eight gate types. payment_execution, external_message, contract_signature, clinical_action, infrastructure_command, data_export, credential_rotation, evidence_export.

KYE Commit Boundary™Separates recommendation from committed action. Examples. draft email vs send. prepare payment vs execute. recommend refund vs issue refund. draft contract vs sign contract.

Review pathMulti-step human-review chain with required role, decision options, optional condition and SLA per step. Schema. review-path.json.

Adoption Evidence Pack™Signed bundle composing intake + readiness + authority record + gates + commit boundaries + review paths + training + sample runtime decisions. hash-chained into the audit ledger. Schema. adoption-evidence-pack.json.

KYE Governed Entity Catalog™ entryDiscovery entry per governed entity — agent, model, tool, service, connector, app, plugin, profile or certified implementation.

KYE AI Worker Readiness App™Assess whether an AI worker is ready for pilot, controlled execution or production deployment. Planned commercial layer.

KYE Cloud Portal™Enterprise dashboard tying use-cases, agents, gates, boundaries, decisions, evidence packs, training and certification together. Planned.

KYE Academy™Training and certification track for KYE Operating Model Profile™ owners and operators. Planned.

Terms introduced by KYE Formal Rules Profile™ (kye-formal-rules-v1). Names only. rule-conflict-detection algorithms, rule-proof internals, rule-compilation engine, contract-to-authority extraction and sector-rule-pack content are proprietary and are not published.

KYE Formal Rules Profile™The rights, obligations and governance layer of KYE™. Models permissions, obligations, prohibitions, powers, exceptions and governance meta-rules as machine-readable authority objects. A rule should not only be written. It should be enforceable, discoverable, revocable, provable and replayable.

Rule familiesSix families. permission, obligation, prohibition, power, immunity, exception. Plus meta_governance recorded under KYEGovernanceRule.

Normative operatorsCompact operator notation. P (may), O (must), F (must not), Pow (has authority to), Imm (cannot be altered by), Ex (displaced by, in conditions).

KYE™ PermissionStanding rule that an actor MAY perform a capability under defined scope + state. Schema. permission.json.

KYE™ ObligationLifecycle object — actor MUST perform a required action by a deadline. States. pending · satisfied · breached · waived · expired · disputed · remediated · superseded. Schema. obligation.json.

KYE™ ProhibitionStanding rule — actor MUST NOT perform the prohibited capability. Stronger than a runtime deny: a deny is "not allowed now". a prohibition is "this class of action is forbidden under this authority model". Schema. prohibition.json.

KYE™ PowerAuthority to create, modify, revoke, waive or override a normative state. Powers govern what may be done to permissions, obligations, prohibitions and other authority objects. Schema. power.json.

KYE™ ExceptionA rule that displaces or modifies another rule under enumerated exceptional conditions (incident response, business continuity, regulatory instruction). Carries time bounds, additional obligations and required approver roles. Schema. exception.json.

KYE™ Governance RuleMeta-rule on who may override which rules, under what conditions, with what evidence. And for how long. Schema. governance-rule.json.

KYE™ Rule ConflictDetected conflict between two or more rules with the resolution strategy applied (e.g., specific overrides general, prohibition overrides permission). Schema. rule-conflict.json.

KYE™ Rule ProofTest result over a rule set checking enumerated consistency properties. Emitted by KYE Rule Prover™. Schema. rule-proof.json.

KYE™ Obligation StateOne state-transition record on a KYEObligation. Append-only. the chain of these records IS the obligation lifecycle. Schema. obligation-state.json.

KYE Rights & Obligations Engine™Runtime engine that evaluates permissions, obligations, prohibitions, powers, exceptions and governance rules. Planned commercial layer.

KYE Obligation Ledger™Append-only ledger tracking every obligation lifecycle, hash-chained into the audit ledger. Planned.

KYE Rule Prover™Pre-runtime consistency checker for rule sets — conflicts, unbounded obligations, missing satisfaction paths, circular delegation, override gaps. Planned.

KYE Control Compiler™Compiles formal KYE™ rules into runtime PDP/PEP policies, authority gates, commit boundaries, signal events and evidence requirements. Planned.

KYE Contract-to-Authority Mapper™Phase-2 — extracts permissions, obligations, prohibitions and powers from contracts, policies and mandates into KYE™ formal rules.

Control mappingThe named link from a protocol artefact to a regulatory control — e.g., evidence pack → SOC 2 CC7.2. 266 mappings across 164 frameworks.

KYE Compliance Mapping Rail™The runtime channel through which evidence becomes per-framework projection. One signed evidence pack → many framework views.

AI System Compliance Card™The public-key-verifiable nutrition label for any AI system. which controls are evidenced, against which framework, with which signing keys.

OSCALNIST Open Security Controls Assessment Language. The protocol projects to OSCAL component-definition / SSP / assessment-results / POA&M, so OSCAL-native auditors keep their workflow.

ProfileOne of 10 canonical conformance profiles — core, pdp, epdp, spdp, pep, runtime-authority, evidence-replay, connector, manifest, conformance. Sector specialisation comes from 57 rule packs + 49 sector packs, not from profile forks.

Non-goalsThings the protocol explicitly does NOT do — replace SCA, replace tokenisation, run fraud scoring, etc. Documented in the threat-model page.

Annex III high-risk system (EU AI Act Art 6)The Annex III enumeration of high-risk AI use-cases (biometric, employment, education, essential services, law enforcement, migration, justice, democracy). KYE™ binds Annex III designation to a per-system risk-management plan + signed Decision Map™ per decision.

EU AI Act Art 9 — Risk managementMandates a continuous risk-management process for high-risk AI. KYE™ binding: data_flow_graph.v1 + signed mitigation plan, audit-chained.

EU AI Act Art 12 — Record-keeping7-year tamper-evident retention of high-risk AI decisions + inputs. KYE™ binding: audit-chain append-only triggers + R2 object-store immutability.

EU AI Act Art 13 — Transparency to deployerThe deployer must understand the AI system's capabilities/limits. KYE™ binding: per-decision Decision Map™ with reason codes + Assurance Card™ surface.

EU AI Act Art 50 — Interaction disclosureNatural persons must be told when interacting with an AI. KYE™ binding: transparency_log.v1 with proof-of-disclosure per call.

HAARF §4.2 verifiable-by-third-partyUK High-Assurance AI Readiness Framework: an artefact is admissible only if a third party can verify it without trusting the vendor. KYE™ binding: signed Evidence Pack™ verifiable offline with the published assembler_kid public key.

HAARF Risk-Reduction-per-EffortHAARF v1.0 ranking heuristic for guard recommendations. The internal ranking algorithm is proprietary and is not disclosed in this repository; the public surface is the signed kye.guard_recommendation.v1 envelope.

SR 11-7 §V — Model risk managementUS Federal Reserve guidance requiring evidence-supportable model decisions. KYE™ binding: per-decision Decision Map™ (signed graph) + Replay Proof™ derivable offline.

SR 11-7 §VI — Model inventoryInventory of all models in use, with classification, owner, retirement plan. KYE™ binding: kye.implementation_registry.v1 + per-model assurance card.

DORA Art 28 — Critical third-partyEU Digital Operational Resilience Act register of ICT third-party providers + assessment. KYE™ binding: signed sub-processor register + cross-border lawful-basis envelope per call.

DORA Art 6 — ICT risk frameworkComprehensive ICT-risk-management framework requirement. KYE™ binding: continuous compliance-attestation cron + signed posture report.

GDPR Art 30 — Record of Processing Activities (RoPA)Controllers and processors must maintain a register of every processing activity. KYE™ binding: Evidence Pack™ per activity with lawful-basis envelope, signed.

GDPR Art 44-49 — Cross-border transfersLawful-basis mechanisms (SCCs, BCRs, adequacy decisions). KYE™ binding: signed kye.lawful_basis.v1 envelope automatically attached to every cross-border call.

GDPR Art 35 — DPIAData Protection Impact Assessment for high-risk processing. KYE™ binding: data_use_manifest.v1 with DPIA flag; signed when high-risk.

SEC 17a-4(f) — Records preservationUS SEC broker-dealer records must be on WORM media for 6+ years. KYE™ binding: object-store immutability mode with 7-year retention floor.

FINRA 4511(d) — Books and recordsCompanion to SEC 17a-4; mandates tamper-evident book-keeping. KYE™ binding: audit-chain append-only triggers + signed chain-of-custody.

PCI DSS 6.4.1 — Segregated environmentsProduction and development environments must be separated. KYE™ binding: per-tenant region binding + signed environment manifests; cross-environment calls denied at the gateway.

ISO 42001 Annex A.4 — LifecycleDocumented AI-system lifecycle from design through decommissioning. KYE™ binding: Assurance Card™ + 8 lifecycle stages bound to per-stage evidence.

ISO 27001 9.1 — Monitoring of operational controlsContinuous monitoring of information-security controls. KYE™ binding: audit-chain queryable by control id + tamper-evident projection.

NIST AI RMF GOVERN-1.2 — TraceabilityDecisions affected by an AI system must be traceable. KYE™ binding: Decision Map™ + per-decision Evidence Pack™ with full input → policy → verdict trace.

NIST 800-207 — Zero Trust ArchitectureEvery request authenticated, authorised, and policy-evaluated. KYE™ binding: per-call admissibility evaluation; deny-by-default at the gateway.

BCBS 239 §6 — Maker-checker / dual controlBanking standard requiring two-person review on irreversibles. KYE™ binding: dual-channel sign-off (in-app + signed email) on banking-grade actions; cannot be turned off per-tenant.

FCA OpRes IBS — Important Business ServiceUK Financial Conduct Authority operational-resilience designation. KYE™ binding: mapped via operating_model.v1 with replay-proof envelope.

MHRA SaMD & AIUK Medicines and Healthcare products Regulatory Agency Software-as-a-Medical-Device regime. KYE™ binding: per-decision risk-tier evidence + Annex IV equivalent documentation bound to KYE™ artefacts.

OSCAL — Open Security Controls Assessment Language (NIST)Machine-readable format for control assessment. KYE™ projects to OSCAL component-definition / SSP / assessment-results / POA&M so OSCAL-native auditors keep their workflow.

HIPAA §164.312 — Technical safeguardsUS Health Insurance Portability Act technical-safeguard requirements. KYE™ binding: per-tenant signing-kid registry + audit-chain WORM triggers; BAA-compatible.

UK NCSC CAF Principle B6 — Staff awareness & trainingNational Cyber Security Centre Cyber Assessment Framework. KYE™ binding: trainer-cohort evidence + signed certification issuance.

OAuth 2.0 / OIDCHuman-centric authorisation + identity federation. KYE Protocol™ composes. it does not replace.

SPIFFE / SPIREWorkload identity for services. Composes with KYE™ entity URNs at the trust-domain boundary.

MCP — Model Context ProtocolTool / agent communication protocol. KYE™ capability profiles map onto MCP tools.

KYA — Know Your AgentThe general industry term for agent attestation. KYE Protocol™ is the open contract layer that makes KYA, KYC. And KYB interoperable.

PSD3EU revised Payment Services Directive. KYE Protocol™ open-banking profile binds delegated payment-initiation authority to PSD3 SCA + reporting obligations.

DORAEU Digital Operational Resilience Act. The protocol's audit chain + evidence packs satisfy DORA's incident-reconstruction obligations.

EU AI ActThe Union's horizontal AI regulation. The protocol provides evidence for high-risk-AI obligations. conformance is a customer obligation, not a protocol claim.

KYE GovernedUI™The human-facing control layer. You review, approve, reject, edit, escalate, evidence, and audit every consequential AI-agent action before it commits. Eleven canonical modules; /governed-ui.html.

Action ApprovalPre-action human review of an agent’s proposed action. Shows actor, action class, target system, payload summary, risk level, policy decision, evidence. Approve / reject / edit / escalate.

Entity PassportAt-a-glance identity for any agent / human / system / external app — verification status, authority profile, allowed capabilities, restricted actions, approval-required actions, recent activity, trust posture.

Authority ScopeThree-way can / cannot / needs-approval breakdown for any entity. Computed from authority profile + active delegations + applicable policies; scope can never widen at a delegation hop.

Critical Point ReviewHeavy-weight review for irreversible / regulated actions. Two-person and two-person-with-legal modes; the required surface for SR 11-7 four-eyes and EU AI Act Article 14 human oversight.

Evidence TimelineReplay-proof chain from proposal to execute-or-block. A regulator with the timeline and the public verification key can re-derive every verdict offline.

Approval QueueMulti-reviewer queue with pending / high-risk / escalations / second-approval-pending / SLA-breached / evidence-gap views.

Authority Drift DetectorLive drift events from the kye-drift-detector Worker (ten dimensions: intent, scope, state, payload, timing, frequency, target, semantic, agency, authority). Emits kye.agency_drift.event.v1.

Approval modesLocked set (§36 §6): none, single_approver, two_person, two_person_with_legal, delegated, auto (forbidden at high+ risk).

Meta-governance gate§36 §9 (LOCKED). Self-grants (delegate_authority or modify_own_authority where actor == grantee) are rejected at the PDP gate with reason_code: meta_governance_violation. No human approval can override; the break-glass flow is separately audited.

Critical-action catalogueTwenty action classes that trigger a signed, replay-proof approval flow: send_email, send_message, delete_file, export_data, access_sensitive_data, update_crm, issue_refund, create_invoice, submit_form, deploy_code, switch_traffic, run_sql, modify_policy, approve_workflow, share_document, call_paid_api, trigger_payment, change_customer_record, delegate_authority, modify_own_authority.