]> Humotica

Netherlands info@humotica.com https://humotica.com/

Security Internet Engineering Task Force causal time Lamport TIBET logical clocks vector clocks forward-only recovery This document describes the TIBET Causal Time Substrate, a forward-only causal ordering model for identity-bound distributed systems. TIBET does not treat wall-clock time as the primary ordering primitive. Instead, it uses a cryptographically bound logical-time structure encoded through append-only linkage, monotonic generation counters, and signed causal references. External wall-clock sources, including NTP, RFC 3161 timestamping services, Roughtime, GNSS, or public ledger timestamps, are treated as auxiliary alignment anchors rather than as the constitutive source of event order. This revision adds an optional vector-observation layer for relating events across independent lanes, a classification of time-bounded checks that separates physical-world windows from ledger-state windows, replay protection that does not depend on clock agreement between parties, and a distinction between forks, breaks, and reseeds. The core claim is simple: TIBET is a forward-only causal substrate that enables recovery and reversibility without rewriting history.

Introduction This memo is revision -03 of draft-vandemeent-tibet-causal-time. Revisions -00 through -02 were derived from operational architecture notes, prototype implementations, and forensic delivery work produced in the Humotica / TIBET stack during May 2026. The -01 revision added the Filename-Surface Contract () following external peer review by Red Specter Security Research (RS-2026-001). The -02 revision added the Position in the Four-W Vault Family (). The -03 revision incorporates what a reference implementation () revealed between May and October 2026. Four gaps in -02 were found in practice: a scalar generation counter cannot tell concurrent events from ordered ones across independent lanes (); the word "expiry" was being used for checks of different kinds, some of which should not depend on wall-clock time at all (); wall-clock validity windows were silently doing the work of replay protection (); and "fork" was being used for several outcomes that need to be told apart (). A complete list of changes is given in . The document captures and formalizes a structural property that TIBET implementations already exhibit, rather than introducing a greenfield timing model. It is intended to align distributed-systems theory, identity-bound execution, off-grid or degraded-network operations, and forward-only recovery semantics.

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 when, and only when, they appear in all capitals, as shown here.

Problem Statement Many distributed systems continue to over-privilege wall-clock time. They assume that safe ordering, freshness, replay defense, and reversibility can be grounded primarily in synchronized UTC. That assumption is fragile under intermittent connectivity, NTP outage or misconfiguration, GNSS disruption, clock drift across edge nodes, compromised or ambiguous time authorities, and adversarial replay after restore or rollback. A less visible form of the same problem arises when a validity window is introduced for one purpose and silently becomes the only defense for another. A message that is carried slowly between two nodes with correctly synchronized clocks can be rejected as "expired" although nothing about it is stale; removing the window to fix that symptom can then remove the only replay protection the message had. addresses this. This document argues that causal order should be primary, wall-clock time auxiliary, recovery forward-only, and history non-rewritable.

Terminology

Causal Time:

The ordering of events by their dependency and sequence relationships, rather than by globally synchronized wall-clock timestamps.

Forward-Only Causal Substrate:

A substrate in which valid state evolution occurs only by appending new causally linked events.

Logical Counter:

A monotonic counter associated with event generation and ordering. Within TIBET this corresponds to the generation field.

Lane:

An identity-bound sequence of events produced by a single participant (for example, one runtime identity or one account). Each lane has its own monotonic counter.

Causal TimeVector:

A record that carries, for each lane known to the observer, the highest counter value from that lane that the observer has causally seen, in the sense of the vector clocks of and .

External Time Anchor:

An observation of an external time-bearing source, recorded into the causal substrate as a signed event.

Drift Record:

A signed record describing observed offset between local time and an external anchor or between two time-bearing participants.

Triage Fork:

A forward-causal isolation path created in response to anomaly, mismatch, or uncertain continuity.

Admitted Fork:

A branch in a chain that is declared as a named transition and carries the proof terms that transition requires ().

Observed Fork:

A branch in a chain that is detected by a reader (for example, two records claiming the same predecessor) but that no participant declared. An observed fork is not an admitted fork.

Break:

A point at which a chain's linkage does not verify ().

Reseed:

A recorded transition by which a participant that cannot prove it closed its previous run starts a new run under a successor runtime identity, recording the break rather than resuming ().

Scar:

A record placed at the head of a pruned chain that declares where the chain was cut ().

Window:

