Internet Engineering Task Force (IETF) Y. Wang Internet-Draft HJS Foundation Intended status: Informational April 29, 2026 Expires: October 29, 2026 CTP/0: Cognitive Time Protocol -- Definition and Framework draft-wang-ctp-definition-01 Abstract This document describes CTP/0, the definition layer of the Cognitive Time Protocol (CTP) family. CTP/0 is a conceptual reference framework for representing, comparing, and referencing time-related claims in AI and agent systems. It defines terminology for cognitive events, event-density claims, ordering claims, branching claims, and declared emergent temporal-structure claims. CTP/0 does not define a wire protocol, message format, signature format, hash-chain format, governance process, physical theory of time, theory of consciousness, or legal accountability framework. Where verifiable records are needed, CTP-compatible claims can be bound to external event or receipt infrastructure such as JEP, HJS, JAC, COE, or CEP. This revision narrows the original CTP/0 draft to an informational framework. Metrics such as Cognitive Event Density (CED), Causal Arrow Entropy (CAE), Verifiable Delay Function (VDF) evidence, and time-related evidence chains are treated as optional claim or evidence profiles, not as universal measures of intelligence, cognition, truth, safety, or responsibility. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 29, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Motivation 1.2. Scope 1.3. Relationship to Event and Receipt Infrastructure 1.4. Infrastructure Positioning 1.5. Requirements Language 1.6. Terminology 2. CTP/0 Model 2.1. Conceptual Framework, Not a Wire Protocol 2.2. Time-Related Claims 2.3. Minimal Core and Optional Profiles 2.4. What CTP Does Not Determine 3. Layered Reference Architecture 3.1. Layer 0: Definition Layer 3.2. Layer 1: Perception and Density Claims 3.3. Layer 2: Direction and Ordering Claims 3.4. Layer 3: Copy and Branching Claims 3.5. Layer 4: Emergence and Declared Temporal Structures 4. Core Concepts 4.1. Cognitive Event 4.2. Cognitive Event Density (CED) 4.3. Causal Arrow Entropy (CAE) 4.4. Sequential Computation Evidence 4.5. Time-Related Evidence Chain References 5. Optional Evidence Profiles 5.1. VDF Evidence Profile 5.2. Hash-Chain Evidence Profile 5.3. Hardware-Attestation Evidence Profile 5.4. Event and Receipt Binding Profiles 6. Validation and Use 6.1. Claim Validation 6.2. Measurement Profiles 6.3. Binding to JEP/HJS/JAC/COE/CEP 6.4. Non-Inference Rules 7. Security and Privacy Considerations 7.1. CTP Metrics Are Not Truth 7.2. VDF Proofs Are Not Cognitive Proofs 7.3. Hash Chains Are Not Causality 7.4. Partial Observation and Target Determinability 7.5. Privacy of Cognitive-Time Metadata 7.6. Hardware Trust Limitations 8. IANA Considerations 9. References 9.1. Normative References 9.2. Informative References Appendix A. Changes from draft-wang-ctp-definition-00 Acknowledgments Author's Address 1. Introduction 1.1. Motivation 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 in one 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 compare physical timestamps, logical order, causal dependencies, and signed receipt chains. CTP/0 provides terminology for these time-related claims. Its purpose is to separate different meanings of "time" that are often conflated: physical time, logical time, computation time, event time, branch time, audit time, and declared cognitive-event time. The framework is deliberately limited. It is not a theory of AI consciousness, subjective experience, psychology, spacetime, moral agency, or legal responsibility. It is a reference vocabulary and architectural map for future documents that may define concrete measurement profiles, evidence profiles, or bindings to external event infrastructure. 1.2. Scope CTP/0 defines: o A conceptual model for time-related claims in AI and agent systems. o Terminology for cognitive events, event-density claims, ordering claims, branching claims, and declared temporal-structure claims. o A layered reference architecture for the CTP family. o Optional evidence-profile concepts, including VDF evidence, hash-chain evidence, hardware-attestation evidence, and event/receipt bindings. o Security and privacy boundaries for interpreting CTP-compatible claims. CTP/0 explicitly does not define: o A wire protocol, message syntax, media type, port number, API, or interoperable data format. o A signature, hash, canonicalization, identity, trust, or receipt mechanism. o A global metric of intelligence, reasoning quality, consciousness, safety, alignment, moral status, or model capability. o A governance framework, monitoring duty, legal accountability framework, fairness system, appeal system, explanation-rights framework, or compliance authority. o A physical theory of time, subjective-time theory, psychological-time model, or proof that any AI system experiences time. 1.3. Relationship to Event and Receipt Infrastructure CTP/0 is a conceptual framework. It does not replace event or receipt infrastructure. When a deployment requires verifiable records, CTP-compatible claims can be bound to external infrastructures. The following relationships are informative: o JEP can bind time-related claims to signed events and event hashes. o HJS can package AI-agent behavior records and receipt bundles that reference CTP-compatible time-related claims. o JAC can express declared dependency links between time-related events or receipt elements. o COE can bind observation records and shared-state claims that include time-related descriptors. o CEP can bind evolution-change records that reference declared temporal structures or time-related evidence. CTP does not define the semantics, validation rules, or registries of those infrastructures. A deployment that uses CTP terminology with one of those systems follows the corresponding JEP, HJS, JAC, COE, or CEP profile. 1.4. Infrastructure Positioning CTP/0 is infrastructure for naming and comparing time-related claims. It provides a vocabulary and a reference architecture. It does not decide what happened, who is responsible, whether an observation is sufficient, whether a process is fair, or whether an AI system is safe, aligned, conscious, or legally compliant. The CTP core is intentionally minimal. It defines concepts; it does not prescribe implementations. Evidence mechanisms, measurement procedures, hardware support, receipt bindings, and external policies are optional profiles or deployment choices. 1.5. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Because this document is an informational framework and not a wire protocol, capitalized requirement words are used mainly to state interpretation boundaries and profile requirements. Concrete interoperability requirements belong to future CTP-family specifications or to external event/receipt profiles. 1.6. Terminology CTP/0: The definition layer of the Cognitive Time Protocol family. It defines the terminology and reference architecture described in this document. Cognitive event: A declared or observed unit of processing in an AI or agent system under a measurement profile. The definition of a cognitive event is profile-defined and implementation-dependent. Time-related claim: A claim about event order, event density, branch structure, sequential computation, temporal evidence, or declared temporal structure. A time-related claim may be measured, asserted, inferred, or externally referenced. Cognitive Event Density (CED): A declared or measured event-density indicator expressing cognitive events per unit of physical time under a shared event definition and measurement profile. Causal Arrow Entropy (CAE): A heuristic or profile-defined measure of uncertainty in an event sequence, often written as conditional entropy of a later event given earlier events. Declared temporal structure: A deployment-defined claim about a branch, synchronization pattern, abstraction, recurrence, or emergent structure in a cognitive-event stream. CTP does not determine whether such a structure is physically real, conscious, novel, or morally relevant. Measurement profile: A deployment or specification-defined procedure for counting events, measuring time, recording uncertainty, or collecting evidence. Evidence profile: A profile that defines how optional evidence, such as VDF proofs, hardware attestations, event hashes, or receipt references, supports a time-related claim. 2. CTP/0 Model 2.1. Conceptual Framework, Not a Wire Protocol CTP/0 does not define packets, messages, headers, fields, APIs, or canonical encodings. Implementations cannot be "CTP/0 wire-compatible" because CTP/0 intentionally does not define a wire format. Future documents may define concrete CTP-family formats, but they are outside this document. A system may be described as CTP-compatible only in the limited sense that it uses the terms and boundaries in this document, or that it implements a future profile that references CTP/0. 2.2. Time-Related Claims A time-related claim is any claim that uses the CTP vocabulary to describe event order, event density, event branching, temporal evidence, or declared temporal structure. Examples include: o A claim that an agent processed N profile-defined cognitive events during a physical interval. o A claim that one event was declared to precede, depend on, or derive from another event. o A claim that a branch of an agent process was copied, forked, replayed, merged, or discarded. o A claim that a VDF, event hash, receipt bundle, or hardware attestation supports a sequential computation or ordering claim. o A claim that a new temporal abstraction or branch structure was observed under a deployment profile. A time-related claim does not by itself establish truth, causality, responsibility, intent, consciousness, or legal effect. 2.3. Minimal Core and Optional Profiles The CTP/0 core consists only of terminology, a layered reference architecture, interpretation boundaries, and optional evidence-profile categories. All measurement methods and evidence mechanisms are optional profiles. A CTP-family profile MAY define concrete procedures for counting events, measuring elapsed time, using VDF evidence, referencing event hashes, binding claims to receipts, or integrating hardware attestations. Such a profile MUST state its event definition, measurement procedure, evidence requirements, and interpretation boundaries. 2.4. What CTP Does Not Determine CTP-compatible records and metrics MUST NOT be interpreted by the protocol as proving: o that an AI system is conscious or has subjective experience; o that a cognitive event is equivalent across different systems without a shared measurement profile; o that high event density implies intelligence, correctness, safety, alignment, or moral status; o that a VDF proof proves reasoning quality, understanding, intent, or subjective duration; o that a hash chain proves factual causality, authorization, responsibility, legal non-repudiation, or target determinability; o that an emergent temporal structure is real, novel, physically meaningful, or morally relevant; or o that a target fact is settled merely because logs, traces, explanations, measurements, or receipts exist. 3. Layered Reference Architecture The CTP family is organized as a reference architecture with Layer 0 providing definitions and Layers 1 through 4 addressing categories of time-related claims. The layers are conceptual. Implementations MAY use a subset of layers, combine layers, or define profiles that reference only selected concepts. 3.1. Layer 0: Definition Layer Layer 0 is this document. It defines the CTP vocabulary, conceptual boundaries, optional evidence-profile categories, and relationships to external event and receipt infrastructures. 3.2. Layer 1: Perception and Density Claims Layer 1 concerns claims about event density or perceived processing rate. A Layer 1 profile may define how to count cognitive events, what physical or logical time base is used, and how a claimed event density is supported by evidence. Layer 1 does not determine subjective experience. It only provides a structure for event-density claims under a declared measurement profile. 3.3. Layer 2: Direction and Ordering Claims Layer 2 concerns claims about ordering, declared dependency, or directional structure among events. These claims may use logical clocks, JEP event hashes, JAC dependency links, causal-edge descriptors, or other external evidence structures. Layer 2 does not establish physical causation, legal causation, responsibility, or completeness of a causal history. 3.4. Layer 3: Copy and Branching Claims Layer 3 concerns claims about copying, branching, replication, synchronization, merging, or abandonment of event streams. These claims may apply to speculative execution, distributed agent branches, simulations, or parallel planning paths. Layer 3 does not determine whether copied branches are equivalent, whether a merge is semantically correct, or whether responsibility follows a branch. Such determinations require external profiles. 3.5. Layer 4: Emergence and Declared Temporal Structures Layer 4 concerns declared emergent temporal structures, such as new branching patterns, synchronization patterns, abstractions, recurrence patterns, or evolution patterns observed in cognitive-event streams. Layer 4 does not determine whether a structure is truly emergent, novel, conscious, physically meaningful, or morally relevant. It only provides terminology for recording and comparing such claims under deployment-defined profiles. 4. Core Concepts 4.1. Cognitive Event A cognitive event is a declared or observed unit of processing under a measurement profile. Examples may include inference steps, tool calls, retrieval operations, planning steps, verification checks, simulation ticks, branch creation, branch merge, or receipt generation. The definition of a cognitive event is not universal. A profile that reports cognitive events SHOULD state: o the event boundary condition; o the event source or instrumentation method; o whether events may overlap or run in parallel; o whether events are weighted; o how events are deduplicated or merged; and o what evidence, if any, supports the event count. 4.2. Cognitive Event Density (CED) Cognitive Event Density (CED) is a declared or measured processing-density indicator: CED = C_total / T_physical where C_total is a count or weighted aggregate of profile-defined cognitive events and T_physical is elapsed physical time under the measurement profile. CED is not a universal measure of intelligence, reasoning quality, consciousness, safety, alignment, or moral status. Comparisons across systems are meaningful only under a shared event definition, shared measurement procedure, and shared evidence profile. A profile that reports CED SHOULD state the event definition, time source, counting method, weighting method if any, and evidence used to support the measurement. 4.3. Causal Arrow Entropy (CAE) Causal Arrow Entropy (CAE) is a heuristic or profile-defined measure of uncertainty in an event sequence. It may be written as: CAE = H(Event_N | Event_{N-1}, ..., Event_0) where H represents conditional entropy under the model or profile. CAE can be used to describe how much information is needed to characterize a later event given earlier events. CAE does not prove physical causality, legal causation, creativity, intent, responsibility, novelty, or emergence. A profile using CAE SHOULD define the event space, probability model, conditioning context, and interpretation limits. 4.4. Sequential Computation Evidence Some deployments may wish to support a claim that a minimum amount of sequential computation occurred. VDFs or other sequential-computation evidence can support such claims under an evidence profile. Sequential computation evidence proves only what the evidence profile states. It does not by itself prove cognitive effort, reasoning quality, intent, understanding, subjective duration, or safety. 4.5. Time-Related Evidence Chain References CTP/0 does not define an independent judgment hash-chain protocol. When a time-related claim needs cryptographic binding, implementations SHOULD reference external evidence structures such as JEP event hashes, JAC declared-dependency links, HJS receipt bundles, COE observation records, CEP evolution-change records, or another deployment-defined evidence structure. A hash chain or signed receipt can provide integrity and ordering evidence. It does not by itself establish factual causality, legal non-repudiation, authorization validity, responsibility, target determinability, or truth. 5. Optional Evidence Profiles 5.1. VDF Evidence Profile A VDF evidence profile MAY be used to support claims about minimum sequential computation. Such a profile SHOULD specify the VDF construction, security parameters, input binding, output proof format, verification procedure, and limitations. A VDF proof MUST NOT be interpreted by the protocol as proving cognition, understanding, intent, human-like deliberation, or subjective duration. 5.2. Hash-Chain Evidence Profile A hash-chain evidence profile MAY be used to support ordering and integrity claims. Such a profile SHOULD specify the hash function, canonicalization method, record format, inclusion rule, chain extension rule, and verification method. If a deployment already uses JEP, HJS, JAC, COE, or CEP, a CTP-compatible hash-chain evidence profile SHOULD prefer references to those existing event hashes or receipt bundles rather than defining a parallel chain. 5.3. Hardware-Attestation Evidence Profile A hardware-attestation evidence profile MAY use trusted execution environments, secure counters, measured boot, remote attestation, or protected storage to support claims about execution environment or measurement integrity. Hardware attestation can support claims about where or how evidence was collected. It does not prove that the event definition is correct, that an observation is complete, that the target is determinable, or that the resulting system is safe, fair, lawful, or aligned. 5.4. Event and Receipt Binding Profiles A CTP-compatible claim MAY be bound to external event and receipt infrastructure. For example: o A JEP event may sign the digest of a CTP-compatible measurement record. o An HJS receipt bundle may include a CTP evidence descriptor for an AI-agent behavior record. o A JAC chain extension may reference a declared ordering or branch dependency described using CTP terms. o A COE shared-state claim may include time-related descriptors for observations and validations. o A CEP evolution-change record may include a declared temporal-structure reference. The binding profile, not CTP/0, defines the concrete data format, signature input, verification procedure, privacy model, and critical-extension behavior. 6. Validation and Use 6.1. Claim Validation A verifier of a CTP-compatible claim should distinguish structural validation from substantive interpretation. Structural validation may check that a record is well formed, that referenced evidence exists, that hashes match, that signatures are valid under an external profile, and that a declared measurement profile was followed. Substantive interpretation asks what the claim means for a target fact, safety conclusion, audit conclusion, governance decision, scientific conclusion, or legal question. Such interpretation is outside CTP/0 and belongs to external profiles, domain models, or legal, organizational, scientific, or governance processes. 6.2. Measurement Profiles A measurement profile SHOULD define at least: o the event definition; o the time source or clock model; o whether physical time, logical time, computation time, event time, or audit time is being measured; o what instrumentation collects the events; o what evidence supports the measurement; o how missing, parallel, duplicated, or redacted events are handled; o whether the measurement is comparable across systems; and o what the measurement must not be interpreted to prove. 6.3. Binding to JEP/HJS/JAC/COE/CEP When CTP-compatible claims are bound to JEP, HJS, JAC, COE, or CEP, the binding record should use the event, receipt, extension, and digest-binding rules of that infrastructure. CTP/0 does not change those rules. For example, a JEP-based binding may place the digest of a CTP measurement record in the JEP "what" field. An HJS receipt bundle may include the same digest as an evidence descriptor. A JAC extension may reference the same digest as a declared dependency. Each binding proves only the relationship specified by its own profile. 6.4. Non-Inference Rules The absence of a CTP-compatible claim MUST NOT be interpreted by the protocol as agreement, waiver, admission, lack of objection, lack of harm, absence of relevant context, absence of external rights, or absence of an external process. The presence of a CTP-compatible claim MUST NOT be interpreted by the protocol as proving truth, fairness, safety, legality, responsibility, consciousness, or target determinability. The claim provides a technical reference; interpretation belongs to external profiles and processes. 7. Security and Privacy Considerations 7.1. CTP Metrics Are Not Truth CTP metrics and descriptors are evidence-related constructs. They may help describe event density, ordering, branching, or temporal structures. They do not prove that a system is correct, intelligent, safe, aligned, conscious, or legally compliant. 7.2. VDF Proofs Are Not Cognitive Proofs A VDF proof can support a claim that a minimum amount of sequential computation was performed under a declared profile. It does not prove that a cognitive process occurred, that reasoning was sound, that intent existed, that understanding occurred, or that a subjective duration was experienced. 7.3. Hash Chains Are Not Causality Hash chains, signatures, and receipts can provide tamper-evident ordering and integrity. They do not by themselves prove causal completeness, intervention-level causation, legal causation, authorization validity, responsibility, fault, or non-repudiation in the legal sense. 7.4. Partial Observation and Target Determinability CTP-compatible observations are often partial. A record may contain timestamps, event counts, branch identifiers, hashes, VDF proofs, and attestations without retaining enough target-relevant causal information to settle an external target fact. In partially observed causal systems, different real histories may produce the same observed event sequence while differing on the target fact of interest. Therefore, CTP provides terminology and optional evidence references, not a guarantee of target determinability. Determining whether an observation is sufficient for a target requires an external model of possible histories, observations, and target facts, as discussed in [TARGET-DETERMINABILITY]. 7.5. Privacy of Cognitive-Time Metadata Time-related metadata can be sensitive. Event density, branch structure, reasoning latency, tool-call timing, and synchronization patterns may reveal operational capabilities, workload, user behavior, model behavior, or proprietary processes. Deployments SHOULD minimize exposed metadata and use privacy-preserving references, aggregation, redaction, access control, or encryption where appropriate. 7.6. Hardware Trust Limitations Hardware trust mechanisms may support measurement integrity, protected counters, or attestation of an execution environment. They do not prove that a measurement profile is meaningful, that an event definition is valid, that observations are complete, or that a target fact is determined. Compromise, misconfiguration, side channels, supply-chain issues, and incorrect measurement design remain deployment risks. 8. IANA Considerations This document makes no requests of IANA. Future CTP-family specifications that define media types, protocol identifiers, registries, or extension identifiers may request IANA actions in their own documents. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [JEP] Wang, Y., "Judgment Event Protocol (JEP)", Work in Progress, Internet-Draft, draft-wang-jep-judgment-event-protocol-05, April 2026. [HJS] Wang, Y., "HJS: An Accountability Layer for AI Agents", Work in Progress, Internet-Draft, draft-wang-hjs-accountability-05, April 2026. [JAC] Wang, Y., "JAC: Declared Dependency Chains for Agent Receipts", Work in Progress, Internet-Draft, draft-wang-jac-02, April 2026. [COE] Wang, Y., "Cognition-Oriented Emergence (COE): A JEP Profile for Shared Observation and State-Claim Evidence", Work in Progress, Internet-Draft, draft-wang-coe-01, April 2026. [CEP] Wang, Y., "Co-Evolve Binding Profile (CEP): A JEP/HJS Profile for AI Evolution-Change Evidence Binding", Work in Progress, Internet-Draft, draft-wang-cep-01, April 2026. [TARGET-DETERMINABILITY] Wang, Y., "Target Determinability under Partial Causal Observation: A Faithful Reduction Framework", Zenodo, Version v1, DOI 10.5281/zenodo.19678205, April 2026, . [VDF] Boneh, D., Bonneau, J., Buenz, B., and B. Fisch, "Verifiable Delay Functions", Proceedings of CRYPTO 2018, . [LAMPORT] Lamport, L., "Time, Clocks, and the Ordering of Events in a Distributed System", Communications of the ACM, Vol. 21, No. 7, pp. 558-565, July 1978. Appendix A. Changes from draft-wang-ctp-definition-00 o Changed the intended status from Experimental to Informational. o Reframed CTP/0 as a conceptual reference framework, not a deployable protocol. o Removed language implying that CTP manipulates time or defines subjective experience. o Reframed Layer 4 as declared temporal structures rather than new time dimensions. o Clarified that CED is an event-density indicator, not a universal intelligence or consciousness metric. o Clarified that CAE is a heuristic or profile-defined uncertainty measure, not a proof of causality or responsibility. o Clarified that VDF evidence supports sequential-computation claims only. o Replaced the independent Judgment Hash Chain concept with references to external event and receipt infrastructure. o Added relationship text for JEP, HJS, JAC, COE, and CEP. o Added partial-observation and target-determinability boundaries. o Moved hardware trust into optional evidence-profile language. o Retained no IANA actions. Acknowledgments The author thanks the contributors to the CTP, JEP, HJS, JAC, COE, and CEP discussions for feedback on narrowing the scope of CTP/0 to a conceptual reference framework. Author's Address Yuqiang Wang HJS Foundation Email: signal@humanjudgment.org GitHub: https://github.com/hjs-spec