KTP/
github
created 26 October 2026 · last modified 2026-10-25
Built with others

The people who have changed the protocol.

KTP is written in public and changed in public. What each person changed is on the record, issue by issue, under the name they use there. The invitation at the end is the same one they took.

Contributor 01 of 03@martherus

Robin Martherus

Tamed Autonomy, the SHOULD layer above KTP, eleven proposals for v3.0.0, and a public Python reference library.

KTP asks whether the environment CAN support an action. Tamed Autonomy, Robin’s work, asks whether the purpose SHOULD be pursued at all. He studied v2.1.0 by building against it, filed eleven proposals from that study with the RFC pull requests to carry them, and published the Python reference library that pins to the v2.1.0 tag.

Contributor 02 of 03@gatekeeper454

Mike Storm

KIL and KAG, the two implementations at the infrastructure boundary, and the execution profile that binds one decision to one exact action.

Before KTP had a name, Mike stretched the ideas and asked the questions that made them click. He built KIL, the Kinetic Infrastructure Layer, and KAG, the Kinetic Action Gateway, both maintained by him and hosted by the project, and he brought the software-substrate execution profile and the consequential-action evidence work to the RFC, with the supplier-neutral editorial that landed first.

Contributor 03 of 03@kimosmond-del

Kimberly Osmond

Induced Conservatism: the adversary who wants denial, and uses KTP’s own fail-closed rules as the weapon.

The threat model had adversaries who want permission. Kimberly named the one who wants denial: manufacture uncertainty, dispute or stress until the protocol’s conservative rules deny, deautomate or hibernate legitimate work, and the attack succeeds when KTP behaves exactly as specified. TM-D-005 gives it an ID and a bound; the two proposals that follow it target v3.0.0.

Your turn

The fourth name could be yours.

Five rules keep a contribution from stalling. They are the whole of the contributor rails, and every person above worked inside them.

  1. 01Text, not code. The RFC repository holds normative text, schemas and conformance vectors; implementations live in their own repositories and are cited by a pinned release.
  2. 02Issue first, on a clock. Every change starts as an issue with a class; a maintainer labels it and the clock in DECISIONS.md starts. Nothing is approved before its floor.
  3. 03Pin to tags. Reference KTP by tag, never by main, and say which release you built against.
  4. 04Interfaces and vectors are fixed; formulas are implementation-defined. Add the vectors any formula would have to satisfy, never the formula.
  5. 05State the evidence limit. Every claim says whether it is modeled, observed or validated.