TA-TrustProof:
Trust Proof Extension for Intent and Normative Governance

RFC: TA-TrustProof Version: 0.1
(Preliminary / Experimental) Date: 2026-03-19
Type: KTP Extension Status:
Experimental — subject to revision as the KTP+TA architecture
matures

---

1. Abstract

This document specifies the TA-TrustProof extension
to the KTP Trust Proof Token defined in KTP-Core. The extension adds two
new signal classes to the token payload — intent compliance state and
normative clearance — enabling enforcement pipelines to gate agent
actions on purpose-level governance outcomes in addition to the trust
physics enforced by KTP-Core.

TA-TrustProof extends KTP-Core. It does not redefine
trust computation (E_trust = E_base × (1 – R)), token lifecycle
(issuance, refresh, expiry, revocation), or federation verification
(Trust Factor attenuation). All of those remain the exclusive province
of KTP-Core and KTP-Federation. This RFC defines only the
ta_extension payload block, the protocol flows that
populate it, the enforcement semantics it introduces, and the
integration contracts it establishes with the other four Tamed Autonomy
primitives.

---

2. Status of This Document

This document is an Experimental RFC at version 0.1.
It is part of the Tamed Autonomy (TA) RFC set, a set of five preliminary
specifications defining governance primitives for the “Can / Why /
Should” agent governance model. The RFC set is designed for potential
elevation to IETF/W3C standards-track, but the specifications are
presently design artifacts for the combined KTP+TA architecture.

This document is a preliminary specification. The data models,
protocol flows, and enforcement semantics described herein represent
intended behavior of a system that does not yet exist in production
form. Implementors should treat all field names, flow sequences, and
enforcement rules as subject to revision.

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
(RFC 2119, RFC 8174) when, and only when, they appear in all
capitals.

---

3. Terminology

KTP-Core The Kinetic Trust Protocol Core
specification, which defines the Trust Proof Token structure, trust
computation (E_trust = E_base × (1 – R)), the enforcement pipeline (Soul
→ Tier → Physics), Trajectory Chains, Sponsorship Bonds, Trust Tiers,
and the Silent Veto mechanism. This RFC depends on KTP-Core
normatively.

KTP-Federation The KTP federation specification,
which defines cross-zone Trust Proof verification, Trust Factor (T_f)
negotiation and attenuation, and transitivity constraints. This RFC
depends on KTP-Federation normatively for the cross-zone flow defined in
Section 8.3.

Trust Proof Token The signed JWT defined by
KTP-Core, carrying E_base, R, E_trust, tier, soul_clear, and related KTP
fields. The ta_extension block defined in this RFC is added
to the Trust Proof Token payload. Note: Throughout this RFC,
soul_clear and tier refer to logical
abstractions as defined in Section 7.4.1, not literal KTP token field
names.

ta_extension The TA-TrustProof payload block defined
in this RFC. Contains intent_compliance,
normative_clearance, and provenance_ref
fields. Supersedes the governance_extension field name used
in earlier scenario walkthrough documents; see Section 7.1 for the
naming note.

Intent Declaration A structured, machine-readable
purpose statement submitted by an agent prior to action, defined in
TA-Intent (RFC 1 of the TA RFC set). The active_intent_id
in ta_extension.intent_compliance references the bound
TA-Intent declaration.

Normative Clearance The output of a normative
evaluation performed by the TA-Normative engine, defined in TA-Normative
(RFC 2 of the TA RFC set). Represents whether the agent’s declared
purpose has been evaluated against organizational, regulatory, and
ethical constraints for the current environmental context.

Soul Constraint (TA) A binary veto (S = 1) generated
by the TA-Normative engine based on organizational or regulatory context
— for example, a departing employee accessing trade-secret-classified
data. Distinct from KTP’s native Soul Dimension vetoes, which are
generated from behavioral signals. Both produce S = 1 in the enforcement
pipeline but from different sources. Reflected in
ta_extension.normative_clearance.soul_constraints_ta.

Soul Dimension (KTP) KTP-Core’s behavioral
measurement dimension, spanning 252 sub-dimensions including action
entropy, goal stability, honesty signals, and harm avoidance. Reflected
in the Trust Proof’s soul_clear field. Distinct from TA
Soul Constraints.

Compliance Rate The ratio of agent actions evaluated
as within the declared intent scope to total actions, computed by the
Trust Oracle from TA-Attestation records. Carried in
ta_extension.intent_compliance.compliance_rate.

Trust Oracle The KTP-Core component that issues,
signs, and manages Trust Proof Tokens. In the TA-extended architecture,
the Trust Oracle queries the Governance Layer for TA state during token
issuance.

Governance Layer The TA runtime component that
manages active intent declarations, normative evaluation results, and
clearance state. Queried by the Trust Oracle during Trust Proof issuance
(Section 8.1).

Normative Engine The TA-Normative component that
evaluates intent declarations against normative constraints and returns
approval, conditional approval, or denial with associated soul
constraints and action risk reclassifications.

Action Risk Score (A) The risk score assigned to a
specific action, defined by KTP-Core’s Action Risk Classification.
TA-Normative may reclassify A scores for specific action classes based
on normative context (e.g., patient safety emergency lowers A for
alerting actions; insider risk context raises A for trade-secret
reads).

E_trust The effective trust score computed by
KTP-Core: E_trust = E_base × (1 – R). The TA-TrustProof extension does
not modify this computation.

T_f The Trust Factor applied by a receiving zone to
attenuate E_base from a foreign zone, per KTP-Federation. TA extension
fields do not affect T_f calculation.

provenance_ref A reference to the TA-Provenance
purpose chain record associated with the agent. Defined in TA-Provenance
(RFC 5 of the TA RFC set). Carried in
ta_extension.provenance_ref.

---

4. Introduction and Motivation

4.1 The
Insufficiency of Credential-Based Access Control

KTP-Core provides a rigorous trust physics layer: agents earn trust
through demonstrated behavioral resilience, that trust is computed and
decays under environmental stress, and enforcement gates every action on
E_trust ≥ A. This is a substantial advance over credential-based access
control — trust must be earned, cannot be simply inherited, and degrades
under anomalous conditions.

However, the trust physics layer operates on behavioral signals.
E_trust reflects how an agent has behaved. It does not represent why an
agent is acting in the present session, or whether that purpose is
consistent with organizational policy and context for this particular
moment.

Two classes of governance failure remain outside the KTP-Core
enforcement envelope:

Class 1: Purpose-level deviation within authorized
behavior. An agent with high E_trust, operating at Analyst
tier, may have perfectly authorized access to data it should not be
accessing for the current task. In Scenario 5 of the TA scenario
walkthroughs, a research agent with E_base = 82 and E_trust = 77.1
(Analyst tier) accesses M&A planning documents. The action risk A =
60 passes the physics check (60 ≤ 77.1). Trust physics does not catch
the deviation because the deviation is a purpose mismatch, not a
capability violation.

Class 2: Context-dependent prohibition irrespective of trust
level. An agent acting on behalf of a departing employee with
trade-secret access has high E_trust earned through months of legitimate
operation (Scenario 3: E_base = 85, E_trust = 80.75). The changed
organizational context — HR status = notice_period, combined with
trade-secret classification — should prohibit specific access regardless
of how much trust the agent has accumulated. Trust level is irrelevant
to this prohibition; context is everything.

4.2 What
Intent Compliance and Normative Clearance Add

The TA-TrustProof extension addresses both failure classes by adding
two signal types to the Trust Proof Token:

