Technical documentation

GAL-2™ Node, Time Contract, and Fractal Time Architecture

GAL-2™ is an application-facing time-governance platform born from Fractal Time research. The Protected Core creates the governed GAL-2 Time trajectory, the GAL-2 API delivers it, GAL-2 Node makes it locally consumable, and the Time Contract gives enrolled applications an explicit decision boundary before time becomes committed state.

Product surface

GAL-2 Node + Time Contract

GAL-2 Node runs locally beside the application and exposes GAL-2 Time through the Time Contract, SHM, and SDK Provider surfaces. Enrolled software evaluates safe_to_consume, mode, reason, validity, uncertainty, sequence, and lineage before protected operations consume time.

Current release

GAL-2 Node v1.0.0-rc10

Current signed limited release for Linux ARM64 with Time Contract 1.2.0-contract-rc.4. A native macOS Apple Silicon GAL-2 Node is the next planned platform release.

Available now: Linux ARM64 Coming next: macOS Apple Silicon
Claim boundary

Not another clock

GAL-2 complements UTC, GNSS, PTP, NTP, chrony, atomic clocks, grandmasters, cloud timing, operating-system clocks, and timing receivers. It does not discipline the host clock. GAL-2 adds governance where time becomes application state.

Start here: an active paid GAL-2 API key is required for GAL-2 Node to receive GAL-2 Time and enter LIVE operation. Use the GAL-2 API Quickstart to obtain and verify API access, then install the current GAL-2 Node release and verify the local http://127.0.0.1:9095/contract surface.

Current public Node release: GAL-2 Node v1.0.0-rc10 · Linux ARM64 . Earlier RC5.x Time Contract packages remain part of the historical public validation lineage, but are not the current GAL-2 Node release.

Decision basis

What is safe_to_consume based on?

The GAL-2 Time Contract does not ask an application to blindly trust a timestamp. It exposes an explicit policy-derived consumption decision based on observable Node state, continuity state, freshness, validity, uncertainty, and declared policy boundaries before GAL-2 Time becomes committed application state.

safe_to_consume is the authoritative application-facing consumption decision. The mode field describes the current continuity state and should not be interpreted by itself as the sole authority for whether an application may consume GAL-2 Time.

Current default policy values are declared configuration, not universal physical constants. The standard profile includes a 6-hour soft holdover boundary, a 72-hour hard holdover boundary, and a standard 30-second upstream API polling interval. Deployments should interpret contract output together with the declared policy profile rather than treating these defaults as metrology guarantees.

Observable state

What the Node can observe

GAL-2 Node evaluates runtime conditions including upstream GAL-2 freshness, last-good synchronization state, cache age, upstream API latency, current continuity mode, validity window, holdover age, uncertainty, recovery state, monotonic publication state, and source lineage.

Declared policy

What continuation may justify

The decision is constrained by declared policy including LIVE validity, holdover soft and hard limits, freshness and latency boundaries, uncertainty growth, recovery guards, continuity rules, policy version, and active policy profile.

Contract output

What the application receives

Applications receive gal2_time, safe_to_consume, mode, reason, valid_until, uncertainty_ms, holdover_age_sec, monotonic_sequence, and source_lineage instead of a raw timestamp alone.

