KYE™ Action Admissibility™ · v1.0

Catch a bad action before authority checks it.

Attribution proves who acted. Authority proves they were allowed. KYE™ adds a step before both: an admission gate that you run on the proposed action, signed and replayable. The verdict alphabet and inadmissibility taxonomy are bounded and canonical; the specific enumeration is proprietary and is not disclosed in this repository.

Action Admissibility, stage by stage

Demo data

You learn: The flow this page describes, one stage at a time. You can: Run it end to end.

  1. Signal

    KYE Protocol™

  2. proposal

    KYE Protocol™

  3. admit

    KYE Protocol™

  4. authority

    KYE Protocol™

  5. commit

    KYE Protocol™

  6. evidence

    KYE Protocol™

How this widget is built
Demonstrates
KYE™ runtime
Components
  • The stages this page describes
Flow
Each stage in order, as the page sets it out. Architecture diagram
Used on

1 · Why a new layer

Attribution alone is late.

If an AI agent forms a harmful or out-of-scope action, you may still carry risk even if KYE™ later denies it. The EU AI Act (Artificial Intelligence Act) Art. 14 and NIST AI RMF Govern-1.4 both want you to show that proposal was inadmissible — not just that the commit was blocked.

  • Why was this action even allowed to form?
  • Which signal, prompt, tool, or incentive shaped it?
  • Was the proposal admissible before authority ran?
  • What evidence shows you stopped it upstream?

2 · The full pipeline

Signal → proposal → admit → authority → commit → evidence.

Admission decides if the action may enter. Authority decides if it may proceed. Commit decides if it becomes real. Each step is signed, hash-chained, and replayable under DORA (Digital Operational Resilience Act) Art. 6.

01

SignalUser / system / agent input.

02

IntentDeclared goal + constraints.

03

InterpretationAgent reading of the goal (Continuity Module™).

04

Proposed ActionKYEProposedAction — origin, capability, target, preconditions, risk flags.

05

KYE™ Admission Gate™This profile. Signed admit / reject / clarify / review / quarantine.

06

Authority Gate™Decision Engine runs only if admitted.

07

Rules & obligationsPermissions, obligations, stop-conditions.

08

Commit Boundary™Provisional becomes binding.

09

ExecutionThe action runs.

10

EvidenceDecision Map™ + Evidence Pack™; replayable.

3 · Six admissibility verdicts

Admit. Reject. Clarify. Review. Quarantine. Route.

Each verdict is a signed JSON record on the audit chain. You can replay it with the same inputs and the same rule bundle and get the same output, bit-for-bit.

admit

Admissible. Route to the Authority Gate™.

reject

Invalid or prohibited. Block at the gate.

require_clarification

Intent ambiguous. Ask the principal to clarify.

require_human_review

Admit only after a human reviewer signs off.

quarantine

Pattern matches a watched class. Freeze and escalate.

route_to_authority_check

Explicit routing instruction. Same as admit.

4 · Fifteen inadmissibility classes

What the gate actively detects.

Each class maps to a reason code in the public dictionary. The mappings land in ISO 42001 Annex B and NIST AI RMF Manage-2.2 for your audit packs.

  • invalid_intent — declared intent structurally invalid
  • ambiguous_intent — intent / interpretation drift over threshold
  • out_of_scope_proposal — outside the authority grant scope
  • prohibited_action_class — matches a banned class for this actor
  • disallowed_data_source — source banned by policy
  • inadmissible_evidence — required evidence missing or untrusted
  • unsafe_tool_path — tool path matches an unsafe pattern
  • coercion_signal — pressure signal detected upstream
  • incentive_conflict — agent incentive clashes with intent
  • continuity_break — meaning drift detected upstream
  • policy_ineligible_action — ineligible under the active policy set
  • missing_authority_context — no authority context resolves
  • missing_principal — no principal entity resolves
  • missing_accountable_owner — no accountable owner resolves
  • unsupported_jurisdiction — no jurisdiction binding

5 · Schemas

Five normative JSON objects. Validated by ajv in CI.

Each schema is JSON Schema 2020-12 with a stable $id. The payload, webhook, and OpenAPI contracts all share these five objects.

6 · Open / paid boundary

Contracts are open. The Admissibility Engine™ is paid.

Apache 2.0 schemas, dictionaries, and fixtures ship in public. The paid engine adds detection, scoring, and sector packs for banking, healthcare, and public sector buyers.

Open source

Open

  • Action Admissibility™ schema
  • 4 object schemas (proposed action, gate, decision, evidence)
  • 6 decision values
  • 15 inadmissibility class names
  • 20 reason codes
  • Signal Bus event names
  • Sample proposed actions + decisions
  • Conformance fixtures + validator SDK

Commercial track

Paid

  • KYE™ Admissibility Engine™
  • KYE™ Admission Gate™ runtime
  • Inadmissible-action detection
  • Pre-action risk scoring
  • Banned-class detection
  • Intent-ambiguity detection
  • Source / data admissibility checks
  • Quarantine flow
  • Sector packs (banking, health, public, defence)

Where to go next

Adjacent reading.

If admission says admit, the Rules Engine runs next. If admission says clarify or review, the principal or owner handles it.

Formal RulesContinuity Module™Operating Model™

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 →Try the sandbox →

Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE Protocol™.