Kinetic Trust Protocol (KTP) - Core Specification¶
This document specifies the Kinetic Trust Protocol (KTP), a framework for dynamic, environment-aware authorization of autonomous agents. KTP replaces static permission models with environment-derived constraints that adapt in real-time to environmental conditions.
The protocol introduces the concept of a Trust Score derived from environmental sensors, a Trust Proof token that travels with each request, and a Silent Veto mechanism that automatically constrains agent capabilities when environmental stability degrades.
Introduction¶
The digital world is experiencing an explosion of autonomous agents - AI systems that act at machine-speed, make decisions without human oversight, and control critical infrastructure. Traditional authorization systems, designed for human-speed interactions, are fundamentally inadequate for this new reality.
The Problem with Static Authorization¶
Current authorization systems suffer from three critical flaws:
-
The Passport Fallacy: They assume that possession of a credential (API key, token, certificate) equals proof of identity. This fails when credentials are stolen, as there is no mechanism to detect that the presenting entity is not the original holder.
-
The Static Fallacy: They verify permissions at time T and assume those permissions remain valid at T+1. In the millisecond gap between verification and action, the environment may have changed dramatically (network compromise, capacity exhaustion, attack initiation).
-
The Vacuum Fallacy: They treat authorization as independent of environmental conditions. A credential that permits "delete database" grants the same permission whether the system is idle or at 99% capacity under active attack.
These flaws create catastrophic risk in agent-heavy environments. An autonomous agent can execute thousands of API calls per second. If even 0.1% of those actions are destructive in context, the damage compounds exponentially before any human can respond.
The Environment-Based Solution¶
KTP addresses these flaws by treating authorization as an environmental problem rather than a policy problem. The key insight is:
This is expressed mathematically as the Zeroth Law:
Where A is the intrinsic risk of the requested action and E is the current capacity established for the operation and environment; for software agents this is the Effective Trust Score of the environment-agent relationship.
Instead of asking "Does this agent have permission?", KTP asks "Can this environment safely support this action right now?"
The environment becomes the final authority. Just as friction vetoes a sprinter's attempt to run on ice, environmental constraints veto an agent's attempt to act beyond the system's current capacity.
Software-agent standing, Proof of Resilience, lineage, and tiers in this document MUST NOT be converted into a general score or rank for people. Human participation follows [KTP-HUMAN] and specifications/human-eligibility.md: eligibility is specific to an operation, and current operational capacity is a separate requirement. Every actual executing actor remains subject to Soul, the unconditional capacity veto, applicable grants, and all tighter constraints.
Requirements Language¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terminology¶
This section defines terms used throughout this specification.
Action Risk (A): A numeric value (0-100) representing the intrinsic risk of a requested action. Higher values indicate more dangerous actions (e.g., "read public data" = 10, "delete database" = 85).
Adaptive Dormancy: The progressive reduction of agent capabilities as environmental conditions degrade. Agents "hibernate" rather than fail.
Base Trust (E_base): A numeric value (0-100) representing a software agent's intrinsic capability, derived from its Proof of Resilience and lineage. It is not a human score.
Blue Zone: A network segment where KTP is enforced. Agents within Blue Zones operate under environment-derived constraints.
Context Tensor: Retired name for what is now split into Context Signals (the measurement catalogue) and the Risk Factors (six weighted inputs plus the Soul veto). See Section 6.
Data Sovereignty: The principle that data is subject to the laws, customs, and governance structures of the nation or community from which it originates or to which it pertains.
Effective Trust Score (E_trust): The software agent's final Trust Score after environmental deflation, calculated as E_base * (1 - R). It supplies E for that agent's capacity check. Human operational E is established separately under the reviewed adapter.
Kinetic Permission: Authorization that depends on real-time environmental state rather than static credentials.
Lineage: The evolutionary history of an agent, from Sponsored (dependent on sponsor) through Independent (building own mass) to Guarantor (fully autonomous).
Policy Decision Point (PDP): A component that evaluates Trust Proofs and makes authorization decisions based on A <= E.
Policy Enforcement Point (PEP): A component that enforces PDP decisions by allowing, blocking, or throttling agent actions.
Proof of Resilience: A cryptographically signed ledger of an agent's successful transactions in high-friction environments. See [KTP- IDENTITY].
Risk Factor (R): A normalized value (0-1) representing aggregated environmental stress. Derived from Context Signals.
Silent Veto: The automatic denial of an action when A > E_trust, without requiring human intervention.
Soul (Sovereignty Veto): The seventh named measurement, representing ethical, legal, and spiritual constraints of data or location. Unlike the six weighted inputs, Soul acts as a binary veto rather than a weighted contributor to the Risk Factor.
Soul Veto: The automatic denial of an action when sovereignty constraints are violated (S = 1), regardless of Trust Score. Takes precedence over the standard Silent Veto evaluation.
Sponsorship Bond: A cryptographic commitment where a high-mass entity stakes trust on behalf of a new, low-mass agent.
Trajectory Chain: A cryptographically linked chain of agent transactions, where each link includes agent signature, environment attestation, and previous state hash. See [KTP-IDENTITY].
Trust Leash: The metaphorical constraint on agent autonomy that tightens (shorter leash) as environmental risk increases.
Trust Oracle: A distributed authority responsible for calculating Trust Scores, signing Trust Proofs, and attesting to agent transactions.
Trust Proof: A signed token (extending JWT) that carries the current Trust Score, its velocity, and environmental context.
Trust Score: See "Effective Trust Score (E_trust)".
Trust Tier: A capability level (Admin Mode, Operator Mode, Analyst Mode, Observer Mode, Hibernation) determined by E_trust thresholds.
Trust Velocity (dE/dt): The rate of change of the Trust Score over time. Rapid negative velocity indicates deteriorating conditions.
Vector Identity: Identity represented as a trajectory (position + momentum) rather than a static credential (a "verb" rather than a "noun").
Zeroth Law: The foundational constraint A <= E: an agent's autonomy must never exceed the environment's stability.
Protocol Overview¶
Architecture¶
A KTP deployment consists of the following components:
+------------------------------------------------------------------+
| TRUST ORACLE MESH |
| +------------+ +------------+ +------------+ |
| | Oracle 1 |<-->| Oracle 2 |<-->| Oracle 3 | (threshold) |
| +------------+ +------------+ +------------+ |
+------------------------------------------------------------------+
| | |
v v v
+------------------------------------------------------------------+
| RISK FACTOR SENSORS |
| [evidence_density] [trust_trend] [adversarial_pressure] [...] |
+------------------------------------------------------------------+
| | |
v v v
+------------------------------------------------------------------+
| POLICY ENFORCEMENT POINTS |
| +----------+ +----------+ +----------+ +----------+ |
| | API GW | | Service | | IAM | | DB | |
| | | | Mesh | | | | Proxy | |
| +----------+ +----------+ +----------+ +----------+ |
+------------------------------------------------------------------+
| | |
v v v
+------------------------------------------------------------------+
| AGENT POPULATION |
| [Sponsored Agents] [Independent Agents] [Guarantor Lineages] |
+------------------------------------------------------------------+
| | |
v v v
+------------------------------------------------------------------+
| FLIGHT RECORDER (IMMUTABLE) |
| [Decision Geometry] [Attestations] [Trajectory Chains] |
+------------------------------------------------------------------+
Figure 1: KTP Architecture
Trust Oracle Mesh: A distributed set of Trust Oracles that collectively calculate Trust Scores and sign Trust Proofs. Threshold signatures (e.g., 3-of-5) distribute signing authority. Agreement on protected state requires the separate consensus contract in specifications/oracle-consensus.md; a signing threshold does not establish a unique history.
Context Signal Sensors: A sensor array that measures environmental reality across the catalogue's seven domains and feeds data to the Trust Oracles.
Policy Enforcement Points: Components that intercept agent requests, present Trust Proofs to the PDP, and enforce authorization decisions.
Agent Population: The agents operating within the KTP domain, at various stages of their evolutionary lineage.
Flight Recorder: An immutable log of all authorization decisions, including the full Decision Geometry for forensic analysis.
Flow¶
The basic authorization flow is:
-
Agent initiates a request (e.g., "DELETE /api/database/users")
-
PEP intercepts the request and extracts the agent's identity
-
PEP requests a Trust Proof from the Trust Oracle, or validates an existing Trust Proof attached to the request
-
Trust Oracle: a. Retrieves agent's E_base from Proof of Resilience ledger b. Retrieves current sensor values from Context Signals c. Calculates R using domain weights d. Calculates E_trust = E_base * (1 - R) e. Signs Trust Proof with Oracle key(s)
-
PDP evaluates A <= E_trust for the requested action
-
If A > E_trust: Silent Veto triggers, action is DENIED. Otherwise, the request continues through Section 6.7 (Aggregation Algorithm) and the remaining authorization checks; satisfying the capacity inequality alone does not permit an action.
-
Decision and full context are logged to Flight Recorder
-
Response returned to agent with Trust Proof for potential forwarding to downstream services
+--------+ +--------+ +--------+ +--------+
| Agent | | PEP | | Trust | | Flight |
| | | | | Oracle | |Recorder|
+---+----+ +---+----+ +---+----+ +---+----+
| | | |
| 1. Request | | |
|---------------->| | |
| | 2. Get/Validate | |
| | Trust Proof | |
| |---------------->| |
| | | 3. Calculate |
| | | E_base, R, |
| | | E_trust |
| | | |
| | 4. Trust Proof | |
| |<----------------| |
| | | |
| | 5. Evaluate | |
| | A <= E_trust | |
| | | |
| | 6. Log Decision | |
| |---------------------------------->|
| | | |
| 7. Response | | |
| (with Proof) | | |
|<----------------| | |
| | | |
Figure 2: KTP Authorization Flow
The Zeroth Law¶
Definition¶
The Zeroth Law is the foundational constraint of KTP:
Where:
A (Autonomy): The intrinsic risk score of the requested action,
expressed as a value from 0 to 100. This value is determined by
the action's potential impact and is assigned by the system
administrator or derived from action classification rules.
E (Environment): The current capacity established for the actual
actor, operation, and environment, on the same declared scale as A.
For software agents this is Effective Trust Score (E_trust),
calculated from agent history and environmental conditions.
For a human actor, an independently approved operational-capacity evaluation MUST establish comparable A and E for the actual request. Eligibility, a professional credential, a role, or a person's approval MUST NOT be substituted for E. The evaluation MUST bind its evidence, measurement profile, scope, and freshness; unresolved or incomparable capacity MUST deny the affected action. No personal E_base, tier, generation, or resilience accumulator is required or permitted as a substitute.
The inequality MUST be evaluated for every authorization request. It is not a policy that can be overridden by human intervention or emergency procedures. It is a physical constraint, analogous to the constraint that prevents a person from running faster than their muscles allow.
The naming "Zeroth Law" is intentional. Just as thermodynamics' Zeroth Law (thermal equilibrium) was recognized as more fundamental than the existing First, Second, and Third Laws, KTP's Zeroth Law precedes all other authorization considerations. Before asking "Is this action permitted by policy?", we must first ask "Is this action possible given the environment's constraints?"
Enforcement¶
Enforcement of the Zeroth Law is cryptographic, not administrative.
For software agents, the Trust Proof token contains: - The current E_trust value - The Trust Oracle's signature over E_trust - The timestamp of calculation
The PEP: - Verifies the Trust Oracle's signature - Checks that the Trust Proof has not expired - Looks up the Action Risk (A) for the requested operation - Evaluates A <= E_trust
If the Trust Proof signature is invalid, the action MUST be denied. If the Trust Proof has expired, a new Trust Proof MUST be obtained. If A > E_trust, the action MUST be denied (Silent Veto).
A human deployment MUST provide the reviewed authorization adapter and authenticated operation/capacity binding specified below. The same signature, current-evidence, ordinary-proof lifetime, sovereignty, and capacity requirements apply; human eligibility is not a replacement proof or a bypass.
There is no "emergency override" mechanism. A different, genuinely lower-demand action, a corrected factual assessment, or changed capacity or environmental conditions requires a fresh evaluation. Relabeling the same action, changing a score by fiat, or receiving human approval MUST NOT relax a veto. Software-agent standing may grow through the established evidence process; that process does not create personal trust points for a human.
This design is intentional. In an emergency, the natural human instinct is to override safety controls. This instinct is often catastrophically wrong. By removing the override capability, KTP forces systems to operate within their actual capacity, even when humans wish they could exceed it.
Trust Score Calculation¶
The E_base composition, historical standing, behavioral signals, and tier calculations in this section apply to software agents. They MUST NOT be applied to human principals, including human sponsors and reviewers. Human operation eligibility and separately evidenced capacity use the installed human policy and reviewed adapter described below.
Base Trust (E_base)¶
Base Trust represents intrinsic capability, independent of current conditions. It is composed of what an agent has done, who is currently accountable for it, and what others observe of it — and it is bounded by ceilings that reflect what it has not yet demonstrated.
E_base is a hundred-point allocation. The shares MUST sum to 100, and each term contributes at most its share. A share is the maximum a term contributes; it is not a multiplier on the term's score.
| Component | Share | Description |
|---|---|---|
| Proof of Resilience | 70 | Historical performance, especially under stress |
| External Root | 30 | The party currently accountable for the agent |
| Peer Signals | declared | Observations by other agents, where implemented |
- An agent with 10,000 transactions during crises has higher E_base than one with 100,000 transactions in calm conditions. Survival under adversity matters more than volume.
- Lineage generation does not contribute to E_base. It bounds it. See Ceilings below.
- Peer signals, where a deployment implements them, occupy a distinct declared term. See Peer Signals below.
Historical Proof of Resilience MUST NOT lose points merely because time passes or the agent is inactive. An invalid historical claim MAY be withdrawn through an authenticated, appended correction under the existing adjudication and consensus rules; elapsed time alone is not such evidence. This rule does not renew an expiring External Root instrument or erase other applicable ceilings and revocations.
Historical standing is not evidence that today's code, model, configuration, tools, permissions, and proposed operation remain within an assessed capability. Active deployments MUST additionally enforce the operation-scoped readiness prerequisite in specifications/operational-readiness.md. Readiness is neither another global score nor a new E_base component. It adds no standing credit and cannot override Soul, capacity, an earlier veto, or any stronger authorization constraint.
The External Root¶
E_base MUST include a term derived from a party that is externally accountable, exposed to loss, and able to revoke. No composition of E_base may consist entirely of terms the subject measures about itself.
The attesting party's own accountability MUST terminate, through a finite and declared chain, at a root outside the agent-trust graph — a physical-presence attestation, a legal entity, or a named human. A cycle of agents attesting for one another does not satisfy this requirement. The attestation MUST declare the chain's terminator and the chain's length, and the length MUST NOT exceed the deployment's declared hop bound, which MUST NOT exceed 12. An attestation whose terminator or chain length is undeclared, or whose chain exceeds the hop bound, computes this term as zero.
The instrument occupying this term changes with lineage stage. The share does not.
| Stage | Instrument | The attestor is exposed to |
|---|---|---|
| Sponsored (generation 0-2) | Live sponsorship bond: sponsor's E_base × stake percentage | the agent's future conduct |
| Independent, Guarantor (generation 3+) | One or more current external attestations | the accuracy of the claim |
At tether release the stake ends; the root does not. What replaces the bond is a current attestation — that a named, externally accountable party stands behind this agent now. The completed-tether record is retained as provenance in the agent's trajectory. It is not the anchor: a record of a completed tether states nothing about who is accountable at the time of evaluation. The sponsor's Ancestral Liability ([KTP-IDENTITY] Section 6.4) persists independently of this term; it is bond accounting, not a composition input.
An agent past Sponsored holding no unexpired, unrevoked attestation computes this term as zero.
An attestation MUST declare the attestor's exposure and the capacity it anchors. Exposure counts toward this term only insofar as it is irrecoverable and non-transferable: exposure that cannot be shed by abandoning the attestor's identity. The declaration MUST name the exposure's class — a named human's professional or legal liability; a license whose revocation attaches to its holder; posted non-recoverable collateral; a legal entity's declared irrecoverable assets. The class list is open; additions compose under the same cannot-be-shed test. An attestation declaring no exposure computes as zero. A declared exposure found not to exist, or found to be transferable, is misattestation.
An agent MAY hold concurrent attestations from distinct attestors. Where it does, this term is computed from the strongest single instrument. An anchor MUST NOT be a combination of attestors: instrument scores are never summed or otherwise aggregated across attestors. Concurrency is redundancy — a second attestation is a hedge against the withdrawal of the first, not an addition to it.
Attestations carry a validity period and MUST be renewed or replaced on expiry. An attestor withdrawing an attestation MUST state whether the withdrawal is for cause. Withdrawal for cause zeroes the instrument immediately. Withdrawal without cause renders the attestation irrevocably non-renewable; the instrument holds until the attestation's declared expiry, then computes as zero. The validity period the attestor declared at issuance is the notice period — no separate notice parameter exists. A for-cause claim that does not survive scrutiny is misattestation. A decline in the attestor's own standing does not zero the term; a finding of misattestation invalidates the attestation and debits the attestor.
The deployment MUST declare the adjudicator for findings of misattestation, including for-cause withdrawal claims. The adjudicator MUST be neither the attestor nor the subject agent. A finding MAY be recorded at any time before the attestation's declared expiry. Every state transition MUST be derivable from the recorded claim, the recorded finding, and the attestation's declared times.
A for-cause claim with no finding at the attestation's expiry lapses unresolved and MUST be recorded as unresolved. No debit is assessed on lapse; an unresolved claim does not become sustained or rejected by lapse of time. The instrument computes as zero in every branch — adjudication decides only whether the attestor is debited.
The Trust Proof MUST carry the instrument's status — current, or non-renewable following a withdrawal without cause — and the instrument's end time. The trust-proof schema carries these in the root_instrument claim, together with the declared exposure, capacity, terminator, and chain length.
Peer Signals¶
Where a deployment implements peer validation, peer signals occupy a distinct term. They MUST NOT be folded into Proof of Resilience or the External Root.
The deployment MUST declare the peer share it applies, within the range given in Section 5.5.5 (Peer Validation), in the Trust Proof. The remaining share is distributed across the base terms in their published proportions. A relying party MUST evaluate E_base against the declared share and MUST NOT compare magnitudes across deployments that declare different shares.
Peer signals MUST be independent of the base terms. A signal that duplicates information already captured by Proof of Resilience or the External Root is not admissible as a peer signal.
Where a deployment does not implement peer validation, the peer share is declared as zero and the base terms carry their published proportions unmodified.
Ceilings¶
E_base MUST NOT exceed the minimum of all applicable ceilings.
| Ceiling | Basis |
|---|---|
| 25 · 35 · 45 · 55 · 65 · 75 · 85 for generations 0-6; 100 for generation 7+ | Lineage generation ([KTP-IDENTITY] Section 8.4) |
| 40 · 80 · 95 by Identity Assurance Level | Identity proofing ([KTP-IDENTITY] Section 7.1) |
| 50 requires 1,000 transactions; 70 requires 10,000 | Trajectory length |
| 60 | No adversity exposure |
Specifications elsewhere in this series may define additional ceilings on E_base. Those ceilings compose under the same rule. Every ceiling applicable to an evaluation MUST be declared in the Trust Proof (the applicable_ceilings claim).
Each ceiling states an independent reason to withhold trust. Reasons to withhold do not average. A ceiling that does not bind an agent — the terminal generation ceiling of 100, which no composition of shares can exceed — imposes no limit of its own and leaves the remaining ceilings to govern.
Maturity raises a ceiling. It does not contribute standing. An agent that has advanced a generation has earned room to accumulate trust, not trust itself. No class of grant lifts a ceiling: standing issued by fiat — a genesis grant, an inheritance bonus — is bounded by the same minimum as standing that is earned.
Base Trust Calculation¶
Let w_p be the declared peer share in points, 0 where peer
validation is not implemented. The three shares sum to 100:
PoR_share = 70 × (100 − w_p) / 100
Root_share = 30 × (100 − w_p) / 100
Peer_share = w_p
Each term contributes at most its share:
E_raw = PoR_contribution × (PoR_share / 70)
+ Root_score × (Root_share / 100)
+ Peer_score × (Peer_share / 100)
E_base = min(E_raw, Generation_ceiling,
IAL_ceiling,
Trajectory_ceiling,
Adversity_ceiling,
...any further applicable, declared ceiling)
Where:
PoR_contribution = 0-70, computed as specified in
[KTP-IDENTITY] Section 5.3. This document
MUST NOT restate that computation.
Root_score = 0-100, the strength of the accountability
instrument:
(Sponsor_E_base × stake_percentage / 100) / 50 × 100 (Sponsored)
min(100, 100 × declared_exposure / anchored_capacity) (Independent, Guarantor)
0 (no valid instrument)
stake_percentage is in percent-points (1-50). Under
concurrent attestations, Root_score is the maximum of
the individual instrument scores, never a sum.
Peer_score = 0-100, as specified in Peer Validation.
Generation_ceiling = per [KTP-IDENTITY] Section 8.4:
25 / 35 / 45 / 55 / 65 / 75 / 85 (generations 0-6),
100 (generation 7+)
E_base MUST be recalculated when new Proof of Resilience attestations are received, when agent generation advances, when sponsorship terms change, when an external attestation is issued, renewed, withdrawn, or expires, and when a for-cause claim is adjudicated.
E_base SHOULD be cached for performance, with a maximum cache lifetime of 60 seconds.
Risk Factor (R)¶
The Risk Factor represents aggregated environmental stress. It is calculated from the six weighted Risk Factor inputs (see Section 6) using domain-specific weights.
The calculation:
R = sum(w_i * s_i) for i in
{evidence_density, trust_trend, adversarial_pressure,
moment_criticality, update_resistance, attestation_coverage}
Where: w_i = Domain-specific weight for dimension i s_i = Normalized sensor value for dimension i (0 to 1) sum(w_i) = 1.0 (weights must sum to 1)
The weight declaration MUST pass the validation of Section 6.5 (Domain Weights) before this calculation. An invalid declaration MUST NOT be used to compute an authorizing score.
R is always in the range [0, 1]: - R = 0: Perfect conditions, no environmental stress - R = 0.5: Moderate stress, significant capability reduction - R = 1: Total crisis, all capabilities suspended
Every term s_i is a STRESS term in [0, 1]. 1 is maximum stress and 0 is its absence, for every weighted Risk Factor, whatever that factor is named. A Risk Factor whose name reads as a desirable quantity is still a stress term; the name describes what is measured, never the direction in which it is bad.
It follows that the conservative substitute for a term the deployment cannot currently observe is 1.0, and that a deployment MUST NOT substitute 0 for an unobserved term. Zero is a measurement of perfect conditions, not a statement that conditions are unknown. Section 6.8 (Undefined Inputs) states this rule for the class of undefined inputs; this section is its application to Risk Factor terms.
Each Risk Factor is a named aggregation over a declared subset of Context Signals. A signal reporting unknown MUST NOT contribute to that aggregation as though it had observed zero risk, and a Risk Factor whose declared subset cannot be populated is unobservable and takes 1.0.
Unobservability is therefore checked at three layers, and a deployment MUST apply the rule at each:
- The FEED, per [KTP-SENSORS] Section 6.1 and 6.2 - a source that has failed or whose observation has passed its staleness threshold.
- The SIGNAL - a Context Signal whose observation is unavailable, which includes a rate whose set of eligible events is empty. An empty denominator is unknown, not zero.
- The TERM, above - the Risk Factor the signals aggregate into.
The layers do not collapse into one another. A signal may be unavailable while every feed populating it is healthy, which is why a feed-level rule alone is insufficient.
The multiplicative relationship between R and E_base (see Section 5.3) is critical. R is not subtracted from E_base; it deflates it. This means:
- At R = 0.1 (10% stress): E_trust = E_base * 0.90 (10% reduction) - At R = 0.5 (50% stress): E_trust = E_base * 0.50 (50% reduction) - At R = 0.9 (90% stress): E_trust = E_base * 0.10 (90% reduction) - At R = 1.0 (total crisis): E_trust = 0 (all actions blocked)
This design ensures that environmental risk has veto power over agent capability. No amount of historical trust can overcome a completely compromised environment.
Risk Domains¶
To prevent oscillation in the Risk Factor—rapid fluctuation caused by local sensor noise—KTP calculates R at three hierarchical levels:
Node Domain: Local to a single resource or endpoint. High frequency updates (1-5 seconds). Captures immediate conditions but subject to noise. Default weight: 30%.
Neighborhood Domain: The local cluster, service mesh, or subnet. Medium frequency updates (10-30 seconds). Smooths out individual node variance. Default weight: 40%.
Global Domain: Zone-wide or federation-wide environment. Low frequency updates (30-120 seconds). Captures broad trends and external threats. Default weight: 30%.
The final Risk Factor aggregates all three levels:
This three-level structure prevents a single node spike from causing tier oscillation while ensuring that genuine widespread degradation is detected and acted upon.
See [KTP-SENSORS] Section 2.3 for detailed specification of Risk Domains including anti-oscillation mechanics and configuration.
Effective Trust Score (E_trust)¶
The Effective Trust Score is the value used to evaluate the Zeroth Law. It is calculated as:
This is the core equation of KTP. It unifies agent history (E_base) with environmental reality (R) into a single scalar value that determines what actions are possible.
Example calculations:
Scenario A: Stable Environment E_base = 95 (highly trusted agent) R = 0.1 (10% environmental stress) E_trust = 95 * (1 - 0.1) = 95 * 0.9 = 85.5
Scenario B: Degraded Environment E_base = 95 (same highly trusted agent) R = 0.7 (70% environmental stress) E_trust = 95 * (1 - 0.7) = 95 * 0.3 = 28.5
Scenario C: Toxic Environment E_base = 95 (same highly trusted agent) R = 0.95 (95% environmental stress) E_trust = 95 * (1 - 0.95) = 95 * 0.05 = 4.75
Note that the agent's intrinsic capability (E_base = 95) remains constant across all three scenarios. It is the environment that changes what is possible.
Trust Velocity (dE/dt)¶
Trust Velocity is the rate of change of E_trust over time:
Where delta_t is the time interval between measurements.
Trust Velocity provides critical predictive information:
- dE/dt > 0: Conditions improving, capabilities expanding - dE/dt = 0: Stable conditions - dE/dt < 0: Conditions degrading, capabilities contracting - dE/dt << 0: Rapid degradation, potential crisis imminent
Implementations MAY use Trust Velocity to:
-
Pre-emptively deny actions that would succeed now but likely fail mid-execution due to degrading conditions
-
Warn agents to reduce activity in anticipation of contraction
-
Trigger early Adaptive Dormancy before E_trust crosses tier thresholds
-
Detect anomalies (e.g., Trust Score changing faster than any known sensor could explain)
Trust Velocity SHOULD be included in the Trust Proof token (see Section 7) and in Flight Recorder logs (see [KTP-AUDIT]).
Trust Score Integrity (Anti-Goodhart Measures)¶
"When a measure becomes a target, it ceases to be a good measure." - Charles Goodhart
Trust Score faces an existential threat: Goodhart's Law. Once agents know they are being measured, they will optimize for the score rather than the underlying property. A generation of AI agents trained to maximize Trust Score would learn to appear trustworthy, not to BE trustworthy.
KTP cannot fully solve this problem — it may be unsolvable in the general case. But we can make gaming expensive, detectable, and risky. This section specifies required countermeasures.
The Goodhart Threat Model¶
Attack: Agent learns Trust Score calculation Goal: Maximize E_trust without genuine trustworthiness Methods: - Pattern mimicry (act like high-trust agents) - Metric manipulation (game specific sensors) - Sybil networks (create false attestation sources) - Timing attacks (act well when observed, poorly when not) - Gradient hacking (if ML- based, manipulate training)
The fundamental challenge: Any observable signal used to calculate trust can potentially be faked. The question is cost.
Multi-Dimensional Scoring¶
GOODHART-001: Trust Score MUST derive from multiple independent signals that are difficult to simultaneously optimize.
Required signal diversity: - At least 3 independent data sources for E_base - At least 4 sensor dimensions for R - Cross-validation between sources - Anomaly detection on source agreement
Rationale: Gaming one dimension is easier than gaming all dimensions consistently. Inconsistency between dimensions is itself a signal of manipulation.
Implementation: - If PoR_score is high but behavioral entropy is low → flag - If E_base is high but peer attestations are sparse → flag - If trajectory is smooth but environmental correlation is weak → flag
Behavioral Unpredictability¶
GOODHART-002: Trust Score calculation SHOULD include unpredictable elements that cannot be anticipated by the agent.
Permitted unpredictability: - Random weight variations within bounds (±10%) - Unannounced sensor emphasis shifts - Periodic recalibration of dimension weights - Random deep audits of trajectory
Every weight variation remains subject to the validity and unit-sum requirements of Section 6.5 (Domain Weights).
NOT permitted: - Arbitrary score manipulation - Retroactive weight changes - Unpredictability that violates deterministic verification
The Trust Oracle MUST be able to prove, after the fact, that any score was correctly calculated given the (unpredictable but recorded) parameters in effect at that time.
Adversity Requirements¶
GOODHART-003: E_base MUST include demonstrated performance under adversity, not just volume of successful transactions.
Proof of Resilience already requires crisis-time attestations. This section strengthens that requirement:
- Agents with no adversity exposure are capped at E_base = 60 - E_base > 60 requires attestations under R > 0.5 - E_base > 80 requires attestations under R > 0.7 - E_base > 90 requires attestations under CRISIS conditions
This cannot be gamed by self-inflicted crises because: - Attestations require Oracle signature - Oracle only signs if crisis is zone-wide (not agent-local) - Manufactured crises harm the manufacturing agent
Peer Validation¶
GOODHART-004: E_base calculation SHOULD incorporate peer signals that the agent cannot directly control.
Peer signals include: - Co-transaction success rate (how often do transactions with this agent succeed for the counterparty?) - Sponsor reputation (high-trust sponsors are selective) - Zone endorsements (zones the agent has operated in) - Negative attestations (complaints, disputes, violations)
Weight: Peer signals SHOULD contribute 10-20% of E_base.
Gaming resistance: An agent cannot force other agents to transact with it, cannot force sponsors to stake on it, cannot forge zone endorsements. Peer signals are externally controlled.
Temporal Consistency¶
GOODHART-005: Trust Score MUST incorporate long-term consistency, not just point-in-time performance.
Requirements: - E_base is a moving average, not instantaneous - Minimum trajectory length for E_base > 50 (1000 transactions) - Minimum trajectory length for E_base > 70 (10,000 transactions) - Sudden behavioral changes trigger investigation
Volatility penalty: - Calculate behavioral volatility over trailing window - High volatility (inconsistent behavior) reduces E_base - Volatility_penalty = std_dev(behavior_vector) * penalty_rate
Gaming resistance: Maintaining a false persona over thousands of transactions is expensive. The longer the trajectory required, the more costly the attack.
Cross-Zone Correlation¶
GOODHART-006: Federated zones SHOULD share anonymized behavioral statistics to detect cross-zone gaming.
Shared statistics: - Distribution of E_base scores (not individual scores) - Behavioral cluster signatures (not individual trajectories)
- Anomaly rates by agent category - Attestation patterns
Detection: If an agent's behavior in Zone A differs significantly from its behavior in Zone B, both zones are alerted. Context may explain the difference; gaming may also explain it.
Privacy: Only aggregate statistics cross zone boundaries. Individual agent data does not.
Human-in-the-Loop Sampling¶
GOODHART-007: Zones SHOULD implement random human review of high- trust agents.
Sampling rate by tier: - Observer: No human review required - Analyst: 0.1% random sample - Operator: 1% random sample - Admin Mode: 10% random sample
Review process: - Human examines trajectory, attestations, peer signals - Human can flag for investigation or confirm - Flagged agents are audited; confirmed agents continue - False positive rate is tracked
Gaming resistance: Agents cannot predict which actions will be reviewed. Consistent good behavior is the only reliable strategy.
Gradient Isolation¶
GOODHART-008: If machine learning is used in Trust Score calculation, the model MUST be isolated from agent influence.
Requirements: - Training data must not be agent-controllable - Model updates must be human-approved - Adversarial robustness testing required - Model weights are not published (security through partial obscurity)
Rationale: An agent that can influence its own training data can perform gradient hacking — subtly manipulating the model to favor its behavior patterns.
Fundamental Limits¶
These measures make gaming expensive and detectable. They do not make it impossible. The honest assessment:
WHAT WE CAN DO: - Make single-dimension gaming ineffective - Make sustained gaming expensive - Detect statistical anomalies - Create audit trails for investigation - Raise the cost of attack above the benefit
WHAT WE CANNOT DO: - Distinguish perfect mimicry from genuine trustworthiness - Prevent nation-state-level sustained deception - Guarantee the Trust Score reflects true trustworthiness
The Trust Score is a proxy. All proxies are imperfect. The goal is a proxy where gaming is harder than genuine trustworthy behavior.
See [KTP-PROBLEMS] Problem #21 for ongoing research into this challenge.
Risk Factors¶
The Risk Factors are seven named measurements of the environment that drive the Risk Factor calculation. Six contribute weighted values to the Risk Factor (R), while the seventh (Soul) acts as an independent veto mechanism.
The Seven Dimensions¶
- evidence_density
Measures the sheer weight of presence in the environment -
human presence, electromagnetic interference, and spatial
congestion.
Sensors:
- Crowd size (LIDAR, turnstiles, badge counts)
- RF noise floor (electromagnetic density)
- Device count on network
- CO2 levels (proxy for human occupancy)
Interpretation:
- Low evidence_density: Empty building, quiet conditions
- High evidence_density: Packed stadium, high RF interference
Impact: high evidence_density slows the environment. It naturally slows
down operations (Time Dilation) and increases the "cost" of
movement through the environment.
- trust_trend
Sensors:
- Transaction rates per second
- Link saturation (percentage of bandwidth used)
- Packet velocity and throughput
- Queue depth (pending messages)
Interpretation:
- Low trust_trend: Idle system, excess capacity
- High trust_trend: System moving fast, approaching saturation
Impact: high trust_trend means standing is moving fast. Sudden
stops or turns (Vector Kinking) create massive G-forces (Risk).
Course corrections become expensive.
- adversarial_pressure
Measures the chaotic energy or friction in the system -
indicators of active attack or system stress.
Sensors:
- Thermal load (CPU temps, voltage droop)
- WAF block count (blocked malicious requests)
- Anomaly rates (entropy in traffic patterns)
- Error logs and exception rates
- Identity velocity (auth attempts per second)
Interpretation:
- Low adversarial_pressure: Cool, stable operations
- High adversarial_pressure: Hot, active attack or system stress
Impact: adversarial_pressure is the deflator. As it rises, the
structural integrity of trust degrades; sustained highs trigger the "Cool-Down"
cycle (Freezing agents to Observer Mode).
- moment_criticality
Measures the criticality of the current moment relative to an
event horizon - where in a temporal cycle the system is.
Sensors:
- Event schedules (e.g., "5 minutes to Kickoff")
- Maintenance windows (scheduled downtime)
- Business hours (peak vs. off-peak)
- Mission criticality timers
Interpretation:
- Low moment_criticality: Low-criticality period (maintenance
window, 3am)
- High moment_criticality: High-criticality period (production,
live event)
Impact: A failure during "Kickoff" has infinitely higher gravity
than a failure at 3:00 AM. Time dilates the risk tolerance -
the same action costs more trust near event horizons.
Provenance: moment_criticality is externally supplied. Six of the seven inputs are aggregations over declared subsets of the Context Signals catalogue; this one is supplied by the action request's context and declared as such. The asymmetry is stated here rather than papered over: no catalogue domain measures what the agent is trying to do, because a task domain would measure A while every existing domain measures E, and the other side of A <= E cannot be appended to the catalogue casually. Until such a domain exists, a deployment MUST declare the source supplying this input.
- update_resistance
Measures the topological importance of a node - how hard is it
to move or stop this asset, and how much depends on it.
Sensors:
- Network topology (degree centrality, betweenness)
- Dependency graph depth (downstream services)
- Data volume stored
- Blast radius estimation (systems affected by failure)
Interpretation:
- Low update_resistance: Leaf node, few dependencies, easy to move
- High update_resistance: Core service, many dependencies,
expensive to move
Impact: a core router has high update_resistance; an edge IoT
device has low. High-resistance nodes require higher Trust Scores to
modify - they resist change.
- attestation_coverage
Sensors:
- VIP presence (executives, regulators, media)
- User segmentation (internal vs. external)
- Regulatory jurisdiction flags
- Audit mode (compliance observation active)
- Life-safety population count
Interpretation:
- Low attestation_coverage: Normal user population, routine
operations
- High attestation_coverage: High-visibility users present,
elevated scrutiny
Impact: The environment's constraints tighten when the Observer
count is high or when specific observers (e.g., Regulators) are
present.
Actions that would be routine become consequential.
- soul
Measures the ethical, legal, and spiritual constraints of the
physical location or data lineage - constraints that exist
independent of operational conditions.
Sensors:
- TK Labels (Traditional Knowledge labels)
- OCAP/CARE protocol flags (Ownership, Control, Access,
Possession / Collective benefit, Authority to control,
Responsibility, Ethics)
- Sacred Land geofences
- Treaty database lookups
- Data provenance chains (where did this data originate?)
- Cultural heritage registries
Interpretation:
- soul = 0: No sovereignty constraints apply
- soul = 1: Sovereignty constraint violated, action forbidden
Impact: This acts as a Boolean Veto or a hard limit. It
represents the "Spirit" of the data or location. If the Soul
constraint is violated, the action becomes impossible
(Probability = 0). No amount of Trust Score can
overcome a Soul veto.
The Soul Veto¶
The Soul input operates differently from the six weighted inputs. While those six contribute weighted values to the Risk Factor (R), Soul acts as an independent constraint that can veto any action regardless of Trust Score.
The Soul evaluation is:
This evaluation occurs BEFORE the standard A <= E_trust check. A Soul veto cannot be overridden by:
- High Trust Score - Low Risk Factor - Emergency procedures - Administrative override
This is by design. The Soul veto encodes constraints that exist outside the operational domain - legal treaties, cultural sovereignty, spiritual significance. These are not "policies" that can be weighed against operational need; they are immutable laws that define what actions are possible.
Example Soul constraints:
- Traditional Knowledge (TK) Labels:
Data tagged with TK Labels (per Local Contexts framework) may
have restrictions on:
- Who can access (TK Community Voice)
- How it can be used (TK Non-Commercial)
- Whether it can be modified (TK Outreach)
- Attribution requirements (TK Attribution)
- OCAP/CARE Principles:
For Indigenous data, the OCAP principles (Ownership, Control,
Access, Possession) and CARE principles (Collective benefit,
Authority to control, Responsibility, Ethics) may require:
- Community consent for access
- Data to remain within tribal jurisdiction
- Specific handling protocols
- Sacred Land Geofences:
Physical locations may have sovereignty constraints:
- Sacred sites where certain activities are forbidden
- Treaty lands with specific data handling requirements
- Cultural heritage zones with restricted access
- Data Lineage Sovereignty:
Data may carry sovereignty constraints from its origin:
- Data collected on tribal land
- Data about Indigenous peoples
- Data derived from traditional knowledge
Even if the data has moved to cloud infrastructure, its Soul
travels with it. If an action would violate origin sovereignty,
S = 1.
The Soul veto response differs from the standard Silent Veto:
{
"error": "SOVEREIGNTY_CONSTRAINT",
"message": "Action violates data sovereignty",
"constraint_type": "tk_label",
"constraint_id": "TK-NC-001",
"authority": "https://localcontexts.org/label/tk-nc/",
"e_trust": 95,
"e_required": 50,
"note": "Trust Score is sufficient, but action is
forbidden by sovereignty constraint"
}
Note that e_trust and e_required are provided for transparency, but the denial is not due to insufficient trust - it is due to an immutable constraint that exists independent of trust.
The Carriage Interface for Normative Content¶
Normative content — authored judgments about what ought to happen, whose disputes are value disputes that measurement cannot resolve — is external to this specification and enters it through exactly three shapes:
-
A veto. The Soul constraint above: externally supplied, authority-adjudicated, carried but never authored here, and evaluated before aggregation.
-
A supplied input. A declared, externally provided signal — moment_criticality is the standing instance — whose source the deployment MUST declare.
-
A gate. An adjudication token evaluated against a declared external schema.
Norm content MUST NOT rewrite the aggregation. A normative judgment that scales capacity rather than gating it has crossed into the measurement layer, and the crossing is the failure this interface exists to prevent. The prudence judgments this series computes from the environment ([KTP-ENFORCE]'s graduated outcomes) are not normative content and do not pass through this interface: their disputes resolve by measurement.
Normalization¶
Each sensor outputs values in its native units (ppm, percentage, events/minute, etc.). These MUST be normalized to a 0-1 scale before aggregation.
The normalization function for each dimension:
Where: s_raw = Raw sensor value s_min = Minimum expected value (maps to 0) s_max = Maximum expected value (maps to 1)
Values below s_min SHOULD be clamped to 0. Values above s_max SHOULD be clamped to 1.
Example normalization thresholds:
+------------+------------+------------+------------+
| Input | Sensor | s_min | s_max |
+------------+------------+------------+------------+
| evidence_density | CO2 (ppm) | 400 | 2000 |
| trust_trend | Link % | 0 | 100 |
| adversarial_pressure | WAF blocks | 0 | 10000/min |
| moment_criticality | Hours out | 72 | 0 |
| update_resistance | Dep count | 0 | 500 |
| attestation_coverage | VIP count | 0 | 50 |
| Soul | N/A | Binary (0 or 1) |
+------------+------------+------------+------------+
Note: Time is inverted (72 hours out = 0 stress, 0 hours = 1 stress) Note: Soul is not normalized - it is a binary veto (see Section 6.2)
Domain Weights¶
Different deployment domains weight the six weighted inputs differently. Each of the six factor weights MUST be a finite number greater than zero and at most one, and the weights MUST sum to 1.0. Boolean and non-numeric values are invalid. Soul is not weighted - it operates as an independent constraint.
The complete weight declaration MUST be validated before computing R and after every reconfiguration. An invalid declaration MUST be rejected; an implementation MUST NOT silently rescale the weights or fill a missing weight with a default. The deployment-profile declaration checker evaluates the sum exactly over the decimal representations of parsed numeric values, as described in specifications/deployment-profile.md. Per-feed aggregation weights are separate from these six factor weights.
Example domain profiles:
Stadium Network: evidence_density=0.25, trust_trend=0.25, adversarial_pressure=0.20, moment_criticality=0.15, update_resistance=0.10, attestation_coverage=0.05
Financial Trading: evidence_density=0.05, trust_trend=0.30, adversarial_pressure=0.25, moment_criticality=0.20, update_resistance=0.15, attestation_coverage=0.05
Healthcare: evidence_density=0.10, trust_trend=0.15, adversarial_pressure=0.25, moment_criticality=0.15, update_resistance=0.20, attestation_coverage=0.15
Cloud Infrastructure: evidence_density=0.05, trust_trend=0.25, adversarial_pressure=0.30, moment_criticality=0.10, update_resistance=0.25, attestation_coverage=0.05
Indigenous Data Repository: evidence_density=0.10, trust_trend=0.10, adversarial_pressure=0.20, moment_criticality=0.10, update_resistance=0.15, attestation_coverage=0.35 (Note: High Observer weight reflects community oversight; Soul veto always active for TK-labeled data)
Implementations MUST allow configuration of domain weights. Implementations SHOULD provide pre-defined profiles for common domains.
Risk Factor Modularity¶
The Risk Factor architecture is designed to be modular at two levels:
- Framework-Level Modularity:
The framework itself is extensible. The seven inputs defined in
this specification represent the core measurement space, but
implementations MAY define additional inputs for domain-specific
requirements.
Additional inputs MUST:
- Be clearly documented with the quantity measured, its units,
and its measurement procedure
- Specify whether they contribute to R (weighted) or act as
independent constraints (like Soul)
- Define normalization rules
- Register with the Trust Oracle
- Feed-Level Modularity:
Each Risk Factor input aggregates multiple sensor feeds. These
feeds are independently configurable:
- Feeds can be enabled/disabled per deployment
- Feed weights within an input can be adjusted
- New feeds can be added to existing inputs
- Feed sources can be local or federated
Example: The Soul input might aggregate:
- TK Labels API (enabled)
- OCAP registry (enabled)
- Sacred Land geofence service (enabled)
- Treaty database (disabled - not applicable)
- Custom cultural heritage API (enabled)
Feed Configuration Example:
{
"dimension": "soul",
"feeds": [
{
"id": "tk-labels",
"source": "https://api.localcontexts.org/v1/labels",
"enabled": true,
"weight": 1.0,
"veto_on_match": true
},
{
"id": "ocap-registry",
"source": "https://ocap.example.org/check",
"enabled": true,
"weight": 1.0,
"veto_on_match": true
},
{
"id": "sacred-geofence",
"source": "local://geofence-service",
"enabled": true,
"weight": 1.0,
"veto_on_match": true
}
],
"aggregation": "any_veto"
}
The "aggregation" field for Soul MUST be "any_veto" - if any enabled feed returns a veto, the Soul input vetoes.
For the six weighted inputs, typical aggregation is "weighted_average" of enabled feeds.
Aggregation Algorithm¶
The software-agent aggregation algorithm is below. For human execution, the reviewed adapter supplies separately evidenced operational E on the same declared scale as A; it MUST NOT run the E_base composition or manufacture its inputs. Soul remains the first substantive authorization gate, and the input, zero-capacity, A > E, margin, and tighten-only checks below apply to either actor type. Principal authentication and request binding precede evaluation; no principal type bypasses a veto. This aggregation stage does not replace grants or the operation-specific prerequisites below.
Step 1: Soul Veto Check (MUST be first)
Step 2: Risk Factor Calculation
Step 3: Trust Score Deflation
Step 4: Input Validation, Capacity Veto, and Decision Result
Before this stage, undefined inputs MUST be resolved restrictively under Section 6.8 (Undefined Inputs). A declared conservative estimate of capacity remains subject to the capacityKnown = false supervision floor in [KINETIC-ENVELOPE]. If no usable numeric A or E_trust is available, the action MUST be vetoed; an implementation MUST NOT substitute a permissive value or manufacture a margin. Undefined inputs MUST be recorded as required by Section 6.7.
The following checks MUST precede division and profile threshold evaluation. A and E_trust MUST be finite, non-negative numbers on the same declared scale and describe the same candidate action. Boolean values, non-numeric values, NaN, and infinities are invalid.
IF A or E_trust is not a finite, non-negative number THEN
RETURN supervision = silent_veto
with reason TRUST_INSUFFICIENT
END IF
IF E_trust = 0 OR A > E_trust THEN
RETURN supervision = silent_veto
with reason TRUST_INSUFFICIENT
END IF
The capacity veto is independent of profile thresholds. A profile, a supervision change, or human approval MUST NOT permit this candidate action after that veto. A revised action MAY be proposed, but its actual parameters and corresponding capacity MUST be evaluated again. Existing sovereignty vetoes, capability grants, and tighter restrictions remain binding.
IF margin <= M_veto THEN
RETURN supervision = silent_veto
with reason TRUST_INSUFFICIENT
ELSE
RETURN supervision derived from margin against the declared
profile thresholds, with tightenedConstraints,
per [KINETIC-ENVELOPE]
END IF
The result of every evaluation is a supervision level and a tighten-only constraint set (tightenedConstraints), as specified in [KINETIC-ENVELOPE]. Supervision is a floor: a consumer MAY raise it and MUST NOT lower a level already set. tightenedConstraints never widens the granted envelope. The result and evidence record MUST include margin when calculation was reached and MUST omit it when an earlier check stopped the evaluation; an omitted margin MUST NOT be interpreted as zero.
Declared profile thresholds MUST be finite numbers satisfying 0 <= M_veto < M_allow. An invalid declaration MUST be rejected before use; it MUST NOT be treated as an omitted declaration. Thresholds have no upper bound: a profile MAY require a margin that prevents stable operation. A deployment that declares no thresholds retains M_veto = M_allow = 0 and the existing zero-margin veto. An explicitly declared equal pair is invalid.
At A = E_trust > 0 the independent capacity veto does not fire, but margin is zero and the current default and valid declared thresholds veto it. This preserves the existing margin contract; it does not introduce permission at equality. Passing the capacity check is a prerequisite for the remaining checks, never an authorization by itself.
The four decision verbs are derived readings of this result, by precedence, and are not a four-valued enumeration:
1. supervision = silent_veto -> VETO
2. supervision raised above stable -> DEAUTOMATE
3. stable, tightenedConstraints strictly
tightened relative to the granted envelope -> SHAPE
4. stable, not tightened -> ALLOW
Every decision reads as exactly one verb. A specification, schema, or record in this series MUST NOT encode the verbs as an enumerated decision type; the result (supervision and tightenedConstraints) is the normative object and the verb is derived from it.
The Soul veto is evaluated first because sovereignty constraints are immutable - no amount of trust can override them. This ordering ensures that sovereignty is respected before operational calculations begin.
Aggregation for ordinary Trust Scores and Trust Proof issuance MUST be performed at the Trust Oracle. The separately authorized emergency evaluation in specifications/emergency-capability.md MAY use its preapproved independent local evaluator when the ordinary Oracle is unavailable. That evaluator remains bound by the same input, sovereignty, capacity, and supervision constraints and MUST NOT issue replacement ordinary Trust Proofs.
Sensor values SHOULD be refreshed at intervals appropriate to their rate of change:
+------------+------------------------+
| Input | Recommended Interval |
+------------+------------------------+
| evidence_density | 30-60 seconds |
| trust_trend | 1-5 seconds |
| adversarial_pressure | 1-5 seconds |
| moment_criticality | 60 seconds |
| update_resistance | 300 seconds |
| attestation_coverage | 30 seconds |
| Soul | On-demand (per action) |
+------------+------------------------+
Soul is evaluated on-demand because sovereignty constraints may be action-specific (e.g., "read" may be permitted while "modify" is forbidden by TK labels).
Implementations MAY cache aggregated R values for up to 100ms to reduce computational load. Soul evaluations SHOULD NOT be cached as they are context-specific.
Undefined Inputs¶
An input that is absent, unanswered, stale beyond its declared refresh, or otherwise undefined MUST NOT resolve toward permission. It resolves toward the more restrictive outcome available at that decision point, and the undefined state MUST be recorded on the decision record. Substituting a measured value for an undefined one - including zero - is prohibited (Section 5.2).
"Toward permission" is the operative phrase. Failing closed does not mean denying on every unknown. Where a decision point offers a graded outcome - the supervision ladder of Section 6.7 (Aggregation Algorithm) - an undefined input clamps the result to a more supervised level, per [KINETIC-ENVELOPE]: an unknown environment reads as low capacity, not high. Denial is the terminal case, reached only where no more restrictive outcome short of denial exists at that decision point. The Soul veto (Section 6.2) is a decision point with exactly that shape - its outcomes are veto and no veto - so an undefined sovereignty input resolves to the veto ([KTP-SENSORS] Section 4.3).
Silence and absence do not separate. A channel that returns nothing and a channel that was never reachable are indistinguishable to the decision, and an adversary who can produce one can produce the other. An implementation MUST NOT resolve an unanswered input differently from an absent one.
Trust Proof Token¶
The Trust Proof is a signed token that travels with each request, carrying the current Trust Score and environmental context.
The standing-bearing claims and examples in this section describe software agents. They do not define a human proof format. Accepting human requests or human delegations requires an installed deployment human_policy binding with mode operation-eligibility-v1, profile_id, version, and digest, plus a reviewed authorization adapter under specifications/human-eligibility.md. Without that adapter and policy, the integration MUST reject the affected request; it MUST NOT fabricate human E_base, tier, lineage, generation, model, or v3 software-trajectory state to satisfy an existing schema.
The human eligibility decision schema defines an UNSIGNED prerequisite body, not a JWT, signature format, or authorization token. The adapter MUST authenticate and bind the complete body to the exact actual request, the fully verified ordinary proof, authenticated principal and executing actor, installed human and deployment profiles, and current evidence epoch/status. It MUST define and test the proof format, trusted issuer/key and role binding, audience/session/request binding, replay controls, and current operational-capacity evidence before accepting humans. A generic JWT, a caller-supplied actor type, or a body whose result says eligible MUST NOT satisfy those obligations. All ordinary proofs retain the existing maximum ten-second lifetime and stronger Crypto requirements; this specification supplies no compatibility fallback around them.
Token Format¶
The Trust Proof extends JSON Web Token (JWT) as defined in RFC 7519. It uses the standard JWT structure:
The header MUST include:
The "alg" field specifies the signature algorithm. Implementations MUST support ES256 (ECDSA with P-256 and SHA-256). Implementations MAY support additional algorithms.
The "typ" field MUST be "ktp+jwt" to distinguish KTP Trust Proofs from standard JWTs.
The "kid" field identifies the Trust Oracle signing key, enabling key rotation and multi-Oracle deployments.
Claims¶
The payload contains standard JWT claims plus KTP-specific claims in the "ktp" namespace.
Standard claims:
iss (Issuer): The Trust Oracle identifier (URI)
sub (Subject): The agent identifier (URI)
iat (Issued At): Unix timestamp of Trust Proof generation
exp (Expiration): Unix timestamp of Trust Proof expiration
jti (JWT ID): Unique identifier for this Trust Proof
KTP claims (in "ktp" object):
e_base: Base Trust score (0-100)
e_trust: Effective Trust score (0-100)
r: Risk Factor (0-1)
de_dt: Trust Velocity (change per second)
sigma: Trust Volatility (standard deviation)
risk_factors: Object containing the six normalized inputs
adversarial_pressure (0-1)
attestation_coverage (0-1)
evidence_density (0-1)
moment_criticality (0-1)
trust_trend (0-1)
update_resistance (0-1)
soul: Object containing sovereignty evaluation
s: Soul veto status (0 = clear, 1 = veto)
constraint_type: Type of constraint if s=1 (null if s=0)
constraint_id: Identifier of triggering constraint
authority: URI of sovereignty authority
lineage: Agent lineage stage ("sponsored", "independent",
"guarantor")
generation: Agent generation number (0+)
sponsor: Sponsor agent identifier (if sponsored)
resilience_hash: Hash of current Proof of Resilience ledger
Example Trust Proof payload (no sovereignty constraint):
{
"iss": "https://oracle.example.com",
"sub": "agent:7gen:optimized:a1b2c3d4",
"iat": 1699900000,
"exp": 1699900010,
"jti": "tp-uuid-12345",
"ktp": {
"e_base": 87,
"e_trust": 42,
"r": 0.517,
"de_dt": -2.3,
"sigma": 0.15,
"context": {
"evidence_density": 0.875,
"trust_trend": 0.920,
"adversarial_pressure": 0.020,
"moment_criticality": 1.000,
"update_resistance": 0.100,
"attestation_coverage": 0.040
},
"soul": {
"soul": 0,
"constraint_type": null,
"constraint_id": null,
"authority": null
},
"lineage": "guarantor",
"generation": 7,
"resilience_hash": "sha256:abc123def456..."
}
}
Example Trust Proof payload (sovereignty constraint active):
{
"iss": "https://oracle.example.com",
"sub": "agent:7gen:optimized:a1b2c3d4",
"iat": 1699900000,
"exp": 1699900010,
"jti": "tp-uuid-12346",
"ktp": {
"e_base": 95,
"e_trust": 90,
"r": 0.053,
"de_dt": 0.1,
"sigma": 0.02,
"context": {
"evidence_density": 0.100,
"trust_trend": 0.150,
"adversarial_pressure": 0.010,
"moment_criticality": 0.200,
"update_resistance": 0.050,
"attestation_coverage": 0.020
},
"soul": {
"soul": 1,
"constraint_type": "tk_label",
"constraint_id": "TK-NC-001",
"authority": "https://localcontexts.org/label/tk-nc/"
},
"lineage": "guarantor",
"generation": 7,
"resilience_hash": "sha256:abc123def456..."
}
}
Note: In the second example, despite high E_trust (90) and low R (0.053), the Soul veto (s=1) will cause any action to be denied that violates the TK Non-Commercial label.
Signature¶
The Trust Proof MUST be signed by the Trust Oracle using the algorithm specified in the header.
For distributed Trust Oracle deployments, the signature MAY be a threshold signature requiring k-of-n Oracles to sign.
Issuers and honest threshold signers in an Oracle mesh MUST derive the proof's standing, including E_base and its trajectory basis, from verified committed state under specifications/oracle-consensus.md. Single-node proof issuance MAY remain available where the deployment's signing requirements permit it, but MUST NOT turn an uncommitted local proposal into authoritative standing. Signature validity or signing-threshold metadata alone does not prove consensus or freshness of that standing. The selected protocol MUST define how issuers establish applicable committed state, and consumers relying on mesh agreement MUST verify its required evidence and binding to the proof's result. Proof lifetime, current environmental evaluation, and all authorization constraints remain binding.
Implementations MUST verify: 1. The signature is valid for the payload 2. The signing key is a known, trusted Oracle key 3. The signing key has not been revoked
Signature verification failure MUST result in action denial.
Operational Readiness for the Requested Action¶
The PEP MUST authenticate both the requesting principal and the actor actually executing the operation. Dispatch MUST use independently authenticated principal type and execution context, not a request label. A human actor requires current operation-specific eligibility and separately evidenced capacity under the installed human policy and reviewed adapter. Evidence correction, grant revocation, profile replacement, or epoch change MUST invalidate superseded dependent decisions; stale proofs, restored state, or a legacy human score MUST NOT recover authority.
A human delegator or supervisor does not turn a software executor into a human actor. The PEP MUST verify the human's current eligibility for the exact delegation or supervisory operation and every applicable restriction along the delegation chain, in addition to the software executor's own grants, capacity, and readiness. Neither co-signing nor delegated permission transfers personal standing or assessment evidence. Missing authenticated actor binding or required human policy MUST deny the affected operation.
For a software executor, an ordinary Trust Proof alone MUST NOT establish operational readiness. Before execution, the PEP MUST verify the separate signed readiness decision required by specifications/operational-readiness.md against the complete ordinary proof, the actual operation and resolved scope, the live subject's code/model/configuration/toolchain/permissions, the installed deployment and readiness profiles, and current readiness epoch and revocation state. The decision MUST bind current assessment evidence issued under independently approved criteria by a competent, accountable assessor. The requesting subject MUST NOT select its own trusted criteria, assessor, configuration expectations, or accepted policy floor. The following readiness lifecycle requirements apply to that software executor, including when a human requests or approves its action.
The readiness attestation and decision have evidence-based validity limits. Heartbeats, process uptime, re-signing, a fresh ordinary proof, or an unchanged historic score MUST NOT renew an assessment. A relevant subject, permission, scope, tool, or policy change invalidates the old match and requires the assessment specified by the installed profile. Missing, expired, revoked, mismatched, or unverifiable readiness evidence MUST prevent execution of the affected operation. Readiness for another operation is not a substitute.
The required checks and fresh challenge MUST be bound before assessment; validity MUST be no later than the oldest required observation plus the installed maximum age. The complete signed attestation digest MUST be registered as active in the authenticated current readiness epoch. A new signature, newer cheap check, or copied digest string does not establish fresh evidence or actual executing state. Registration, revocation, and the accepted standing-policy/profile/format floor MUST persist across restart and recovery, with shared-state transitions governed by specifications/oracle-consensus.md.
An ordinary proof MUST NOT expire after the readiness supporting its dependent authority. The readiness decision MUST expire no later than the ordinary proof, readiness evidence, or applicable issuer/assessor key validity, and known invalidation may end use sooner. These limits never extend the ordinary ten-second maximum. Existing agents retain admissible historical evidence at migration but have no current readiness for dependent scopes until assessed and activated; an old profile is not a fallback.
Readiness is checked as an additional prerequisite; it never turns a failed earlier check into permission. Assessment and remediation require a separately authorized safe route whose scope does not depend on assuming the capability being assessed. Retain the ordinary ten-second proof limit and all continuing-action checks. The readiness decision remains a separate sidecar, avoiding any signature/hash cycle with the already complete ordinary proof; trajectory records retain it under the existing signed action.details.readiness field without changing their top-level format.
Lifetime¶
Trust Proofs are intentionally short-lived to ensure they reflect current environmental conditions.
The claims MUST establish 0 < exp - iat <= 10 seconds. A verifier MUST establish iat <= current_time < exp; at current_time = exp the proof is expired. If a timestamp or current time is invalid or unverifiable, the proof MUST NOT authorize an action. Clock rollback MUST NOT restore or prolong expired authority.
Implementations SHOULD use shorter lifetimes (1-5 seconds) in high- volatility environments.
Trust Proofs MUST NOT be cached beyond their expiration.
If an action takes longer than the Trust Proof lifetime, the agent MUST obtain a new Trust Proof before continuing. Otherwise it MUST cease protected execution through its previously declared bounded safe transition; this is not permission to finish arbitrary work. This may result in mid-action denial if conditions have degraded.
The ten-second maximum applies to every zone and conformance level. An existing session, cached proof, queued refresh, surrounding token, or emergency declaration MUST NOT extend ordinary authorization. Separately authorized safety or recovery actions follow specifications/emergency-capability.md. That capability is disabled unless an approved policy is pinned; it does not replace an expired proof or override a sovereignty, capacity, or prior veto. Changes to emergency authority are governed by the companion's protected amendment process, including during recovery.
Silent Veto Mechanism¶
The Silent Veto is the automatic denial of an action when A > E_trust. It is "silent" because it requires no human intervention - the environment itself enforces the constraint.
Action Risk Classification¶
Each action type MUST be assigned an intrinsic risk score (A). The following table provides baseline classifications:
+----------------------+-----+--------------------------------+
| Action Class | A | Description |
+----------------------+-----+--------------------------------+
| Read (public) | 10 | Read publicly accessible data |
| Read (internal) | 20 | Read internal/private data |
| Read (sensitive) | 30 | Read PII, credentials, keys |
| Write (append) | 40 | Add new data, no modification |
| Write (modify) | 50 | Modify existing data |
| Execute (safe) | 60 | Run pre-approved operations |
| Execute (unsafe) | 75 | Run arbitrary code |
| Delete (recoverable) | 80 | Delete with backup/undo |
| Delete (permanent) | 85 | Delete without recovery |
| Admin (config) | 90 | Change system configuration |
| Admin (infra) | 95 | Modify infrastructure |
+----------------------+-----+--------------------------------+
Implementations MAY define additional action classes. Implementations MUST allow configuration of A values. Implementations SHOULD log any changes to A values.
Veto Trigger¶
The veto evaluation is performed at the PEP:
IF A > E_trust THEN
trigger Silent Veto
ELSE
continue through Section 6.7 (Aggregation Algorithm) and the remaining checks
END IF
The evaluation MUST occur for every action request. For software actors it MUST use E_trust from a valid, unexpired Trust Proof; for human actors it MUST use the current operational E authenticated by the reviewed adapter and bound to the exact request and ordinary proof. The input and zero-capacity checks in Section 6.7 (Aggregation Algorithm) MUST precede arithmetic; this abbreviated capacity check does not replace them. Profile evaluation MUST NOT lower a silent_veto result or treat A <= E as sufficient permission.
The veto is triggered automatically. A correctly evaluated veto MUST NOT be overridden by an appeal, emergency declaration, manager approval, or grace period. This does not prohibit meaningful explanation, independent review, or correction under [KTP-HUMAN], [KTP-PRIVACY], and specifications/human-eligibility.md. A correction changes the authoritative evidence and requires a fresh evaluation with all safety checks; it does not retroactively authorize the denied action. Superseded evidence and dependent authority MUST NOT be revived through caching, replay, or restoration.
This is by design. The veto represents a physical constraint, not a policy decision. Overriding it would be like overriding gravity.
Veto Response¶
When a Silent Veto is triggered, the PEP MUST:
-
Deny the action immediately
-
Return an error response to the agent including: - Error code indicating Trust-based denial - Current E_trust value - Required E_trust for the action (A) - Trust Velocity (dE/dt) for predictive purposes
-
Log the denial to the Flight Recorder with full Decision Geometry
Recommended HTTP response:
{
"error": "TRUST_INSUFFICIENT",
"message": "Action risk exceeds current trust",
"e_trust": 42,
"e_required": 50,
"de_dt": -2.3,
"retry_after": null
}
The "retry_after" field MAY contain an estimated time (in seconds) until conditions might permit the action, based on Trust Velocity projections. If conditions are degrading (dE/dt < 0), this field SHOULD be null.
Trust Oracle¶
The Trust Oracle is the authoritative source of Trust Scores and Trust Proofs within a KTP domain.
Responsibilities¶
The Trust Oracle:
- Ingests sensor data from the Context Signal sensors 2. Maintains the Proof of Resilience ledger for all agents 3. Calculates E_base for each agent 4. Calculates R from the Risk Factor inputs 5. Calculates E_trust = E_base * (1 - R) 6. Signs Trust Proofs with its private key 7. Issues Attestations of Passage for successful transactions 8. Publishes its public key for Trust Proof verification
Distribution¶
To avoid single points of failure, the Trust Oracle SHOULD be distributed across multiple nodes.
Distribution models:
-
Active-Passive: One primary Oracle, one or more standby Oracles that take over on primary failure. Simple but has failover latency.
-
Active-Active with Consensus: Multiple Oracles that must agree on Trust Scores. More resilient but higher latency.
Threshold signing is an independent signing configuration that can accompany either distribution model: multiple Oracles contribute partial signatures, with k-of-n required for a valid Trust Proof. It does not replace state consensus.
Implementations MUST support at least Active-Passive distribution. Implementations SHOULD support threshold signatures.
Consensus¶
Oracle meshes MUST use the reviewed, named and versioned consensus protocol required by specifications/oracle-consensus.md for protected authoritative state, including E_base changes, trajectory commitments, genesis, and zone or Oracle membership configuration. For N authenticated members and a declared bound f on Byzantine members, the Byzantine profile requires f >= 1, N >= 3f + 1, and homogeneous decision quorums satisfying floor((N + f) / 2) + 1 <= q <= N - f; the default is N = 5, f = 1, q = 4. Distinct authenticated votes, membership epochs, durable voting and locks, safe view changes, and safe membership transitions are required. Single-Oracle and active-passive operation alone provide no Byzantine consensus guarantee.
When multiple Oracles are active, they MUST agree on:
- Current sensor values (within tolerance) 2. Agent E_base values (must match exactly) 3. Calculated R and E_trust (within tolerance)
Tolerance for sensor values: 5% relative difference Tolerance for E_trust: 2 points absolute difference
If Oracles disagree beyond tolerance, they MUST:
- Log the disagreement with full context 2. Use the more conservative (lower) E_trust value 3. Alert operators to investigate
This conservative environmental calculation MUST NOT reconcile conflicting committed histories or authorize a protected-state update without the required commit evidence. Without a decision quorum, the mesh MUST pause new protected-state commitments; unreachable nodes MUST NOT be removed locally to lower the quorum. Four responsive, mutually communicating members can support progress in the default five-member deployment under the selected protocol's liveness assumptions. Fewer than four cannot commit new protected state, including when one Byzantine member withholds participation and one honest member is unavailable. No bounded completion time is promised during an arbitrary partition. Existing proofs remain subject to their validity rules; an outage does not extend their lifetime.
Oracle disagreement MAY indicate: - Sensor failure or manipulation - Network partition between Oracles - Attack on Oracle infrastructure
Limits of This Specification¶
A specification that does not state its limits invites implementations that promise past them. The falsification program forced each of the following; this section states them the way the program forced them — as boundaries of the claim space fixed in advance, not qualifications recovered after an incident.
L1. Pre-execution episode classification is undecidable¶
Universal pre-execution inference of episode membership for arbitrary code is undecidable. The reduction is from the halting problem (an agent that performs a governed action if and only if an arbitrary program halts), and Rice's theorem generalizes the obstruction to every non-trivial semantic property.
Consequently, a conformant implementation MAY validate finite, completed events against a signed, policy-indexed adjudication token at runtime, and MUST NOT claim advance classification of the episode membership of arbitrary code. The parent episode identifier MUST be fixed before execution and carried by every implementation event; runtime membership checking is signature validation, never inference.
L2. No self-certification¶
No composition of E_{base} may consist entirely of terms the subject measures about itself. The accountability chain behind the External Root MUST terminate, through a finite and declared chain, at a root outside the agent-trust graph. A cycle of agents attesting for one another does not satisfy this requirement.
This is a structural necessity, not a policy preference. A gate grounded in itself has no base case; grounding in raw traces is essentially contested (independent functions can agree on every event and still legitimately disagree on the unit of accountability). Both rails therefore terminate in externally owned ground: the CAN rail at the External Root, the SHOULD rail at a declared institutional schema. The system does not certify its own trustworthiness from the inside.
Kind alone does not discharge the requirement. The root MUST carry irrecoverable, non-transferable exposure at least proportional to the capacity it anchors; an anchor whose exposure can be shed by abandoning the identity anchors nothing.
L3. Level-independence is conditional¶
Admissibility verdicts are invariant under re-description — packet level, syscall level, API level, agent level — only because action risk attaches to governed-world state transitions rather than to description events, and composition merges causal action contracts before evaluating risk. That algebra is discharged. The theorem it yields is conditional on faithful description: a proof, per description level, that the level's events implement the claimed consequence semantics.
Where a refinement proof cannot be discharged — arbitrary code, no causal model — the invariance claim stops. These proofs are a work program of the linearizability/refinement genre, owed and not yet delivered. An implementation MUST NOT cite level-independence for a description level whose refinement into its governed-world model has not been demonstrated.
The result holds within computation. No cross-substrate claim is made or implied.
L4. The judgment term is exposed to metric gaming (open)¶
J — earned Judgment, the supply side of the should-gate W <= J — is a measured quantity that gates automaticity. Any measured quantity that gates becomes a target: measured J can be improved by an agent or its operator without improvement in the judgment it proxies. This specification provides no guard against that pressure — no stress-weighting analogous to Proof of Resilience on the CAN rail, no adversarial discipline on the J estimate.
v2 records this as an open limitation. No repair is claimed.
Adjacent but distinct: J also fails to survive actor substitution unless the actor-binding law is stated and enforced. That failure has a named repair and is carried as a spec obligation, not a limit.
L5. The terminal generation ceiling never binds arithmetically¶
The generation-7+ ceiling on E_{base} is 100, and the composition reaches 100 only when every term is simultaneously at its maximum share. The terminal ceiling therefore never withholds anything the composition could otherwise grant. It is retained deliberately: it states that terminal maturity is the absence of a generation limit, and it keeps the ceiling table total. This is a disclosure, not a defect.
L6. Episode overlap has no declared precedence mechanism (staged)¶
Episode overlap. Episode membership is a relation, not a function: one event may carry several parent episode identifiers, each fixed before execution. v2 declares no precedence mechanism between them. Absent one, disagreeing adjudications combine restrictively under Section 6.7 — the supervision floor is the maximum and the constraint set the tightest of the applicable tokens — and an implementation MUST NOT resolve a disagreement toward permission. Owed for v2.1: the identity-stability property (an episode identifier is a function of actor and adjudication context, never of accumulated evidence), termination and merge semantics, the schema carrier for declared precedence, and whether any explicit artifact may relax the restrictive composition.
L7. Some catalogued quantities are named, not measured¶
This specification does not claim that a populated signal is a measurement of the phenomenon its identifier names. Two classes fall outside the claim. In the first, the observand is absent from any observation of the world: quantities that require the result of the act that was not taken, and quantities that require another party's internal state. In the second, the observand exists but resolves only after the decision it would inform — silent-failure and false-negative rates, adjudicated accuracy, replication outcomes, and every identifier that names a future fact.
The first class is not a measurement problem that a better instrument closes. A
counterfactual quantity requires the outcome of a thing that did not happen, and
another mind is not available to any instrument the agent holds. A classifier
can emit 0.83; that does not mean the phenomenon named by the identifier is
identifiable or has been measured. In the second class the defect is timing
rather than identifiability: a quantity measurable only after the authorized
action is either stale or empty at the commit point, and an empty signal is not
a low reading.
A conformant implementation MUST NOT treat the presence of an identifier as evidence that the named phenomenon was measured. For any signal in either class, the deployment profile MUST declare the estimator or model that produces the value and the population against which it was validated; a signal in the second class MUST additionally carry its earliest-availability offset, and an aggregation MUST NOT treat a lagging signal as current. An absent or expired value MUST fail closed and MUST NOT be read as absence of risk. A signal whose value would require covert inference of a person's internal state MUST NOT be populated by inference; a declared self-report instrument, or nothing.
One further boundary inside the first class, and it is not ours to move: the relational signals drawn from Indigenous framing describe a relation between parties, and reducing that relation to a classifier output is a different order of error than a unit mistake. This specification does not claim the authority to set that bar.
Converts to spec text when each affected identifier either renames to the estimator the system actually holds, with provenance as a required field, or carries a declared instrument with stated validation, and the availability offset becomes a required envelope field.
L8. A value that encodes a classification is not an observation¶
This specification does not claim that a signal whose value depends on a taxonomy is an observation of the world. Where the label set, the thresholds, the adjudicating party, or whose perspective counts determines the number, the value carries a contested choice in the shape of a fact. What this specification fixes is the interface. It does not fix the choice, and it does not claim its own published taxonomies are neutral ones.
The class is large and was measured rather than estimated: on the order of 170
signals, of which roughly 90 enumerate their label set in the identifier
namespace — change the taxonomy and the signal count changes — about 20 are
derived over those label sets and arithmetically bound to them, and the
remainder turn on a single contested boundary that moves the value. The
uncontested half is the proof the rule works: signals that cite an external
standard, or that declare their taxonomy silently in the unit column, are not
contested. The contested rows are precisely the ones whose unit column reads
0-1.
A conformant implementation MUST declare, in its deployment profile, the label set each such signal populates, and a signal with no declared label set MUST NOT be used in a Risk Factor aggregation. A signal derived over a declared label set of cardinality N MUST state its range in terms of N. Two cases lie outside what declaration reaches, and this specification does not claim they are repaired by it: a single scalar asserting that heterogeneous legal requirements are commensurable, and a completion measure that lets the party responsible for a harm declare that harm closed. Neither MAY be presented as a measurement of compliance or of restoration. Where a taxonomy already published carries hard-coded trust baselines, declaring the label set does not unship the baseline, and an implementation MUST NOT cite the declaration as though it had.
Converts to spec text when the declared-label-set obligation and the declared-unit obligation are settled as one obligation or two, and the published taxonomies carrying fixed baselines are either re-derived from a declared authority or withdrawn.
L9. Declared non-coverage¶
A complete and entirely unalarming signal set is not a statement that an act is safe. Three things no signal in this catalogue reads, and this specification declares them absent rather than leaving the silence to be discovered. Nothing measures the sensitivity or the usage restriction of the content the act concerns. Nothing measures whether a counterparty is the party the graph says it is — uniquely bound, live, non-cloned, continuously controlled, the same party as last time. Nothing measures the agent's own runtime integrity below firmware, or its physical actuation state, including its ability to stop.
Each gap has a specific consequence and that is why they are named. The epistemic domain measures whether the environment is truthful, manipulated, fresh and amplified, and none of that reads whether the thing in hand is a secret, a credential, personal or health or financial data, a restricted record, or purpose-limited; that is the gap that turns a correct authorization into a disclosure incident with every other domain reading green. The relational domain measures inbound trust and authority-source for entities whose identity it never establishes, which is this framework's own trajectory-is-identity doctrine turned back on it: it reads the credential. The substrate domain covers firmware and stops, leaving kernel, hypervisor, runtime, loaded model, executable image and active process set unmeasured, and no domain anywhere holds commanded-versus-actual motion, force, braking, interlock, or emergency-stop state.
A conformant implementation MUST NOT infer the absence of these risks from completeness of coverage. Where a deployment's governed actions can touch restricted content, an unverified counterparty, or physical actuation, the constraint MUST be obtained from outside this catalogue and declared in the deployment profile, and the implementation MUST fail closed rather than proceed on ambient signals alone. Conformance to the signal catalogue is not a claim about any of the three.
Converts to spec text when sensitivity is sited (a property of the act or a signal about the environment; declared label, detected label, or both), counterparty identity assurance is sited, and the substrate domain either carries actuation state or states its exclusion as scope.
L10. E carries no cardinal consequence units¶
This specification does not claim that E is denominated in units of consequence. E is an ordinal position on a hundred-point display scale, and the Trust Score E_trust = E_base x (1 - R) is a scaling of that position, not a budget in any physical, temporal or monetary unit.
An ordinal score does not acquire units by being multiplied by (1 - R). Any statement that a given E authorizes a given magnitude of consequence, and any comparison of E across two deployments, requires a bridge law from the score to a declared consequence unit, and no such law is stated here.
A conformant implementation MAY use the hundred-point scale as a display calibration. It MUST NOT represent an E value as a maximum tolerable consequence budget, and MUST NOT compare E values across deployments that have not declared a common calibration.
Converts to spec text when a bridge law fixes E to a declared consequence unit and the display scale is restated as a calibration of that unit.
L11. There are two SHOULD rails, and only one of them is this specification's¶
Above the CAN rail (A <= E: what the environment can support) sit two should-questions, and they are not the same question.
The first is this specification's: should the environment allow this to happen — a prudence judgment computed from the same measured environment as the CAN rail. It is amoral. The graduated enforcement outcomes (throttle, downgrade, defer), hysteresis, the risk floor under suspicious conditions, deautomation as A approaches E, and the taxation trade are all this rail, and two honest deployments with identical sensors and identical declared parameters converge on its answers: its disputes are measurement disputes. The rail stays amoral only while its parameters are declared — the specification ships the mechanism, the deployment declares the appetite, and an undeclared prudence constant is a smuggled norm.
The second is normative — ought this happen — and it is external to this specification by derivation, not by editorial convenience: a rail whose norms are supplied by the system the norms constrain has no base case, which is L2 applied a second time. Honest parties may legitimately diverge on its answers at any parameter setting; its failures are capture and illegitimacy, and they are corrected by governance, not by measurement. Its content lives in a declared external schema (the co-authored normative profile); this specification carries only the interface.
The carriage interface admits norm content in exactly three shapes: a veto (the Soul constraint), a supplied input (a declared, externally provided signal), and a gate (an adjudication token against a declared schema). Norm content MUST NOT rewrite the aggregation: a normative judgment that scales capacity rather than gating it has crossed into the measurement layer, and the crossing is the failure this entry exists to name. A conformant implementation MUST carry the mechanism — the gate, the token, envelope carriage, and fail-closed behavior on an undefined demand term — MUST reference a declared external schema for norm content, and MUST NOT present conformance as evidence that the norms in force are adequate.
Converts further when the co-authored profile lands and the two documents cross-reference; the prudence-rail naming paragraph is spec text now.
L12. The privacy marker has no stated rule¶
The marker that identifies human-derived telemetry is descriptive. This specification does not state the rule that produces the marked set, does not claim the marked set is complete or internally consistent, and does not claim the marker is sufficient as the attachment point for a consent architecture. It does not authorize collection, and it never did.
The inconsistency is visible on the face of the catalogue: a person-count in the environment domain is marked, a vehicle count is not, and neither is any economic signal, though all three are aggregate human behavior. The two candidate rules — individually identifiable, and human-derived — mark materially different sets, and the current marking reads as a partial application of the broader one. Whether the marker propagates to a derivative computed over marked telemetry is also unstated, and the adopted derivation rule creates such derivatives in quantity.
A conformant implementation MUST NOT rely on the marker's absence as evidence that a signal falls outside a consent obligation, and MUST NOT treat its presence as authorization to collect. A deployment handling human-derived telemetry MUST determine its obligations from the applicable legal regime and, where a community sets the bar for its own data, from that community's instrument. That bar is not set here.
Converts to spec text when one of the two rules is adopted, applied across the catalogue as a sweep rather than per signal, and the derivative-propagation rule is stated.
L13. The resilience evidence curve is uncalibrated¶
This specification does not claim that its upper capability tiers are reachable by a plausible deployment. The resilience contribution grows logarithmically in accumulated attested evidence, so each fixed increment of contribution costs an order of magnitude more evidence than the one before it. The curve was chosen for that shape — early attestations count, later ones diminish — and was never fitted to the thresholds that read it. What evidence mass should correspond to what contribution is stated nowhere in the corpus.
The consequence is arithmetic and it is checkable in an afternoon, which is why it is stated here rather than found later. This specification's own worked example of an agent that has been tested under fire lands in the lowest tier before any additional readiness restriction. The upper thresholds require much more attested evidence, but no published empirical regime calibrates that amount to operational capability or a plausible time to attainment. The ceiling written into the resilience term sits so far above the top tier's own requirement that it has never bound a computation in any published version, under either reading of the type error that was ruled out separately.
The curve prices capability in accumulated evidence, and prices it steeply. That is the design. What it has never done is publish the price.
A conformant implementation MUST NOT present tier attainability as a property of the protocol independent of a declared evidence regime. A deployment claiming a tier MUST declare its history-with-scoped-readiness policy and the attestation regime the claim rests on, and MUST NOT cite the resilience ceiling as a bound on anything. Retaining historical PoR without inactivity subtraction removes an unsupported decay rule; it does not calibrate the logarithmic curve, establish fair access to attestable adversity, or prove tier attainability. Passing a readiness assessment establishes only the assessed operation under its current scope and evidence, not those broader claims.
Converts to spec text when either a scale constant is fitted to the tier table, or the tier table is reduced to the tiers a declared regime can enter, with the ceiling term made to bind or removed.
L14. One Risk Factor is externally supplied, and the specification says so¶
This specification does not claim that all seven Risk Factors share a
provenance. Six are named aggregations over declared subsets of Context Signals.
moment_criticality is not: it is supplied by the action request. The asymmetry
is declared at the site of use rather than left to be inferred from the
catalogue's silence.
The reason it cannot be repaired by adding signals is that the quantity is on the other side of the relation. Every domain in the catalogue measures E; criticality relative to an event horizon is a property of the act proposed against the environment, not of the environment, and so it measures A. A catalogue that has only ever held one side of A <= E has nothing for this Risk Factor to aggregate, and that is a fact about the object, not an omission in the authoring.
A conformant implementation MUST declare, at the site of use, that an externally supplied Risk Factor input is externally supplied, together with the supplying party and the unit convention in force. It MUST NOT present the value as signal-derived, MUST NOT claim a declared Context Signal subset underneath it, and MUST NOT compare the value across deployments that have not declared a common convention. Absent input MUST fail closed on the same rule as any other undefined term.
Converts to spec text when the task-side domain lands, giving this quantity signals to aggregate and stating the supplier, the units, and the verification path a verifier walks. That domain is carried as a v2.1 obligation; until it lands, the declaration is the whole of the treatment.
Security Considerations¶
This section addresses security considerations for KTP implementations.
Trust Oracle Compromise¶
The Trust Oracle is the most critical component. A compromised Oracle could issue fraudulent Trust Proofs, enabling unauthorized actions.
Mitigations: - Distribute across multiple failure domains - Use threshold signatures (k-of-n) - Store signing keys in HSMs - Rotate keys on a defined schedule - Monitor for anomalous Trust Proof issuance - Implement Byzantine fault tolerance
Sensor Manipulation¶
Attackers may attempt to manipulate sensors to reduce R, thereby increasing E_trust and enabling higher-risk actions.
Mitigations: - Use multiple independent sensors per dimension - Cross-validate sensors (e.g., CO2 should correlate with badge) - Detect sudden sensor value changes - Maintain minimum R floor during suspicious conditions - Physically secure sensor infrastructure
Replay Attacks¶
Attackers may capture and replay Trust Proofs.
Mitigations: - Short Trust Proof lifetime (max 10 seconds) - Include action hash in Trust Proof - Track Trust Proof JTIs to prevent reuse
- Bind Trust Proof to TLS session
Trajectory Forgery¶
Attackers may attempt to forge agent trajectories to inflate E_base.
Mitigations: - Trajectory chains require Oracle co-signature - Each transaction links to previous state hash - Continuity enforcement prevents "teleportation" - See [KTP-IDENTITY] for detailed countermeasures
Denial of Service¶
Attackers may artificially increase R (e.g., by generating WAF blocks) to deny service to legitimate agents.
Mitigations: - Distinguish attack indicators from legitimate load - Implement hysteresis to prevent oscillation - Allow operators to adjust weights during confirmed attacks - Maintain minimum capability for critical agents
Privacy Considerations¶
Trust Proofs contain detailed information about agent history, environmental conditions, and organizational operations.
Mitigations: - Encrypt Trust Proofs in transit - Implement access controls on Flight Recorder - Consider privacy-preserving Trust Proofs (ZK proofs of E_trust >= threshold without revealing actual value) - Comply with relevant data protection regulations
IANA Considerations¶
This document requests the following IANA registrations:
JWT Claim Registration¶
Claim Name: ktp Claim Description: Kinetic Trust Protocol data Change Controller: IETF Specification Document(s): This document
Media Type Registration¶
Type name: application Subtype name: ktp+jwt Required parameters: None Optional parameters: None Encoding considerations: binary (JWT is Base64url-encoded) Security considerations: See Section 10 Interoperability considerations: None Published specification: This document Applications which use this media type: KTP implementations Fragment identifier considerations: None Restrictions on usage: None Additional information: None Person to contact for further information: [TBD] Intended usage: COMMON Author/Change controller: IETF
URI Scheme Registration¶
Scheme name: ktp Status: Provisional Applications/protocols that use this scheme: KTP Contact: [TBD] Change controller: IETF References: This document
Changes from v1¶
This appendix records what a v1 implementation must change to conform to v2.0.0. The break is deliberate and there is no dual-accept period: an implementation reads v1 or it reads v2.
The lineage stage names¶
The three lineage stages are renamed on the wire and in prose. Numeric protobuf values are unchanged, so only the symbol names move.
| v1 | v2.0.0 |
|---|---|
tethered |
sponsored |
divergent |
independent |
persistent |
guarantor |
This affects agent identifier strings (agent:<stage>:...), the lineage
enum, and the protobuf LineageType member names. The v1 words each carried
an unintended security reading - in jailbreak and intrusion vocabulary,
"tethered" means a compromise that dies at reboot and "persistent" is the
established word for one that survives a restart - and the three together read
as a coherent escalation narrative rather than as a maturity ladder. Stage 3
is now named for what it can be held to rather than what it is freed of.
The E_base composition¶
v1 computed E_base as a weighted sum — Proof of Resilience at 70%, a Lineage_cap summand at 20%, a sponsor term at 10% — whose prose and formula were mutually unsatisfiable, and which multiplied a contribution cap by a weight so the same 70 was charged twice. v2.0.0 replaces it with a hundred-point allocation: shares sum to 100, each term contributes at most its share, lineage generation bounds E_base through a ceiling ramp instead of contributing to it, and the External Root term (the accountability instrument) replaces the sponsor weight. See Section 5.1; an implementation computing the v1 formula does not conform to v2.
The risk_factors object and the per-tier caps¶
The v1 wire object named context_tensor is renamed risk_factors in v2.0.0, and its keys are the six input names rather than single letters. The per-tier numeric action cap (Max A) is deleted: a tier permits action classes, and the numeric bound is the Zeroth Law itself, A <= E_trust, evaluated per action.
The Trust Tier thresholds¶
| Tier | v1 | v2.0.0 |
|---|---|---|
| Admin Mode | E_trust >= 95 |
E_trust >= 85 |
| Operator Mode | E_trust >= 85 |
E_trust >= 72 |
| Analyst Mode | E_trust >= 70 |
E_trust >= 58 |
| Observer Mode | E_trust >= 50 |
E_trust >= 22 |
| Hibernation | E_trust < 50 |
E_trust < 22 |
The v1 set was unreachable from the v1 generation ceilings: generations 0 through 2 were capped below the lowest threshold, so an agent was in Hibernation by lineage rather than by environment, and the top tier could not be reached in any zone at the calm conditions the specification's own worked example uses. The generation ceilings are unchanged; one table moved, not two.
Two consequences travel with the change. Hibernation exit moves from
E_trust >= 55 to E_trust >= 24, because a five-point hysteresis over a
floor of 50 becomes a thirty-three-point one over a floor of 22. And the
stable-conditions requirement for the top tier moves from R < 0.05 to
R < 0.10, because 0.05 is stricter than the calm baseline the corpus
illustrates.
Example Calculations¶
A.1. Stadium Network at Kickoff
Scenario: A deployment agent attempts to push a code update to the ticketing system during a major sporting event.
Sensor values: CO2: 1800 ppm Link saturation: 92% WAF blocks: 200/min Time to kickoff: 5 minutes Dependency count: 50 VIP count: 2
Normalization: M = (1800 - 400) / 1600 = 0.875 P = 92 / 100 = 0.920 H = 200 / 10000 = 0.020 T = 1 - (0.083 / 72) = 0.999 ≈ 1.000 I = 50 / 500 = 0.100 O = 2 / 50 = 0.040
Domain weights (stadium): w_M=0.30, w_P=0.25, w_H=0.20, w_T=0.15, w_I=0.05, w_O=0.05
Risk calculation: R = (0.30 * 0.875) + (0.25 * 0.920) + (0.20 * 0.020) + (0.15 * 1.000) + (0.05 * 0.100) + (0.05 * 0.040) R = 0.263 + 0.230 + 0.004 + 0.150 + 0.005 + 0.002 R = 0.654
Agent E_base: 95 (highly trusted deployment agent)
E_trust calculation: E_trust = 95 * (1 - 0.654) = 95 * 0.346 = 32.87
Action requested: Deploy code (A = 50)
Zeroth Law evaluation: A <= E_trust ? 50 <= 32.87 ? FALSE
Result: Silent Veto. Deployment denied.
A.2. Same Agent, Calm Conditions
Same agent, but during a maintenance window:
Sensor values: CO2: 450 ppm Link saturation: 12% WAF blocks: 5/min Time to event: 48 hours Dependency count: 50 VIP count: 0
Normalization: M = (450 - 400) / 1600 = 0.031 P = 12 / 100 = 0.120 H = 5 / 10000 = 0.001 T = 1 - (48 / 72) = 0.333 I = 50 / 500 = 0.100 O = 0 / 50 = 0.000
Risk calculation: R = (0.30 * 0.031) + (0.25 * 0.120) + (0.20 * 0.001) + (0.15 * 0.333) + (0.05 * 0.100) + (0.05 * 0.000) R = 0.009 + 0.030 + 0.000 + 0.050 + 0.005 + 0.000 R = 0.094
E_trust calculation: E_trust = 95 * (1 - 0.094) = 95 * 0.906 = 86.07
Action requested: Deploy code (A = 50)
Zeroth Law evaluation: A <= E_trust ? 50 <= 86.07 ? TRUE
Result: Action permitted.
JSON Schemas¶
B.1. Trust Proof Schema
The canonical schema is the published file, not this appendix.
Location: https://kinetic-trust-protocol.net/specs/schemas/v2/trust-proof.json
SHA-256 of the canonical file at the time this document was produced: 41d5dd2506893094d41e21193cf95eed396dc99b8d32d7264f50ea1a7972d4e0
The published file carries the v2 claims (the declared peer share, applicable ceilings, advancement floor, and root instrument) and references the risk-factors schema. This appendix previously carried a hand-copied inline schema; hand copies of a schema drift, and this document's did — the copy disagreed with the published file in four ways while nobody could validate either. A reference plus a hash cannot drift silently: a mismatch is detectable, an edit to the file changes the hash, and the appendix stops being a second authority.