Protected Core + GAL-2 API Reference inputs feed the protected governance system. The Protected Core creates GAL-2 Time and the GAL-2 API delivers that governed trajectory to an entitled Node.
→
GAL-2 Node Local delivery, freshness, bounded holdover, uncertainty, continuity, recovery, publication, SHM, and Provider behavior.
→
Time Contract decision The enrolled application receives GAL-2 Time together with an explicit governed decision to consume, continue under policy, recover, or refuse before state is committed.
State
Observable condition
safe_to_consume resolution
LIVE
Fresh GAL-2 synchronization is available, the contract remains inside declared freshness and validity boundaries, and the Node can justify the current governed output.
true while the Time Contract remains valid and current policy permits consumption.
WARMING
The Node is starting or has not yet established enough valid GAL-2 state to justify application consumption.
false. The enrolled GAL-2 path should wait until the Node publishes a valid consumable Time Contract.
HOLDOVER
Fresh GAL-2 API synchronization is temporarily unavailable, but the Node has a valid last-good GAL-2 state and remains inside declared holdover, validity, uncertainty, and continuity limits.
may remain true only while declared policy permits it. If the hard safety boundary is exhausted, the protected path becomes non-consumable.
REJOIN
Fresh GAL-2 synchronization has returned and reconciliation is required before the Node can safely resume the normal LIVE trajectory.
conditional. The Time Contract remains authoritative while controlled recovery is performed. When reconciliation is not required, recovery may return directly to LIVE.
Degraded conditions
Timing or upstream conditions may deteriorate before the protected application path reaches a terminal safety boundary. Degradation is reflected through contract state, reason, freshness, uncertainty, validity, and continuity metadata.
determined by the Time Contract. Applications should use safe_to_consume as the authority rather than inferring safety from a descriptive condition alone.
FAIL_CLOSED
GAL-2 can no longer justify safe consumption because the relevant freshness, trusted state, validity, holdover, uncertainty, continuity, or policy boundary has been exhausted.
false. The protected GAL-2 path refuses consumption rather than silently substituting raw host time.
Local /contract reads are loopback reads from GAL-2 Node. The field api_latency_ms, when present in the contract surface, describes upstream GAL-2 API synchronization context; it should not be confused with the latency of the application's local contract read.
source_lineage records the observable GAL-2 delivery and continuity lineage used for audit, diagnostics, and evidence. It is contract metadata, not a disclosure of the protected Fractal Time governance logic.
GAL-2 Node does not recreate the Protected Core locally during HOLDOVER. It continues from the last valid GAL-2 state under bounded policy, with explicitly growing uncertainty and declared safety limits.
The protected application path never silently substitutes raw host time when GAL-2 Time becomes unsafe or unavailable. If policy can no longer justify safe consumption, the Node exposes a non-consumable contract and the protected path fails closed.
Backend entitlement and the Time Contract answer different questions: backend entitlement decides access; the Time Contract decides safe consumption.
GAL-2 preserves its Fractal Time architecture while exposing only the operational surfaces applications need. The Protected Core and underlying governance implementation remain protected; the public application surface is GAL-2 Time plus the observable Time Contract, Node behavior, release identity, and reproducible validation evidence.
The innovation is not another clock. The innovation is the governed boundary between delivered time and committed software state.

Architecture

System architecture

GAL-2 is organized as a modular temporal-governance architecture. Reference inputs feed the protected governance system, the Protected Core creates the governed GAL-2 Time trajectory, the GAL-2 API delivers it to entitled Nodes, and GAL-2 Node makes that trajectory locally consumable by enrolled applications through the Time Contract, SHM, and SDK Provider.

Public interfaces expose governed outputs, continuity state, policy-visible metadata, and contract behavior. Protected internal modules coordinate correction, routing, pacing, coherence, alignment, and operational continuity without exposing protected implementation details.

Reference inputs + Protected Core External reference context enters the protected governance boundary. The Protected Core applies the GAL-2 Fractal Time architecture and creates the governed GAL-2 Time trajectory.
→
GAL-2 API + GAL-2 Node The API delivers GAL-2 Time to an entitled Node. The Node provides local continuity, bounded holdover, recovery, publication, SHM, and Provider access.
→
Time Contract + application The Time Contract exposes the application-facing safe-consumption decision before GAL-2 Time becomes committed application state.
CAMI

Correction and Alignment Module for Integration

Coordinates correction logic and alignment between internal time representations and external system interfaces within the protected GAL-2 architecture.

Aria

Adaptive Relay for Integrated Access

Provides adaptive routing and access coordination between GAL-2 components and connected systems within the protected architecture.

Emma

Emitter of Modular Metronomic Alignment

Manages pacing and timing-emission concepts used to support coherent and consistent GAL-2 system behavior.

CHAR

Coordinated Harmonic Alignment Relay

Handles coordination and alignment across distributed GAL-2 processes and protected internal pathways.

YO-EL5

Operational Coordination Layer

Acts as an internal control and orchestration layer responsible for coherence and operational continuity across the protected system.

Time Contract

Application-facing governance boundary

Exposes governed gal2_time together with safe_to_consume, validity, uncertainty, mode, reason, sequence, and source lineage for enrolled applications.

CAMI, Aria, Emma, CHAR, and YO-EL5 describe the protected GAL-2 architectural model; they are not separate application integration products. The current public product surfaces are the GAL-2 API and GAL-2 Node, with the Time Contract governing safe application consumption.
Detailed mathematical derivations, the protected Fractal Time formula, correction formulas, tuning logic, private keys, backend implementation, and protected governance logic are not exposed in public documentation.

