TIMEVERSE
Syncing T2°...
Timeverse
Docs

HS-Intent v1.0

Intent Declaration Extension for Phase-Window Actions (Signable “What is being attempted?” Context for Audit and Policy)

Status: Official Spec (v1.0)
DOI: 10.5281/zenodo.18216336

Abstract

Phase-window coordination stacks (Conventions/Q-Address/TAQA) execute actions by cycle-anchored, wrap-safe phase windows verified in fixed-point ticks. In real deployments, correct timing is not sufficient: actions also require explicit policy context about what is being attempted and at what declared risk tier. This document specifies HS-Intent v1.0 as a minimal, protocol-friendly intent declaration extension: a signable, deterministic object that classifies an intended action (intent class), its kind (execute/reserve/cancel/observe), and a risk tier for audit and policy gating. HS-Intent does not redefine execution semantics, does not define cryptographic primitives, and does not define authorization by itself. Integrity and anti-replay are provided by the external Timeverse Security Profile. HS-Intent is designed to compose with HS-Bloch (quality gating) and HS-bit (consumption reporting) under higher-level policy profiles.

Normative Dependencies

1. Scope and design intent

HS-Intent is an extension, not an execution spec: HS-Intent adds intent declaration fields as signed context. It MUST NOT redefine canonical phase/tick execution semantics, which remain defined by Conventions/Q-Address/TAQA.

HS-Intent is not authorization: HS-Intent does not grant privileges by itself. Authentication, integrity, authorization, and anti-replay are provided by the Timeverse Security Profile and deployment policy. HS-Intent is policy input, not a security primitive.

Deterministic, signable fields: HS-Intent fields MUST be deterministic and signable (no floats required). Verifiers MUST treat HS-Intent as public context (not secrets).

2. HS-Intent concept

Motivation: In distributed and safety-sensitive systems, it is insufficient to know that an action is scheduled in the correct window. Operators and verifiers also need an auditable declaration of what is being attempted (action class), what kind of operation it is (execute vs reserve vs cancel vs observe), and a declared risk tier to drive policy gating.

HS-Intent role: HS-Intent answers the question: What is being attempted (and at what declared risk tier)? It is intended to be evaluated alongside (i) tick-canonical execution context and (ii) security verification.

3. Data model

Schema identifier: HS-Intent v1.0 objects MUST declare: hsintent_schema_id = TV-HSINTENT-2026-01.

3.1 Enumerations

Intent kind:

HS-Intent v1.0 defines intent_kind as one of:
  • "EXECUTE": request execution of an action,
  • "RESERVE": reserve a future window/action (commitment intent),
  • "CANCEL": cancel a previously reserved or planned action,
  • "OBSERVE": declare observation/logging intent (non-actuating).

3.2 Core object

HSIntentObject:

A conforming HS-Intent v1.0 object is:
  • hsintent_schema_id (MUST equal TV-HSINTENT-2026-01),
  • intent_class_id (MUST): a string identifier for the action class (deployment-defined namespace),
  • intent_kind (MUST): one of the v1.0 kinds,
  • risk_tier_u8 (MUST): an unsigned 8-bit integer risk tier,
  • purpose (OPTIONAL): short human-readable purpose string for audit/UI,
  • ttl_cycles_u32 (OPTIONAL): unsigned integer time-to-live in cycles for this intent (policy horizon).

Risk tier encoding:

risk_tier_u8 MUST be an integer in [0, 255]. Deployments SHOULD use a small set of tiers, e.g.:
  • 0: informational / observe-only
  • 1: low-risk actuation
  • 2: medium-risk actuation
  • 3: high-risk / safety-critical actuation
This tier is a declared policy input; it does not replace security authorization.

Intent class identifier: intent_class_id SHOULD be stable, versioned, and namespaced (e.g. "TV-INTENT-ENTANGLE-ATTEMPT-2026-01"). Implementations MUST treat it as an opaque identifier.

4. Placement, signing, and interoperability

Signed placement for enforcement: If HS-Intent is used for enforcement (policy gating), the HS-Intent object MUST be carried in a signed context (e.g. under ext_signed.hs_intent or an equivalent signed envelope) governed by the active security_profile_id. Unsigned HS-Intent objects MUST NOT be used for security-critical enforcement.

5. Deterministic validation and TTL guidance

Well-formedness (HS-Intent):

An HS-Intent object is well-formed if and only if:
  • hsintent_schema_id matches TV-HSINTENT-2026-01,
  • intent_class_id is a non-empty string,
  • intent_kind is one of the v1.0 kinds,
  • risk_tier_u8 is an integer in [0, 255],
  • if present, ttl_cycles_u32 is an integer in [0, 2³² − 1].

Unknown kinds fail enforcement: If intent_kind is not recognized by the verifier, HS-Intent validation MUST fail when HS-Intent is used for enforcement.

6. Examples (informative)

Example: execution intent (signed context)

{
  "security_profile_id": "TV-SECPROFILE-2025-12",
  "ext_signed": {
    "hs_intent": {
      "hsintent_schema_id": "TV-HSINTENT-2026-01",
      "intent_class_id": "TV-INTENT-ENTANGLE-ATTEMPT-2026-01",
      "intent_kind": "EXECUTE",
      "risk_tier_u8": 2,
      "purpose": "entanglement distribution attempt A-B",
      "ttl_cycles_u32": 0
    }
  }
}

Example: reservation intent (signed context)

{
  "security_profile_id": "TV-SECPROFILE-2025-12",
  "ext_signed": {
    "hs_intent": {
      "hsintent_schema_id": "TV-HSINTENT-2026-01",
      "intent_class_id": "TV-INTENT-RESERVE-WINDOW-2026-01",
      "intent_kind": "RESERVE",
      "risk_tier_u8": 1,
      "purpose": "reserve future execution window for lab run",
      "ttl_cycles_u32": 2
    }
  }
}

7. Conformance

HS-Intent v1.0 conforming producer:

A producer is conforming if it:
  • emits HS-Intent objects with hsintent_schema_id=TV-HSINTENT-2026-01,
  • uses only the v1.0 intent_kind values,
  • encodes risk_tier_u8 as an integer in [0, 255],
  • places enforceable HS-Intent objects in signed contexts when used for enforcement.

HS-Intent v1.0 conforming verifier:

A verifier is conforming if it:
  • validates well-formedness deterministically,
  • rejects unknown intent_kind values for enforcement,
  • defers signatures, canonical encoding, and anti-replay to the Security Profile,
  • does not treat HS-Intent fields as secrets.

References