TIMEVERSE
Syncing T2°...
Timeverse
Docs

Timeverse Protocol v4.5

Core Conventions with Tiles, TSAE, and Security Profile Interface

Status: Official Spec (v4.5)
DOI: 10.5281/zenodo.XXXXXXX

Abstract

Timeverse Protocol v4.5 specifies a phase-coordinated infrastructure core for triadic Human–AI–Quantum systems, with a cybersecurity-oriented design: canonical cycle-anchored phase conventions on S¹, wrap-safe phase windows, tick-canonical execution semantics (no floating-point boundary checks), Q-Address alignment (macro window + micro slot), tile identifiers for routing/community/audit scope, and TSAE records/receipts for tamper-evident provenance. Timeverse fields are public context (not secrets). Cryptography and anti-replay policy are defined by external, versioned Security Profiles (crypto-agility, including post-quantum migration) without changing Timeverse semantics.

Normative dependencies (DOIs)

Recommended machine tags: This protocol is compatible with machine-facing schema tags used by dependent specs: qaddr_schema=TV-QADDR-2025-12 and tsae_schema=TV-TSAE-2025-12. These tags prevent silent incompatibilities and do not change human-facing semantics.

1. Scope and design intent

Operational protocol conventions: Timeverse defines interoperable protocol conventions for cyclic phase coordination and auditable logging. It does not modify physics and does not increase physical clock precision.

Triadic stack compatibility: The core is designed to support triadic stacks: Humans choose/approve windows, AI proposes/optimizes windows and policies, and hardware executes within windows. Quantum- and hardware-specific micro-timing/control hooks are handled by extension documents.

2. Time scale for computation (normative)

Autonomous arithmetic time variable:

Implementations MUST perform arithmetic using an autonomous linear/monotone time variable (seconds or fixed-point), not directly on UTC wall-clock timestamps. Human-facing UTC/RFC3339 timestamps are allowed for I/O/logging only and MUST be mapped to the arithmetic variable according to the policy bound by convention_id (see Conventions).

: This avoids leap-second ambiguity in computing cycle index and phase, and supports deployments that operate without continuous external time infrastructure.

3. Core conventions (normative via Conventions)

Canonical definitions live in Conventions: This protocol uses the canonical definitions from Conventions:

n(t) = ⌊(t − t₀)/Tcycle⌋ ∈ ℤ,

ϕ(t) = ((t − t₀)/Tcycle) mod 1 ∈ [0, 1) ≅ S¹,

including the negative-safe modulo convention, circular distance on S¹, and wrap-safe phase windows with half-width tolerance.

Earth-first defaults are informative: A deployment MAY choose Earth-first defaults (e.g. a day-length cycle), but normatively t₀ and Tcycle are defined by convention_id under Conventions. This document does not require a specific epoch or cycle period.

4. HS displays and UI projections

Derived HS displays (UI-only):

Human-facing displays (e.g. HS degrees or HS index) are derived from ϕ(t) and MUST NOT be used for verification.

5. SWT (canonical reference and UI projections)

SWT12 is canonical; projections are UI-only: SWT12 is the canonical reference for interoperability. Other SWT labels are user-facing projections and MUST NOT mutate canonical (n,ϕ) or tick semantics.

6. Phase windows and ticks (normative)

Ticks are canonical for verification: Verification/gating MUST NOT use floating-point boundary comparisons. Window membership MUST be checked using fixed-point ticks as defined by Conventions and carried by convention_id.

7. Tiles

Tiles are protocol identifiers: Tiles are protocol identifiers used for community feeds, routing domains, moderation scope, and audit scoping. They are not physical objects.

Tile schema identifier:

If tiles are used, a deployment MUST specify a tile_schema_id describing how tile identifiers are defined and parsed. If a tile mapping is used for policy enforcement, edge handling must be deterministic.

8. Q-Address alignment

Q-Address minimal view (tick-canonical):

A minimal Q-Address view compatible with window coordination is:

(qaddr_schema, convention_id, scope, cycle_index, resolution=R, phi_ticks, deltaPhi_ticks, slot).

This is a view; the full schema and canonical encoding rules are specified in the Q-Address document. Recommended schema tag: qaddr_schema=TV-QADDR-2025-12.

: Macro coordination is via (cycle_index, phi_ticks, deltaPhi_ticks). Micro timing (slot) is local and should use integer units (e.g. nanoseconds) per the Q-Address spec.

9. TSAE and anchoring interface

TSAE provides auditable anchoring: TSAE records/receipts provide tamper-evident anchoring of time-contextual events for reproducibility and governance.

TSAE record (tick-canonical, minimal):

A TSAE record includes canonical phase context using ticks:

(tsae_schema, convention_id, scope, cycle_index, resolution=R, phi_ticks, action_hash, signer_id, nonce, ext).

Recommended schema tag: tsae_schema=TV-TSAE-2025-12. ext MAY include tile identifiers and derived UI-only displays as metadata.

Canonical verification: Canonical verification MUST be based on convention_id and tick fields (cycle_index, resolution, phi_ticks), plus signature/nonces per the Security Profile. UI fields (SWT labels, HS displays) are not normative.

Anchoring minimalism: If ledger anchoring is used, store commitment hashes on-chain and keep large payloads off-chain when needed.

10. Security profiles interface

Context is not secret: Timeverse fields (phase, SWT/HS displays, tiles, Q-Address fields, TSAE fields) are public context and MUST NOT be treated as secrets.

Security profile identifier:

A security_profile_id selects cryptographic algorithms and policy rules (canonical serialization, hashing/domain separation, signature formats, anti-replay policy, key binding model).

Associated-data binding: Security profiles SHOULD bind canonical Timeverse context as associated data (AAD) for domain separation and replay resistance, e.g. (convention_id, scope, cycle_index, resolution, phi_ticks, optional tile schema/id).

11. Conclusion

Timeverse Protocol v4.5 defines a hardened cyber-facing core: canonical cycle-anchored phase semantics, wrap-safe windows with tick-canonical verification, tiles for routing/community/audit scope, Q-Address alignment for execution, and TSAE records/receipts for auditable anchoring under crypto-agile security profiles. Quantum/AI capabilities are supported as plug-in extensions that consume the same immutable core semantics.

References