Fractal Time

Theoretical foundation

GAL-2 is built on a fractal-based theoretical framework that treats time as a governed system property rather than merely a raw timestamp obtained from a hardware or operating-system clock.

The Fractal Time architecture informs how the Protected Core reasons about temporal trajectory, correction, continuity, bounded behavior, coherence, and safe downstream consumption under changing or impaired timing conditions.

Public documentation focuses on observable behavior and integration semantics. The protected formula and its internal implementation are not distributed inside GAL-2 Node. The Node does not recreate the Protected Core locally and does not apply a second Fractal Time correction engine to received GAL-2 Time. 

Conceptual flow, public-safe:

reference inputs
        │
        ▼
protected GAL-2 governance boundary
        │
        ├── Fractal Time architecture
        ├── protected correction / alignment logic
        ├── continuity and coherence authority
        └── GAL-2 Time trajectory creation
        │
        ▼
GAL-2 API
        │
        │  delivers GAL-2 Time to entitled Node
        ▼
GAL-2 Node
        │
        ├── LIVE delivery
        ├── bounded HOLDOVER
        ├── controlled recovery / REJOIN when required
        ├── uncertainty tracking
        ├── local publication
        ├── SHM
        └── SDK Provider
        │
        ▼
Time Contract
        │
        ├── gal2_time
        ├── safe_to_consume
        ├── valid_until
        ├── uncertainty_ms
        ├── holdover_age_sec
        ├── mode
        ├── reason
        ├── monotonic_sequence
        └── source_lineage
        │
        ▼
enrolled application
HOLDOVER does not mean that the Node invents a new independent time source or reruns the protected Fractal Time engine locally. It continues from the last valid GAL-2 state under bounded declared policy while uncertainty grows explicitly.
Public documentation intentionally exposes the behavior applications need to integrate and audit GAL-2 while preserving the mathematical and implementation boundary of the Protected Core.

Deployment

Installation and integration

GAL-2 is designed to run alongside existing timing infrastructure including GNSS, NTP, PTP, chrony, grandmasters, atomic references, cloud timing, operating-system clocks, and enterprise timing systems. Customers do not need to remove or replace their existing timing stack.

The current deployment pattern is to install GAL-2 Node beside the application. The Node receives GAL-2 Time through the GAL-2 API and makes it locally consumable through the Time Contract, SHM, and SDK Provider.

An active paid GAL-2 API key is required for the Node to receive GAL-2 Time and enter LIVE operation.

01 · Access

Get GAL-2 API access

Obtain an active GAL-2 API plan and configure the Node with the corresponding API credential.

02 · Node

Install GAL-2 Node

Install the signed GAL-2 Node release on the compatible host beside the application you intend to enroll.

03 · Application

Connect the application once

Consume GAL-2 locally through the intended Node surface and make the Time Contract authoritative for protected time-dependent operations. 

# Inspect the local Time Contract
curl -s http://127.0.0.1:9095/contract | python3 -m json.tool
Current platform availability: GAL-2 Node v1.0.0-rc10 is currently available for Linux ARM64.

Coming next: native macOS Apple Silicon GAL-2 Node.
Current GAL-2 Node release:
Download GAL-2 Node v1.0.0-rc10 · Linux ARM64

API access:
Get GAL-2 API Access  ·  GAL-2 API Quickstart
Release verification:
RC10 Release Identity  ·  GAL-2 Release Signing Public Key

RC10 public handoff SHA-256:
080a17dc6f477a6a707e78efe14412d3a0f15d38cc2829cda0ddd9bf8024ac6b
The Professional API plan is recommended for one continuously running GAL-2 Node at the standard 30-second polling interval. At that cadence, one Node uses approximately 86,400 requests in a 30-day month and 89,280 requests in a 31-day month. Local application reads from the Node do not each consume an upstream API request.
Protected workflows can include ledger writes, audit events, authorization decisions, ordering-sensitive jobs, expiration logic, cache invalidation, event ingestion, workflow transitions, Y2038 application-state boundaries, and other paths where unsafe time could become durable state.

Application surface

Time Contract response

The Time Contract returns GAL-2 Time together with the runtime semantics required for safe application consumption. gal2_time is the governed time value. safe_to_consume is the authoritative application-facing decision indicating whether the protected path should consume it.

Fields such as mode, reason, validity, uncertainty, sequence, holdover age, and lineage explain the state under which that decision was published. 