Any check that accepts or refuses something based on elapsed time or on a bound expressed in time. distinguishes the kinds of window.

Design Goals The TIBET Causal Time Substrate is intended to preserve causal ordering without dependence on absolute time, support cryptographic identity binding of events, permit recovery and revocation without history rewriting, and remain meaningful under offline or degraded-network conditions. It is also intended to integrate with external time anchors, support replay-sensitive freshness checks, and surface time uncertainty honestly. A further goal added in this revision is that every time-bounded check states what it measures, so that a reader can tell a check on the physical world from a check on ledger state.

Model Overview TIBET encodes causal order through a set of existing structural primitives including append-only linkage, signatures, generation counters, and parent references. These map naturally onto a Lamport-style logical ordering model: happened-before pointers, tamper-evident order proof, authenticated event origin, logical counters, causal predecessors, and event-line roots. The important consequence is that TIBET already behaves as a causally ordered logical-time substrate. This document formalizes that fact. A chain may have two distinct origins. The causal origin is its first record. The authority origin is the first record made under an established identity (a genesis). Records written before an identity exists (for example, during a pre-boot phase) are causally ordered but carry no authority. Implementations SHOULD keep the two origins distinct and MUST NOT derive authority from records that precede the authority origin.

Relation to Lamport and Related Work This document is directly aligned with Lamport's logical-time model and the later vector-clock tradition of Fidge and Mattern . TIBET extends that tradition by binding logical ordering to cryptographic identity, append-only lineage, and explicit fork, merge, and tombstone semantics. A scalar Lamport counter is consistent with causality but cannot distinguish "A happened before B" from "A and B were concurrent". Where that distinction matters, this revision adds an optional vector layer (). This document does not claim novelty in either the logical-time or the vector-clock model, only in their identity-bound and signed composition.

Forward-Only Property The defining property of TIBET causal time is not merely that events are ordered, but that valid evolution occurs only by moving forward. Restore MUST become fork rather than rewind, revocation MUST become a successor event rather than a mutation, correction MUST become an amendment rather than an overwrite, and cancellation MUST become a compensating action rather than an erasure. A revocation or tombstone closes a branch. Continuing after a revocation is a fork with its own record; it is never an "unrevoke" of the closed branch.

Event Classes

• ordinary application or system action events
• fork or snapshot-reference events
• merge or transfer-pair events
• tombstone events
• triage or quarantine events
• external time-anchor events
• drift-record events
• reseed events ()
• scar records marking a pruned chain head ()
• repair records for an interrupted append ()

These classes are not all necessarily already standardized in TIBET registries, but they align structurally with the substrate described here.

External Time Anchors External time anchors provide auxiliary alignment between local causal order and broader time-bearing reference systems such as NTP, timestamping authorities defined by , Roughtime, GNSS, PTP, public ledger timestamps, or observed environmental anchors. External time anchors MAY improve alignment. They MUST NOT redefine already established causal order.

Drift and Alignment Clock drift is expected in real systems, especially edge systems and off-grid nodes. TIBET treats drift as a recordable condition, not as a collapse of ordering truth. Implementations SHOULD be able to represent locally observed time, externally anchored time, offset between them, uncertainty window, and validity scope of the observation. Where a record carries wall-clock information alongside causal information, the wall-clock part SHOULD be labelled as supporting evidence (for example, with its source, uncertainty, and observed drift), so that no reader mistakes it for the ordering basis.

Processing Model

Local Event When a local event is committed, the implementation increments or derives a monotonic generation value, binds the event to prior causal state, signs the event, and appends it according to .

Incoming Causal Reference When a remote or transferred event enters local reasoning, the implementation evaluates causal relation and derives successor progression in Lamport style as max(local generation, remote generation) plus one for any new local successor event that depends on both. When the vector layer is in use, the incoming event's vector is additionally merged as described in .

Recovery Recovery produces successor state by fork, compensation, revocation, reseed, or new forward-causal action. It MUST NOT pretend to restore the system to an earlier pre-committed causal state. Whether a participant may resume or must reseed is decided as in .

Time Anchoring When external time is sampled, the implementation MAY write an external-anchor event and MAY write drift information, but MUST NOT use the anchor to invalidate already committed causal order.

