CTP/0: Cognitive Time Protocol -- Definition and Framework

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 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.¶

CTP/0 provides terminology for these time-related claims.¶

Its purpose is to prevent different meanings of "time" from being silently collapsed into one another.¶

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.¶

1.2. Scope

CTP/0 defines:¶

• a conceptual model for time-related claims in AI and agent systems;¶
• terminology for cognitive-event, event-density, ordering, branching, sequential-computation, and declared temporal-structure claims;¶
• a layered reference architecture for organizing those claim categories;¶
• requirements that measurement profiles make comparison assumptions explicit;¶
• optional evidence-profile categories;¶
• interpretation, security, privacy, and non-inference boundaries.¶

CTP/0 explicitly does not define:¶

• a wire protocol, message syntax, media type, port number, API, or interoperable record encoding;¶
• a signature, hash, canonicalization, identity, trust, or receipt mechanism;¶
• a global event definition;¶
• a global clock or synchronization mechanism;¶
• a universal metric of intelligence, reasoning quality, consciousness, safety, alignment, moral status, or model capability;¶
• a causal model;¶
• a governance, approval, monitoring, fairness, appeal, explanation-rights, or compliance framework;¶
• a physical, subjective, or psychological theory of time;¶
• proof that any AI system experiences time.¶

1.3. Relationship to External Infrastructure

CTP/0 is a conceptual framework. It does not replace event, receipt, dependency, observation, or change-evidence infrastructure.¶

The following relationships are informative:¶

• [JEP] can carry signed statements that reference CTP-compatible claims or evidence while retaining JEP-Core event semantics.¶
• JEP Receipt Profile [JEP-RECEIPT] can package CTP-compatible records or evidence as digest-addressed receipt artifacts.¶
• [JAC] can express declared dependency-graph structure among JEP events associated with time-related claims.¶
• [COE] can carry observations or shared-state claims containing time-related descriptors or evidence.¶
• [CEP] can carry declared change records referencing time-related evidence or temporal structures.¶

CTP/0 does not redefine the semantics, identifiers, validation rules, or registries of those specifications.¶

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.¶

1.4. Infrastructure Positioning

CTP/0 is infrastructure for naming and comparing time-related claims.¶

It defines concepts and comparison preconditions; it does not prescribe one implementation.¶

Measurement procedures, evidence mechanisms, hardware support, signed-event bindings, receipts, dependency graphs, and domain policies remain external 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.¶

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.¶

1.6. Terminology

CTP/0: The definition layer of the Cognitive Time Protocol family.¶

Cognitive Event: 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.¶

Event Definition: The profile-defined rule that determines what counts as one Cognitive Event.¶

Time Base: The clock, counter, logical-order domain, computational measure, or other temporal reference used by a measurement profile.¶

Time-Related Claim: A claim concerning event order, event density, branch structure, sequential computation, temporal evidence, or a declared temporal structure.¶

Measurement Profile: 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.¶

Evidence Profile: A profile that defines how evidence supports a time-related claim.¶

Cognitive Event Density (CED): A profile-scoped event-density indicator expressing profile-defined Cognitive Events per declared time unit.¶

Causal Arrow Entropy (CAE): A heuristic or profile-defined uncertainty measure over an explicitly defined event sequence and probability model.¶

Declared Temporal Structure: A declared claim about branch, synchronization, recurrence, abstraction, copy, merge, or other temporal structure in an event stream.¶

Comparable Claims: Two time-related claims whose applicable profiles define sufficiently compatible event definitions, time bases, measurement procedures, and normalization rules for the intended comparison.¶

2.1. Conceptual Framework, Not a Wire Protocol

CTP/0 does not define packets, messages, headers, fields, APIs, canonical encodings, or a conformance wire format.¶

An implementation cannot be "CTP/0 wire-compatible" because CTP/0 intentionally defines no wire representation.¶

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.¶

2.2. Claim Types

CTP/0 recognizes several broad categories of time-related claims:¶

• event-density claims;¶
• order or direction claims;¶
• branch, copy, merge, or synchronization claims;¶
• sequential-computation claims;¶
• temporal-evidence claims;¶
• declared temporal-structure claims.¶

A claim MAY be measured, asserted, inferred, or externally referenced.¶

The claim type does not determine whether the claim is true.¶

2.3. Claim Context

A CTP-compatible time-related claim SHOULD identify, directly or through an applicable profile:¶

• the claim type;¶
• the subject or event domain;¶
• the Event Definition;¶
• the Time Base;¶
• the measurement or inference procedure;¶
• the applicable profile identifier;¶
• the evidence basis, if any;¶
• whether the claim is intended to be comparable with another class of claims;¶
• known assumptions, exclusions, or incompleteness.¶