{
  "version": "1.2.0-contract-rc.4",

  "gal2_time": "2026-08-14T18:42:31.482Z",

  "safe_to_consume": true,

  "mode": "LIVE",

  "health": "green",

  "reason": "fresh_api_sync",

  "valid_until": "...",

  "uncertainty_ms": "...",

  "uncertainty_ms_basis":
    "conservative_model_v1_not_external_metrology_validated",

  "holdover_age_sec": 0,

  "monotonic_sequence": "...",

  "source_lineage": [
    "gal2_api",
    "...",
    "time_contract_1.2.0_contract_rc4"
  ]
}
This is a representative public example intended to explain the contract surface. Exact runtime values, reason strings, lineage members, sequence values, and timing measurements vary with the running Node and current operating state.
uncertainty_ms is exposed under a conservative operational model. Its declared basis is conservative_model_v1_not_external_metrology_validated. It should not be represented as external metrology certification.

Core fields

Field
Meaning
Application use
gal2_time
Governed GAL-2 Time made locally consumable by GAL-2 Node.
Use for enrolled protected operations only when the Time Contract permits consumption.
safe_to_consume
Authoritative application-facing decision indicating whether the current GAL-2 Time publication is safe to consume under the active contract and declared policy.
If false, the protected GAL-2 path must not commit using GAL-2 Time.
valid_until
Declared validity boundary associated with the current contract decision.
Do not reuse stale contract decisions beyond their valid consumption window.
mode
Describes the current GAL-2 continuity state.
Use for diagnostics and application policy context. Do not treat mode alone as the authority for safe consumption.
reason
Explanation associated with the current contract decision.
Record with protected operations for diagnostics, audit, and incident review.
uncertainty_ms
Conservative operational uncertainty associated with the current GAL-2 continuity state.
Use with policy and contract state when evaluating continued safe consumption.
holdover_age_sec
Age of the current bounded HOLDOVER state when applicable.
Use to understand proximity to declared holdover policy boundaries.
monotonic_sequence
Consumer-visible publication sequence used for continuity and review.
Record alongside protected operations and use for continuity diagnostics.
source_lineage
Observable lineage metadata describing the GAL-2 delivery and continuity path associated with the publication.
Use for diagnostics, incident review, and evidence packaging. It is not disclosure of protected Fractal Time logic.

Continuity and mode behavior

safe_to_consume remains authoritative. Modes describe the state of GAL-2 continuity; they do not independently override the contract's safe-consumption decision.

State
Meaning
Application behavior
LIVE
Fresh GAL-2 synchronization is available and the Node is operating inside the active Time Contract policy.
Proceed only when safe_to_consume=true and the publication remains valid.
HOLDOVER
Fresh upstream GAL-2 synchronization is unavailable, but the Node can continue from the last valid GAL-2 state under bounded policy. Uncertainty grows as continuity ages.
Proceed only while safe_to_consume=true and the declared holdover, validity, continuity, and uncertainty boundaries remain satisfied.
REJOIN
Upstream GAL-2 synchronization has returned and controlled reconciliation is required before normal LIVE operation resumes.
Follow the Time Contract decision. REJOIN is used when reconciliation is required; recovery may return directly to LIVE when it is not.
FAIL_CLOSED
GAL-2 can no longer justify safe consumption because the relevant continuity or declared policy boundary has been exhausted.
Do not commit. The protected path refuses rather than silently substituting raw host time.
Startup / WARMING
The Node is starting or has not yet established sufficient valid GAL-2 state to publish a consumable contract.
Wait for a valid Time Contract. The protected path must not silently substitute raw host time.
Degraded conditions
Timing, freshness, upstream, or continuity conditions may deteriorate while GAL-2 remains able to describe and govern the condition.
Use safe_to_consume, reason, validity, uncertainty, and current continuity metadata as the authority.

Y2038

Y2038 application-state remediation at the commit boundary

GAL-2 does not replace platform-level Y2038 remediation. It does not convert a 32-bit time_t implementation to 64-bit, patch a legacy kernel, replace firmware, migrate a database schema, or repair a legacy binary.

GAL-2 provides a different layer of remediation: for an enrolled application path, the Time Contract governs whether time should be consumed before a Y2038-style timestamp failure can become committed application state.

Platform-level remediation

Repair the underlying time representation

64-bit time migration, operating-system and kernel updates, firmware replacement, database/schema changes, runtime migration, and legacy binary remediation.