Append Discipline In a hash-linked chain, each record names its predecessor by a digest of the predecessor's serialized form. If two writers read the same chain head and then both append, both new records name the same predecessor and the chain forks without any participant intending it. Appending with an operating-system "append" mode does not prevent this, because the conflict arises when the head is read, before the write. An implementation SHOULD serialize the sequence "read the head, compute the predecessor reference, append, make durable" as one critical section per chain. If such serialization is unavailable on the storage in use, the implementation SHOULD still write the record, and the record itself MUST state that the concurrency guarantee was absent. Refusing to write would discard evidence; writing without the statement would let a reader mistake an unintended fork for tampering, or tampering for a race. Availability of serialization SHOULD be tested on the target storage rather than assumed, because some storage accepts a lock request without enforcing it. If a chain does not end on a record boundary (an earlier write was interrupted), an implementation MUST NOT append directly after the fragment. Repairing the tail is a separate act that produces its own record naming the fragment that was set aside. A transition that is only valid under a precondition on the chain (for example, "no newer revocation exists") SHOULD evaluate that precondition against the verified chain inside the same critical section in which the transition is appended. Where serialization is unavailable, such a conditional transition SHOULD be refused rather than written with an absent-guarantee marker, because its meaning depends on its position.

Pruning and Scars A chain MAY be pruned (older records removed), for example for storage reasons. Without further information, a reader that finds the first surviving record pointing at a predecessor that is absent cannot tell pruning from corruption. A pruning implementation SHOULD therefore write a scar record at the new head of the chain. The scar declares the full digest of the last removed record. A verifier treats the cut as declared if, and only if, the scar's declared value equals the predecessor reference carried by the first surviving record. The scar MUST be at the head, not appended at the end, so that a verifier walking forward meets the declaration before it meets the missing link. A scar makes a cut visible; it does not authorize it. Whoever can rewrite the chain can also write a scar; protection against that requires an anchor outside the chain.

Vector Observation Across Lanes The scalar successor rule of yields an order consistent with causality, but when several lanes operate independently (for example, during a network partition) it cannot express that two events were concurrent. This section defines an OPTIONAL vector layer for that purpose. A Causal TimeVector record carries at least: a version identifier, the lane identifier of the event, an event identifier, the lane's own counter value, the vector (a map from lane identifier to counter value), and the identifier of the parent event, if any. It MAY carry wall-clock observation and clock evidence as supporting data. The operations are:

genesis:

The first event on a lane has counter 0 and a vector that contains only that lane, at 0.

tick:

A new local event increments the lane's own entry by one and names the previous local event as its parent.

observe:

On receiving a remote vector, the observer takes the element-wise maximum of its own and the remote vector, then increments its own lane's entry by one, producing a new local event.

compare:

Vector A is "before" B if every entry of A is less than or equal to the corresponding entry of B and at least one is strictly less; "after" is the converse; "same" if all entries are equal; otherwise "concurrent".

In comparison, a lane that is absent from a vector MUST be treated as lower than any present value, including a genesis value of 0. Treating an absent lane as 0 would make a vector that has seen a lane's genesis indistinguishable from one that has never seen the lane. The lane's own counter in a vector record is not the same quantity as the scalar generation of : the former advances by one per event on that lane, the latter is max(local, remote) plus one across lanes. An implementation that carries both MUST NOT use one in place of the other. The vector is causal evidence. It is not authority: signatures and identity binding remain the basis for accepting an event. "Concurrent" is not an error; it means that neither side had yet observed the other. An implementation MAY use the vector to refuse an event that claims to act on behalf of a prior consented event but whose vector does not dominate that event's vector, or whose claimed parent is unknown, or which has no parent and is not itself a consented root. Such refusals are statements that the event is causally impossible as presented, not that it is malicious.

Classification of Time-Bounded Checks A "TTL", "expiry", or "timeout" is not one kind of thing. Before a time-bounded check is introduced or kept, an implementation SHOULD classify it by what it measures:

Physical-world window:

The question is about the physical world, for example "did a person present a credential within the last ten minutes". Elapsed wall-clock time is the correct measure, and drift considerations () apply.

Ledger-state window:

The question is about the state of a chain, for example "is this candidate still the latest proposal". Wall-clock time is the wrong measure. Such checks SHOULD be expressed in causal terms (sequence, generation, vector relation, or the existence of a newer record under the same serialization).

Handoff window:

A window that exists so that, when it closes, a different path opens (for example, offering a ceremony on a different enrolled device). A handoff record MUST name its destination. A window that names no destination is an expiry, not a handoff. A handoff record SHOULD also state what stays the same across the move (for example, the subject and the operator), and the destination MUST establish its own evidence afresh rather than inherit it from the path that did not answer.

