FAQs
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 will ask before a pilot.
GAL-2™ Time Contract is an application-facing temporal governance layer. It does not replace UTC, GNSS, PTP, NTP, chrony, atomic clocks, grandmasters, or timing receivers. It sits closer to the software boundary and serves governed gal2_time as the application-facing output, so protected systems can continue safely within policy, rejoin under control, or fail closed before unsafe time becomes committed state.
Buyer decision questions
1) What is GAL-2™ Time Contract?
GAL-2™ Time Contract is a local daemon and API-backed contract path that exposes
gal2_time with runtime semantics such as safe_to_consume, valid_until, mode, reason, monotonic_sequence, and source_lineage. The goal is to let protected applications consume governed time instead of trusting raw time directly.
2) What problem does GAL-2 actually solve?
GAL-2 solves the application boundary problem. Timing infrastructure can deliver a reference, but applications still need to decide whether that time should be trusted for commits, ordering, ledgers, logs, authorization, cache expiration, workflows, and audit trails. GAL-2 governs that consumption path so unsafe time does not silently become committed state.
3) Is GAL-2 a temporal lifeline for applications?
Yes, within declared policy limits. GAL-2 is designed to act as a temporal safety layer for protected applications. When upstream time is healthy, applications consume governed
gal2_time normally. When timing conditions degrade, GAL-2 can preserve bounded monotonic continuity, enter holdover, perform controlled rejoin, or fail closed before unsafe time becomes committed state.
The key point is that GAL-2 does not promise to keep every system running forever. It gives applications a governed path: continue safely when justified, recover under control when possible, or stop protected operations cleanly when safety can no longer be justified.
4) Is this just monitoring?
No. Monitoring watches a time path and reports what happened. GAL-2 is designed to be placed in the consumption path. Applications consume
gal2_time through the contract. When conditions degrade, GAL-2 can continue within policy, enter holdover, perform controlled rejoin, or fail closed before unsafe time becomes trusted state.
5) Why would a company pay for this?
Because timing incidents are not only clock problems. They become application-state problems. GAL-2 gives buyers a way to reduce silent temporal corruption, create audit evidence, and define what the system should do when time becomes unsafe.
6) What is the cleanest buyer category?
GAL-2 Time Contract is best understood as a Temporal Circuit Breaker for production systems. Technically, it is an application-facing Time Contract layer. Commercially, it is a time safety layer for systems that cannot afford silent timestamp corruption.
7) What is the strongest honest claim?
GAL-2 does not replace time infrastructure. It governs application consumption of time when infrastructure is healthy, degraded, unavailable, or recovering. It provides governed output, explicit contract state, bounded continuity where policy allows, controlled rejoin, fail-closed semantics, and auditable runtime evidence.
8) What should GAL-2 not claim?
GAL-2 should not claim to replace UTC, GNSS, PTP, NTP, chrony, atomic clocks, grandmasters, or timing receivers. It should not claim universal Y2038 or leap-second elimination. It should not claim nanosecond or microsecond accuracy unless independently measured and scoped. It should not claim to protect applications that bypass the contract path.
9) How do I get started?
Download the evaluator release for your platform, install the local daemon, configure a valid GAL-2 API key, verify
/status, call /contract, and integrate one protected workflow against gal2_time and the Time Contract semantics.
Product and integration questions
10) Is GAL-2 just another clock?
No. A clock answers what time it is. GAL-2 answers whether governed time can safely become application state, and it provides a contract path for consuming that governed time. GAL-2 is not trying to be another GNSS receiver, NTP server, PTP grandmaster, or atomic reference.
11) What is the simplest explanation for a customer?
Your timing stack delivers time. GAL-2 governs how applications consume it before it becomes state. Precision protects the reference. GAL-2 protects the consumer.
12) What does an application actually call?
The primary local endpoint is
http://127.0.0.1:9095/contract. Applications should use the Time Contract for protected state-changing operations instead of reading raw system time directly for those operations.
13) What fields should engineers care about first?
The first field is
gal2_time, because that is the governed timestamp the application consumes. Then the application evaluates safe_to_consume, valid_until, mode, reason, monotonic_sequence, and source_lineage. Status fields describe the governed output. They are not the product by themselves.
14) What does an application developer need to change?
Protected state-changing operations should call the local
/contract endpoint and use gal2_time only when the Time Contract allows it. The application should log mode, reason, sequence, validity, and lineage with protected commits.
15) Can we start by using GAL-2 only for selected workflows?
Yes. A practical pilot can start with one protected workflow: ledger writes, audit events, authorization decisions, cache invalidations, ordering-sensitive jobs, or event ingestion. The first goal is to prove the consumption boundary before expanding coverage.
16) How should GAL-2 be integrated safely?
Start with non-production evaluation. Define protected operations. Replace raw time reads in that path with
gal2_time. Define behavior for safe_to_consume=false. Log contract fields. Run nominal and impairment tests. Review false positives, latency, and fail-closed behavior before any production decision.
17) What platforms are supported?
Current evaluator releases support macOS and Linux. The macOS package is intended to be Developer ID signed and notarized. The Linux package is distributed as an installer-friendly release with verification artifacts.
18) Where is the API key configured?
On macOS RC3.1, the expected configuration path is
/usr/local/gal2/config/daemon.env. The daemon should not serve production GAL-2 Time without a valid API key.
19) What happens with no API key?
The daemon can expose local status and warming semantics, but it should not serve production GAL-2 Time. A clean no-key installation should report a non-consuming state such as
WARMING, reason such as warming_no_cache, and safe_to_consume=false.
Differentiation against existing timing stacks
20) Why do I need this if I already have GNSS?
GNSS provides a timing reference. GAL-2 governs what your application consumes when that reference becomes degraded, jammed, spoofed, stale, unavailable, or returns out of phase. GNSS protects reference delivery. GAL-2 protects the application boundary.
21) Why do I need this if I already use PTP or a grandmaster?
PTP and grandmasters distribute precise time. GAL-2 does not replace that. GAL-2 sits downstream, closer to the application, and governs whether the application should consume, hold, rejoin, or stop using time under operational stress.
22) Why do I need this if I already use NTP or chrony?
NTP and chrony discipline system time. GAL-2 governs application consumption of time. Chrony can tell the operating system how to adjust a clock. GAL-2 tells the application whether governed time can safely be used for state-changing behavior and provides mode, validity, reason, sequence, and lineage.
23) 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 audit reasoning. GAL-2 adds a consumption contract around governed time, not just a local counter.
24) 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. A customer can keep their GNSS, PTP, NTP, chrony, TimeCard, grandmaster, or atomic infrastructure and add GAL-2 where time becomes application state.
25) Is this just a wrapper around clock_gettime()?
No. A wrapper returns time. GAL-2 exposes a runtime contract around governed time: mode, validity, reason, monotonic sequence, lineage, holdover state, rejoin behavior, and fail-closed semantics. The value is the policy and behavior at the application boundary.
Hard engineering objections
26) What is your accuracy spec?
GAL-2 Time Contract is not positioned as a metrology accuracy product. In healthy mode, it inherits the quality of the upstream reference path and exposes governed application-facing time. The primary claim is application failure behavior under timing stress: monotonic consumption, policy-limited holdover, controlled rejoin, fail-closed behavior, and auditability.
GAL-2 should be evaluated by governed output behavior under impairment, not as a replacement for certified UTC traceability or hardware timing references.
27) Does GAL-2 make upstream time more precise?
No. GAL-2 does not claim to improve upstream metrological precision. It improves what the application does when timing conditions misbehave. The product surface is governed consumption, not reference superiority.
28) Holdover without a real oscillator sounds like guessing. Is it?
Holdover must be bounded, labeled, and policy-limited. GAL-2 does not claim that holdover is more accurate than a physical reference. It claims that continuity can be governed, disclosed, constrained, and stopped when policy can no longer justify safe consumption.
29) What happens if holdover exceeds policy limits?
The contract should move toward
FAIL_CLOSED and safe_to_consume=false. At that point, protected state-changing operations should block, defer, or follow an explicitly defined application fallback. Silent fallback to raw time is not recommended for protected operations.
30) What happens when the upstream reference returns?
GAL-2 should not force abrupt raw recovery behavior into the application. It enters controlled rejoin semantics, reconciles back toward the reference path, and preserves no-backward-step behavior for contract consumers where policy allows.
31) What if the GAL-2 daemon goes down?
Daemon unavailability must be treated as a defined contract state, not silence. Protected applications should treat the contract path as unavailable and follow a predefined policy: block protected commits, use an explicitly approved fallback, or route to a high-availability GAL-2 instance when configured.
32) Are you adding a single point of failure?
GAL-2 adds an in-path component to remove silent temporal corruption. That tradeoff must be engineered honestly. For serious pilots, deployment patterns should define local behavior, daemon-down semantics, monitoring of the contract path, and high-availability options. The point is not to hide failure. The point is to make temporal failure explicit and governable.
33) What is the latency impact?
The intended integration pattern is a local daemon endpoint, not a remote API call for every protected operation. Latency should be measured locally during pilots. For enterprise evaluation, p50, p95, and worst-case contract-call latency should be reported under both nominal and impaired conditions.
34) What prevents false positives from blocking healthy systems?
This is a valid pilot metric. GAL-2 should be evaluated with a nominal baseline that measures unnecessary degraded or fail-closed events during stable conditions. The product should not only fail closed correctly. It should also avoid unnecessary interruption under healthy timing conditions.
35) 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 another side path and uses it for protected commits, that behavior is outside the GAL-2 protection boundary.
Failure behavior and operational value
36) What does safe_to_consume=false mean?
It means the GAL-2 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 an explicitly approved fallback. It should not silently switch to raw time for protected commits.
37) What does safe_to_consume=true mean?
It means
gal2_time is safe to consume under the current policy, mode, validity window, and source lineage. It is not an unlimited guarantee that all possible timing risk has disappeared.
38) What are the main Time Contract modes?
Common modes include
LIVE, DEGRADED, HOLDOVER, REJOIN, WARMING, and FAIL_CLOSED. These modes help applications understand whether governed time is fresh, degraded, locally held, recovering, warming up, or unsafe to consume.
39) What is the business value?
The business value is bounded blast radius during timing incidents. GAL-2 gives teams evidence of what the application did with time: whether it continued, held, rejoined, or stopped before unsafe timestamps became committed state.
40) What kinds of failures can GAL-2 help with?
GAL-2 is designed for timing degradation scenarios such as stale references, upstream loss, backward steps, forward jumps, recovery out of phase, VM resume behavior, network partitions, local restart, and other conditions where raw time consumption can become dangerous.
41) Does GAL-2 prevent all timestamp corruption?
No. GAL-2 protects consumers of the Time Contract within declared policy limits. It cannot protect applications that bypass the contract, misuse the fields, ignore
safe_to_consume=false, or commit through raw time side paths.
42) Does GAL-2 solve leap seconds?
GAL-2 does not claim to universally solve leap seconds. It can reduce application risk from leap-second-like discontinuities for consumers that use the Time Contract, because the application consumes governed time and contract semantics rather than blindly trusting raw timing behavior.
43) Can GAL-2 help with Y2038 risk?
GAL-2 may reduce risk for some legacy time-boundary behavior when applications consume time through a governed contract path. It should not be described as a universal Y2038 fix. The correct evaluation is specific: test the legacy consumer, the boundary condition, the GAL-2 integration path, and the resulting application behavior.
Security, IP, and trust
44) Is the core formula public?
No. The protected mathematical model and backend logic are not public. GAL-2 exposes behavior through controlled interfaces, public evidence, evaluator packages, and contract outputs without disclosing protected implementation details.
45) Why should engineers trust a protected core?
Engineers do not need to accept private implementation claims on faith. They should evaluate observable behavior: contract fields, mode transitions, monotonicity, holdover limits, rejoin behavior, fail-closed behavior, logs, hashes, reproducible test outputs, and independent pilot results.
46) How is access controlled?
Production serving requires a valid GAL-2 API key. The local daemon exposes only the contract behavior needed by the application. The protected core remains server-side, and evaluator releases should be distributed with hashes, signatures where available, and clear release scope.
47) Are Time Contract responses signed?
Public claims about signed contracts should only be made when signature support is implemented and verified. Until then, signatures should be treated as an enterprise attestation roadmap item. Current evaluation should focus on contract behavior, release verification, logs, and evidence packages.
48) Can GAL-2 be deployed in regulated or safety-critical environments today?
RC3.1 is a Limited Availability evaluator release for developer pilots, architecture review, and controlled non-production technical evaluation. It is not certified for production critical infrastructure, safety-critical systems, regulated trading, medical systems, aviation, emergency services, life-support systems, nuclear facilities, weapons systems, or other high-risk environments without a separate written agreement and additional validation.
Evidence and validation
49) What evidence exists today?
GAL-2 has public validation work around application-facing Time Contract behavior, Red Light style consumption-control testing, operational source-isolation testing, and longer-run API-backed daemon evidence. The strongest evidence should be read as application-boundary behavior under defined conditions, not as a claim that GAL-2 replaces certified timing references.
50) What does the Red Light Test prove?
It demonstrates consumption control. A raw-time application can continue committing through unsafe timing conditions. A GAL-2-aware application can block unsafe protected operations and produce auditable contract evidence. It is not a nanosecond accuracy test.
51) What should a serious pilot measure?
A serious pilot should measure monotonicity for contract consumers, holdover duration, rejoin behavior, fail-closed behavior, false-positive rate, decision latency, daemon restart behavior, local cache behavior, source lineage, evidence hashes, and raw app versus GAL-2 app behavior under the same impairment.
52) What would make GAL-2 fail a pilot?
GAL-2 should fail evaluation if the protected path allows unsafe time to be committed 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.
53) Can an external engineer reproduce the tests?
That is the goal for serious evaluation. Public and evaluator packages should include clear test plans, raw outputs, logs, summaries, SHA256 manifests, and limitations. External reproduction is a priority before broader enterprise claims.