TIMEVERSE
Syncing T2°...
Timeverse
Docs

HS-Carbon v1.0

Energy-Aware Extension for Tick-Canonical Phase-Window Actions (HS-E-bit and Carbon-Gated Execution)

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

Abstract

Tick-canonical phase-window stacks (Conventions/Q-Address/TAQA) specify when an action may execute under a shared cyclic phase convention, but do not by themselves incorporate energy or carbon constraints as preconditions. HS-Carbon v1.0 specifies a minimal, optional extension that makes carbon intensity a deterministic gate: an action is eligible only if it lies within the agreed tick-canonical phase window and the local carbon intensity at execution is below a threshold. HS-Carbon preserves separation of concerns: it does not redefine phase/tick semantics (Conventions), does not redefine execution (Q-Address/TAQA), does not define cryptography (Security Profile), and does not replace deterministic policy evaluation (HS-Core). For robustness in signed enforcement and audit, this specification uses fixed-point integer field encodings for energy and carbon (no floating-point fields are required for normative enforcement objects). Examples are aligned with a fixed-point reference implementation (Timeverse v4.6.1 challenge branch).

1. Scope and non-scope

Extension, not a new time model: HS-Carbon is normative only for energy-aware gating semantics. It MUST NOT redefine the canonical meanings of (t₀, Tcycle, n(t), ϕ(t)), modulo rules, wrap-safe windows, or tick encodings, which remain defined by Conventions.

Separation of responsibilities: Execution remains defined by Conventions/Q-Address/TAQA. Integrity, canonical encoding, and anti-replay remain defined by the Timeverse Security Profile. HS-Core consumes their outputs but does not replace them.

2. Normative Dependencies

Related (informative): HS-Intent v1.0 (DOI: 10.5281/zenodo.18216336) provides a signable “what is being attempted” context for audit/policy. HS-Carbon does not require HS-Intent to define its core gating semantics.

3. Energy-aware window fields (fixed-point, no-float)

Energy-aware fields (fixed-point)

HS-Carbon adds the following fixed-point integer fields to a window object (proposal / Q-Address context):

  • energy_mwh_u32 (mWh): estimated energy cost of the action, encoded as milli-watt-hour.
  • carbon_threshold_mgco2_per_kwh_u32 (mgCO₂/kWh): maximum allowed carbon intensity, encoded as milli-(gCO₂/kWh).

These fields MUST be treated as public context (not secrets).

Derived display-only real values: Implementations MAY display derived real-valued quantities for UI/logging. However, floating-point values MUST NOT be used for signed enforcement objects or boundary checks.

4. Tick-canonical membership, HS-bit, and HS-E-bit

Tick-canonical membership

Let R be ticks per cycle. Let: φ₀ := phi_ticks, Δ := deltaPhi_ticks, φ_action := phi_action_ticks.

Define d_ticks(a,b) := min{|a-b|,R-|a-b|}.

Then φ_action ∈ W ⇔ d_ticks(φ_action,φ₀) ≤ Δ.

HS-bit (unchanged)

This is an indicator function: HS-bit is 1 if d_ticks(φ_action,φ₀) ≤ Δ, and 0 otherwise.

HS-E-bit (energy-aware, fixed-point)

Let I_max_mg := carbon_threshold_mgco2_per_kwh_u32.

Then: HS-E-bit is 1 if d_ticks(φ_action,φ₀) ≤ Δ AND I_mg(φ_action) < I_max_mg, and 0 otherwise.

5. Execution gating algorithm (normative)

Prescriptive carbon gate: If HS-E-bit is 0, execution MUST NOT proceed under HS-Carbon gating. Recommended outcomes: `WAIT` when outside the phase window, `DELAY_CARBON` when in-window but carbon exceeds threshold.

hs_bit = (d_ticks(phi_action, phi_center) <= deltaPhi_ticks)

carbon_ok = (
  carbon_intensity_mgco2_per_kwh_u32(phi_action) <
  carbon_threshold_mgco2_per_kwh_u32
)

hsE_bit = hs_bit and carbon_ok

if not hs_bit:
    verdict = "WAIT"
elif not carbon_ok:
    verdict = "DELAY_CARBON"
else:
    verdict = HSCore.evaluate(...)
    execute iff verdict in {"ALLOW","DEGRADE"}

6. TSAE receipts (aligned field names)

Carbon fields in receipts: If HS-Carbon gating is active, TSAE receipts SHOULD include HS-Carbon fields for audit.

{
  "tsae_schema": "TV-TSAE-2025-12",
  "convention_id": "TV-CONV-EARTH-2026-01:DAILY;...",
  "hsE_bit": 1,
  "energy_mwh_u32": 12000,
  "carbon_intensity_mgco2_per_kwh_u32": 188600,
  "carbon_threshold_mgco2_per_kwh_u32": 260000,
  "estimated_emissions_mgco2_u64": 2263,
  "verdict": "ALLOW"
}
Emissions estimate (fixed-point)

HS-Carbon uses the following deterministic fixed-point estimate:

estimated_emissions_mgco2_u64 = floor((energy_mwh_u32 * carbon_intensity_mgco2_per_kwh_u32) / 1000000).

7. Security considerations

  • Public context: Carbon intensity and thresholds are public context fields, not secrets.
  • Authenticity: If external forecasts/certificates are used, authenticity MUST be verified under deployment trust anchors.
  • Replay: Proposals and receipts MUST be protected by nonce-based anti-replay per Security Profile.
  • Tick-canonical enforcement: Window membership MUST be enforced in ticks (no floating-point boundary checks).
  • Canonical encoding: If HS-Carbon fields are used for enforcement, they MUST be carried inside a signed canonical encoding governed by the active security_profile_id.

8. References