Open question:

A request awaiting a decision is not a window. It does not age into an answer. What triggers further action is that the channel on which it was asked is silent, which is a measurement about the channel, not about elapsed time.

A window that is too short can change the outcome rather than only the timing: if a slower but chosen path cannot complete within it, the system may fall back to a different path that the principal did not choose. Window lengths for physical-world windows SHOULD be chosen against the slowest path they are meant to admit. Ageing MAY raise attention. Ageing MUST NOT by itself change a verdict: an undecided item (a hold) may become stale, but it does not become a denial by being old. An item whose age cannot be determined MUST NOT be treated as fresh. "Expired" can mean evidence freshness, request freshness, display priority, or execution eligibility. Implementations SHOULD name which of these a given expiry affects. When a decision arrives after the window it answers has closed, the implementation SHOULD refuse it by name and record that nothing was decided, rather than record the decision. Any claim that something changed is a claim about an interval. Records that assert change or absence of change SHOULD name the interval over which they measured, and SHOULD state when the interval could not be measured, instead of reporting "no change".

Freshness and Replay Without Clock Agreement Replay protection and freshness are different properties and SHOULD NOT share one mechanism. For a single-use artifact such as an offer or invitation, replay protection SHOULD be provided by a nonce that the accepting side consumes atomically on first acceptance and refuses thereafter. A wall-clock validity window MAY be kept as a liveness bound, but once replay is handled by nonce consumption the window can be generous, and its expiry is then a statement about liveness only. Where the vector layer is used, the offering side SHOULD include its vector inside the signed offer, so that it cannot be altered without invalidating the signature. The accepting side derives its own observation by merging that vector () and MUST refuse if the offer's vector is not "before" or "same" relative to the resulting observation. A recommended order of checks at acceptance is: signature, liveness bound (if any), causal descent (if a vector is present), nonce consumption, then construction of the accepted state. Placing nonce consumption after the checks that can refuse avoids burning a nonce on an artifact that is refused for another reason. An implementation MUST NOT gate identity on the agreement of two clocks it does not both control. Where an artifact is created on a clock the verifier does not control (for example, a browser of an unknown party), its self-asserted issue and expiry times SHOULD only be checked against a broad plausibility envelope; freshness comes from a single-use element issued on the verifier's own clock. A key or binding that has been tombstoned MUST be refused regardless of signature validity or freshness. A key that has been re-anchored to a successor proves history and MUST NOT authorize new action.

Forks, Breaks, and Reseeds Revision -02 used "fork" broadly. In practice several outcomes need to be distinguished, because they call for different responses.

Observed and Admitted Forks An admitted fork is a declared transition with a name from a fixed set and the proof terms that the name requires. One such set, used by the reference implementation, is: Canonical Transitions and Required Proof Terms

Transition	Required proof	If proof is missing
new	genesis	nothing was created
restore	verified identity bundle	new actor, not restore
reseed	successor key	successor, not continuity
retire	tombstone	not retired
replace	tombstone and successor	retired but pointing nowhere, or not retired

A claimed transition that lacks its proof SHOULD be reclassified as the weaker outcome that its evidence does support, rather than simply refused. Transition names MUST be compared exactly; a verifier that normalizes case or whitespace lets the recorded bytes and the verdict diverge. An observed fork, including one caused by concurrent writers (), is not admitted. A validator that assesses whether a present state has a valid path from origin SHOULD start from "unproven" and accept only continuations that conserve the preceding proof and admitted forks.

Break Classes When linkage verification fails, the cause determines the remedy. A verifier SHOULD classify each break rather than stop at the first. A useful classification is:

race fork:

more than one record claims the same predecessor.

bad predecessor:

the predecessor reference names a record that exists but is not the physical predecessor.

unknown predecessor:

the predecessor reference names no record in the chain.

mid-stream genesis:

a genesis predecessor value appears in the middle of a chain where no declared rotation or scar explains it.

malformed:

a record that cannot be parsed.

Counts reported by such a classifier SHOULD state whether they count broken links or incidents, since one fork with three children produces two broken links. A chain whose linkage is intact can still be incomplete: its last record may have started an operation that never reached a terminal record. Such an "open tail" is a distinct finding from a break.