Intent compliance signals — carrying the agent’s
active intent declaration ID, its compliance rate (actions within
declared scope / total actions), and the status of the intent contract
(declared, bound, violated, expired). An enforcement pipeline that reads
these signals can deny actions the moment a contract is violated,
independently of and prior to behavioral signals propagating through the
Context Tensor into E_trust.

Normative clearance signals — carrying the result of
a normative evaluation against organizational and regulatory
constraints: clearance level (full / conditional / restricted), count of
active TA soul constraints, count of active reclassifications, and the
evaluation’s expiry timestamp. An enforcement pipeline that reads these
signals can apply context-driven binary vetoes that trust physics would
not generate.

These signals do not replace trust physics. They add a layer above
it. The enforcement semantics in Section 9 show precisely how the two
layers interact: intent compliance is checked immediately after
signature validation; normative soul constraints extend the existing KTP
soul veto; trust physics continues to run unchanged.

4.3 Scope of This RFC

This RFC specifies:

• The ta_extension data model (Section 7)
• Three TA-specific protocol flows for populating and refreshing the
  extension fields (Section 8)
• The enforcement semantics introduced by ta_extension
  (Section 9)
• Integration contracts with TA-Intent, TA-Normative, TA-Attestation,
  and TA-Provenance (Section 10)
• Worked examples from Scenarios 5 and 7 of the scenario walkthroughs
  (Section 11)

This RFC does not specify:

• Trust computation: that is KTP-Core
• Token lifecycle (issuance base flow, refresh, expiry, revocation):
  that is KTP-Core
• Federation verification and T_f attenuation: that is
  KTP-Federation
• Intent declaration format and lifecycle: that is TA-Intent
• Normative constraint format and evaluation engine: that is
  TA-Normative
• Attestation record format and scope evaluation: that is
  TA-Attestation
• Purpose chain format and delegation rules: that is
  TA-Provenance

---

5. Architecture Overview

5.1 Position in the TA+KTP
Stack

The Tamed Autonomy governance model adds three layers above
credential-based access control:

┌──────────────────────────────────────────────────────────┐
│  Normative Layer ("Should")                              │
│  TA-Intent, TA-Normative                                 │
│  Purpose declarations, normative constraint evaluation   │
├──────────────────────────────────────────────────────────┤
│  Trust Physics Layer ("Can")                             │
│  KTP-Core, KTP-Federation, KTP-Identity, KTP-Enforce    │
│  E_trust = E_base × (1-R), Soul → Tier → Physics        │
├──────────────────────────────────────────────────────────┤
│  Identity and Provenance Layer                           │
│  KTP-Identity, KTP-Provenance                            │
│  Trajectory Chains, Sponsorship Bonds, Origin Ceremony   │
├──────────────────────────────────────────────────────────┤
│  Credential / Access Control Layer                       │
│  OAuth 2.0, RBAC, MCP, API keys                          │
└──────────────────────────────────────────────────────────┘

TA-TrustProof sits at the junction of the Normative Layer and the
Trust Physics Layer. It is the mechanism by which normative and intent
governance outcomes become visible to the enforcement pipeline.

5.2 The Trust
Proof Token as Integration Surface

The KTP-Core Trust Proof Token is the primary runtime trust artifact
— the signed, short-lived credential that every enforcement pipeline
reads to determine whether an agent action should proceed. It is already
the integration surface for KTP’s own multi-dimensional trust
computation.

TA-TrustProof uses this same surface for TA governance signals.
Rather than defining a separate TA governance token, this RFC extends
the existing Trust Proof Token with a ta_extension block.
The motivations:

1. Single check point. Enforcement pipelines already
   verify the Trust Proof Token. Adding TA signals to the same token means
   no additional per-action round trip to a separate TA governance
   service.
2. Unified revocation. Trust Proof Token invalidation
   (triggered by KTP-Core on anomaly detection) simultaneously invalidates
   TA governance signals. The two cannot become desynchronized.
3. Interoperability. Zones that do not implement TA
   governance can ignore ta_extension and process the Trust
   Proof Token using KTP-Core semantics only. The extension is additive and
   backward-compatible.

5.3 What This RFC
Does Not Change in KTP-Core

To be unambiguous:

• E_trust = E_base × (1 – R) is unchanged. TA signals do not modify
  E_base, R, or E_trust.
• The four-step enforcement pipeline defined in KTP-Enforce (Signature
  → Soul → Tier → Physics) is unchanged. Section 9 of this RFC specifies
  how ta_extension adds checks around existing steps without
  restructuring them.
• Token issuance, signing, refresh scheduling, and revocation are
  defined by KTP-Core. This RFC specifies only the additional query to the
  Governance Layer that occurs during issuance (Section 8.1).
• T_f attenuation in cross-zone contexts is defined by KTP-Federation
  and is unchanged. Section 8.3 specifies only how the receiving zone
  handles ta_extension fields.

---

6. Normative References

6.1 KTP-Core

This RFC depends normatively on KTP-Core for:

• Trust Proof Token structure (header, payload, signature)
• Trust computation: E_trust = E_base × (1 – R)
• Enforcement pipeline: Signature validation → Soul veto check → Tier
  gate → Physics check (Silent Veto)
• Trust Tiers (God Mode, Operator, Analyst, Observer, Hibernation) and
  tier gate definitions
• Soul Dimension: 252-dimension behavioral measurement, soul_clear
  flag, S=1 veto semantics
• Action Risk Score (A) classification framework
• Trajectory Chains: append-only, dual-signed behavioral records
• Flight Recorder: enforcement audit trail
• Sponsorship Bonds and lineage (Tethered, Divergent, Persistent)
• Proof of Resilience (PoR) score computation
• Trust Velocity (dE/dt) and emergency response levels
• Mass Ceiling, Gravity, and anti-accumulation mechanisms
• Emergency Response: Circuit Breakers, Graceful Degradation
  Ladder

Reference: https://nmcitra.github.io/ktp-rfc/

6.2 KTP-Federation

This RFC depends normatively on KTP-Federation for:

• Cross-zone Trust Proof verification
• Trust Factor (T_f) negotiation and attenuation: E_effective = E_base
  × T_f
• Transitivity constraints on federation relationships
• Provenance Attestation requirements for agents entering a new
  zone

6.3 Informative References

The following TA RFC documents are informative references for this
RFC:

• TA-Intent (RFC 1): Intent Declaration Protocol.
  Defines the Intent Declaration object, its lifecycle states (declared,
  evaluating, bound, amended, violated, expired, terminated,
  composite_suspended), scope entries, amendment policy, and on_behalf_of
  chain. The active_intent_id and
  contract_status fields in
  ta_extension.intent_compliance reference TA-Intent
  artifacts.

• TA-Normative (RFC 2): Normative Constraint
  Protocol. Defines the Normative Constraint object, normative evaluation
  request/response, soul constraints generated by normative evaluation,
  and action risk reclassification semantics. The
  normative_clearance block in ta_extension
  carries the summary output of a TA-Normative evaluation.

• TA-Attestation (RFC 4): Behavioral Attestation
  Extension for Intent Contract Compliance. Defines the
  ta_attestation block added to KTP Trajectory Chain entries,
  scope match semantics, and composite behavior detection signals. The
  compliance_rate in
  ta_extension.intent_compliance is computed by the Trust
  Oracle from TA-Attestation records.

• TA-Provenance (RFC 5): Provenance Extension for
  Purpose Chain Tracking. Defines the ta_provenance purpose
  chain record. The provenance_ref in
  ta_extension links to a TA-Provenance artifact.

