A login session, an OAuth scope, a payment mandate, a legal delegation, a healthcare consent, an API permission and an AI-agent capability are not the same thing. KYE™ maps these concepts without collapsing them into one vague permission model.
KYE Ontology Profile™ defines how entities, authorities, capabilities, scopes, states, decisions and evidence relate across systems, sectors and profiles. Schemas make data valid. Ontologies make data meaningful.
The ontology layer is not a replacement for any of the others. It gives them shared meaning so different systems can agree on what an entity, agent, authority, capability, state, decision or evidence pack actually is.
Domains carve the semantic surface so terms cannot drift across categories silently. delegated_payment_authority lives in authority; payment_initiation lives in capability; amount_limit lives in scope. Mappings between domains are explicit.
Every external-system term mapped into KYE™ declares exactly one mapping type. The runtime enforces it. An OAuth scope may be related_not_identical to a delegated payment authority — presenting the scope alone, without the companion authority record, is denied.
When does it apply?
Source and KYE™ term are interchangeable for runtime purposes. Rare in practice; usually only safe within a single trust domain.
Example: oidc_id_token.sub ≡ kye:term:entity:human when both reference the same KYE-issued URN.
Runtime effect: presenting either term resolves to the same KYE™ term. No companion object required.
When does it apply?
The source term MUST NOT be treated as the KYE™ term. Asserting equivalence is itself a policy violation.
Example: oauth.scope:profile.read ≠ kye:term:legal:power_of_attorney.
Runtime effect: deny with reason code semantic_equivalence_rejected.
When does it apply?
A label-level alias only — same KYE™ term under a different display name.
Example: "payment mandate" alias of kye:term:authority:delegated_payment_authority.
Runtime effect: presenting either resolves identically; no policy gate.
When does it apply?
The source term is a narrower meaning than the KYE™ term.
Example: card_purchase subsumes the broader kye:term:capability:payment_initiation only for card-rail subset.
Runtime effect: resolves to the KYE™ term but only within the declared narrow scope.
When does it apply?
The source term is a broader meaning than the KYE™ term.
Example: generic.access subsumed_by kye:term:authority:delegated_payment_authority — presenting the broad term is insufficient.
Runtime effect: require additional KYE™ objects to narrow the resolution; deny if absent.
ontology-profile.json — KYE Ontology Profile™ manifestontology-term.json — one canonical termontology-relationship.json — (subject, predicate, object) triple with constraintsontology-mapping.json — external term → KYE™ term mapping with mapping_type + companion-objectssemantic-assertion.json — decision-bound semantics, hash-chained into the audit ledgerjsonld-context.json — JSON-LD context for semantic interoperabilityRDF / OWL export is supported as an optional serialization for research, public-sector, and regulator integrations. KYE™ is JSON-native at runtime and ontology-aware at the semantic layer.
Open under Apache 2.0
Commercial / patent track
book implies prepare-only, reserve-only, or purchase authority — preventing intent / authority drift.KYESemanticAssertion, hash-chained into the audit ledger; a regulator can re-derive what the decision meant, not just what it returned.KYE™ is JSON-native at runtime, JSON-LD-ready for semantic interoperability, and graph-aware for authority discovery, continuity and evidence.