GAL-2 remediation

Protect the application commit boundary

Govern, continue under bounded policy, recover under controlled rules, or fail closed before unsafe time becomes durable application state.

Platform remediation fixes the underlying time representation. GAL-2 provides application-state remediation at the commit boundary.

Integration rule

GAL-2 protects application paths that are actually enrolled through the GAL-2 Node and Time Contract. If software bypasses the protected path, independently reads raw host time, and commits that value as protected state, that operation is outside the GAL-2 protection boundary. 

contract = gal2_provider.read()

if contract.safe_to_consume:
    commit_with_timestamp(contract.gal2_time)
else:
    block_or_defer_protected_operation(
        mode=contract.mode,
        reason=contract.reason
    )
The Provider and local Node path perform the required contract validation. Protected application code should not reintroduce raw host time as a silent substitute when GAL-2 reports a non-consumable state.
A practical integration pattern is to begin with one state-changing workflow, record the relevant Time Contract metadata with protected operations, and expand enrollment deliberately as application requirements are validated.
Keep your timing stack. Install the GAL-2 Node. Connect the application once.

Interfaces

API and configuration boundary

GAL-2 exposes the interfaces required for service access, local application consumption, observability, continuity, and audit without exposing the protected Fractal Time formula, internal governance logic, tuning mechanisms, private keys, or authoritative backend implementation. 

Primary local Time Contract surface:

GET http://127.0.0.1:9095/contract


Upstream GAL-2 API:

GET https://api-v2.gal-2.com/time


Application integration surfaces:

Time Contract
Local SHM
SDK / Clock Provider

The GAL-2 API delivers GAL-2 Time created by the Protected Core. GAL-2 Node consumes that governed trajectory and makes it locally available to enrolled applications.

If upstream GAL-2 API access becomes temporarily unavailable and the Node has a valid last-good GAL-2 state, the Node may continue through bounded HOLDOVER according to declared policy while uncertainty grows. When upstream synchronization returns, recovery may proceed directly to LIVE when reconciliation is unnecessary or through controlled REJOIN when reconciliation is required.

If the declared safe-consumption boundary can no longer be maintained, GAL-2 exposes a non-consumable contract with safe_to_consume=false and transitions the protected path toward FAIL_CLOSED behavior rather than silently substituting raw host time.

Access and safety are separate authorities. Backend entitlement determines whether a Node is authorized to access the GAL-2 service. The Time Contract determines whether GAL-2 Time is safe for an enrolled application to consume.
An active paid GAL-2 API key is required for GAL-2 Node to receive GAL-2 Time and operate in LIVE mode.
IXOYE remains advisory-only. It is not the GAL-2 Time source, is not a fallback time source, and does not determine safe_to_consume. Safe application consumption remains governed by the Time Contract.
Holdover should be understood as governed continuity under a declared policy and uncertainty budget. It is not a claim of metrology-certified oscillator accuracy, certified UTC traceability, or universal physical-precision superiority.

Evidence

Laboratory and validation evidence

GAL-2 validation focuses on the behaviors that matter at the application boundary: governed timeline continuity, monotonic consumption behavior, bounded holdover, controlled recovery, fail-closed semantics, restart continuity, source lineage, application-state protection, host-clock non-interference, and auditable release identity.

Earlier Time Contract releases and long-duration experiments remain part of the public GAL-2 evidence lineage. They should be read as historical evidence supporting the evolution of the architecture, not as substitutes for the identity of the current GAL-2 Node release.

Current Node release

GAL-2 Node v1.0.0-rc10

Current signed limited release for Linux ARM64 with local Time Contract, SHM and SDK Provider consumption, bounded holdover, controlled recovery, fail-closed behavior, and explicit release identity.

Release identity: RC10_RELEASE_IDENTITY.txt

Public handoff: Download RC10

Full-week governed timeline

Solstice 7D

DOI: 10.5281/zenodo.18018704

Documents a GAL-2 governed timeline over a full-week run with 508,548 observed samples and zero observed backward steps in the reported application-facing trajectory.

Contract behavior under stress

5-Day Adversarial Run

DOI: 10.5281/zenodo.20357131

Documents 14,397 Time Contract samples, zero reported fetch failures, zero observed monotonic-sequence backward steps, and FAIL_CLOSED behavior with safe_to_consume=false during the adversarial window.

Extended continuity evidence

72-Hour Holdover Policy

DOI: 10.5281/zenodo.20582981

