Understanding GAL-2™
Clear answers about governed time, application-state risk, and how GAL-2 helps protected systems hold, rejoin, or fail closed before unsafe time becomes committed state.
Technical and buyer FAQ
Questions engineers and buyers ask before evaluating GAL-2.
GAL-2™ Time Contract is an application-facing time governance product. It combines
the GAL-2 API, a local daemon, and a Time Contract surface so protected applications can
evaluate governed gal2_time, check safety before commit, hold over within policy,
rejoin under control, or fail closed before unsafe time becomes state.
1) What is GAL-2™ Time Contract?
GAL-2™ Time Contract is the application-facing product surface of GAL-2. It runs locally as a daemon, is backed by the GAL-2 API, and exposes a contract your software can call before committing time-dependent state.
The core fields include gal2_time, safe_to_consume,
mode, reason, valid_until,
monotonic_sequence, and source_lineage.
2) Is the Time Contract the same as the daemon?
They are different parts of the same product system. The Time Contract is the application-facing runtime object. The daemon is the local process that serves the contract to protected applications.
Applications integrate with the local daemon and evaluate the Time Contract before using time in state-changing operations.
3) What problem does GAL-2 actually solve?
GAL-2 solves the application-consumption problem. Timing infrastructure can deliver time, but applications still need to decide whether that time is safe to use for commits, ordering, ledgers, logs, authorization, cache expiration, workflows, and audit trails.
GAL-2 governs that boundary so unsafe timing behavior does not silently become application state.
4) Why would a company pay for this?
Because timing incidents do not stay inside clocks. They become corrupted logs, bad ordering, ledger errors, stale authorization, broken expirations, failed audit trails, and unsafe commits.
GAL-2 gives engineering teams a controlled, auditable way to decide what software should do when time is healthy, degraded, unavailable, recovering, or unsafe.
5) What is the cleanest buyer category?
Commercially, GAL-2 is an application-facing Time Contract for systems where time becomes state. Technically, it is a time consumption governance layer. Architecturally, it is a software-defined time governance boundary.
6) Is this just monitoring?
No. Monitoring observes and reports. GAL-2 is designed to sit in the application consumption path.
Protected software evaluates gal2_time through the contract and reacts to
safe_to_consume, mode, reason, validity, sequence, and lineage before committing state.
7) What should GAL-2 not claim?
GAL-2 should not be described as a replacement for UTC, GNSS, PTP, NTP, chrony, atomic clocks, grandmasters, timing receivers, or certified metrology references. It should not claim nanosecond or microsecond accuracy unless independently measured against a named reference.
The strongest claim is application-facing governance: governed output, monotonic continuity for contract consumers, bounded holdover where policy allows, controlled rejoin, fail-closed behavior, and auditable runtime evidence.
8) What does an application actually call?
The primary local endpoint is http://127.0.0.1:9095/contract.
Applications should call this endpoint for protected state-changing operations instead of
reading raw system time directly for those operations.
9) What is the difference between the GAL-2 API and the local Time Contract?
The GAL-2 API provides the upstream governed timeline. The local daemon is the application-facing contract surface. The daemon turns upstream governance into a local contract with mode, safety, validity, reason, sequence, and lineage.
For production-style integration, applications should integrate with the local Time Contract.
10) What is RapidAPI for?
RapidAPI is a fast way to test the upstream GAL-2 Time API. It is useful for first contact, API exploration, and simple developer testing.
The full GAL-2 Time Contract experience requires the local daemon and a GAL-2 API key.
11) How do I get started?
Start with the Quickstart. Test your GAL-2 API key, download the evaluator daemon for macOS
or Linux Docker ARM64, activate the daemon with your key, verify /status, and call
/contract.
12) What happens with no API key?
The daemon may expose local status and warming behavior, but it should not serve live production
GAL-2 Time. A clean no-key state should report something like WARMING,
warming_no_cache, and safe_to_consume=false.
13) Can we start with only one workflow?
Yes. A controlled technical evaluation can start with one protected workflow: ledger writes, audit events, authorization decisions, ordering-sensitive jobs, cache invalidation, event ingestion, Y2038 boundary handling, or recovery behavior.
14) What platforms are supported?
RC5.8 evaluator support includes macOS and Linux Docker ARM64. macOS is distributed as a customer-installable package. Linux is distributed as a Docker ARM64 evaluator bundle with verification artifacts.
15) Why do I need GAL-2 if I already have GNSS?
GNSS provides a reference. GAL-2 governs what applications consume when a reference is degraded, jammed, spoofed, stale, unavailable, or recovering out of phase.
GNSS protects reference delivery. GAL-2 protects the application boundary.
16) Why do I need GAL-2 if I already use PTP or a grandmaster?
PTP and grandmasters distribute precise time. GAL-2 does not replace them. GAL-2 sits downstream, closer to the application, and governs whether software should consume, hold, rejoin, degrade, or fail closed when timing behavior becomes unsafe.
17) Why not just use a monotonic clock?
A monotonic clock helps with local ordering, but it does not provide upstream lineage, freshness, validity windows, holdover policy, controlled rejoin, fail-closed semantics, or machine-readable audit reasoning.
GAL-2 adds a contract around governed time, not just a local counter.
18) Is GAL-2 competing with timing hardware companies?
GAL-2 is complementary. Timing hardware protects the reference layer. GAL-2 protects the software consumption layer. Customers can keep GNSS, PTP, NTP, chrony, TimeCards, grandmasters, atomic clocks, and receivers while adding GAL-2 where time becomes state.
19) What does safe_to_consume=false mean?
It means the governed output should not be used for protected state-changing operations under the current contract state. The application should block, defer, fail closed, or follow a specifically approved fallback. It should not silently switch to raw time.
20) What happens when timing degrades?
GAL-2 can enter bounded holdover, preserve monotonic behavior for contract consumers,
perform controlled rejoin when the reference returns, or move to FAIL_CLOSED
when safe consumption can no longer be justified.
21) What happens when the upstream reference returns?
GAL-2 should not force abrupt raw recovery behavior into the application. It uses controlled rejoin semantics to reconcile back toward upstream-backed operation while preserving no-backward-step behavior for contract consumers where policy allows.
22) Does GAL-2 remediate Y2038?
GAL-2 can help remediate Y2038-style application-state failure for workflows integrated through the GAL-2 contract path. The key is that unsafe legacy timestamp behavior can be governed, blocked, translated, or prevented from becoming committed state.
GAL-2 does not mean customers can ignore operating system, kernel, firmware, database, schema, or legacy binary remediation. Those layers still matter. GAL-2 operates at a different layer: the application-consumption boundary where time becomes state.
23) Does GAL-2 solve leap-second-like discontinuities?
GAL-2 can reduce application risk from leap-second-like discontinuities for consumers that use the Time Contract, because the application evaluates governed time and contract semantics instead of blindly trusting raw timing behavior.
24) Can applications bypass GAL-2 and still be protected?
No. GAL-2 protects consumers of the Time Contract. If an application reads raw system time through a side path and commits protected state with that raw value, that behavior is outside the GAL-2 protection boundary.
25) What public evidence exists today?
GAL-2 has public evidence packages showing API-backed governed timeline continuity, Time Contract behavior under stress, protected commit behavior, source-isolation behavior, and application-facing temporal safety testing.
These datasets should be read as continuity and governance evidence, not as certified metrological UTC accuracy claims.
26) What does the Solstice 7D dataset show?
The Solstice 7D dataset shows that a GAL-2 API-backed governed timeline maintained application-facing continuity over a full-week run on commodity hardware, with strict monotonicity verified across 508,548 observed samples under real-world network conditions.
27) What does the 5-Day Adversarial run show?
The 5-Day Adversarial run shows contract behavior under controlled stress: 14,397 contract
samples, zero fetch failures, zero monotonic sequence backward steps, and observed
FAIL_CLOSED behavior with safe_to_consume=false during the
adversarial window.
28) What should a serious evaluation measure?
A serious evaluation should measure monotonicity for contract consumers, decision latency, holdover duration, rejoin behavior, fail-closed behavior, false-positive rate, restart behavior, local cache behavior, source lineage, evidence hashes, and raw application versus GAL-2-aware application behavior under the same impairment.
29) What would make GAL-2 fail an evaluation?
GAL-2 should fail evaluation if the protected path allows unsafe time to become committed
state without disclosure, if gal2_time moves backward for contract consumers,
if holdover continues past policy without fail-closed behavior, if mode or reason fields
misrepresent reality, or if evidence cannot be reproduced.
30) Is the GAL-2 core public?
No. The protected mathematical model, backend governance logic, key material, and implementation details are not delivered as customer source code. GAL-2 exposes behavior through the local Time Contract, controlled APIs, evaluator packages, public evidence artifacts, policy lineage, and reproducible validation records.
The evaluation boundary is the observable contract behavior: what the application receives, how modes transition, how policy is represented, and whether the system behaves as claimed under controlled test conditions.
31) How should a protected core be evaluated?
GAL-2 should be evaluated through observable behavior, not private claims. Engineers should inspect the Time Contract fields, mode transitions, monotonic sequence behavior, holdover limits, rejoin behavior, fail-closed behavior, source lineage, raw logs, SHA-256 manifests, evaluator packages, and reproduced test outputs.
The developer-facing integration surface remains the auditable Time Contract. The protected upstream core remains controlled, while contract behavior can be externally characterized under real timing infrastructure.
32) Why should engineers trust a controlled implementation?
Engineers should not be asked to trust a hidden claim. They should test the contract.
A serious evaluation should verify whether safe_to_consume, mode, reason,
validity windows, policy, uncertainty, sequence behavior, and lineage match observed
system behavior under nominal, degraded, holdover, rejoin, and fail-closed conditions.
The trust model is evidence-backed: signed or hashed artifacts where available, public datasets, reproducible validation records, and controlled characterization beside existing timing infrastructure.
33) Are Time Contract responses signed?
Public claims about signed contract responses should only be made when signature support is implemented, documented, and verified. Until then, signed response envelopes should be treated as an enterprise attestation roadmap item.
34) Can GAL-2 be used in regulated or safety-critical environments today?
Current evaluator releases are intended for developer evaluation, architecture review, and controlled technical evaluation. Production use in critical infrastructure, safety-critical systems, regulated trading, aviation, medical systems, emergency services, life-support systems, nuclear facilities, weapons systems, or other high-risk environments requires separate written agreement, additional validation, and deployment-specific review.
35) Is GAL-2 core IP for sale?
No. GAL-2 core IP, formula, protected governance logic, and ownership are not for sale. Commercial access is provided through API usage, daemon licensing, evaluator access, controlled technical evaluation, enterprise contracts, and dedicated partner arrangements where appropriate.
36) What is the best first commercial step?
The best first step is a controlled technical evaluation. Pick one workflow, define the raw-time risk, integrate the Time Contract, run nominal and impaired tests, compare behavior, and produce a clean evidence package with logs, metrics, and decision outcomes.