<?xml version="1.0" encoding="utf-8"?>
<rfc ipr="trust200902" docName="draft-wang-ctp-definition-02" category="info" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <front>
    <title abbrev="CTP/0">CTP/0: Cognitive Time Protocol -- Definition and Framework</title>
    <seriesInfo name="Internet-Draft" value="draft-wang-ctp-definition-02"/>
    <author initials="Y." surname="Wang" fullname="Yuqiang Wang">
      <organization/>
      <address>
        <email>signal@humanjudgment.org</email>
        <uri>https://github.com/hjs-spec</uri>
      </address>
    </author>
    <date year="2026" month="September" day="26"/>
    <keyword>CTP</keyword>
    <keyword>cognitive time</keyword>
    <keyword>event density</keyword>
    <keyword>temporal claims</keyword>
    <abstract>
      <t>This document describes CTP/0, the definition layer of the Cognitive Time Protocol (CTP) family. CTP/0 is an informational conceptual framework for naming, separating, comparing, and referencing time-related claims in AI and agent systems.</t>
      <t>CTP/0 defines terminology for profile-defined cognitive events, event-density claims, ordering claims, branching claims, sequential-computation evidence, and declared temporal-structure claims.</t>
      <t>CTP/0 does not define a wire protocol, message format, signature format, identity system, hash-chain protocol, governance process, physical theory of time, theory of consciousness, or legal-accountability framework. Where verifiable records are required, CTP-compatible claims can be bound to external event, receipt, dependency-graph, observation, or change-evidence infrastructure.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro"><name>Introduction</name>
      <section anchor="motivation"><name>Motivation</name>
      <t>AI and agent systems often operate through event streams that do not map cleanly to wall-clock time. A planning system may perform many internal steps during one physical second. A distributed agent may branch into speculative paths. A simulator or world model may advance logical time faster or slower than physical time. An audit system may need to distinguish declared event time, logical order, physical time, evidence time, receipt time, and dependency structure.</t>
      <t>CTP/0 provides terminology for these time-related claims.</t>
      <t>Its purpose is to prevent different meanings of "time" from being silently collapsed into one another.</t>
      <t>CTP/0 is not a theory of AI consciousness, subjective experience, psychological time, physical spacetime, moral agency, or legal responsibility. It is a reference vocabulary and architectural framework for future measurement profiles, evidence profiles, and bindings to external interoperability infrastructure.</t>
      </section>
      <section anchor="scope"><name>Scope</name>
      <t>CTP/0 defines:</t>
      <ul spacing="normal">
        <li>a conceptual model for time-related claims in AI and agent systems;</li>
        <li>terminology for cognitive-event, event-density, ordering, branching, sequential-computation, and declared temporal-structure claims;</li>
        <li>a layered reference architecture for organizing those claim categories;</li>
        <li>requirements that measurement profiles make comparison assumptions explicit;</li>
        <li>optional evidence-profile categories;</li>
        <li>interpretation, security, privacy, and non-inference boundaries.</li>
      </ul>
      <t>CTP/0 explicitly does not define:</t>
      <ul spacing="normal">
        <li>a wire protocol, message syntax, media type, port number, API, or interoperable record encoding;</li>
        <li>a signature, hash, canonicalization, identity, trust, or receipt mechanism;</li>
        <li>a global event definition;</li>
        <li>a global clock or synchronization mechanism;</li>
        <li>a universal metric of intelligence, reasoning quality, consciousness, safety, alignment, moral status, or model capability;</li>
        <li>a causal model;</li>
        <li>a governance, approval, monitoring, fairness, appeal, explanation-rights, or compliance framework;</li>
        <li>a physical, subjective, or psychological theory of time;</li>
        <li>proof that any AI system experiences time.</li>
      </ul>
      </section>
      <section anchor="external-infra"><name>Relationship to External Infrastructure</name>
      <t>CTP/0 is a conceptual framework. It does not replace event, receipt, dependency, observation, or change-evidence infrastructure.</t>
      <t>The following relationships are informative:</t>
      <ul spacing="normal">
        <li><xref target="JEP"/> can carry signed statements that reference CTP-compatible claims or evidence while retaining JEP-Core event semantics.</li>
        <li>JEP Receipt Profile <xref target="JEP-RECEIPT"/> can package CTP-compatible records or evidence as digest-addressed receipt artifacts.</li>
        <li><xref target="JAC"/> can express declared dependency-graph structure among JEP events associated with time-related claims.</li>
        <li><xref target="COE"/> can carry observations or shared-state claims containing time-related descriptors or evidence.</li>
        <li><xref target="CEP"/> can carry declared change records referencing time-related evidence or temporal structures.</li>
      </ul>
      <t>CTP/0 does not redefine the semantics, identifiers, validation rules, or registries of those specifications.</t>
      <t>In particular, CTP/0 does not redefine JEP Event Identity or Event Hash. A logical reference to a JEP event uses JEP Event Identity. Event Hash is an exact signed-artifact identifier.</t>
      </section>
      <section anchor="positioning"><name>Infrastructure Positioning</name>
      <t>CTP/0 is infrastructure for naming and comparing time-related claims.</t>
      <t>It defines concepts and comparison preconditions; it does not prescribe one implementation.</t>
      <t>Measurement procedures, evidence mechanisms, hardware support, signed-event bindings, receipts, dependency graphs, and domain policies remain external profiles or deployment choices.</t>
      </section>
      <section anchor="requirements"><name>Requirements Language</name>
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals.</t>
      <t>Because CTP/0 is an informational framework rather than a wire protocol, capitalized requirement words in this document primarily define interpretation boundaries and requirements for specifications that claim CTP-compatible measurement or evidence semantics.</t>
      </section>
      <section anchor="terminology"><name>Terminology</name>
      <t><strong>CTP/0:</strong> The definition layer of the Cognitive Time Protocol family.</t>
      <t><strong>Cognitive Event:</strong> A declared or observed unit of processing under an explicit measurement profile. The term is operational and does not itself assert consciousness, understanding, reasoning quality, or subjective experience.</t>
      <t><strong>Event Definition:</strong> The profile-defined rule that determines what counts as one Cognitive Event.</t>
      <t><strong>Time Base:</strong> The clock, counter, logical-order domain, computational measure, or other temporal reference used by a measurement profile.</t>
      <t><strong>Time-Related Claim:</strong> A claim concerning event order, event density, branch structure, sequential computation, temporal evidence, or a declared temporal structure.</t>
      <t><strong>Measurement Profile:</strong> A specification or deployment-defined procedure that defines the event definition, time base, measurement procedure, evidence requirements, and interpretation boundaries for a time-related claim.</t>
      <t><strong>Evidence Profile:</strong> A profile that defines how evidence supports a time-related claim.</t>
      <t><strong>Cognitive Event Density (CED):</strong> A profile-scoped event-density indicator expressing profile-defined Cognitive Events per declared time unit.</t>
      <t><strong>Causal Arrow Entropy (CAE):</strong> A heuristic or profile-defined uncertainty measure over an explicitly defined event sequence and probability model.</t>
      <t><strong>Declared Temporal Structure:</strong> A declared claim about branch, synchronization, recurrence, abstraction, copy, merge, or other temporal structure in an event stream.</t>
      <t><strong>Comparable Claims:</strong> Two time-related claims whose applicable profiles define sufficiently compatible event definitions, time bases, measurement procedures, and normalization rules for the intended comparison.</t>
      </section>
    </section>
    <section anchor="model"><name>CTP/0 Model</name>
      <section anchor="not-wire"><name>Conceptual Framework, Not a Wire Protocol</name>
      <t>CTP/0 does not define packets, messages, headers, fields, APIs, canonical encodings, or a conformance wire format.</t>
      <t>An implementation cannot be "CTP/0 wire-compatible" because CTP/0 intentionally defines no wire representation.</t>
      <t>A system MAY be described as CTP-compatible only in the limited sense that it uses the terms and interpretation boundaries in this document or implements a future specification that explicitly references CTP/0.</t>
      </section>
      <section anchor="claim-types"><name>Claim Types</name>
      <t>CTP/0 recognizes several broad categories of time-related claims:</t>
      <ul spacing="normal">
        <li>event-density claims;</li>
        <li>order or direction claims;</li>
        <li>branch, copy, merge, or synchronization claims;</li>
        <li>sequential-computation claims;</li>
        <li>temporal-evidence claims;</li>
        <li>declared temporal-structure claims.</li>
      </ul>
      <t>A claim MAY be measured, asserted, inferred, or externally referenced.</t>
      <t>The claim type does not determine whether the claim is true.</t>
      </section>
      <section anchor="claim-context"><name>Claim Context</name>
      <t>A CTP-compatible time-related claim SHOULD identify, directly or through an applicable profile:</t>
      <ul spacing="normal">
        <li>the claim type;</li>
        <li>the subject or event domain;</li>
        <li>the Event Definition;</li>
        <li>the Time Base;</li>
        <li>the measurement or inference procedure;</li>
        <li>the applicable profile identifier;</li>
        <li>the evidence basis, if any;</li>
        <li>whether the claim is intended to be comparable with another class of claims;</li>
        <li>known assumptions, exclusions, or incompleteness.</li>
      </ul>
      <t>CTP/0 does not define a canonical record containing these members.</t>
      </section>
      <section anchor="minimal-core"><name>Minimal Core and Optional Profiles</name>
      <t>The CTP/0 core consists only of terminology, claim categories, comparison preconditions, interpretation boundaries, and a layered reference architecture.</t>
      <t>All concrete measurement procedures and evidence mechanisms are external profiles.</t>
      <t>A CTP-family profile that defines a measurable quantity MUST state:</t>
      <ul spacing="normal">
        <li>its Event Definition;</li>
        <li>its Time Base;</li>
        <li>its measurement or inference procedure;</li>
        <li>its normalization and aggregation rules;</li>
        <li>its evidence requirements;</li>
        <li>treatment of missing, duplicated, parallel, redacted, or sampled events;</li>
        <li>comparison conditions;</li>
        <li>interpretation limits.</li>
      </ul>
      </section>
      <section anchor="no-equivalence"><name>No Implicit Equivalence</name>
      <t>Two CTP-compatible claims MUST NOT be treated as quantitatively comparable merely because they use the same metric label, such as <tt>CED</tt> or <tt>CAE</tt>.</t>
      <t>Cross-system comparison requires an applicable profile that establishes compatible semantics or explicitly defines a conversion or normalization procedure.</t>
      <t>A shared numeric unit alone does not establish semantic comparability.</t>
      </section>
      <section anchor="non-determination"><name>What CTP Does Not Determine</name>
      <t>CTP-compatible claims, metrics, and evidence MUST NOT be presented by CTP/0 itself as proving:</t>
      <ul spacing="normal">
        <li>that an AI system is conscious or has subjective experience;</li>
        <li>that two Cognitive Events are equivalent without compatible Event Definitions;</li>
        <li>that higher event density implies greater intelligence or reasoning quality;</li>
        <li>that a lower or higher CAE value is intrinsically better;</li>
        <li>that sequential-computation evidence proves cognitive effort or understanding;</li>
        <li>that ordering evidence proves factual causality;</li>
        <li>that a branch, copy, or merge is semantically equivalent to another;</li>
        <li>that an emergent temporal structure is physically real or novel;</li>
        <li>that logs or receipts are complete;</li>
        <li>that an external target fact is determined;</li>
        <li>that responsibility, authorization, safety, fairness, legality, or policy compliance follows.</li>
      </ul>
      </section>
    </section>
    <section anchor="layers"><name>Layered Reference Architecture</name>
      <t>The CTP layers are conceptual categories, not protocol stacks.</t>
      <t>Implementations MAY use a subset of them. A higher-numbered layer does not imply greater correctness, intelligence, sophistication, or authority.</t>
      <section anchor="layer0"><name>Layer 0: Definition Layer</name>
      <t>Layer 0 is this document.</t>
      <t>It defines CTP terminology, claim categories, comparison boundaries, evidence categories, and relationships to external infrastructures.</t>
      </section>
      <section anchor="layer1"><name>Layer 1: Event and Density Claims</name>
      <t>Layer 1 concerns claims about counts, rates, durations, or densities of profile-defined Cognitive Events.</t>
      <t>A Layer 1 profile SHOULD define the Event Definition, Time Base, counting method, overlap rules, weighting rules, and evidence basis.</t>
      <t>Layer 1 does not determine subjective experience or reasoning quality.</t>
      </section>
      <section anchor="layer2"><name>Layer 2: Ordering and Direction Claims</name>
      <t>Layer 2 concerns claims about ordering, dependency, direction, or temporal precedence among events or records.</t>
      <t>Possible evidence includes logical clocks <xref target="LAMPORT"/>, counters, trusted timestamps, signed events, JEP Event Identity references with optional exact-artifact pins, or JAC dependency graphs.</t>
      <t>Layer 2 does not establish factual causality, complete history, legal causation, authorization, or responsibility.</t>
      </section>
      <section anchor="layer3"><name>Layer 3: Copy, Branch, and Merge Claims</name>
      <t>Layer 3 concerns claims about copying, branching, replication, synchronization, merging, replaying, or abandonment of event streams.</t>
      <t>A Layer 3 profile SHOULD state how branch identity, common ancestry, fork points, merge points, and duplicate/replayed events are represented.</t>
      <t>Layer 3 does not establish semantic equivalence of branches or determine whether a merge is correct.</t>
      </section>
      <section anchor="layer4"><name>Layer 4: Declared Temporal Structures</name>
      <t>Layer 4 concerns declared temporal structures such as recurring patterns, synchronization patterns, abstraction layers, branching motifs, or change-related patterns observed in event streams.</t>
      <t>Layer 4 does not establish that a structure is emergent, novel, conscious, physically meaningful, valuable, or morally relevant.</t>
      </section>
    </section>
    <section anchor="concepts"><name>Core Concepts</name>
      <section anchor="cognitive-event"><name>Cognitive Event</name>
      <t>A Cognitive Event is a declared or observed processing unit under a Measurement Profile.</t>
      <t>Examples MAY include inference steps, tool calls, retrieval operations, planning steps, verification checks, simulation ticks, branch creation, branch merge, or receipt generation.</t>
      <t>The term "cognitive" in CTP is a protocol-family label. It MUST NOT be interpreted as a claim that the event involves consciousness, understanding, human-like cognition, or subjective experience.</t>
      <t>A profile that counts Cognitive Events SHOULD state:</t>
      <ul spacing="normal">
        <li>the event boundary condition;</li>
        <li>the event source or instrumentation method;</li>
        <li>whether events may overlap or execute in parallel;</li>
        <li>whether events are weighted;</li>
        <li>how duplicate, retried, merged, or sampled events are handled;</li>
        <li>what evidence supports the event count.</li>
      </ul>
      </section>
      <section anchor="time-bases"><name>Time Bases</name>
      <t>CTP distinguishes the following non-exhaustive time bases:</t>
      <ul spacing="normal">
        <li>physical or wall-clock time;</li>
        <li>monotonic process time;</li>
        <li>logical time;</li>
        <li>event order;</li>
        <li>computation or work measure;</li>
        <li>receipt or archive time;</li>
        <li>profile-defined declared time.</li>
      </ul>
      <t>A claim MUST identify the Time Base required for its interpretation.</t>
      <t>One Time Base MUST NOT be silently substituted for another.</t>
      <t>An actor-declared timestamp is not trusted physical time unless an applicable evidence profile establishes that property.</t>
      </section>
      <section anchor="ced"><name>Cognitive Event Density (CED)</name>
      <t>For a Measurement Profile that defines a count or weighted aggregate <tt>C_total</tt> and a denominator interval <tt>T</tt>, CED MAY be expressed as:</t>
      <sourcecode type="text"><![CDATA[
CED = C_total / T
]]></sourcecode>
      <t>The profile MUST define what <tt>C_total</tt> counts and what Time Base and units <tt>T</tt> uses.</t>
      <t>A CED value is meaningful only under the applicable Event Definition, Measurement Profile, Time Base, and normalization rules.</t>
      <t>Two CED values MUST NOT be compared as equivalent measurements unless those conditions are compatible or an explicit conversion profile is used.</t>
      <t>CED MUST NOT be presented as a universal measure of intelligence, consciousness, correctness, safety, alignment, moral status, or capability.</t>
      </section>
      <section anchor="cae"><name>Causal Arrow Entropy (CAE)</name>
      <t>CAE is a profile-scoped heuristic or uncertainty measure over a defined event space and probability model.</t>
      <t>A profile MAY define an expression such as:</t>
      <sourcecode type="text"><![CDATA[
CAE = H(Event_N | Event_{N-1}, ..., Event_0)
]]></sourcecode>
      <t>where <tt>H</tt> denotes conditional entropy under that profile's model.</t>
      <t>A CAE profile MUST define:</t>
      <ul spacing="normal">
        <li>the event space;</li>
        <li>random variables;</li>
        <li>conditioning context;</li>
        <li>probability estimation procedure;</li>
        <li>treatment of missing or censored events;</li>
        <li>units or logarithm base where relevant;</li>
        <li>comparison conditions;</li>
        <li>interpretation limits.</li>
      </ul>
      <t>CAE does not prove causal direction, factual causality, novelty, creativity, intent, responsibility, or emergence.</t>
      </section>
      <section anchor="sequential-evidence"><name>Sequential-Computation Evidence</name>
      <t>Some deployments may use Verifiable Delay Functions <xref target="VDF"/> or other mechanisms as evidence for minimum sequential work under a defined construction.</t>
      <t>Sequential-computation evidence establishes only the property specified by the applicable evidence profile.</t>
      <t>It MUST NOT be presented by CTP as proof of reasoning quality, understanding, intent, subjective duration, consciousness, intelligence, safety, or alignment.</t>
      </section>
      <section anchor="ordering-evidence"><name>Ordering and Dependency Evidence</name>
      <t>CTP/0 does not define an independent judgment hash-chain protocol.</t>
      <t>When a time-related claim needs verifiable ordering or dependency evidence, implementations SHOULD use an appropriate external structure rather than creating a CTP-specific chain.</t>
      <t>For JEP-based systems:</t>
      <ul spacing="normal">
        <li>logical JEP event identity is JEP Event Identity;</li>
        <li>Event Hash MAY pin one exact signed artifact;</li>
        <li>JAC MAY express declared dependency graphs;</li>
        <li>JEP Receipt Profile MAY preserve portable evidence artifacts.</li>
      </ul>
      <t>Neither signed order nor dependency structure alone establishes factual causality.</t>
      </section>
      <section anchor="branch-identity"><name>Branch and Copy Identity</name>
      <t>CTP/0 does not define a universal identity rule for branches, copies, replicas, or merged processes.</t>
      <t>A Layer 3 profile that requires cross-system branch comparison MUST define how branch identity, ancestry, copy points, and merge points are identified.</t>
      <t>Two branches MUST NOT be treated as semantically identical merely because their observed event sequences or hashes are equal.</t>
      </section>
      <section anchor="temporal-structures"><name>Declared Temporal Structures</name>
      <t>A Declared Temporal Structure is a claim under an applicable profile.</t>
      <t>It may describe recurrence, branching, synchronization, abstraction, periodicity, or another profile-defined temporal pattern.</t>
      <t>CTP/0 does not define a universal emergence detector or novelty criterion.</t>
      </section>
    </section>
    <section anchor="evidence-profiles"><name>Optional Evidence Profiles</name>
      <section anchor="evidence-general"><name>General Requirements</name>
      <t>An Evidence Profile SHOULD state:</t>
      <ul spacing="normal">
        <li>the evidence object or mechanism;</li>
        <li>what claim property the evidence supports;</li>
        <li>how evidence is bound to the claim;</li>
        <li>verification procedure;</li>
        <li>trust assumptions;</li>
        <li>failure behavior;</li>
        <li>privacy considerations;</li>
        <li>properties the evidence does not establish.</li>
      </ul>
      </section>
      <section anchor="vdf-profiles"><name>VDF Evidence Profiles</name>
      <t>A VDF evidence profile MAY support a claim about minimum sequential computation.</t>
      <t>Such a profile SHOULD specify the VDF construction, security parameters, input binding, output proof format, verification procedure, and limitations.</t>
      <t>A VDF proof MUST NOT be interpreted as proof of cognition, understanding, intent, human-like deliberation, or subjective duration.</t>
      </section>
      <section anchor="ordering-profiles"><name>Ordering and Integrity Evidence Profiles</name>
      <t>An ordering or integrity evidence profile MAY use hashes, signatures, logical clocks, transparency systems, trusted timestamps, counters, or other mechanisms.</t>
      <t>The profile MUST distinguish integrity, ordering, freshness, and causality. Evidence for one of those properties MUST NOT be silently presented as evidence for another.</t>
      <t>If JEP or JAC is already used, a CTP-compatible evidence profile SHOULD reuse their Event Identity, Event Hash, and dependency semantics rather than define parallel meanings.</t>
      </section>
      <section anchor="hardware-profiles"><name>Hardware-Attestation Evidence Profiles</name>
      <t>A hardware-attestation evidence profile MAY use trusted execution environments, secure counters, measured boot, remote attestation, protected storage, or similar mechanisms.</t>
      <t>Hardware attestation MAY support claims about an execution environment or measurement path.</t>
      <t>It does not establish that an Event Definition is meaningful, that observed events are complete, that a target fact is determined, or that an AI system is safe, fair, lawful, conscious, or aligned.</t>
      </section>
      <section anchor="binding-profiles"><name>External Binding Profiles</name>
      <t>A CTP-compatible claim MAY be bound to external infrastructure.</t>
      <t>Examples include:</t>
      <ul spacing="normal">
        <li>a JEP event carrying or referencing a CTP-compatible claim under an explicitly selected profile or extension;</li>
        <li>a JEP Receipt Profile bundle containing a CTP measurement or evidence artifact;</li>
        <li>a JAC graph associating JEP events involved in a time-related claim;</li>
        <li>a COE Observation Record or Shared-State Claim referencing temporal evidence;</li>
        <li>a CEP Evolution-Change Record referencing temporal evidence or a declared temporal structure.</li>
      </ul>
      <t>The external binding specification, not CTP/0, defines concrete record format, signature input, identifiers, digest binding, validation behavior, and critical-extension semantics.</t>
      </section>
    </section>
    <section anchor="comparison-validation"><name>Comparison and Validation</name>
      <section anchor="structural-vs-interpretation"><name>Structural Validation Versus Interpretation</name>
      <t>A verifier SHOULD distinguish structural or evidentiary validation from substantive interpretation.</t>
      <t>Structural or evidentiary validation may determine that:</t>
      <ul spacing="normal">
        <li>a measurement profile is identified;</li>
        <li>required fields of that profile are present;</li>
        <li>evidence digests or signatures validate under an external specification;</li>
        <li>a declared measurement was computed according to a stated procedure;</li>
        <li>declared references resolve consistently.</li>
      </ul>
      <t>Substantive interpretation asks what the claim implies about intelligence, quality, causality, safety, consciousness, governance, scientific validity, legal effect, or another external conclusion.</t>
      <t>Those conclusions are outside CTP/0.</t>
      </section>
      <section anchor="measurement-requirements"><name>Measurement Profile Requirements</name>
      <t>A CTP Measurement Profile intended for interoperable use SHOULD identify itself using a stable collision-resistant identifier, preferably an absolute URI.</t>
      <t>A Measurement Profile MUST define enough information to reproduce or independently evaluate the claimed measurement, including:</t>
      <ul spacing="normal">
        <li>Event Definition;</li>
        <li>Time Base;</li>
        <li>input domain;</li>
        <li>counting or measurement procedure;</li>
        <li>normalization;</li>
        <li>treatment of concurrency;</li>
        <li>treatment of missing, duplicated, replayed, sampled, and redacted events;</li>
        <li>evidence requirements;</li>
        <li>comparison conditions;</li>
        <li>uncertainty or error model where applicable;</li>
        <li>interpretation limits.</li>
      </ul>
      </section>
      <section anchor="comparability"><name>Comparability</name>
      <t>Two CTP-compatible claims are comparable only for the property and scope authorized by their applicable Measurement Profiles.</t>
      <t>A verifier MUST NOT infer comparability solely from:</t>
      <ul spacing="normal">
        <li>equal metric names;</li>
        <li>equal numeric units;</li>
        <li>equal subject type;</li>
        <li>equal time interval length;</li>
        <li>equal event counts;</li>
        <li>use of the same external event or receipt infrastructure.</li>
      </ul>
      <t>If two profiles define a conversion or normalization mapping, the resulting comparison MUST identify the mapping used.</t>
      </section>
      <section anchor="binding-external"><name>Binding to JEP, Receipt Profile, JAC, COE, and CEP</name>
      <t>When CTP-compatible claims are bound to external infrastructure, that infrastructure retains authority over its own identifiers and semantics.</t>
      <t>In particular:</t>
      <ul spacing="normal">
        <li>JEP signed-event semantics remain JEP-defined;</li>
        <li>JEP Event Identity identifies the logical JEP event;</li>
        <li>JEP Event Hash identifies an exact signed artifact;</li>
        <li>JEP Receipt Profile defines receipt packaging and receipt validation;</li>
        <li>JAC defines declared dependency-graph semantics;</li>
        <li>COE defines shared-observation and state-claim evidence semantics;</li>
        <li>CEP defines evolution-change evidence-binding semantics.</li>
      </ul>
      <t>CTP/0 MUST NOT redefine those meanings.</t>
      <t>A binding MAY reference a CTP-compatible record by digest through an appropriate external profile. CTP/0 itself does not prescribe where that digest appears in a JEP event.</t>
      </section>
      <section anchor="non-inference"><name>Non-Inference Rules</name>
      <t>The absence of a CTP-compatible claim MUST NOT be interpreted as agreement, waiver, admission, lack of objection, absence of change, absence of harm, absence of context, or absence of external rights or processes.</t>
      <t>The presence or successful validation of a CTP-compatible claim MUST NOT be presented by CTP/0 as proof of truth, fairness, safety, legality, responsibility, consciousness, causality, authorization, or target determinability.</t>
      </section>
    </section>
    <section anchor="partial-determinability"><name>Partial Observation and Determinability</name>
      <section anchor="open-world"><name>Open-World Default</name>
      <t>CTP/0 uses an open-world default.</t>
      <t>An observed event stream is not necessarily complete.</t>
      <t>Absence of an event from an observed stream MUST NOT be interpreted as proof that the event did not occur unless an explicitly selected external profile establishes a closed-world or complete-log assumption.</t>
      </section>
      <section anchor="determinability"><name>Target Determinability</name>
      <t>A time-related record may contain timestamps, counts, branch identifiers, hashes, sequential-computation proofs, attestations, receipts, or dependency references without retaining enough target-relevant information to determine an external fact.</t>
      <t>CTP/0 therefore does not define or guarantee target determinability.</t>
      <t>A determinability analysis MAY use an external formal model, but the validity of that analysis is external to CTP/0.</t>
      </section>
      <section anchor="completeness"><name>Completeness</name>
      <t>A set of CTP-compatible claims MUST NOT be presented as a complete temporal history solely because:</t>
      <ul spacing="normal">
        <li>it is cryptographically signed;</li>
        <li>every observed record has a hash;</li>
        <li>records form an acyclic dependency graph;</li>
        <li>records have trusted timestamps;</li>
        <li>a receipt bundle contains them;</li>
        <li>the observed time interval has no gaps.</li>
      </ul>
      <t>Completeness requires an explicit external assumption or profile.</t>
      </section>
    </section>
    <section anchor="security-privacy"><name>Security and Privacy Considerations</name>
      <section anchor="metric-gaming"><name>Metric Gaming</name>
      <t>Measurement definitions can be optimized against.</t>
      <t>An implementation may increase a metric such as CED by changing the event granularity without improving any external property.</t>
      <t>A profile SHOULD therefore make Event Definition, aggregation, normalization, and comparison rules explicit.</t>
      </section>
      <section anchor="clock-confusion"><name>Clock and Timestamp Confusion</name>
      <t>Implementations MUST distinguish actor-declared time, local wall-clock time, monotonic time, logical time, trusted timestamp evidence, receipt time, and other profile-defined Time Bases.</t>
      <t>A timestamp field MUST NOT be treated as trusted time merely because it is signed.</t>
      </section>
      <section anchor="vdf-boundary"><name>VDF Proofs Are Not Cognitive Proofs</name>
      <t>A VDF proof can support a sequential-computation property under an applicable construction.</t>
      <t>It does not prove cognition, reasoning quality, understanding, intent, subjective duration, or intelligence.</t>
      </section>
      <section anchor="ordering-boundary"><name>Ordering Evidence Is Not Causality</name>
      <t>Hashes, signatures, timestamps, counters, Event Identity references, Event Hash pins, receipts, and dependency graphs can support integrity or ordering properties.</t>
      <t>They do not by themselves establish factual causality, intervention-level causation, legal causation, authorization, responsibility, fault, or complete history.</t>
      </section>
      <section anchor="partial-observation"><name>Partial Observation</name>
      <t>Selective collection, redaction, sampling, instrumentation failure, or unobserved execution can make an apparently consistent event stream incomplete.</t>
      <t>A verifier MUST NOT convert absence of observed contradiction into proof of completeness.</t>
      </section>
      <section anchor="privacy"><name>Privacy of Temporal Metadata</name>
      <t>Event density, latency, branch structure, timing, synchronization patterns, tool-call patterns, and update cadence can reveal sensitive operational, behavioral, security, or proprietary information.</t>
      <t>Deployments SHOULD minimize disclosed temporal metadata and use aggregation, redaction, access control, pseudonymous references, or encryption when appropriate.</t>
      </section>
      <section anchor="hardware-limitations"><name>Hardware Trust Limitations</name>
      <t>Hardware trust mechanisms can support measurement integrity, protected counters, or execution-environment attestation.</t>
      <t>They do not prove that a Measurement Profile is meaningful, that the Event Definition is valid, that observations are complete, or that the target fact is determined.</t>
      </section>
    </section>
    <section anchor="iana"><name>IANA Considerations</name>
      <t>This document requests no IANA actions.</t>
      <t>Future CTP-family specifications that define protocol identifiers, media types, registries, or concrete interoperable formats may request IANA actions in their own documents.</t>
    </section>
    <section anchor="changes"><name>Changes from -01</name>
      <t>Major changes from <tt>draft-wang-ctp-definition-01</tt>:</t>
      <ul spacing="normal">
        <li>retained CTP/0 as an Informational conceptual framework rather than a wire protocol;</li>
        <li>aligned external infrastructure references with JEP-Core 0.7;</li>
        <li>replaced the historical HJS technical dependency with JEP Receipt Profile;</li>
        <li>changed logical JEP event references from Event Hash to Event Identity and retained Event Hash only for exact signed-artifact pinning;</li>
        <li>removed the example that placed a CTP digest directly in generic JEP <tt>what</tt>;</li>
        <li>clarified that external binding profiles decide where and how CTP-compatible digests are bound;</li>
        <li>replaced the earlier hash-chain emphasis with general ordering and integrity evidence profiles and reuse of JAC when appropriate;</li>
        <li>made Event Definition and Time Base explicit first-class concepts;</li>
        <li>defined Comparable Claims and prohibited implicit cross-profile metric comparison;</li>
        <li>strengthened CED comparison requirements;</li>
        <li>strengthened CAE profile requirements and interpretation limits;</li>
        <li>clarified the operational and non-consciousness meaning of "Cognitive Event";</li>
        <li>added explicit Time Base separation and timestamp non-inference;</li>
        <li>added branch/copy identity boundaries;</li>
        <li>clarified open-world, completeness, and target-determinability boundaries;</li>
        <li>updated relationships to JEP Receipt Profile, JAC-03, COE-02, and CEP-02;</li>
        <li>retained no IANA actions.</li>
      </ul>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner"/><date year="1997" month="March"/></front>
          <seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><author initials="B." surname="Leiba"/><date year="2017" month="May"/></front>
          <seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="JEP">
          <front><title>Judgment Event Protocol (JEP)</title><author initials="Y." surname="Wang" fullname="Yuqiang Wang"/><date year="2026" month="September" day="26"/></front>
          <seriesInfo name="Internet-Draft" value="draft-wang-jep-judgment-event-protocol-07"/>
        </reference>
        <reference anchor="JEP-RECEIPT">
          <front><title>JEP Receipt Profile: Verifiable Behavior and Evidence Receipts</title><author initials="Y." surname="Wang" fullname="Yuqiang Wang"/><date year="2026" month="September" day="26"/></front>
          <seriesInfo name="Internet-Draft" value="draft-wang-jep-receipt-profile-00"/>
        </reference>
        <reference anchor="JAC">
          <front><title>JAC: Declared Dependency Graphs for JEP Events and Receipts</title><author initials="Y." surname="Wang" fullname="Yuqiang Wang"/><date year="2026" month="September" day="26"/></front>
          <seriesInfo name="Internet-Draft" value="draft-wang-jac-03"/>
        </reference>
        <reference anchor="COE">
          <front><title>Cognition-Oriented Emergence (COE): A JEP Profile for Shared Observation and State-Claim Evidence</title><author initials="Y." surname="Wang" fullname="Yuqiang Wang"/><date year="2026" month="September" day="26"/></front>
          <seriesInfo name="Internet-Draft" value="draft-wang-coe-02"/>
        </reference>
        <reference anchor="CEP">
          <front><title>Co-Evolve Binding Profile (CEP): A JEP Profile for Evolution-Change Evidence Binding</title><author initials="Y." surname="Wang" fullname="Yuqiang Wang"/><date year="2026" month="September" day="26"/></front>
          <seriesInfo name="Internet-Draft" value="draft-wang-cep-02"/>
        </reference>
        <reference anchor="VDF">
          <front><title>Verifiable Delay Functions</title><author initials="D." surname="Boneh"/><author initials="J." surname="Bonneau"/><author initials="B." surname="Buenz"/><author initials="B." surname="Fisch"/><date year="2018"/></front>
        </reference>
        <reference anchor="LAMPORT">
          <front><title>Time, Clocks, and the Ordering of Events in a Distributed System</title><author initials="L." surname="Lamport"/><date year="1978"/></front>
        </reference>
      </references>
    </references>
  </back>
</rfc>