Documents the earlier RC4-derived 120-hour Time Contract characterization, the declared 72-hour holdover boundary, fail-closed behavior at the safety boundary, and recovery back to LIVE.

Historical public release evidence

RC5.x Time Contract lineage

RC5.1 through RC5.8 preserve the earlier public Time Contract evaluation lineage, including signed/notarized artifacts, application-facing contract semantics, macOS packaging work, Linux ARM64 packaging, IXOYE advisory observation, and published evidence packages.

RC5.1 DOI: 10.5281/zenodo.20646973

Application-state remediation

Y2038 Evidence Corpus

GAL-2 validation includes legacy timestamp-boundary testing, protected commit behavior, continuity experiments, and database-backed application-state evidence for Y2038-style failure conditions.

The claim boundary remains explicit: GAL-2 does not replace platform-level 64-bit time migration or legacy-system remediation. It provides Y2038 application-state remediation at the commit boundary for enrolled application paths.

See: Public Validation

Evidence is presented as application-facing continuity, Time Contract behavior, release identity, and protected application-state behavior under defined conditions. It is not presented as a universal nanosecond-accuracy claim, metrology certification, or certified UTC-traceability claim.
Historical evidence remains historically valid for the artifact and policy boundary it documented. It should not be relabeled as testing performed on GAL-2 Node v1.0.0-rc10 when it predates that release.

Runtime behavior

Performance and benchmarks

GAL-2 performance should be evaluated in the environment where it will run. The relevant engineering question is not only timestamp precision, but whether the enrolled application receives predictable local consumption behavior, correct continuity transitions, bounded failure semantics, and acceptable runtime overhead.

Metric
Purpose
Why it matters
Local contract / Provider latency
Measures the application-facing cost of consuming GAL-2 locally.
Quantifies runtime overhead without confusing local consumption with upstream API latency.
Monotonicity
Checks whether the protected GAL-2 consumption path experiences backward progression.
Protects ordering-sensitive and stateful workflows.
Holdover duration
Characterizes bounded continuity during upstream GAL-2 loss.
Validates that continuation remains constrained by declared policy rather than becoming indefinite.
Uncertainty growth
Measures the explicit growth of operational uncertainty during continuity.
Makes degradation visible instead of allowing continued consumption without a declared safety budget.
Recovery timeline
Measures transition from interrupted upstream access back to LIVE or, when needed, through controlled REJOIN.
Validates controlled recovery without an uncontrolled application-side time shock.
Fail-closed behavior
Checks whether unsafe consumption is refused when declared safety boundaries can no longer be justified.
Prevents the protected GAL-2 path from silently converting unsafe time into committed state.
Restart continuity
Evaluates whether continuity survives or is correctly refused across Node and Provider lifecycle changes.
Protects against silently accepting incompatible generations, stale publications, or invalid continuity assumptions.
False-positive rate
Measures unnecessary non-consumable decisions during otherwise healthy conditions.
Protects operational usability while preserving the fail-closed boundary.
Benchmark numbers should always identify the exact release, platform, configuration, policy profile, workload, and measurement method. Historical measurements should not be presented as universal RC10 performance.

Layer distinction

Comparative analysis

GAL-2 operates at a different layer from traditional reference and synchronization systems. UTC, GNSS, NTP, PTP, chrony, grandmasters, atomic references, timing receivers, and operating-system clocks help define, obtain, discipline, or distribute time. GAL-2 governs how an enrolled application consumes time before that time becomes state.

  • UTC and national timing references: establish civil or reference time but do not define the application-side consumption decision during local failure, partition, stale state, continuity exhaustion, or recovery.
  • GNSS: provides high-value reference timing but can be unavailable, degraded, jammed, spoofed, obstructed, or otherwise unsuitable for blind application-side trust.
  • NTP and chrony: synchronize or discipline system time but do not themselves provide the GAL-2 application-facing Time Contract with safe_to_consume, validity, uncertainty, reason, lineage, bounded holdover, controlled recovery, and fail-closed semantics.
  • PTP and grandmasters: distribute high-precision time in supported environments but operate at a different layer from application-consumption governance.
  • Atomic clocks and physical references: provide physical timing authority and precision. GAL-2 does not replace their metrological function.
  • GAL-2 API: delivers GAL-2 Time created by the Protected Core to authorized Nodes.
  • GAL-2 Node: makes GAL-2 Time locally consumable and provides bounded continuity, recovery, SHM, Provider access, and the local Time Contract surface.
  • Time Contract: governs whether the enrolled application should consume GAL-2 Time before it becomes application state.