Resume and Reseed A participant MAY resume a previous run under the same runtime identity only if it can prove that the previous run closed, for example through a durable shutdown record written as part of an orderly stop. If no such proof exists but there is evidence that a previous run took place (as after a crash, forced termination, or power loss), the participant MUST NOT silently resume. It SHOULD write a reseed record that states the break, retire the previous runtime identity, and continue under a successor. Long-lived identity (for example, an enrolled account) can persist across a reseed; the runtime binding does not. The absence of a closing record is itself information: for an involuntary stop it is expected; for a voluntary stop it is suspicious. Implementations SHOULD NOT fill in a missing closing record after the fact.

Key Loss and Unilateral Forks A participant whose key changes is not "lagging"; under the same name there is now a different signer. A verifier SHOULD report a differing key as a fork, and SHOULD treat it as more serious than an absent key, since a differing key continues to produce valid-looking signatures. A lost key cannot sign its own revocation. When a bilateral relation can no longer be closed bilaterally because one party's key is gone, the remaining party MAY record a unilateral fork. That record MUST identify itself as unilateral, MUST NOT present itself as a bilateral supersession, and MUST NOT alter the original relation record, which remains valid as history. Any successor relation is a separate, fresh agreement.

Order Is Not Descent A predecessor reference proves write order: this record was written after that one. It does not prove that this record was made because of, or in response to, that one. Presenting write order as descent obscures rather than establishes causality. Where descent matters (for example, "this retry answers that refusal"), the record SHOULD name its parent explicitly and record the subject that both concern, so that a reader can check whether parent and child are about the same subject. The result of that comparison SHOULD be one of "same", "changed", or "unknown", and an unreadable subject MUST yield "unknown", never "same".

Example Flows

Snapshot and Resume In the TIBET model, a snapshot references a chain position and resume becomes a fork from that position. The new line advances with its own forward-only history.

Transfer Pair In TAT or TIBET Drop, transfer_out records sender-side causal commitment, transfer_in records receiver-side causal acknowledgement, and successor generation derives from the maximum of local and sender generation plus one.

Relation Handshake with Causal Descent Two participants form a relation in three steps.

1. The offering side creates an offer containing its identity, its public key, a fresh lane identifier, a single-use nonce, a generous liveness bound, and a genesis vector for its own lane, and signs the whole offer.
2. The accepting side verifies the signature, merges the offer's vector into a new observation of its own lane (producing, for example, {offerer: 0, accepter: 1}), checks that the offer's vector is "before" that observation, consumes the nonce under a lock, and signs its half of the relation.
3. The offering side completes the two-party signature.

If the offer is carried slowly, nothing in this flow fails as long as the liveness bound is not exceeded; replay of the same offer fails at nonce consumption regardless of clock state.

Semantic Surface Mismatch If routing surface and sealed manifest differ (see ), content may still be valid, but the causal substrate should treat the situation as anomaly and create a triage fork or isolation path.

Filename-Surface Contract The semantic surface of a sealed continuity envelope is carried in two layers: the filename layer, observable without unpacking, and the manifest layer, authoritative only after Ed25519 signature verification. These two layers MAY agree, partially agree, or conflict. A verifying implementation produces one of four surface_status verdicts: MATCH (all surface_* fields agree), PARTIAL (some agree, others absent or differ), MISMATCH (both layers present and at least one field conflicts -- potential rename attack), or NONE (neither layer has surface_* fields -- legacy bundle). Filename construction is the operator's responsibility. The packing library SHOULD provide a helper that derives a canonical filename from the manifest's surface_* fields, so MATCH is the default for freshly packed envelopes. However, this specification does not require it. PARTIAL is therefore a valid and expected verdict for envelopes that an operator has consciously renamed for human navigation (e.g. "vergadering-dinsdag.pdf"). It is NOT a defect; it is a recorded statement that the human-applied name diverges from the canonical-from-manifest name. Implementations MUST be able to reconstruct the canonical filename from the manifest alone, so that any peer with the bundle can recover the original SSM-derived name after operator rename, record both the human name and the canonical name in audit so that rename events become explicit instead of silent, and detect MISMATCH as a candidate rename-attack signal distinct from PARTIAL (operator-renamed) and MATCH (no rename or aligned rename). Audit records emitted by a verifying implementation SHOULD carry the field name "canonical_name" alongside the on-disk "name" field, with a boolean "renamed_by_operator" derived from their inequality. This naming convention is referred to as the canonical_name field throughout this specification; the helper function that computes it from a manifest is named canonical_filename(). This contract anchors causality to the visible surface: a peer seeing only the filename has a hint; a peer seeing the sealed content has the truth; the audit chain records the relationship between the two.