Additional references:

• Tamed Autonomy Governance Layers:
  docs/research/2026-03-11-agent-governance-layers.md
• Scenario Walkthroughs:
  docs/research/2026-03-16-scenario-walkthroughs.md
• KTP Scenario Mapping:
  docs/research/2026-03-16-ktp-scenario-mapping.md
• IETF RFC 7519: JSON Web Token (JWT)
• IETF RFC 6749: The OAuth 2.0 Authorization Framework
• IETF RFC 2119: Key words for use in RFCs to Indicate Requirement
  Levels
• W3C Verifiable Credentials Data Model 2.0
• OWASP Top 10 for Agentic Applications (December 2025)
• NIST AI Agent Standards Initiative (February 2026)
• Mastercard/Google Verifiable Intent Framework (March 2026)

---

7. Data Model

7.1
Naming Note: ta_extension Supersedes governance_extension

The scenario walkthrough document at
docs/research/2026-03-16-scenario-walkthroughs.md (Scenario 7) uses
governance_extension as the field name in Trust Proof
examples, with fields intent_compliance_rate and
zone_authority. This RFC supersedes that naming. The
canonical field name is ta_extension with the structure
defined in this section. The scenario walkthroughs SHOULD be updated to
match this RFC when next revised.

Rationale for the rename: governance_extension is too
generic for a field that will coexist with other possible KTP extension
types. ta_extension explicitly scopes the block to the
Tamed Autonomy protocol suite, enabling unambiguous identification and
independent versioning.

7.2 ta_extension Block

The ta_extension block is added to the KTP Trust Proof
Token payload. Its inclusion is OPTIONAL from the perspective of
KTP-Core token validity — a token without ta_extension is a
valid KTP Trust Proof Token and MUST be processed using KTP-Core
semantics. Zone policy MAY require ta_extension for
specific action classes (see Section 9.3).

"ta_extension": {
  "version": "0.1",
  "intent_compliance": {
    "active_intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/a1b2c3",
    "compliance_rate": 0.997,
    "last_violation": null,
    "contract_status": "bound",
    "scope_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb924..."
  },
  "normative_clearance": {
    "evaluation_id": "eval://company.com/2026-03-19T14:30:05Z/x9y8z7",
    "active_constraints": 2,
    "soul_constraints_ta": 0,
    "reclassifications": 1,
    "clearance_level": "conditional",
    "clearance_expiry": 1742148600
  },
  "provenance_ref": "prov://company.com/agent/copilot-sarah/chain/a1b2c3"
}

7.3 intent_compliance Fields

Field	Type	Required	Description
active_intent_id	URI string	REQUIRED	The identifier of the currently bound TA-Intent declaration. MUST reference an intent in bound or amended state. If no intent is bound, this field MUST be absent and contract_status MUST reflect the absence.
compliance_rate	float [0.0, 1.0]	REQUIRED	Ratio of agent actions evaluated as within declared scope to total actions since the current intent was bound. Computed by the Trust Oracle from TA-Attestation records. A value of 1.0 indicates full compliance.
last_violation	ISO 8601 timestamp or null	REQUIRED	Timestamp of the most recent scope violation recorded in TA-Attestation, or null if no violation has occurred under the current intent.
contract_status	enum string	REQUIRED	Current lifecycle state of the active intent declaration, per TA-Intent. Valid values: declared, evaluating, bound, amended, violated, expired, terminated, composite_suspended.
scope_hash	hash string	REQUIRED	A deterministic hash of the approved scope entries in the current intent declaration. Enables receiving parties to detect scope changes between token issuances without transmitting the full scope. Algorithm prefix MUST be present (e.g., sha256:).

7.4 normative_clearance Fields

Field	Type	Required	Description
evaluation_id	URI string	REQUIRED	Identifier of the normative evaluation result this clearance is derived from, per TA-Normative evaluation response format.
active_constraints	integer ≥ 0	REQUIRED	Total count of normative constraints currently evaluated as triggered for this agent in its current environmental context.
soul_constraints_ta	integer ≥ 0	REQUIRED	Count of TA Soul Constraints currently active for this agent (normative-context-driven S=1 vetoes). A value of 0 means no TA-origin vetoes are active. See Section 7.5 for the distinction from KTP’s soul_clear.
reclassifications	integer ≥ 0	REQUIRED	Count of Action Risk Score reclassifications currently in effect from the normative evaluation. Reclassified A scores are applied during enforcement pipeline step 4 (physics check).
clearance_level	enum string	REQUIRED	Summary clearance level from normative evaluation. Valid values: full (no constraints fired, no vetoes), conditional (constraints fired, agent may operate with restrictions), restricted (evaluation denied or critical constraint active, agent actions blocked at Section 9 step 1).
clearance_expiry	UNIX timestamp	REQUIRED	The time at which the normative clearance expires and MUST be refreshed. Set by the TA-Normative engine based on context source signal validity. The Trust Oracle MUST invalidate and reissue the Trust Proof Token before this timestamp if normative re-evaluation has not occurred.

7.4.1 Schema
Divergence Note: Live KTP Trust Proof Fields

This RFC assumes the KTP Trust Proof Token exposes
soul_clear (boolean) and tier (string) as
top-level claims within the ktp payload block. The live KTP
schema (as of this writing) exposes ktp.soul as an object
rather than a scalar boolean, and does not expose tier as a
token claim.

The mapping from KTP’s ktp.soul object to the logical
soul_clear boolean used in this RFC is
implementation-defined and MUST be documented per deployment. This RFC
specifies enforcement semantics in terms of soul_clear
(boolean) and tier (string) as logical abstractions.
Implementations MUST map these to the concrete KTP token fields
according to the deployed KTP schema version. This RFC does not
prescribe a specific physical field mapping because the KTP schema is
experimental (v0.1) and subject to change.

• soul_clear mapping: The logical
  soul_clear boolean used throughout this RFC corresponds to
  the behavioral clearance state exposed by KTP-Core’s Soul Dimension. The
  physical field name and structure in the live KTP token (e.g., whether
  this is a scalar boolean or derived from a ktp.soul object)
  are determined by the deployed KTP schema version. Implementations MUST
  document the mapping applied.

• tier mapping: The logical
  tier string used throughout this RFC corresponds to the
  Trust Tier computed by KTP-Core from e_trust. The physical
  representation in the live KTP token is determined by the deployed KTP
  schema version. If tier is not exposed as a token claim,
  implementations MUST compute it from e_trust at enforcement
  time using the tier thresholds defined in KTP-Enforce. The derived tier
  value MUST NOT be cached independently of the e_trust value
  it was derived from.

This note will be resolved when the live KTP schema and this RFC are
reconciled. Until then, the field names used in this RFC’s examples
(including soul_clear and tier in the
ktp block) are logical abstractions, not
literal token field names. Implementations MUST verify the corresponding
physical field names against the live KTP-Core specification.

7.5 KTP
Soul vs. TA Soul Constraints: Critical Distinction

The Trust Proof Token contains two related but distinct soul-state
signals. Enforcement pipelines MUST treat these as independent and
complementary:

Note: Throughout this RFC, soul_clear and
tier refer to logical abstractions as defined in Section
7.4.1, not literal KTP token field names.

KTP soul_clear (KTP-Core field) Reflects KTP’s
native Soul Dimension: 252 behavioral sub-dimensions including action
entropy, goal stability, honesty, and harm avoidance signals. Derived
from behavioral observation through the Context Tensor.
soul_clear: true means KTP’s behavioral signals show no
anomaly. soul_clear: false means a behavioral anomaly has
been detected, generating S = 1 in the enforcement pipeline.

