Skip to content

Specifications

The complete technical blueprint for the Kinetic Trust Protocol

The KTP specification suite defines every aspect of the protocol—from cryptographic primitives to governance mechanisms. These documents are the authoritative reference for implementers, auditors, and researchers.

Where the specifications live

Every normative artifact is in the repository, outside this documentation site: the RFC set in rfcs/, the two standalone normative documents in specifications/, the wire schemas in schemas/. This site describes them and links to them. Where the two disagree, the repository is right.

  • RFCs on GitHub

    27 Request for Comments documents covering every protocol component. Browse the source.

    Browse RFCs

  • Kinetic Envelope

    A ≤ E evaluated per action against the kinematics of the request: graduated deautomation, the kinematic veto, and a seven-vector conformance suite.

    Read the spec

  • Deployment Profile

    The declaration surface: one object carrying every declaration the series requires of a deployment — the Risk Factor bridge, feed mapping, aliases, normalization, and the declared parameters.

    Read the spec

  • Schemas

    The seven wire schemas — Risk Factors, Trust Proof, deployment profile, and the rest — with their absolute $id URLs.

    View Schemas

  • Blue Zones

    A pointer to KTP-Zones: the zone gradient, what an operator guarantees, and how trust crosses a border.

    Blue Zones

  • Identity

    A pointer to KTP-Identity: identity as a trajectory, the proof carried for it, attestation and revocation.

    Identity

Choose Your Path

Different readers need different entry points. Select the journey that matches your goals:

🏗️ Implementer's Path

Building a KTP-compliant system? Follow this sequence:

Foundation → Identity → Environment → Compliance

  1. KTP-Core → KTP-Crypto → KTP-Transport
  2. KTP-Identity → KTP-Signals
  3. KTP-Zones → KTP-Federation
  4. KTP-Conformance → KTP-Audit

🔍 Auditor's Path

Validating a KTP implementation? Focus on these areas:

Compliance → Security → Governance

  1. KTP-Conformance → KTP-Audit
  2. KTP-Threat-Model → KTP-Crypto
  3. KTP-Governance → KTP-Human

🎓 Researcher's Path

Understanding the theory behind KTP? Explore:

Philosophy → Mechanics → Innovation

  1. KTP-Core (Sections 1-4) → Constitution
  2. KTP-Signals → KTP-Attenuation → KTP-Information
  3. KTP-Oracle → KTP-Celestial

Specifications by Domain

The bedrock protocols that define KTP's core architecture.

Specification Status Description
KTP-Core Stable The Zeroth Law, Trust Scores, A ≤ E constraint
KTP-Crypto Stable Cryptographic primitives and algorithms
KTP-Transport Stable Network transport and messaging protocols
KTP-Identity Stable Vector Identity and trajectory-based authentication

Start Here

If you're new to the specifications, begin with KTP-Core. It establishes the foundational concepts that all other RFCs build upon.

How trust is measured, computed, and flows through the system.

Specification Status Description
KTP-Signals Stable Context Signals specification (1,644 signals)
KTP-Attenuation Draft Capability attenuation: constraint types and real-time application
KTP-Information Draft Trust signal propagation and analysis
KTP-Relational Draft Agent-to-agent trust relationships
KTP-Oracle Experimental Trust oracles and external attestation
Understanding Trust Flow

Trust in KTP flows through a measurement → computation → enforcement pipeline:

  • Signals capture the 1,644-signal environmental state
  • Signal propagates trust changes through the network
  • Gravity enforces constraints as agents approach limits
  • Relational tracks inter-agent trust dynamics

Where agents operate and how trust boundaries are established.

Specification Status Description
KTP-Zones Draft Blue Zone architecture and governance
KTP-Federation Draft Cross-domain trust federation
KTP-Sensors Draft Environmental sensor requirements
KTP-Celestial Experimental Universal time and coordination
The Zone Gradient

Environments range from maximum constraint to no enforcement:

  • Deep Blue: Maximum constraint, cryptographic guarantees
  • Blue: High constraint, monitored operations
  • Cyan: Moderate constraint, verified agents
  • Green: Light constraint, basic verification
  • Wild: No KTP enforcement

Rules, oversight, and compliance mechanisms.

Specification Status Description
KTP-Governance Draft Protocol governance and amendment
KTP-Human Stable Human oversight requirements
KTP-Enforce Draft Enforcement mechanisms
KTP-Conformance Stable Conformance testing requirements
KTP-Audit Stable Audit trail and non-repudiation
Governance Hierarchy

KTP governance follows a clear hierarchy:

  1. Constitution — Immutable foundational law
  2. Core RFCs — Stable specifications requiring deprecation process
  3. Extended RFCs — Evolving specifications under active development
  4. Implementation Guidance — Non-normative best practices

Evolution, resilience, and system maintenance.

Specification Status Description
KTP-Migration Draft Version migration protocols
KTP-Recovery Draft Trust recovery after incidents
KTP-Emergency Draft Emergency response procedures
KTP-Deprecation Stable Deprecation and sunset process
KTP-Legacy Draft Legacy system integration
KTP-Provenance Draft Model and data provenance tracking
Lifecycle Principles

KTP systems must plan for change:

  • Migration: Smooth transitions between protocol versions
  • Recovery: Rebuilding trust after compromise
  • Emergency: Rapid response to active threats
  • Deprecation: Graceful retirement of old features

Threat modeling and security analysis.

Specification Status Description
KTP-Threat-Model Stable Comprehensive threat analysis
KTP-Problems Draft Known issues and mitigations
KTP-Privacy Draft Privacy-preserving computations
Security Considerations

Every KTP implementation must address:

  • Gaming: Agents attempting to inflate trust scores
  • Collusion: Coordinated attacks across agent networks
  • Sybil: Fake identity proliferation
  • Oracle Manipulation: Corrupting external trust sources

Specification Status Guide

Status Icon Meaning
Stable Production-ready. Breaking changes require formal deprecation process.
Draft Under active development. May change significantly before stabilization.
Experimental Research stage. Not recommended for production use.

Risk Factors Schema

The Risk Factors object — formerly the Context Tensor; renamed risk-factors.json by the v2 schema rewrite — carries the six weighted inputs to the risk aggregate R. Six keys, each a number in [0, 1], all required, no others accepted:

Key What it measures
evidence_density Weight and density of presence in the environment
trust_trend Rate of change of standing, and its direction
adversarial_pressure Measured adversarial stress on the environment
moment_criticality Criticality of the current moment or operational phase
update_resistance How hard the trust value is to move — the depth of the evidence base behind current standing
attestation_coverage How much of the agent's activity is witnessed and attestable

The Soul veto is evaluated before aggregation and is not a term in it — six plus a veto, never seven. It has its own schema, soul-constraint.json.

For the full JSON schema definition, see risk-factors.json.

Quick Reference

Most Referenced

KTP-Core · KTP-Identity · KTP-Zones · KTP-Signals

Complete RFC Index

For a flat listing of all specifications, visit the GitHub RFC directory.

Where to Go Next

  • Deep Dive: Blue Zones

    Understand the architecture of trust environments in detail.

    Blue Zones

  • Data Structures

    Explore the JSON schemas that define KTP's core data formats.

    Schemas

  • Back to Basics

    Need a conceptual refresher before diving into specs?

    Core Concepts

  • Start Building

    Ready to implement? Get the developer guide.

    Developer Guide