created 20 October 2026 · last modified 2026-10-26
Build · the implementations
Three implementations, pinned to one tag.
KTP is specified in text. Three public implementations now build against the v2.1.0 tag, each with its own maintainer and its own limits. None is certified. Each says what it does and does not do, and so does this page.
Every line about an implementation is its README’s wording, checked 2026-10-26. None of this code runs here.
The evidence ladder
What you can verify
Specification
Public · tagged
27 RFCs at v2.1.0, archived at Zenodo with a DOI. Interfaces and conformance vectors are fixed; formulas are implementation-defined.
KIL and KAG carry draft conformance runners that report their own cases as unsupported and qualification false. A tagged release that runs the published vectors is the bar.
One at the semantics, one at the ingress, one at the action. Each is its maintainer’s work, hosted or published under their own name; what it does and what it is not are their words.
Implementation 01 of 03 · Python · Apache-2.0Informative reference library · 2.1.0 on PyPI
Implements selected deterministic KTP v2.1.0 protocol primitives in Python. It returns immutable protocol values and factual results, not product instructions.
Does: deterministic KTP validation and evaluation, Decision Record projection, Trust Proof operations, Soul Constraint document parsing, Trajectory parsing and adjacent-pair assessment.
Is not: an official KTP SDK, and not certified, maintained or endorsed by NMCITRA. Not an enforcement point. “A Trust Proof is not permission to perform an action.”
Pins:KTP_SPEC_TAG == "v2.1.0" and the tag’s commit; the pinned source is the immutable release, “not upstream main or informative website text.”
Service:kinetic-trust-service 2.1.0 is an optional package of synchronous composition helpers built on the library. “Despite its name, it is not a server or daemon.”
An implementation of KTP at the infrastructure boundary: signed-state verification, per-action authorization between authoritative refreshes, and enforcement at a real ingress with evidence that the action did or did not happen.
Does: the external-authorization adapter, the authorizer, the signed-state verifier, the decision engine and the evidence joins. Vendor-neutral; anything that wires a specific product lives elsewhere.
Is not: the specification (that is ktp-rfc, pinned by tag) or a deployment guide. Tests “do not run Envoy/Kubernetes, demonstrate production isolation, or qualify the adopted KTP conformance suite.”
Status: experimental, review by 2026-12-10. “Nothing here is a conformance claim until a tagged release runs the published vectors and says so.” Built first by Mike; hosted by the KTP project.
An implementation of KTP at the point where an authorized decision becomes a real action: the gateway binds one signed decision to one exact operation, holds it to the decision at release, and records what happened.
Does: closed ingress, the fixed-action library, transport identity, actor and decision enforcement, the execution reducer and the evidence recorder. No third-party dependencies.
Is not: KIL. “KIL verifies signed state and decides per action; KAG holds the action to that decision.” Separate repositories; KAG depends on KIL’s published interface, never its internals.
Status: experimental, review by 2026-12-10. Comparison baseline v2.1.0; the draft execution and evidence reference is RFC PR #139. “Qualification remains false.”
From the semantics to the action, and then the part no package supplies. The READMEs draw the same line; this table repeats it.
01Kinetic Trust Library
Deterministic evaluation, Decision Record projection, Trust Proof operations. The semantic layer.
02KIL
Verifies signed state and decides per action at a real ingress, between authoritative refreshes.
03KAG
Holds one exact action to one signed decision at release, and records what happened.
··Your own code
Networking, storage, retries, source authentication, key lifecycle, observability, human workflows, enforcement. “Neither package supplies these capabilities.”
The mechanism
What a conformant authorize() runs
The same sequence every time: identity, the Soul veto, Context Signals into Risk Factors, the Trust Score, the tier, the Zeroth Law check, the decision, the record. The Trust Score shown is the public form; the full instrumented form is held in private research.
authorization flow · what the SDK runs on every authorize() call
the equation, with a worked exampletrust tiers · what each floor permits
The Soul veto
Soul is a binary veto evaluated before any continuous trust calculation. S = 0 means the action is structurally impossible; no E_trust value can override it. The veto encodes Indigenous data sovereignty (TK Labels), OCAP and CARE principles, and community-controlled constraints. It is the place in the system where ethics is treated as physics.
S = 0 → silent veto, regardless of E_trust
Build against the tag
Install, as the projects say to
Reference KTP by tag, never by main. Each block is the project’s own instruction; each note is its own limit.
Package major.minor follows the implemented KTP RFC series; patch versions advance independently. “If you are unsure, start with Library and add Service only when EvidenceHost or Issuer removes composition code you would otherwise maintain.”
Python 3.12. The README: tests cover modeled decisions, signed-state rejection, harmless local HTTP fixtures and recorder joins; “no key generation, network runtime or target effects occur.”
KAG, from source
bash
git clone https://github.com/nmcitra/kag.git
cd kag
bash scripts/check-all.sh
Go 1.27.1 or later. The README: “Passing core tests provides modeled evidence only.” No report is a signature, a deployed safety proof or a release authorization.
Library or Service · the library’s own guidance
You need deterministic KTP validation and evaluation, Decision Record projection, Trust Proof operations, Soul Constraint document parsing, or Trajectory parsing.
Library directly
You want Service’s ordered, fail-first EvidenceHost for product-supplied adapters, or its Issuer to compose one evaluation with Decision Record projection and, when Soul-clear, proof issuance.
Library plus Service
You need networking, storage, retries, source authentication, key lifecycle, observability, human workflows, action execution or enforcement.
Product-owned code around either
Conformance
In their words
Conformance applies to a named, versioned application and its deployment, not to a library by itself. The levels are cumulative. This is orientation, not a certification checklist; the controlling requirements are KTP-Conformance v2.1.0.
Basic
An operational Oracle interface and product-owned evidence sources; secure key and Trust Proof lifecycle; a real PEP that intercepts every protected request, validates proofs, enforces the Zeroth Law before the protected effect, and logs the result; queryable decision records retained for at least 30 days; conservative failure handling; published evidence for the required Basic tests.
Standard
Everything in Basic, plus a three-or-more-node Oracle mesh with 2-of-3 threshold signing; all six weighted Risk Factors and the independent Soul veto; velocity, lineage, Proof of Resilience, sponsorship and federation behavior; five-tier and Soul enforcement with graceful degradation; tamper-evident Decision Geometry and one-year decision retention; automated key rotation; published Standard test evidence.
Full
Everything in Standard, plus at least five Oracle nodes across at least three regions with 3-of-5 threshold signing; redundant failover sensing and Indigenous Data Sovereignty controls; all-zone layered enforcement within the required latency; externally anchored multi-region records with seven-year retention; HSM-backed keys; formal security review, penetration testing, incident response; third-party certification.
KIL, todayThe draft component report: all 38 pinned runtime cases are unsupported for complete profile semantics. “Synthetic charge is not A/E; denial is not a signed silent veto. The 26 schema vectors are unexecuted metadata, not conformance evidence.”
KAG, todayThe draft runner: twelve modeled matches and eight unsupported cases are expected; “qualification remains false and the explicit qualification command exits 1.” Modeled matches are not production conformance, security clearance, signing approval or release qualification.
Honest scope
Where it is, where it goes, the bar
Where it is.Three public implementations, each experimental or informative by its own description, each pinned to the v2.1.0 tag. The library is on PyPI; KIL and KAG are source-only imports with draft conformance runners.
Where it goes.v3.0.0 “Ostrom”, planned for December 10, 2026, not committed: the software-substrate execution profile (#124, PR #131), consequential-action execution and evidence (#129, PR #139), and Robin’s eleven proposals (#147–#157) with their RFC pull requests.
The bar.A tagged release that runs the published vectors and says so. No implementation has published one. Until then every claim on this page is modeled, observed or author-reported, and says which.