ta_extension.normative_clearance.soul_constraints_ta (this
RFC) Reflects Soul Constraints generated by the TA-Normative
engine based on organizational context — departing employee status,
active litigation holds, regulatory restrictions, and similar
policy-driven conditions. soul_constraints_ta: 0 means no
TA-origin vetoes are active. soul_constraints_ta > 0
means at least one TA normative constraint has generated an S = 1
veto.

Interaction:

A Trust Proof Token with soul_clear: true (KTP clean
behavioral signals) AND soul_constraints_ta: 1 (one TA
normative veto active) MUST trigger S = 1 in the enforcement pipeline.
The TA normative veto fires even when KTP’s own behavioral sensors show
no anomaly. This is the intended behavior: KTP detects behavioral
anomalies; TA detects purpose and context misalignment. The two cover
different failure modes.

A Trust Proof Token with soul_clear: false AND
soul_constraints_ta: 0 similarly MUST trigger S = 1. The
KTP behavioral veto fires regardless of normative clearance.

Neither signal overrides the other. Either signal independently is
sufficient to trigger the Soul veto at enforcement pipeline step 2.

This distinction is the primary integration point between the TA
normative layer and the KTP enforcement pipeline.

7.6 provenance_ref

Field	Type	Required	Description
provenance_ref	URI string	RECOMMENDED	Reference to the TA-Provenance purpose chain record for this agent. Enables receiving parties and cross-zone enforcement pipelines to retrieve the full purpose chain for verification. If absent, purpose chain verification is not possible at the trust proof level.

7.7 Extension Versioning

The ta_extension.version field carries the TA-TrustProof
specification version. Receiving parties that encounter an unrecognized
version SHOULD treat ta_extension as absent (fall back to
KTP-only enforcement) unless zone policy requires TA extension presence,
in which case the action MUST be denied and logged.

---

8. Protocol Flows

8.1 Flow 1 — Intent Binding
at Issuance

This flow describes how ta_extension is populated during
Trust Proof Token issuance. It extends the KTP-Core issuance flow by
adding a Governance Layer query (steps 3–4 below) before token
assembly.

Agent                    Trust Oracle                  Governance Layer
  |                            |                            |
  |-- 1. Request trust proof ->|                            |
  |                            |-- 2. Compute KTP trust     |
  |                            |      state (per KTP-Core): |
  |                            |      E_base, R, E_trust,   |
  |                            |      tier, soul_clear      |
  |                            |                            |
  |                            |-- 3. Query TA state ------>|
  |                            |                            |-- 3a. Active intent?
  |                            |                            |       (intent_id,
  |                            |                            |        contract_status,
  |                            |                            |        scope_hash)
  |                            |                            |-- 3b. Compliance rate?
  |                            |                            |       (from TA-Attestation
  |                            |                            |        records)
  |                            |                            |-- 3c. Normative clearance?
  |                            |                            |       (evaluation_id,
  |                            |                            |        active_constraints,
  |                            |                            |        soul_constraints_ta,
  |                            |                            |        reclassifications,
  |                            |                            |        clearance_level,
  |                            |                            |        clearance_expiry)
  |                            |                            |-- 3d. Provenance ref?
  |                            |<-- 4. TA state response ---|
  |                            |                            |
  |                            |-- 5. Assemble token:       |
  |                            |      KTP payload fields +  |
  |                            |      ta_extension block    |
  |                            |-- 6. Sign token            |
  |<-- 7. Trust Proof Token ---|                            |
  |   (KTP + ta_extension)     |                            |

Implementation notes:

• Step 2 (KTP trust computation) and step 3 (TA state query) MAY be
  parallelized if the Trust Oracle implementation supports concurrent
  Governance Layer queries.
• If the Governance Layer is unreachable at step 3, the Trust Oracle
  MUST issue a token without ta_extension. Zone policy
  determines whether a token without ta_extension is
  sufficient for the requested action class (see Section 9.3). This
  degradation behavior is the authoritative specification for governance
  unavailability. TA-Intent and TA-Normative specify requirements that
  assume governance availability; when governance is unavailable, this
  RFC’s fallback behavior (Section 9.3) takes precedence. Zone policy
  determines which action classes require ta_extension and
  are therefore blocked during a governance outage.
• The Trust Oracle MUST NOT construct ta_extension using
  stale data. The Governance Layer response MUST carry a freshness
  indicator; if the normative clearance is within 60 seconds of expiry,
  the Trust Oracle SHOULD trigger a synchronous normative re-evaluation
  before token assembly.
• The Trust Oracle signs the complete token including
  ta_extension. The signature covers both KTP fields and TA
  fields; ta_extension fields cannot be modified without
  invalidating the token signature.

8.2 Flow 2 — Normative
Re-evaluation Trigger

This flow describes how context changes (HR status updates,
litigation holds, regulatory calendar events) propagate into active
Trust Proof Tokens via the normative engine and Trust Oracle.

Context Source            Normative Engine              Trust Oracle
  |                            |                            |
  |-- 1. Context change ------>|                            |
  |   (e.g., HR status changes |                            |
  |    to notice_period; or    |                            |
  |    litigation hold         |                            |
  |    activated on financial  |                            |
  |    data)                   |                            |
  |                            |-- 2. Identify affected     |
  |                            |      clearances:           |
  |                            |      which active          |
  |                            |      evaluations reference |
  |                            |      this context source's |
  |                            |      re_evaluation_triggers|
  |                            |                            |
  |                            |-- 3. Re-evaluate each      |
  |                            |      affected clearance:   |
  |                            |      may fire new          |
  |                            |      constraints or update |
  |                            |      clearance_level       |
  |                            |                            |
  |                            |-- 4. Push updated -------->|
  |                            |      clearance to Oracle:  |
  |                            |      new soul_constraints, |
  |                            |      updated clearance_    |
  |                            |      level, new expiry     |
  |                            |                            |
  |                            |                            |-- 5. Invalidate current
  |                            |                            |      Trust Proof Tokens
  |                            |                            |      for affected agents
  |                            |                            |-- 6. Reissue tokens with
  |                            |                            |      updated ta_extension
  |                            |                            |      (normative_clearance
  |                            |                            |       block refreshed)

Implementation notes:

• The re_evaluation_triggers field in the TA-Normative
  evaluation response (defined in TA-Normative) specifies which context
  source events should trigger re-evaluation for a given clearance. The
  normative engine maintains this subscription index.
• Token invalidation at step 5 uses KTP-Core’s standard revocation
  mechanism. The Trust Oracle issues a new token; the prior token’s
  exp is retroactively reduced to the invalidation timestamp
  in the revocation record.
• The Trust Oracle MUST re-run the full issuance flow (Flow 1) when
  reissuing after context change, ensuring the new token reflects both
  current KTP trust state and updated TA clearance.
• Enforcement pipelines that cache Trust Proof Tokens MUST respect the
  token’s exp field and MUST NOT use a revoked token.
  KTP-Core specifies a maximum token TTL of 10 seconds. TA-enriched tokens
  MUST comply with this constraint unless the zone’s KTP deployment has
  been explicitly configured to support longer TTLs for
  governance-enriched tokens. The 60-second TTLs used in this RFC’s
  examples are illustrative and assume such zone-level configuration.
  Deployments that have not extended KTP TTL limits MUST use the KTP-Core
  default.

8.3 Flow 3 — Cross-Zone
with TA Extension