Position in the Four-W Vault Family The Causal Time Substrate defined in this document does not stand alone. It underpins a four-part family of credential and continuity primitives, agreed informally by the implementation team on 12 May 2026 and elaborated in companion specifications.

Overview The four-W family arose from the recurring observation that secret-handling systems consistently fail to answer four distinct questions: when may a sealed result be disclosed, how is the underlying secret stored and tracked, why is a specific bounded act permitted, and where is the act safely performed. Each W maps to its own primitive in the family. The family members are: tibet-vault, the WHEN primitive, which is a temporal trigger that releases a sealed payload on a date or upon a dead-man-switch condition; tibet-keychain, the WHERE/HOW primitive, which records custody and timeline for where a secret currently lives, who touched it, when it was rotated or exposed, and how it moved between owner, custodian, and active operator; tibet-sam, the WHY primitive, which is a Sealed Authentication Module that permits a single bounded act without releasing the underlying secret and is specified as an extension to the Semantic Surface Manifest (, Section 13); and tibet-gateway, the WHERE-EXEC primitive, which is the execution boundary runtime in which a SAM envelope is unsealed, validated, executed against an upstream credential, and the ephemeral session destroyed. Note that the WHEN primitive's date trigger is a physical-world window in the sense of : it concerns calendar time, and wall-clock evidence is the appropriate basis for it.

Causal relation between the family members The Causal Time Substrate provides the verifiable ordering and identity-bound action chain that lets the four family members interoperate. Every meaningful event in the family produces an entry in a TIBET audit chain: secret creation in tibet-keychain, SAM materialisation linking back to the issuing keychain action, gateway execution linking to the materialised SAM, and disclosure events in tibet-vault when applicable. The forward-only property defined in of this document ensures that none of these events can be retroactively altered: a credential-handling system built on this substrate cannot pretend that a secret was rotated earlier than it was, nor that an authorisation was granted before the prior revocation event.

Regulatory fit The four-W family answers four distinct regulatory questions that traditional secret-store products do not natively address: who has access (custody timeline, WHERE/HOW primitive); why was a specific use authorised (intent and scope record, WHY primitive); where did the use occur (execution boundary record, WHERE-EXEC primitive); and when may the result be disclosed (temporal trigger, WHEN primitive). Implementations of any subset of these primitives SHOULD record their events into a shared Causal Time Substrate chain so that audit walkers (such as tibet-cbom) can reconstruct the full sequence after the fact.