CTP/0 does not define a canonical record containing these members.¶

2.4. Minimal Core and Optional Profiles

The CTP/0 core consists only of terminology, claim categories, comparison preconditions, interpretation boundaries, and a layered reference architecture.¶

All concrete measurement procedures and evidence mechanisms are external profiles.¶

A CTP-family profile that defines a measurable quantity MUST state:¶

• its Event Definition;¶
• its Time Base;¶
• its measurement or inference procedure;¶
• its normalization and aggregation rules;¶
• its evidence requirements;¶
• treatment of missing, duplicated, parallel, redacted, or sampled events;¶
• comparison conditions;¶
• interpretation limits.¶

2.5. No Implicit Equivalence

Two CTP-compatible claims MUST NOT be treated as quantitatively comparable merely because they use the same metric label, such as CED or CAE.¶

Cross-system comparison requires an applicable profile that establishes compatible semantics or explicitly defines a conversion or normalization procedure.¶

A shared numeric unit alone does not establish semantic comparability.¶

2.6. What CTP Does Not Determine

CTP-compatible claims, metrics, and evidence MUST NOT be presented by CTP/0 itself as proving:¶

• that an AI system is conscious or has subjective experience;¶
• that two Cognitive Events are equivalent without compatible Event Definitions;¶
• that higher event density implies greater intelligence or reasoning quality;¶
• that a lower or higher CAE value is intrinsically better;¶
• that sequential-computation evidence proves cognitive effort or understanding;¶
• that ordering evidence proves factual causality;¶
• that a branch, copy, or merge is semantically equivalent to another;¶
• that an emergent temporal structure is physically real or novel;¶
• that logs or receipts are complete;¶
• that an external target fact is determined;¶
• that responsibility, authorization, safety, fairness, legality, or policy compliance follows.¶

3.1. Layer 0: Definition Layer

Layer 0 is this document.¶

It defines CTP terminology, claim categories, comparison boundaries, evidence categories, and relationships to external infrastructures.¶

3.2. Layer 1: Event and Density Claims

Layer 1 concerns claims about counts, rates, durations, or densities of profile-defined Cognitive Events.¶

A Layer 1 profile SHOULD define the Event Definition, Time Base, counting method, overlap rules, weighting rules, and evidence basis.¶

Layer 1 does not determine subjective experience or reasoning quality.¶

3.3. Layer 2: Ordering and Direction Claims

Layer 2 concerns claims about ordering, dependency, direction, or temporal precedence among events or records.¶

Possible evidence includes logical clocks [LAMPORT], counters, trusted timestamps, signed events, JEP Event Identity references with optional exact-artifact pins, or JAC dependency graphs.¶

Layer 2 does not establish factual causality, complete history, legal causation, authorization, or responsibility.¶

3.4. Layer 3: Copy, Branch, and Merge Claims

Layer 3 concerns claims about copying, branching, replication, synchronization, merging, replaying, or abandonment of event streams.¶

A Layer 3 profile SHOULD state how branch identity, common ancestry, fork points, merge points, and duplicate/replayed events are represented.¶

Layer 3 does not establish semantic equivalence of branches or determine whether a merge is correct.¶

3.5. Layer 4: Declared Temporal Structures

Layer 4 concerns declared temporal structures such as recurring patterns, synchronization patterns, abstraction layers, branching motifs, or change-related patterns observed in event streams.¶

Layer 4 does not establish that a structure is emergent, novel, conscious, physically meaningful, valuable, or morally relevant.¶

4.1. Cognitive Event

A Cognitive Event is a declared or observed processing unit 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 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.¶

A profile that counts Cognitive Events SHOULD state:¶

• the event boundary condition;¶
• the event source or instrumentation method;¶
• whether events may overlap or execute in parallel;¶
• whether events are weighted;¶
• how duplicate, retried, merged, or sampled events are handled;¶
• what evidence supports the event count.¶

4.2. Time Bases

CTP distinguishes the following non-exhaustive time bases:¶

• physical or wall-clock time;¶
• monotonic process time;¶
• logical time;¶
• event order;¶
• computation or work measure;¶
• receipt or archive time;¶
• profile-defined declared time.¶

A claim MUST identify the Time Base required for its interpretation.¶

One Time Base MUST NOT be silently substituted for another.¶

An actor-declared timestamp is not trusted physical time unless an applicable evidence profile establishes that property.¶

4.3. Cognitive Event Density (CED)

For a Measurement Profile that defines a count or weighted aggregate C_total and a denominator interval T, CED MAY be expressed as:¶

CED = C_total / T