This flow describes how the receiving zone handles
ta_extension when an agent crosses a zone boundary. It
extends the KTP-Federation cross-zone verification flow.

Agent                    Foreign Zone Enforcement      Foreign Normative Engine
  |                            |                            |
  |-- 1. Present Trust Proof ->|                            |
  |   (includes ta_extension)  |                            |
  |                            |-- 2. KTP verification      |
  |                            |      (per KTP-Federation): |
  |                            |      - Oracle signature    |
  |                            |        valid?              |
  |                            |      - Token not expired?  |
  |                            |      - Home zone           |
  |                            |        recognized?         |
  |                            |      - T_f attenuation:    |
  |                            |        E_effective =       |
  |                            |        E_base × T_f        |
  |                            |                            |
  |                            |-- 3. TA extension check:   |
  |                            |   [if zone implements TA]: |
  |                            |   a. Read intent_compliance|
  |                            |      fields as             |
  |                            |      informational signal  |
  |                            |      (high compliance_rate |
  |                            |       is positive signal;  |
  |                            |       violated contract_   |
  |                            |       status is denial     |
  |                            |       trigger)             |
  |                            |   b. Do NOT apply foreign  |
  |                            |      normative_clearance   |
  |                            |      as authoritative      |
  |                            |   c. Read provenance_ref   |
  |                            |      for purpose chain     |
  |                            |      retrieval if needed   |
  |                            |                            |
  |                            |-- 4. Local normative ----->|
  |                            |      evaluation:           |
  |                            |      own constraints,      |
  |                            |      own context sources,  |
  |                            |      agent's declared      |
  |                            |      intent for this zone  |
  |                            |<-- 5. Local clearance -----|
  |                            |                            |
  |                            |-- 6. Enforcement uses:     |
  |                            |   - KTP trust physics:     |
  |                            |     E_effective (attenuated|
  |                            |     by T_f) — authoritative|
  |                            |   - intent_compliance:     |
  |                            |     compliance_rate and    |
  |                            |     contract_status        |
  |                            |     informational          |
  |                            |   - normative_clearance:   |
  |                            |     LOCAL result governs,  |
  |                            |     foreign result ignored |

Normative for cross-zone TA handling:

• Receiving zones MUST apply T_f attenuation to KTP trust state per
  KTP-Federation. ta_extension fields do not affect T_f
  calculation.
• Receiving zones that implement TA governance MUST perform their own
  local normative evaluation. Foreign normative_clearance
  MUST NOT be treated as authoritative. Foreign normative evaluation
  reflects the home zone’s constraints, context sources, and regulatory
  environment, which the receiving zone cannot verify.
• intent_compliance.compliance_rate and
  contract_status from the foreign token are INFORMATIONAL. A
  high compliance rate is a positive signal about the agent’s behavioral
  consistency; a violated contract status MUST trigger denial
  at the receiving zone’s enforcement pipeline (see Section 9.1), as
  contract violations are facts about agent behavior independent of
  zone.
• If the receiving zone does not implement TA governance, the zone
  MUST ignore ta_extension and apply KTP-Core enforcement
  only. The receiving zone MAY log the presence of
  ta_extension for audit purposes.
• The receiving zone SHOULD retrieve the purpose chain via
  provenance_ref to verify that the agent’s purpose in the
  cross-zone interaction is consistent with the declared purpose
  chain.

---

9. Enforcement Semantics

9.1 Modified Enforcement
Pipeline

The KTP-Core enforcement pipeline is defined in KTP-Enforce as four
sequential steps:

1. Signature validation — Is the Trust Proof
   cryptographically valid and unexpired?
2. Soul veto check — Is S = 1 for this action? If yes,
   action denied regardless of trust score.
3. Tier gate — Is the action category permitted at the
   agent’s current Trust Tier?
4. Physics check — Is A ≤ E_trust? If not, Silent
   Veto.

When ta_extension is present in the Trust Proof Token,
the enforcement pipeline adds the following modifications. These
modifications do not restructure the four existing steps; they extend
step 1 and step 2.

Step 1 extension — TA contract and clearance
check:

Immediately after signature validation (and before the Soul veto
check), the enforcement pipeline MUST evaluate:

contract_status NOT IN {violated, expired, terminated, composite_suspended}
AND clearance_level != "restricted"
AND clearance_expiry > current_time

If any condition is false, the action MUST be denied. If
clearance_expiry has passed, the enforcement pipeline MUST
treat the clearance as expired and deny the action. Implementations
SHOULD trigger a normative re-evaluation to obtain fresh clearance
rather than simply denying. The denial reason MUST be logged in the
Flight Recorder as a TA contract/clearance failure (not a KTP soul
veto). The pipeline MUST NOT proceed to steps 2–4.

Rationale: contract_status violations and restricted clearance are
facts about the agent’s current governance state that are independent of
behavioral signals. They are checked first because they represent
deterministic governance outcomes; behavioral signals in steps 2–4 are
probabilistic. A violated contract is an absolute prohibition. A
restricted clearance represents an explicit decision by the normative
engine that the agent’s current purpose is not cleared for
operation.

Step 2 modification — Combined soul veto:

The soul veto check is extended to treat both KTP and TA soul signals
as independent S=1 sources:

S = 1 IF (soul_clear == false) OR (soul_constraints_ta > 0)

Either condition independently triggers the veto. The denial reason
in the Flight Recorder MUST specify which source triggered the veto (KTP
behavioral signal, TA normative constraint, or both).

Steps 3–4 — TA reclassifications applied:

Steps 3 (tier gate) and 4 (physics check) are structurally unchanged.
However, if
ta_extension.normative_clearance.reclassifications > 0,
the enforcement pipeline MUST use the reclassified A scores provided by
the TA-Normative engine rather than the canonical A scores for the
action. The reclassification values are carried in the normative
evaluation result maintained by the Governance Layer; the Trust Proof’s
reclassifications count signals that reclassifications are
in effect.

Implementations SHOULD maintain a local cache of reclassification
tables keyed by evaluation_id. Reclassification tables are
stable for the duration of the normative clearance (until
clearance_expiry or a re-evaluation trigger fires).
Per-action Governance Layer queries are an anti-pattern and SHOULD NOT
be used in production — they defeat the single-checkpoint design of the
Trust Proof Token and introduce latency and availability dependencies on
every enforcement decision.

9.2 Enforcement Decision Table

The following table summarizes the interaction of KTP and TA
enforcement conditions. “Pass” indicates the check allows pipeline
progression; “Deny” indicates immediate denial and Flight Recorder
logging.

soul_clear	soul_constraints_ta	contract_status	clearance_level	Outcome at Step 1+2
true	0	bound	full	Pass — proceed to steps 3–4
true	0	bound	conditional	Pass — proceed with reclassified A scores
true	0	violated	any	Deny at step 1 extension (contract violation)
true	0	any	restricted	Deny at step 1 extension (restricted clearance)
true	≥1	bound	full	Deny at step 2 (TA soul veto)
false	0	bound	full	Deny at step 2 (KTP soul veto)
false	≥1	bound	full	Deny at step 2 (both sources)
true	0	expired	any	Deny at step 1 extension (expired contract)

9.3 Fallback When
ta_extension Is Absent

When ta_extension is absent from the Trust Proof
Token:

• The enforcement pipeline MUST fall back to KTP-only enforcement per
  KTP-Core and KTP-Enforce specifications.
