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.

---

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

[ Browse RFCs](https://github.com/nmcitra/ktp-rfc/tree/main/rfcs-txt){ target="_blank" }

---

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](https://github.com/nmcitra/ktp-rfc/blob/main/specifications/kinetic-envelope.md)

---

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](https://github.com/nmcitra/ktp-rfc/blob/main/specifications/deployment-profile.md)

---

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

[ View Schemas](https://github.com/nmcitra/ktp-rfc/tree/main/schemas)

---

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

[ Blue Zones](blue-zones.md)

---

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

[ Identity](identity.md)

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

Foundation

The bedrock protocols that define KTP's core architecture.

Start Here

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

Trust Mechanics

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

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

Environment

Where agents operate and how trust boundaries are established.

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

Governance

Rules, oversight, and compliance mechanisms.

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

Lifecycle

Evolution, resilience, and system maintenance.

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

Security

Threat modeling and security analysis.

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

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:

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{ target="_blank" }.

Where to Go Next

---

Understand the architecture of trust environments in detail.

[ Blue Zones](blue-zones.md)

---

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

[ Schemas](https://github.com/nmcitra/ktp-rfc/tree/main/schemas)

---

Need a conceptual refresher before diving into specs?

[ Core Concepts](../learn/core-concepts.md)

---

Ready to implement? Get the developer guide.

[ Developer Guide](../implement/developer-guide.md)