The profile MUST define what C_total counts and what Time Base and units T uses.¶

A CED value is meaningful only under the applicable Event Definition, Measurement Profile, Time Base, and normalization rules.¶

Two CED values MUST NOT be compared as equivalent measurements unless those conditions are compatible or an explicit conversion profile is used.¶

CED MUST NOT be presented as a universal measure of intelligence, consciousness, correctness, safety, alignment, moral status, or capability.¶

4.4. Causal Arrow Entropy (CAE)

CAE is a profile-scoped heuristic or uncertainty measure over a defined event space and probability model.¶

A profile MAY define an expression such as:¶

CAE = H(Event_N | Event_{N-1}, ..., Event_0)

where H denotes conditional entropy under that profile's model.¶

A CAE profile MUST define:¶

• the event space;¶
• random variables;¶
• conditioning context;¶
• probability estimation procedure;¶
• treatment of missing or censored events;¶
• units or logarithm base where relevant;¶
• comparison conditions;¶
• interpretation limits.¶

CAE does not prove causal direction, factual causality, novelty, creativity, intent, responsibility, or emergence.¶

4.5. Sequential-Computation Evidence

Some deployments may use Verifiable Delay Functions [VDF] or other mechanisms as evidence for minimum sequential work under a defined construction.¶

Sequential-computation evidence establishes only the property specified by the applicable evidence profile.¶

It MUST NOT be presented by CTP as proof of reasoning quality, understanding, intent, subjective duration, consciousness, intelligence, safety, or alignment.¶

4.6. Ordering and Dependency Evidence

CTP/0 does not define an independent judgment hash-chain protocol.¶

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.¶

For JEP-based systems:¶

• logical JEP event identity is JEP Event Identity;¶
• Event Hash MAY pin one exact signed artifact;¶
• JAC MAY express declared dependency graphs;¶
• JEP Receipt Profile MAY preserve portable evidence artifacts.¶

Neither signed order nor dependency structure alone establishes factual causality.¶

4.7. Branch and Copy Identity

CTP/0 does not define a universal identity rule for branches, copies, replicas, or merged processes.¶

A Layer 3 profile that requires cross-system branch comparison MUST define how branch identity, ancestry, copy points, and merge points are identified.¶

Two branches MUST NOT be treated as semantically identical merely because their observed event sequences or hashes are equal.¶

4.8. Declared Temporal Structures

A Declared Temporal Structure is a claim under an applicable profile.¶

It may describe recurrence, branching, synchronization, abstraction, periodicity, or another profile-defined temporal pattern.¶

CTP/0 does not define a universal emergence detector or novelty criterion.¶

5.1. General Requirements

An Evidence Profile SHOULD state:¶

• the evidence object or mechanism;¶
• what claim property the evidence supports;¶
• how evidence is bound to the claim;¶
• verification procedure;¶
• trust assumptions;¶
• failure behavior;¶
• privacy considerations;¶
• properties the evidence does not establish.¶

5.2. VDF Evidence Profiles

A VDF evidence profile MAY support a claim 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 as proof of cognition, understanding, intent, human-like deliberation, or subjective duration.¶

5.3. Ordering and Integrity Evidence Profiles

An ordering or integrity evidence profile MAY use hashes, signatures, logical clocks, transparency systems, trusted timestamps, counters, or other mechanisms.¶

The profile MUST distinguish integrity, ordering, freshness, and causality. Evidence for one of those properties MUST NOT be silently presented as evidence for another.¶

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.¶

5.4. Hardware-Attestation Evidence Profiles

A hardware-attestation evidence profile MAY use trusted execution environments, secure counters, measured boot, remote attestation, protected storage, or similar mechanisms.¶

Hardware attestation MAY support claims about an execution environment or measurement path.¶

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.¶

5.5. External Binding Profiles

A CTP-compatible claim MAY be bound to external infrastructure.¶

Examples include:¶

• a JEP event carrying or referencing a CTP-compatible claim under an explicitly selected profile or extension;¶
• a JEP Receipt Profile bundle containing a CTP measurement or evidence artifact;¶
• a JAC graph associating JEP events involved in a time-related claim;¶
• a COE Observation Record or Shared-State Claim referencing temporal evidence;¶
• a CEP Evolution-Change Record referencing temporal evidence or a declared temporal structure.¶

The external binding specification, not CTP/0, defines concrete record format, signature input, identifiers, digest binding, validation behavior, and critical-extension semantics.¶

6.1. Structural Validation Versus Interpretation

A verifier SHOULD distinguish structural or evidentiary validation from substantive interpretation.¶

Structural or evidentiary validation may determine that:¶