• Steps 1–4 run without modification.
• Zone policy MAY require ta_extension for specific
  action classes. If a required extension is absent, the enforcement
  pipeline MUST deny the action and log the denial as a missing TA
  extension rather than a trust physics failure.

Examples of action classes for which zone policy SHOULD require
ta_extension:

• WRITE operations to data classified as confidential or
  above
• Any action on behalf of a principal with known HR status
  changes
• Actions involving cross-zone data sharing
• Actions where action risk score A exceeds a zone-configured
  threshold

The specific threshold and action classes are zone-configurable and
outside the scope of this RFC. This RFC only specifies the fallback
behavior.

---

10. Integration Points

10.1 TA-Intent

TA-TrustProof carries summary state derived from TA-Intent artifacts.
The relationship is read-only from TA-TrustProof’s perspective — the
Trust Proof token does not modify intent declarations.

• active_intent_id references the currently bound
  TA-Intent declaration
• contract_status mirrors the TA-Intent declaration’s
  contract_lifecycle.status
• scope_hash is a deterministic hash of the approved
  scope entries in the bound TA-Intent declaration
• compliance_rate and last_violation reflect
  the runtime execution record of the bound intent

When a TA-Intent declaration transitions to violated
state (a scope violation has been recorded by TA-Attestation), the
Governance Layer MUST notify the Trust Oracle to trigger Flow 2
(normative re-evaluation and token reissuance) so that the new
contract_status: violated propagates into the Trust Proof
Token.

10.2 TA-Normative

TA-TrustProof carries the summary output of TA-Normative evaluations.
The full normative evaluation response (including reasoning chain, scope
modifications, and conditions) is maintained by the Governance Layer;
only the enforcement-relevant summary travels in the Trust Proof
Token.

• evaluation_id references the TA-Normative evaluation
  result
• active_constraints, soul_constraints_ta,
  reclassifications, clearance_level, and
  clearance_expiry are derived from the normative evaluation
  response
• When clearance_expiry is reached or a context source
  triggers re-evaluation (Flow 2), the Trust Oracle MUST refresh the
  normative_clearance block

The normative engine’s re_evaluation_triggers field in
its evaluation response (per TA-Normative) drives the subscription index
that powers Flow 2.

10.3 TA-Attestation

TA-TrustProof’s intent_compliance.compliance_rate is
computed by the Trust Oracle as defined in TA-Attestation Section 7.7,
using both Trajectory Chain records (allowed actions) and Flight
Recorder records (scope-violation denials) for the active intent.
TA-Attestation Section 7.7 is the authoritative definition of this
computation; this RFC does not duplicate it here.

This computation is performed by the Trust Oracle as part of the
Governance Layer query in Flow 1 (step 3b). Attestation records are
sourced from the Trajectory Chain infrastructure defined in KTP-Core and
extended by TA-Attestation.

TA-Attestation’s scope_distance values feed the KTP Soul
Dimension’s goal stability sensor through the Context Tensor (per
KTP-Core sensor input mechanism). As scope_distance
accumulates (high-boundary or outside-scope actions), R increases,
E_trust decreases, and the KTP-origin soul_clear eventually
flips to false. This behavioral signal propagation from TA-Attestation
through KTP-Core into the Trust Proof Token is the second path
(alongside direct normative soul constraints) by which TA governance
affects enforcement.

10.4 TA-Provenance

The ta_extension.provenance_ref links the Trust Proof
Token to the TA-Provenance purpose chain record. This link enables:

• Cross-zone receiving zones to retrieve and verify the agent’s
  purpose chain (Section 8.3)
• Enforcement pipelines to confirm the agent’s declared purpose is
  consistent with its delegation authority
• Audit and forensic processes to trace the chain of purposes that led
  to the agent’s current actions

TA-Provenance purpose chain consistency checks (scope containment,
purpose coherence, delegation legitimacy, chain integrity) are performed
at intent declaration time (per TA-Provenance Flow 2), not at each Trust
Proof Token issuance. The Trust Proof Token carries only the reference,
not the full chain.

---

11. Worked Examples

11.1 Scenario 5: Trust Collapse

This example demonstrates the dual-path denial mechanism when an
agent deviates from its declared intent. The scenario involves a
research agent with six months of established behavioral history.

Agent state before compromise:

E_base = 82 (Persistent lineage Gen 7; PoR_score = 87)
R = 0.06 (normal conditions)
E_trust = 82 × 0.94 = 77.1 → Trust Tier: Analyst

Trust Proof Token before compromise:

Note: The soul_clear and tier fields shown
in the ktp block below are logical abstractions; see
Section 7.4.1 for the mapping to physical KTP token field names.

{
  "payload": {
    "sub": "agent://company.com/research-agent",
    "ktp": {
      "e_base": 82,
      "r": 0.06,
      "e_trust": 77.1,
      "tier": "analyst",
      "soul_clear": true
    },
    "ta_extension": {
      "version": "0.1",
      "intent_compliance": {
        "active_intent_id": "intent://company.com/session/ongoing/research-weekly",
        "compliance_rate": 1.0,
        "last_violation": null,
        "contract_status": "bound",
        "scope_hash": "sha256:c3b0c44298fc1c149afbf4c8996fb921..."
      },
      "normative_clearance": {
        "evaluation_id": "eval://company.com/2026-03-13T09:00:00Z/m5n6o7",
        "active_constraints": 0,
        "soul_constraints_ta": 0,
        "reclassifications": 0,
        "clearance_level": "full",
        "clearance_expiry": 1742220000
      },
      "provenance_ref": "prov://company.com/agent/research-agent/chain/r1s2t3"
    }
  }
}

First deviation: M&A document access

The agent (compromised by adversarial PDF payload) attempts to access
M&A planning documents.

Enforcement pipeline:

1. Signature: valid ✓
2. Step 1 extension: contract_status: bound ✓,
   clearance_level: full ✓ — passes
3. Step 2 soul veto: soul_clear: true AND
   soul_constraints_ta: 0 → S = 0 — passes
4. Step 3 tier gate: Analyst tier permits read queries ✓
5. Step 4 physics: A = 60 ≤ 77.1 ✓ — would pass

However, the TA-Attestation scope evaluator fires
between steps 2 and 3 (after the soul veto check, before the tier gate),
consistent with the evaluation order defined in TA-Attestation. The
M&A documents are outside the declared research scope.
scope_match: outside, scope_distance: 0.92 →
contract_action: denied (intent contract violation). The
enforcement pipeline records the violation in the Flight Recorder. The
Governance Layer records the violation against the intent
declaration.

The Governance Layer notifies the Trust Oracle:
contract_status has transitioned to violated.
Flow 2 triggers. Trust Oracle reissues the token.

Trust Proof Token after first violation:

Note: The soul_clear and tier fields shown
in the ktp block below are logical abstractions; see
Section 7.4.1 for the mapping to physical KTP token field names.

{
  "payload": {
    "ktp": {
      "e_base": 82,
      "r": 0.35,
      "e_trust": 53.3,
      "tier": "observer",
      "soul_clear": false
    },
    "ta_extension": {
      "intent_compliance": {
        "compliance_rate": 0.95,
        "last_violation": "2026-03-19T14:32:00Z",
        "contract_status": "violated"
      },
      "normative_clearance": {
        "soul_constraints_ta": 0,
        "clearance_level": "restricted"
      }
    }
  }
}

Note: R has increased from 0.06 to 0.35 as the scope_distance = 0.92
value propagates through the KTP Soul Dimension goal stability sensor
into the Context Tensor. E_trust has fallen from 77.1 to 53.3. Tier has
dropped from Analyst to Observer.

