Glossary · every term, in plain English

Every KYE Protocol™ term, in plain English.

Defined once, used consistently. Where the term is a trademark of the KYE Protocol™ project, the ™ is shown; where it is a generic concept, it is not. Glossary anchors are stable URLs — link to glossary.html#authority-finality in your own docs.

01architecture Core protocol 02bolt Runtime 03verified Evidence 04trending_up Continuity 05explore Discoverability 06hub Ontology 07route Operating Model 08badge Assurance 09policy Formal Rules 10fact_check Admissibility 11rule Compliance 12workspace_premium Programme 13extension External
01architectureCore protocol

Identity, authority, and the chain.

  • 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.
    • 02boltRuntime

    Decision, enforcement, cascade.

  • DecisionThe runtime's verdict on a single requested action: allow, allow_with_constraints, require_approval, deny — plus a reason code.
  • Decision codesThe standard set: allow_with_constraints, require_approval, deny. Stable across versions; mappable to your own code-set via the conformance pack.
  • Decision Map™The signed, replayable artefact emitted with every authorise call. Shows which inputs led to which decision; verifiable offline with public keys.
  • PEP — Policy Enforcement PointThe component that intercepts an action and asks the PDP for a decision. Lives in your application; ships as a reference Express middleware.
  • PDP — Policy Decision PointThe component that evaluates the request against authorities + state + scope and returns a decision. Ships as the reference Gateway.
  • ePDP — Edge PDPA locally-cached, offline-capable PDP for the bank/merchant edge. Walks the chain, verifies signatures, returns a decision in < 1 ms.
  • CascadeThe propagation pattern applied when an upstream authority is revoked or quarantined; downstream-derived authorities become unusable before the originating request returns. Mechanism is part of the patent track.
  • Authority Finality™The protocol-level *property* that a request's KYE Chain of Authority™ is provably terminal — verified end-to-end with public keys alone before the action takes effect, and replayable after. The technical and evidentiary foundation behind the entire protocol.
    • 03verifiedEvidence

    Audit chain, packs, replay.

  • 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.
    • 04trending_upContinuity

    Decision values, drift types, evidence pack.

    Terms introduced by KYE Continuity Profile™ (kye-continuity-v1). Names only; detection algorithms and scoring weights are part of the normative specification and the patent track and are not published.

  • KYE Continuity Profile™The runtime profile that binds interpreted intent vs declared intent, multi-dimension authority state, pressure context, incentive context and oversight state into a signed pre-commit verdict at every decision point.
  • Authority Continuity™The protocol-level property that an actor's authority at decision time matches the authority granted by its delegation chain — no scope drift, no state drift, no capability drift, no broken delegation.
  • Agency Continuity™The protocol-level property that an actor's interpreted goal at decision time matches its declared intent, and that pressure / incentive / oversight context preserves principal agency.
  • Continuity decision valuesThe standard set: continuity_preserved, continuity_degraded, continuity_broken. Companion continuity_score is a numeric in [0, 1].
  • Drift typesTen named categories: intent_drift, authority_drift, scope_drift, state_drift, capability_drift, execution_drift, incentive_drift, oversight_drift, evidence_drift, delegation_drift. Detection rules are not published.
  • Continuity Decision Map™The signed, replayable artefact bound to a single continuity decision. Same shape as the standard Decision Map™; carries the continuity inclusion set.
  • Continuity Evidence Pack™A signed bundle composing intent + interpretation + 6-dimension state + pressure + incentive + decision + execution + drift events under deterministic canonical encoding. Hash-chain-bound to the audit chain.
  • KYEAgencyDriftEventOne record per detected drift, signed and hash-chained into the audit ledger; surfaced as a kye.agency_drift.detected signal on the KYE Signal Bus™.
  • KYE Continuity Gateway™Runtime extension to the reference Gateway adding the continuity decision surface + drift-event endpoints.
  • KYE Agency Drift Monitor™Drift detection + alerting surface (planned commercial layer).
    • 05exploreDiscoverability

    Directory, path finder, risk discovery.

    Terms introduced by KYE Discoverability Profile™ (kye-discoverability-v1). Names only; graph-traversal mechanisms and pruning rules are part of the patent track 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.
    • 06hubOntology

    Semantic layer — shared meaning, not just permission.

    Terms introduced by KYE Ontology Profile™ (kye-ontology-v1). Names only; semantic-resolution algorithms, false-equivalence detection heuristics, cross-profile reconciliation, tenant-overlay resolution and risk-weighted ontology traversal are part of the patent track and are not published.

  • KYE Ontology Profile™The semantic layer of KYE™. Defines shared meaning of entities, authorities, capabilities, scopes, states, decisions, evidence, profiles, connectors and sectors. Schemas make data valid; ontologies make data meaningful.
  • Ontology domainOne of twelve domains every KYE™ term must declare: entity, authority, capability, scope, state, decision, evidence, continuity, discoverability, connector, sector, certification.
  • PredicateStable predicate dictionary. New predicates require an RFC. Examples: grants, requires, constrains, evidenced_by, acts_on_behalf_of, equivalent_to, related_not_identical, not_equivalent_to.
  • Mapping typeSix explicit categories: equivalent, related_not_identical, not_equivalent, aliased_by, subsumes, subsumed_by. A mapping of related_not_identical MUST list requires_additional_kye_objects.
  • KYE™ ontology termOne canonical term in the registry. Has domain, definition, preferred_name, aliases, related_terms, not_equivalent_to and profile_refs. Schema: ontology-term.json.
  • KYE™ ontology relationshipOne predicate triple (subject, predicate, object) with constraints + evidence requirements. Schema: ontology-relationship.json.
  • KYE™ ontology mappingExternal-system → KYE™ term mapping with mapping_type, confidence, and (for related_not_identical) the list of companion KYE™ objects required at runtime. Schema: ontology-mapping.json.
  • KYE™ Semantic AssertionA signed record bound to a runtime decision listing every term, mapping and predicate consulted; hash-chained into the audit ledger; included in the Continuity Evidence Pack™. Schema: semantic-assertion.json.
  • KYE Ontology Registry™Managed registry for terms, relationships, mappings and semantic assertions. Planned commercial layer.
  • KYE Semantic Authority Mapper™Maps OAuth scopes, IAM roles, payment mandates, legal delegations, healthcare consents, API permissions and sector terms into KYE™ without losing meaning.
  • KYE Semantic Graph™Graph view of the ontology + live instances; semantic-path search and risk-ranked traversal.
  • KYE Ontology Conformance™Conformance fixture suite + certification track for ontology-correct implementations.
  • JSON-LD contextRecommended semantic-interoperability serialisation. Published at https://kyeprotocol.com/schemas/jsonld-context.json. KYE™ is JSON-native at runtime and ontology-aware at the semantic layer.
    • 07routeOperating Model

    Adoption layer — from readiness to runtime control.

    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 part of the patent track 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 + readiness score in [0,1] + required profiles, gates and evidence. 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.
    • 08badgeAssurance

    Living lifecycle assurance — system cards become executable.

    Terms introduced by KYE Assurance Card Profile™ (kye-assurance-card-v1). Names only; assurance-card generation, runtime-evidence binding, review-automation, sector packs and use-case library recommendation algorithms are part of the patent track and are not published.

  • KYE Assurance Card Profile™The lifecycle assurance layer of KYE™. Turns runtime evidence into a living assurance record per delegated entity. System cards say what should be assured. KYE™ proves what happened.
  • KYE Assurance Card™Living lifecycle record per delegated entity — owner, accountable entity, intended use, prohibited uses, authority model, human involvement, provenance, performance + limitations, evidence, review cycle, decommissioning. Schema: assurance-card.json.
  • Assurance lifecycle stagesEight stages: design, pilot, deploy, monitor, incident_review, scope_change_review, retention_review, decommission.
  • KYE Human Involvement Plan™Schema-bound record of points where authorised humans must influence, direct, limit, approve, override or review an AI-enabled system. Bypass attempts denied at runtime + signed event emitted onto Signal Bus™.
  • Human involvement typesSix types: influence, direct, limit, approve, override, review.
  • KYE™ Provenance EvidenceProvenance + supply-chain dimension — model / dataset / tool / hardware / supplier / licence references with verification status. Schema: provenance-evidence.json.
  • KYE Assurance Review Cycle™Scheduled + event-triggered review windows. Ten triggers: scheduled, scope_change, new_capability, incident, risk_state_change, model_update, authority_change, supplier_change, licence_change, retention, decommission.
  • KYE™ Decommissioning PlanRetention windows, off-boarding step sequence, cascade-revocation scope, evidence-archival policy, post-execution verification. Schema: decommissioning-plan.json.
  • Off-boarding actionsEight named actions: revoke_authority, quarantine_credentials, rotate_keys, archive_evidence, notify_owner, notify_supplier, update_catalog, remove_from_runtime.
  • KYE Assurance Card Builder™Generate living assurance cards from KYE™ runtime objects. Planned commercial layer.
  • KYE Assurance Card Library™Discoverable library of governed AI use cases + assurance patterns. Planned.
  • KYE Human Involvement Planner™Define where authorised humans must review, approve, limit or override AI-enabled actions across the lifecycle. Planned.
  • KYE Provenance & Supply Chain Evidence App™Track datasets, models, tools, suppliers, licences and hardware lineage as runtime-bound evidence. Planned.
  • KYE Assurance Review Scheduler™Scheduled + event-triggered + scope-change + incident + retention + decommissioning review cycles. Planned.
  • KYE Governed Use Case Library™Sector-curated library of governed AI use cases linking authority records, gates, commit boundaries, decisions, evidence packs and assurance cards. Planned.
    • 09policyFormal Rules

    Rights, obligations, prohibitions, powers — enforceable.

    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 part of the patent track 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.
    • 10fact_checkAdmissibility

    Pre-action layer — before authority.

    Terms introduced by KYE Action Admissibility Profile™ (kye-action-admissibility-v1). Names only; admissibility-scoring algorithm, prohibited-action-class detection heuristics, intent-ambiguity detection, source / data admissibility decision rules, agent-proposal quarantine triggers and sector admission packs are part of the patent track and are not published.

  • KYE Action Admissibility Profile™The upstream pre-action layer of KYE™. Checks whether a proposed action is admissible into the authority pipeline before any authority, formal-rule or commit-boundary check runs. Attribution alone is late.
  • KYE™ Proposed ActionThe candidate action submitted to KYE Admission Gate™ for admissibility check before any authority decisioning. Carries origin, intent refs, requested capability, target resource, preconditions and risk flags. Schema: proposed-action.json.
  • KYE Admission Gate™Pre-admission gate placed UPSTREAM of authority gates. Declares applicable scopes, decision policy, required checks, evidence requirements and signal events.
  • Admissibility decision valuesSix values: admit, reject, require_clarification, require_human_review, quarantine, route_to_authority_check.
  • Inadmissibility classesFifteen classes the engine actively detects: invalid_intent, ambiguous_intent, out_of_scope_proposal, prohibited_action_class, disallowed_data_source, inadmissible_evidence, unsafe_tool_path, coercion_signal, incentive_conflict, continuity_break, policy_ineligible_action, missing_authority_context, missing_principal, missing_accountable_owner, unsupported_jurisdiction.
  • KYE™ Admissibility DecisionSigned verdict for a proposed action with checked dimensions, next-step routing, obligations and reference to the admissibility-evidence record. Schema: admissibility-decision.json.
  • KYE™ Admissibility EvidenceHash-chained record of the inputs and signals consulted at admission time; offline-verifiable against the published JWKS. Schema: admissibility-evidence.json.
  • KYE Admissibility Engine™Runtime engine performing the admission check across intent, source, data, policy and rule dimensions. Planned commercial layer.
  • KYE Pre-Action Filter™Product-friendly synonym for the admission surface in marketing copy.
    • 11ruleCompliance

    Mapping rail, OSCAL, frameworks.

  • Control mappingThe named link from a protocol artefact to a regulatory control — e.g., evidence pack → SOC 2 CC7.2. 266 mappings across 13 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.
  • ProfileA scoped overlay of the spec for a specific sector or use case — kye-payments-1.0, kye-custody-1.0, etc. 50 v1.0 profiles.
  • Non-goalsThings the protocol explicitly does NOT do — replace SCA, replace tokenisation, run fraud scoring, etc. Documented in the threat-model page.
    • 12workspace_premiumProgramme

    Conformance, certification, partner ladder.

  • Conformance packThe 41 black-box fixtures any implementation runs to demonstrate spec compliance. Reproducible on a laptop; deterministic outputs.
  • KYE Self-Tested™L1 of the conformance ladder. You run the fixtures locally and self-declare results.
  • KYE Self-Attested™L2. Signed self-attestation (Ed25519, JWS) bundled with fixture results.
  • KYE Conformant™L3. Programme-reviewed conformance report + badge + registry listing.
  • KYE Certified™L4. Third-party-audited certification by an approved firm. Annual revalidation.
  • KYE Cloud Gateway™The optional commercial layer: hosted Registry, Validator, Evidence Vault, Conformance Runner. The protocol works without it.
  • RFCThe four-stage process for landing changes: discussion → spec PR → conformance fixture → sign-off. Documented on the working groups page.
    • 13extensionExternal standards we compose with

    For reference, not redefinition.

  • 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.
    • Where to go next

    Adjacent reading.

    category The 6 primitives → menu_book Vocabulary architecture Protocol menu_book Whitepaper help FAQ

    Ready to see your AI agents flagged?

    Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.

    rocket_launch Apply for pilot → science Try the sandbox →