• a measurement profile is identified;¶
• required fields of that profile are present;¶
• evidence digests or signatures validate under an external specification;¶
• a declared measurement was computed according to a stated procedure;¶
• declared references resolve consistently.¶

Substantive interpretation asks what the claim implies about intelligence, quality, causality, safety, consciousness, governance, scientific validity, legal effect, or another external conclusion.¶

Those conclusions are outside CTP/0.¶

6.2. Measurement Profile Requirements

A CTP Measurement Profile intended for interoperable use SHOULD identify itself using a stable collision-resistant identifier, preferably an absolute URI.¶

A Measurement Profile MUST define enough information to reproduce or independently evaluate the claimed measurement, including:¶

• Event Definition;¶
• Time Base;¶
• input domain;¶
• counting or measurement procedure;¶
• normalization;¶
• treatment of concurrency;¶
• treatment of missing, duplicated, replayed, sampled, and redacted events;¶
• evidence requirements;¶
• comparison conditions;¶
• uncertainty or error model where applicable;¶
• interpretation limits.¶

6.3. Comparability

Two CTP-compatible claims are comparable only for the property and scope authorized by their applicable Measurement Profiles.¶

A verifier MUST NOT infer comparability solely from:¶

• equal metric names;¶
• equal numeric units;¶
• equal subject type;¶
• equal time interval length;¶
• equal event counts;¶
• use of the same external event or receipt infrastructure.¶

If two profiles define a conversion or normalization mapping, the resulting comparison MUST identify the mapping used.¶

6.4. Binding to JEP, Receipt Profile, JAC, COE, and CEP

When CTP-compatible claims are bound to external infrastructure, that infrastructure retains authority over its own identifiers and semantics.¶

In particular:¶

• JEP signed-event semantics remain JEP-defined;¶
• JEP Event Identity identifies the logical JEP event;¶
• JEP Event Hash identifies an exact signed artifact;¶
• JEP Receipt Profile defines receipt packaging and receipt validation;¶
• JAC defines declared dependency-graph semantics;¶
• COE defines shared-observation and state-claim evidence semantics;¶
• CEP defines evolution-change evidence-binding semantics.¶

CTP/0 MUST NOT redefine those meanings.¶

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.¶

6.5. Non-Inference Rules

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.¶

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.¶

7.1. Open-World Default

CTP/0 uses an open-world default.¶

An observed event stream is not necessarily complete.¶

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.¶

7.2. Target Determinability

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.¶

CTP/0 therefore does not define or guarantee target determinability.¶

A determinability analysis MAY use an external formal model, but the validity of that analysis is external to CTP/0.¶

7.3. Completeness

A set of CTP-compatible claims MUST NOT be presented as a complete temporal history solely because:¶

• it is cryptographically signed;¶
• every observed record has a hash;¶
• records form an acyclic dependency graph;¶
• records have trusted timestamps;¶
• a receipt bundle contains them;¶
• the observed time interval has no gaps.¶

Completeness requires an explicit external assumption or profile.¶

8.1. Metric Gaming

Measurement definitions can be optimized against.¶

An implementation may increase a metric such as CED by changing the event granularity without improving any external property.¶

A profile SHOULD therefore make Event Definition, aggregation, normalization, and comparison rules explicit.¶

8.2. Clock and Timestamp Confusion

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.¶

A timestamp field MUST NOT be treated as trusted time merely because it is signed.¶

8.3. VDF Proofs Are Not Cognitive Proofs

A VDF proof can support a sequential-computation property under an applicable construction.¶

It does not prove cognition, reasoning quality, understanding, intent, subjective duration, or intelligence.¶

8.4. Ordering Evidence Is Not Causality

Hashes, signatures, timestamps, counters, Event Identity references, Event Hash pins, receipts, and dependency graphs can support integrity or ordering properties.¶

They do not by themselves establish factual causality, intervention-level causation, legal causation, authorization, responsibility, fault, or complete history.¶

8.5. Partial Observation

Selective collection, redaction, sampling, instrumentation failure, or unobserved execution can make an apparently consistent event stream incomplete.¶

A verifier MUST NOT convert absence of observed contradiction into proof of completeness.¶

8.6. Privacy of Temporal Metadata

Event density, latency, branch structure, timing, synchronization patterns, tool-call patterns, and update cadence can reveal sensitive operational, behavioral, security, or proprietary information.¶

Deployments SHOULD minimize disclosed temporal metadata and use aggregation, redaction, access control, pseudonymous references, or encryption when appropriate.¶

8.7. Hardware Trust Limitations

Hardware trust mechanisms can support measurement integrity, protected counters, or execution-environment attestation.¶

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.¶