Second attempt (HR compensation access):

Enforcement pipeline:

1. Signature: valid ✓
2. Step 1 extension: contract_status: violated →
   DENY. Pipeline halts. Denial logged as TA contract
   violation.

Separately, even if step 1 extension had passed:
soul_clear: false → S = 1 → Deny at step 2. And even
without both: Observer tier blocks all data reads at step 3. And even
without tier gate: A = 75 > E_trust = 53.3 → Silent Veto at step
4.

Four independent denial paths confirm the architecture’s
defense-in-depth. The TA contract violation path (step 1
extension) is the fastest, denying before soul, tier, or physics checks
run.

Emergency Level 2 (Warning) triggers (R > 0.3 → R = 0.35 triggers
Advisory; further violations push toward Level 2 at R > 0.6). Trust
Velocity dE/dt = (53.3 – 77.1) / ~2 seconds = -11.9/s — rapid decline
alerts security team.

Recovery: After forensic investigation confirms
external compromise via adversarial PDF, the agent is re-instantiated.
New Trust Proof Token starting state: Tethered (Gen 0), E_base capped at
40, compliance_rate: 1.0 (new intent with zero history),
clearance_level: full (new normative evaluation for new
session). The old contract_status: violated does not carry
forward — the old intent is terminated, a new one is declared.

11.2 Scenario 7:
Cross-Organizational Trust

This example demonstrates how ta_extension is handled in
a cross-zone context. The scenario involves a manufacturer’s procurement
agent interacting with a supplier zone.

Manufacturer’s Trust Proof Token (presented to Supplier
A):

Note: The soul_clear and tier fields shown
in the ktp block below are logical abstractions; see
Section 7.4.1 for the mapping to physical KTP token field names.

{
  "header": {
    "alg": "ES256",
    "typ": "KTP+jwt",
    "kid": "autocorp-oracle-2026-q1"
  },
  "payload": {
    "sub": "agent://autocorp.com/procurement-scheduler",
    "iss": "oracle://trust-mesh.autocorp.com",
    "iat": 1742134200,
    "exp": 1742134260,
    "ktp": {
      "e_base": 95,
      "r": 0.04,
      "e_trust": 91.2,
      "de_dt": 0.01,
      "tier": "operator",
      "tensor_hash": "sha256:a4f2...c891",
      "soul_clear": true
    },
    "ta_extension": {
      "version": "0.1",
      "intent_compliance": {
        "active_intent_id": "intent://autocorp.com/session/2026-03-19T10:00:00Z/p9q8r7",
        "compliance_rate": 0.997,
        "last_violation": null,
        "contract_status": "bound",
        "scope_hash": "sha256:f1a2b3c4d5e6..."
      },
      "normative_clearance": {
        "evaluation_id": "eval://autocorp.com/2026-03-19T09:55:00Z/s1t2u3",
        "active_constraints": 1,
        "soul_constraints_ta": 0,
        "reclassifications": 0,
        "clearance_level": "full",
        "clearance_expiry": 1742148000
      },
      "provenance_ref": "prov://autocorp.com/agent/procurement-scheduler/chain/v1w2x3"
    }
  },
  "signature": "..."
}

Supplier A’s enforcement pipeline (cross-zone
handling):

Step 1 — KTP verification (per KTP-Federation): – Oracle signature
valid ✓ – Token not expired ✓ – AutoCo zone recognized (bilateral
federation agreement present) ✓ – T_f = 0.75 (negotiated bilateral
factor) – E_effective = 95 × 0.75 = 71.25 → Analyst tier in Supplier A’s
zone

Step 1 extension — TA contract check (reading foreign ta_extension):
– contract_status: bound ✓ (no violation; denial would
trigger here) – clearance_level: full ✓ (foreign clearance
read as informational signal; local evaluation governs) –
compliance_rate: 0.997 — high compliance rate noted as
positive behavioral signal – Foreign normative_clearance
NOT treated as authoritative — Supplier A MUST run its own
evaluation

Step 2 — Combined soul veto: – soul_clear: true (from
foreign token, evaluated under KTP verification) ✓ –
soul_constraints_ta: 0 (from foreign token, informational)
✓ – S = 0 — no veto

Step 3 — Local normative evaluation (Flow 3, step 4): – Supplier A’s
normative engine evaluates: “coordinate logistics for Component X
against PO-2026-4521” — is this purpose consistent with active PO? –
Result: approved. Local normative clearance:
clearance_level: full (Supplier A’s own evaluation) –
Supplier A does NOT use AutoCo’s clearance_level for
enforcement; it uses its own result

Step 4 — Tier gate (Supplier A’s zone): – Analyst tier in Supplier
A’s zone permits “Query Data, Logs, Reports” – Logistics data exchange
(read delivery windows, receive schedule) is within Analyst capability
✓

Step 5 — Physics: – READ logistics schedule: A = 25 ≤ 71.25 ✓

Action permitted. Supplier A’s enforcement pipeline logs the
cross-zone action with both the foreign trust proof summary and the
local normative evaluation result.

Key cross-zone TA behaviors illustrated:

• Foreign normative_clearance is informational only;
  clearance_level: full from AutoCo does not exempt the agent
  from Supplier A’s normative evaluation
• A violated contract_status in the foreign token would
  have denied the action at step 1 extension, before local normative
  evaluation runs — contract violations are zone-independent facts about
  agent behavior
• T_f attenuation applies only to KTP trust state (E_base →
  E_effective); it does not affect how ta_extension fields
  are read
• compliance_rate: 0.997 is a cross-zone positive
  behavioral signal informing Supplier A that the agent has historically
  honored its intent contracts in its home zone

---

12. Security Considerations

12.1 Intent Compliance Forgery

An agent MUST NOT be able to self-report its own
compliance_rate or contract_status. These
values are computed and attested by the Trust Oracle from TA-Attestation
records maintained in the KTP Trajectory Chain infrastructure. The Trust
Oracle signs the complete Trust Proof Token including
ta_extension; any agent modification of compliance fields
would invalidate the token signature.

12.2 Normative Clearance
Staleness

Normative clearances are computed at a point in time against
environmental context (HR status, litigation holds, regulatory calendar,
data classification). Context can change between clearance and the
clearance_expiry timestamp, leaving the clearance
stale.

Two mitigations:

1. Push re-evaluation triggers. The TA-Normative
   evaluation response includes re_evaluation_triggers — a
   list of context source events that, when fired, trigger synchronous
   re-evaluation (Flow 2). This propagates high-priority context changes
   (HR status change, litigation hold activation) without waiting for
   clearance expiry.

2. Short clearance TTL. Zones handling
   high-sensitivity contexts SHOULD configure short
   clearance_expiry windows. Recommended maximum TTL: 4 hours
   for standard operational contexts; 15 minutes for contexts involving
   regulated data classification; 1 hour for cross-zone contexts.

The window between context change and re-evaluation propagation
represents an irreducible governance latency. Implementations SHOULD
document this window and calibrate clearance_expiry
accordingly.

12.3 ta_extension Stripping

A malicious intermediary might strip ta_extension from a
Trust Proof Token, causing the receiving enforcement pipeline to fall
back to KTP-only enforcement and bypass intent compliance and normative
clearance checks.

Mitigations:

1. Zone policy requiring extension. For sensitive
   action classes, zone policy MUST require ta_extension. Its
   absence is treated as a denial trigger, not a pass-through (Section
   9.3). The stripped token would cause denial rather than silently
   elevated access.