Application boundary

Real-world use cases

GAL-2 is designed for systems where time becomes state and where unsafe timestamps, continuity failures, or uncontrolled recovery can create operational, financial, forensic, security, or distributed-system damage.

Distributed systems

Ordering and coordination

Helps protect ordering-sensitive writes, reconciliation, sequencing, distributed workflows, and audit trails when the normal time path becomes unsafe.

Reference interruption

Bounded continuity

Provides explicit governed behavior when upstream GAL-2 access or surrounding timing conditions become unavailable, degraded, intermittent, or recover after interruption.

Edge and autonomous systems

Intermittent operation

Supports explicit continuity state for systems that may operate across isolation, reconnection, service interruption, and local restart.

Audit and forensics

Runtime evidence

Records mode, reason, validity, uncertainty, sequence, and lineage alongside protected operations for post-event review.

Cloud infrastructure

Application consumption boundary

Complements the existing timing stack by adding governance close to the software path where timestamps become durable state.

Y2038 application-state remediation

Legacy timestamp boundaries

GAL-2 provides application-state remediation for enrolled workflows by governing whether Y2038-style unsafe timestamp behavior can become committed state.

This does not replace operating-system, kernel, firmware, database, schema, runtime, or legacy-binary remediation at their own layers.

Platform remediation fixes the underlying time representation. GAL-2 provides application-state remediation at the commit boundary.

Security model

Security

GAL-2 is designed around controlled access, protected core logic, signed release identity, local application consumption, explicit failure behavior, and separation between backend entitlement and application-side safe-consumption authority.

  • Paid API entitlement: LIVE service access requires an active GAL-2 API credential and backend entitlement.
  • Credential handling: API credentials should be provisioned and stored through the supported Node configuration path and should never be embedded in application code, public artifacts, documentation, or logs.
  • Transport security: upstream communication should use the GAL-2 supported encrypted service path and standard secure networking practices.
  • Local consumption: enrolled applications consume GAL-2 locally through Node interfaces rather than making an upstream API request for every application time read.
  • Fail-closed application path: GAL-2 does not silently replace an unsafe GAL-2 publication with raw host time.
  • Host non-interference: GAL-2 Node does not discipline, steer, or replace the host system clock.
  • Release integrity: current Node releases are distributed with explicit SHA-256 identity and GPG signing material.
  • Frozen release identity: a published frozen release is not silently modified in place. A package or behavior change requires a new release identity.
  • Protected governance core: protected formulas, private keys, internal correction logic, backend implementation, and authoritative protected mechanisms are not distributed with the Node.
GAL-2 Node v1.0.0-rc10 public handoff SHA-256:
080a17dc6f477a6a707e78efe14412d3a0f15d38cc2829cda0ddd9bf8024ac6b
Current GAL-2 release-signing fingerprint:
802C 8978 FF85 7550 60B6 D6BC 8AB8 59E4 D705 822F

Standards and compliance boundary

GAL-2 is designed to operate alongside established timing, networking, operating-system, cloud, and physical reference infrastructure. It does not replace NTP, PTP, GNSS, UTC, chrony, atomic clocks, grandmasters, timing receivers, operating-system time, cloud time, or national metrology references.

GAL-2's role is different: it adds a governed application-consumption boundary between available time and committed software state.

For regulated, safety-critical, or production-critical environments, organizations should validate GAL-2 against their own requirements, deployment policies, risk models, audit obligations, and applicable technical or regulatory frameworks.

Release lineage

Maintenance and versioning

GAL-2 releases evolve through explicit controlled versioning. Frozen releases are not modified silently. Changes to runtime behavior, installer, schema, package identity, signing, compatibility, or public contract semantics require a new release identity.

  • GAL-2 Node v1.0.0-rc10: current signed limited release for Linux ARM64. Includes the current Node product surface, local Time Contract, SHM and SDK Provider consumption path, bounded holdover, controlled recovery, fail-closed behavior, and host-clock non-interference.
  • Time Contract 1.2.0-contract-rc.4: current Time Contract generation exposed by the GAL-2 Node release line.
  • macOS Apple Silicon: planned next native GAL-2 Node platform release. It is not part of RC10.
  • RC5.8 / 1.2.0-rc.3: historical public Time Contract evaluator release for macOS and Linux Docker ARM64. Preserved as part of the GAL-2 evidence and packaging lineage, not as the current Node release.
  • RC5.7 / RC5.7.1: historical evaluator packaging and platform lineage preserved for evidence and release history.
  • RC5.1: DOI-published public Time Contract evidence package preserved as historical public validation.
  • Future releases: may expand supported platforms, application SDK surfaces, attestation mechanisms, policy profiles, validation evidence, operational tooling, and enterprise deployment controls.
  • Deployment policy: organizations should define which workflows are enrolled, what behavior is permitted during continuity events, and what the application must do when safe_to_consume=false.