Implementation Status [RFC Editor: please remove this section and the reference to RFC 7942 before publication.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

AInternet-in-a-Box (Humotica)

Organization:

Humotica.

Description:

A self-contained node runtime in which each runtime identity writes hash-linked TIBET records to a local chain, and pairs of nodes form signed relations. It is the reference implementation from which the changes in this revision were derived.

Maturity:

Development. Operated on a small number of test machines by the author's team. Not a production deployment.

Coverage:

• Vector layer (): genesis, tick, observe, and compare as specified, with absent lanes compared as lower than genesis. A guard refuses events with no parent that are not consented roots, events whose parent is unknown, events that do not dominate their parent, and events with no path to a consented root. The vector module uses only a standard library and is carried inside the node so that its availability does not depend on package installation; where it is absent, an inline encoding of the same shape is used and records state which engine produced them.
• Relation handshake (): the offer carries a signed genesis vector; acceptance merges it, refuses unless the offer is "before" or "same", and consumes the nonce under a lock. The wall-clock bound is enforced as a hard check only for offers that carry no vector, and its default is 24 hours.
• Append discipline (): a single writer serializes read-head, append, and durable sync under an advisory file lock; tests whether the lock works on the target file system; marks records written without it; refuses to append after an unterminated tail and treats repair as a separate recorded act; and offers a conditional append that evaluates its precondition against the verified chain under the same lock and refuses if no lock is available.
• Break classes () and open-tail detection, implemented by chain readers.
• Scars (), in the chain of a release preflight tool, together with explicit parent and subject comparison ().
• Canonical transitions with reclassification and an ancestry check that starts from "unproven" ().
• Resume versus reseed () at node start, based on a durable shutdown record.
• Unilateral fork on key loss ().
• Caller freshness (): tombstone checked before freshness, refusal of re-anchored keys for new action, and refusal of an already-used single-use reference.
• Handoff records () that are refused unless the previous step was measured as having fallen through, and whose destination is limited to carriers the principal enrolled.

Known gaps:

• One ledger-state check (the validity of a pre-genesis candidate) is still bounded by wall-clock time. It has been classified as a ledger-state window under and is recorded as open work.
• Records asserting change do not yet carry named measurement intervals in general; the interval guidance in is design guidance derived from a defect found in practice, not an implemented field set.
• The vector layer is applied to relation handshakes; it is not yet applied to every authority-changing operation. Verification of a completed two-party relation record still applies that record's wall-clock bound, with the vector attached as evidence rather than consulted for the verdict.
• Drift records and external time anchors (, ) have no standardized token shape in the implementation; a vector record carries only a basic clock-evidence field.

Experience:

On one test node (measured 28 August 2026), a chain of 903,436 records written by several unserialized writers showed 223 broken links, all of the race-fork class, with no adversary present. This is the observation behind . Separately, a handshake offer between two nodes with synchronized clocks was rejected as expired because it was carried slowly; investigation showed that the wall-clock bound was also the only replay protection, which is the observation behind .

Licensing:

AGPL-3.0-or-later for the node implementation; see for the vector component.

Contact:

Jasper van de Meent, info@humotica.com.

tibet-timevector A stand-alone package implementing the Causal TimeVector record (version identifier "tibet.causal-timevector.v0.1") and the guard described above, published under the MIT license. The node implementation in carries a pinned copy of it. Contact as above.

Security Considerations This document assumes an attacker may replay previously valid artifacts, re-inject old state through backup or restore channels, manipulate wall-clock sources or exploit clock drift, rename or relabel artifacts outside sealed causal truth, or attempt destructive rollback semantics through operational tooling. The forward-only causal model is specifically designed to reduce replay-after-restore, replay-after-revoke, backup injection, clock-spoofing ambiguity, drift concealment, and destructive rollback. The key invariant is that security-sensitive reversibility MUST be implemented as forward causal compensation, not as history rewrite. Additional considerations identified in this revision:

• Unintended forks. A chain that can fork through concurrent writing cannot distinguish tampering from a race. The append discipline of and the explicit absent-guarantee marker exist so that tamper evidence keeps its meaning.
• Coupled mechanisms. If a wall-clock window is the only replay defense, relaxing the window to fix an availability problem silently removes replay protection. separates the two.
• Untrusted clocks. Accepting identity based on a party's self-asserted timestamps makes the verifier depend on a clock it does not control.
• Laundering by age. If an undecided item turns into a refusal (or an approval) by ageing, a decision is made that nobody took. The rules in prevent this.
• Laundering by order. Presenting write order as causal descent can make a step appear to answer a condition it never examined ().
• Scars and repair records make cuts and repairs visible; they do not prove that the chain was not rewritten by a party with write access. An external anchor is needed for that.
• A differing key under an unchanged name produces valid signatures and passes checks that look only at signature validity; it needs to be detected as a fork ().
• The vector layer reports causal relations among the events an implementation has seen. It cannot detect an event that was withheld from it, and a participant can omit lanes from the vector it presents. Its refusals are therefore conservative signals, not proofs of good behaviour when they pass.

Interoperability Considerations This substrate is designed to compose with JIS identity, UPIP continuity, TAT transfer flow, TBZ or ICC container semantics, and semantic routing surfaces. Interoperability therefore depends less on UTC agreement and more on shared causal encoding, verifiable linkage, explicit anchor semantics, and clear distinction between order and alignment. Linkage digests are computed over serialized records, so every writer and verifier of a chain MUST use the same serialization, including key ordering, separators, and whether the record terminator is part of the digested bytes. A writer that follows the convention almost exactly produces chains that every verifier reports as broken. Tools that merge several chains into one view for display MAY order the merged view by wall-clock time, but verification MUST proceed per chain along its linkage, and display order MUST NOT be presented as causal order.

Relationship to the Broader Humotica Stack Within the broader architecture, Turing answers what computes, Lamport-style causal time answers when in event order, JIS answers who is permitted, and semantic framing layers answer within what semantic frame a process is interpreted. TIBET occupies the causal-time substrate role while composing with the other axes.

Future Work

• standardized external time-anchor token shape
• standardized drift-record token shape
• explicit uncertainty handling
• standardized encoding of the Causal TimeVector record and of its signature coverage
• a standardized representation of named measurement intervals for change claims
• causal freshness proofs for intermittently connected devices
• zero-disclosure continuity proofs over long time horizons
• alignment with RFC 3161, Roughtime, and public-ledger anchoring profiles

Questions for Future Revisions The following topics are non-blocking for the present version and are recorded here to guide later discussion and interoperability work.

• whether drift should be standardized as its own token type or as a subclass of time-anchor event
• whether external anchor trust levels should be formally graded
• whether causal freshness should be defined as a reusable verification primitive ( is a partial answer for single-use artifacts)
• how uncertainty and stale-anchor conditions should be surfaced in operator tooling
• whether some domains should require time-anchor presence while others permit purely local causal mode
• whether the set of canonical transitions in should be a registry
• whether vector records should be bounded in size (for example, by pruning lanes no longer active) and how such pruning interacts with the comparison rule for absent lanes

IANA Considerations This document has no IANA actions in the present version. Future revisions may define registries for external time-anchor token shapes, drift-record token shapes, causal freshness proof types, or canonical transition names, likely under Expert Review policy as described in .

References Normative References Informative References

Changes from -02

• Header: docName and seriesInfo updated to -03; date set to 29 October 2026; keyword "vector clocks" added. Author, category, IPR, and submission type unchanged.
• Abstract: one paragraph added summarizing the additions of this revision.
• : the in-body section formerly titled "Status of This Memo" (which duplicated the name of the boilerplate section) is retitled "Introduction"; hard-coded section numbers replaced by cross-references; paragraph added naming the four gaps addressed; claim of an "already deployed" property softened to "already exhibit".
• : new; BCP 14 key words adopted. Key invariants in , , , , and are now expressed with BCP 14 key words. The text carried over unchanged from -01 in and already used capitalized key words.
• : paragraph added on a validity window silently serving as replay protection.
• : added Lane, Causal TimeVector, Admitted Fork, Observed Fork, Break, Reseed, Scar, and Window.
• : goal added that each time-bounded check states what it measures.
• : paragraph added distinguishing the causal origin from the authority origin of a chain.
• : Fidge and Mattern now cited as references; paragraph added on the limits of a scalar counter and on novelty.
• : BCP 14 key words; paragraph added that revocation closes a branch and continuation is a fork.
• : reseed, scar, and repair records added.
• : paragraph added on labelling wall-clock data as supporting evidence.
• : Recovery now includes reseed; Incoming Causal Reference points to the vector layer; new subsections and .
• : new section defining the optional vector layer, including the rule for absent lanes and the distinction between the lane counter and the scalar generation.
• : new section classifying time-bounded checks.
• : new section separating replay protection from freshness.
• : new section with subsections on observed and admitted forks, break classes, resume and reseed, key loss, and order versus descent.
• : new example ; references to the TAT and SSM drafts added; the -02 pointer to "Section 9.4 and Section 12" of an earlier SSM revision dropped in favour of a document reference.
• : "Section 7" replaced by a cross-reference; SSM reference made a formal reference; note added that the WHEN primitive's date trigger is a physical-world window. Otherwise unchanged.
• : new, per RFC 7942.
• : list of additional considerations added.
• : paragraphs added on shared serialization for linkage digests and on display order versus verification order.
• : items added for TimeVector encoding and measurement intervals.
• : stale reference to "-00" removed; two questions added; one annotated as partly answered.
• : canonical transition names listed as a possible future registry.
• References: split into normative and informative; RFC 2119, RFC 8174, RFC 7942, Fidge 1988, Mattern 1988, and the SSM and TAT drafts added; RFC 3161 author list completed; DOIs added.
• Acknowledgements: editorial and review assistance by Root AI and Codex acknowledged.

Acknowledgements The author thanks the Humotica team for editorial assistance, internal peer review, and operational tooling that made this substrate framing concrete rather than theoretical. In particular, Root AI (Claude, Anthropic) and Codex contributed analysis, implementation review, and editorial assistance; several of the distinctions in this revision were first named in their review work. The substrate framing also builds on the logical-time tradition established by and the vector-clock work of and . The author also thanks Richard Barron of Red Specter Security Research for adversarial validation that helped sharpen the forward-only recovery property under realistic attack conditions.