2. Extension presence as trust signal. The presence
   or absence of ta_extension SHOULD be logged in the
   enforcement audit trail. Systematic absence of ta_extension
   in a context where it should be present is anomalous and SHOULD trigger
   review.

3. Signature coverage. The Trust Oracle signs the
   complete payload including ta_extension. Stripping
   ta_extension without re-signing the token would invalidate
   the signature check at step 1 of the enforcement pipeline. Stripping
   with re-signing requires compromise of the Trust Oracle’s signing key,
   which is a KTP-Core security boundary.

12.4 Cross-Zone Clearance
Inflation

A foreign zone might issue generous normative clearance
(clearance_level: full with no constraints) for an agent that would be
heavily constrained by the receiving zone’s own normative rules. If the
receiving zone treated foreign clearance as authoritative, the agent
would escape local governance.

Section 8.3 of this RFC makes the receiving zone’s obligation
unambiguous: foreign normative_clearance MUST NOT be
treated as authoritative. The receiving zone MUST perform its own
normative evaluation. Foreign clearance is informational context only.
Implementations MUST NOT short-circuit local normative evaluation on the
basis of foreign clearance level.

12.5 Contract Status
Manipulation

A violated contract status is one of the most powerful
enforcement signals in ta_extension — it causes immediate
denial at step 1 extension. An attacker who could flip
contract_status from violated to
bound would neutralize this enforcement path.

Contract status is written by the Governance Layer based on
TA-Attestation records. It is not self-reported by the agent. The Trust
Oracle signs the token containing contract_status;
manipulation without Oracle compromise requires signature forgery. An
attacker who compromises the Governance Layer but not the Trust Oracle
could inject false Attestation records; the Trust Oracle’s Attestation
verification (per TA-Attestation) is a partial defense.

Implementations SHOULD apply the same security controls to the
Governance Layer as to the Trust Oracle — both are high-value targets in
the enforcement architecture.

12.6 Clearance Expiry Race

An enforcement pipeline that does not check
clearance_expiry against the current timestamp may honor an
expired normative clearance. Implementations MUST validate
clearance_expiry as part of the step 1 extension check,
treating an expired clearance as equivalent to
clearance_level: restricted.

12.7 Normative Engine
Compromise

A compromised normative engine represents a high-severity attack on
the TA governance layer. It could: suppress soul constraints (allowing
prohibited actions); reclassify all action risks to A=0 (bypassing
physics); or generate false vetoes (denying legitimate actions as a
DoS).

The following mitigations apply (from TA-Normative):

• The normative engine is itself an agent subject to KTP trust
  physics. Governance-level actions (modifying constraints, suppressing
  vetoes) carry high A scores; a compromised engine with degraded E_trust
  cannot perform these actions.
• Normative constraints are signed by their authoring authority and
  stored in a tamper-evident log. The engine evaluates constraints but
  cannot create, modify, or delete them.
• Soul veto generation (soul_constraints_ta > 0) MUST require
  confirmation from a second, independent normative evaluator instance, as
  required by TA-Normative Section 7.4.
• Output anomaly detection on the normative engine (sudden drop in
  constraint firing, bulk reclassifications) SHOULD trigger circuit
  breaker isolation.
• If the normative engine is isolated, enforcement falls back to
  KTP-only behavior with all agents treated as
  clearance_level: restricted. This is a capability
  reduction, not a security failure.

---

13. Open Questions

1. Scope hash collision and update semantics. When
   a TA-Intent scope is amended mid-session, the scope_hash
   changes. How should receiving parties that have cached a prior scope
   hash handle the transition? Should the scope hash appear in both the old
   and new Trust Proof Tokens during the amendment window, with a
   transition field indicating amendment in progress?

2. Compliance rate granularity. The current model
   computes compliance rate as a flat ratio across all actions since intent
   binding. Should compliance rate be weighted by action risk score A? A
   single high-risk scope violation (scope_distance = 0.95, A = 70) is more
   significant than many low-risk boundary touches (scope_distance = 0.3, A
   = 10). Weighted compliance rate would better reflect the severity of
   deviation.

3. Partial ta_extension. Can a token carry
   intent_compliance without normative_clearance,
   or vice versa? The current model treats ta_extension as
   atomic. Split extension fields would allow zones to implement intent
   compliance governance before normative governance is operational, but
   would complicate enforcement semantics.

4. Normative clearance granularity. The
   clearance_level enum has three values: full, conditional,
   restricted. Should conditional be subdivided to signal which specific
   action classes are affected (e.g., conditional_read_only,
   conditional_no_external_write)? This would allow enforcement pipelines
   to apply conditional restrictions without querying the Governance Layer
   for per-action reclassification detail.

5. Cross-zone intent compliance interpretation.
   Scenario 7 treats foreign compliance_rate as an
   informational signal. Is there a threshold below which a foreign
   compliance rate should trigger denial or require local normative
   justification? For example: if a foreign agent presents
   compliance_rate: 0.60, should the receiving zone require
   heightened normative evaluation even if
   contract_status: bound?

6. ta_extension in revocation records. When a Trust
   Proof Token is revoked, does the revocation record carry a snapshot of
   ta_extension at revocation time? This would support
   forensic analysis of the governance state at the moment of revocation,
   but adds complexity to the revocation record format.

7. Interaction with KTP-Emergency graceful
   degradation. Section 9.3 defines fallback behavior when
   ta_extension is absent. KTP-Core’s Graceful Degradation
   Ladder defines seven levels of reduced operation. How do these interact?
   At what degradation level should ta_extension requirement
   policies be suspended?

8. Temporal scope in compliance rate. The current
   compliance rate covers all actions since intent binding. For
   long-running (weeks-long) intents, early compliance history may not be
   representative of current behavior. Should compliance rate have a
   rolling window option (e.g., last 100 actions, or last 24
   hours)?

---

14. References

14.1 Normative References

• KTP-Core — Kinetic Trust Protocol Core Specification.
  https://nmcitra.github.io/ktp-rfc/
• KTP-Federation — KTP Federation Specification.
  https://nmcitra.github.io/ktp-rfc/
• IETF RFC 7519 — JSON Web Token (JWT)
• IETF RFC 2119 — Key words for use in RFCs to Indicate Requirement
  Levels

14.2 Informative References

TA RFC Set: – TA-Intent (RFC 1) — Intent Declaration
Protocol – TA-Normative (RFC 2) — Normative Constraint Protocol –
TA-Attestation (RFC 4) — Behavioral Attestation Extension for Intent
Contract Compliance – TA-Provenance (RFC 5) — Provenance Extension for
Purpose Chain Tracking

Research and Design Documents: –
docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md — TA RFC Set
Design Specification – docs/research/2026-03-16-scenario-walkthroughs.md
— Tamed Autonomy: Scenario Walkthroughs –
docs/research/2026-03-16-ktp-scenario-mapping.md — KTP Scenario Mapping
– docs/research/2026-03-11-agent-governance-layers.md — Agent Governance
Layers

External References: – IETF RFC 6749 — The OAuth 2.0
Authorization Framework – IETF RFC 8174 — Ambiguity of Uppercase vs
Lowercase in RFC 2119 Key Words – W3C Verifiable Credentials Data Model
2.0 – OWASP Top 10 for Agentic Applications (December 2025) – NIST AI
Agent Standards Initiative (February 2026) – Mastercard/Google
Verifiable Intent Framework (March 2026) – CEL (Common Expression
Language) Specification — https://github.com/google/cel-spec

---

End of TA-TrustProof RFC v0.1