Glossary

  • GAL-2: the application time-consumption governance platform encompassing GAL-2 API, GAL-2 Node, the Time Contract, and the protected Fractal Time architecture.
  • Fractal Time: GAL-2's protected theoretical and mathematical foundation for governed temporal trajectory, correction, continuity, and alignment.
  • Protected Core: the protected GAL-2 governance system that creates the governed GAL-2 Time trajectory. Its protected formula and implementation are not distributed with GAL-2 Node.
  • GAL-2 API: the service interface that delivers GAL-2 Time created by the Protected Core to entitled GAL-2 Nodes.
  • GAL-2 Node: the local GAL-2 product surface that makes GAL-2 Time consumable beside enrolled applications and provides continuity, bounded holdover, recovery, local publication, Time Contract, SHM, and SDK Provider access.
  • Time Contract: the application-facing contract that governs whether GAL-2 Time is safe to consume and exposes the relevant validity, uncertainty, mode, reason, sequence, and lineage.
  • gal2_time: the governed GAL-2 Time value consumed by enrolled applications when the Time Contract allows it.
  • safe_to_consume: the authoritative application-facing decision indicating whether the current GAL-2 Time publication may be consumed under the active Time Contract and declared policy.
  • HOLDOVER: bounded continuation from the last valid GAL-2 state when fresh upstream GAL-2 synchronization is temporarily unavailable. HOLDOVER operates under declared limits and explicit uncertainty growth.
  • REJOIN: controlled reconciliation used when fresh upstream GAL-2 synchronization returns and the Node cannot safely transition directly back to LIVE.
  • LIVE: continuity state in which fresh upstream GAL-2 synchronization is available and the Node is operating under the active contract policy.
  • FAIL_CLOSED: condition in which GAL-2 can no longer justify safe consumption and the protected application path refuses rather than silently substituting raw host time.
  • Uncertainty: explicit conservative operational uncertainty associated with the current GAL-2 continuity state. The current basis is not represented as external metrology certification.
  • Source lineage: observable metadata describing the GAL-2 delivery and continuity path associated with a publication without disclosing protected governance logic.
  • Backend entitlement: the service-side authority that determines access to GAL-2 API. It does not replace the Time Contract's authority over safe consumption.
  • IXOYE Witness Layer: the advisory solar-witness concept associated with the broader IXOYE Time vision. IXOYE is not the GAL-2 Time source, not a fallback source, and does not decide safe_to_consume.
  • Y2038 application-state remediation: GAL-2 governance at the application commit boundary intended to prevent unsafe Y2038-style timestamp behavior from silently becoming committed application state in enrolled workflows. It does not replace platform-level Y2038 remediation.

Technical position

GAL-2 is not another clock.

Existing timing infrastructure continues to perform its reference, synchronization, distribution, and host-clock functions. GAL-2 introduces a different boundary: governed consumption at the point where time becomes application state.

GAL-2 API creates GAL-2 Time. GAL-2 Node makes it locally consumable. The Time Contract governs its use.
Keep your timing stack. Install the GAL-2 Node. Connect the application once.
Validation · Docs · Whitepaper · Pricing · Vision
GAL-2 Time Contract Layer · Powered by AWS · Verified Apple Developer ID XWFX4JS9C2 · Local contract endpoint 127.0.0.1:9095/contract
Public evidence: RC4 72h Holdover · 5-Day Adversarial · Solstice 7D · SHA-256 sealed validation artifacts
© 2026 GAL-2™ Technologies LLC. All rights reserved. · Application-facing Time Contract infrastructure · Terms of Service · Privacy Policy · support@gal-2.com GAL-2 governs whether software should consume time before committing state. It is not a replacement for UTC, GNSS, PTP, NTP, chrony, atomic clocks, grandmasters, hardware clocks, or existing timing infrastructure.