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 adopting GAL-2.
GAL-2 is an application time-consumption governance layer. The Protected Core creates GAL-2 Time, the GAL-2 API delivers it, GAL-2 Node makes it locally consumable, and the Time Contract governs whether an enrolled application should use it before time becomes committed application state.
1) What is GAL-2?
GAL-2 is an application time-consumption governance layer for software systems where time becomes application state.
The product architecture has distinct responsibilities: the Protected Core creates GAL-2 Time, the GAL-2 API delivers it, GAL-2 Node makes it locally consumable, and the Time Contract governs its use.
2) Is the Time Contract the same as GAL-2 Node?
No. They are different parts of the same product architecture.
GAL-2 Node is the locally installed product that maintains the application-facing GAL-2 consumption path. The Time Contract is the governed runtime contract exposed by the Node so enrolled software can determine whether GAL-2 Time is safe to use.
Applications can consume through supported local surfaces including the Time Contract, shared-memory publication, and the GAL-2 SDK Provider.
3) What problem does GAL-2 actually solve?
GAL-2 addresses the application-consumption problem. Timing infrastructure can deliver time, but applications still need a governed decision about whether that time should be trusted for commits, ordering, ledgers, logs, authorization, expiration, workflows, transactions, and audit trails.
GAL-2 creates that boundary before unsafe timing behavior can silently become committed application state.
4) Why would a company pay for this?
Because timing failures do not necessarily remain clock problems. Once software trusts the wrong timestamp, the consequence can become bad ordering, disputed records, corrupted state, broken expiration logic, audit exposure, operational recovery work, and customer impact.
GAL-2 gives engineering teams a reusable application-facing policy layer for deciding what protected software should do when GAL-2 Time is LIVE, operating under bounded continuity, recovering, or no longer safe to consume.
5) What is the cleanest buyer category?
The clearest category is Application Time Consumption Governance Layer.
GAL-2 is not another synchronization protocol or another system clock. It sits at the application-consumption boundary where time becomes software state.
6) Is this just monitoring?
No. Monitoring observes and reports. GAL-2 is designed to participate in the protected application-consumption path.
Enrolled software receives GAL-2 Time together with an explicit
safe_to_consume decision and contract metadata such as
mode, reason, validity, uncertainty, sequence, and lineage before
committing protected state.
7) What should GAL-2 not claim?
GAL-2 is not a replacement for UTC, GNSS, PTP, NTP, chrony, atomic clocks, grandmasters, timing receivers, hardware clocks, or certified metrology references.
GAL-2 does not discipline or steer the host system clock and does not claim universal nanosecond or microsecond accuracy.
Its strongest currently demonstrated claims are at the application boundary: governed GAL-2 Time consumption, explicit safety decisions, bounded HOLDOVER, controlled recovery, FAIL_CLOSED behavior, no silent raw host-time fallback through the protected path, and auditable runtime state.
8) What does an application actually consume?
The primary local HTTP surface is
http://127.0.0.1:9095/contract.
GAL-2 Node also supports local shared-memory publication and the GAL-2 SDK Provider for application integration.
Core Time Contract fields include
gal2_time,
safe_to_consume,
mode,
reason,
valid_until,
uncertainty_ms,
holdover_age_sec,
monotonic_sequence,
and source_lineage.
9) What is the difference between the GAL-2 API and GAL-2 Node?
The Protected Core creates GAL-2 Time and the GAL-2 API delivers it.
GAL-2 Node receives that trajectory and makes it locally consumable beside the application, adding local continuity, uncertainty handling, controlled recovery, Time Contract governance, SHM publication, and SDK Provider integration.
The Time Contract then tells the enrolled application whether the current GAL-2 publication is safe to consume.
10) Do I have to install GAL-2 Node to use GAL-2?
No. GAL-2 supports two consumption paths.
Applications can call the GAL-2 API directly when they do not require Node-managed local continuity.
GAL-2 API + GAL-2 Node is the recommended resilient path when time becomes committed application state and the workload benefits from local HOLDOVER, uncertainty, controlled recovery, Time Contract governance, and low-latency local delivery.
11) What is API Quickstart / RapidAPI for?
API Quickstart is the fastest way to explore GAL-2 Time directly before installing the local Node.
It is useful for API exploration, development, integration testing, and workloads that do not require Node-managed local continuity.
12) How do I get started with GAL-2 Node?
Start by activating GAL-2 API access.
Download the appropriate GAL-2 Node v1.0.0-rc11 technical evaluation
package for Linux ARM64 or macOS Apple Silicon, verify the release
identity, install the Node, configure your API credentials securely,
and confirm the local Time Contract at
http://127.0.0.1:9095/contract.
Linux AMD64 / x86_64 is additionally available as an RC11 evaluator package for approved independent technical evaluation and reproducibility testing.
Then connect the application once through the supported local GAL-2 interface.
13) Does GAL-2 Node require paid API access?
Normal commercial GAL-2 Node LIVE operation requires an active GAL-2 API credential with sufficient entitlement.
Approved independent evaluators may receive temporary evaluator credentials under the applicable evaluation terms.
The two decisions remain separate: backend entitlement decides access; the Time Contract decides safe consumption.
14) What happens with no valid GAL-2 API access?
The Node must not treat missing or invalid entitlement as permission to silently substitute raw host time.
Without valid upstream access, the protected GAL-2 path cannot enter normal API-backed LIVE operation. Application behavior remains governed by the available contract state and declared policy rather than silently falling back to the host clock.
15) Can we start with only one workflow?
Yes. A company can begin with one enrolled workflow: ledger writes, audit events, authorization decisions, ordering-sensitive jobs, cache expiration, event ingestion, Y2038 boundary handling, or another path where time becomes state.
Enrollment does not require rewriting every timestamp operation. The intended model is to connect the application to the Node-supported provider path once and govern protected time consumption there.
16) What platforms are supported?
GAL-2 Node v1.0.0-rc11 is currently available as a Technical Evaluation Release for Linux ARM64 and macOS Apple Silicon.
A Linux AMD64 / x86_64 RC11 evaluator package is also available for approved independent technical evaluation and reproducibility testing.
17) Why do I need GAL-2 if I already have GNSS?
GNSS can provide an upstream timing reference. GAL-2 operates at a different boundary: what the application should consume when the governed timing path is healthy, stale, unavailable, operating under continuity policy, or recovering.
GAL-2 does not replace GNSS. It adds an application-facing governance decision downstream.
18) Why do I need GAL-2 if I already use PTP or a grandmaster?
PTP and grandmasters distribute precise infrastructure time. GAL-2 does not replace them.
GAL-2 sits closer to the application and governs whether an enrolled consumer should use GAL-2 Time, continue under bounded HOLDOVER, recover directly to LIVE, use REJOIN when reconciliation is needed, or FAIL_CLOSED when safe consumption can no longer be justified.
19) Does GAL-2 discipline or modify the host clock?
No. GAL-2 Node does not discipline, steer, or modify the host system clock.
Existing NTP, PTP, chrony, GNSS, hardware timing, and other system timing infrastructure can remain in place. Applications that are not enrolled in GAL-2 continue using their existing timing path.
20) Why not just use a monotonic clock?
A monotonic clock is useful for local ordering and elapsed-time measurement,
but it does not by itself provide GAL-2 source lineage, validity windows,
uncertainty policy, bounded HOLDOVER, controlled recovery,
FAIL_CLOSED semantics, or an application-facing
safe_to_consume decision.
GAL-2 provides a governed contract around application time consumption, not merely a local counter.
21) Is GAL-2 competing with timing hardware companies?
GAL-2 is designed to be complementary to existing timing infrastructure.
Customers can keep GNSS, PTP, NTP, chrony, grandmasters, atomic references, hardware clocks, timing receivers, and existing synchronization infrastructure while adding GAL-2 at the application-consumption boundary.
22) What does safe_to_consume=false mean?
It means the current GAL-2 contract does not authorize the protected application path to consume GAL-2 Time for the governed operation.
The application should block, defer, return an explicit error, fail closed, or apply its separately defined business handling. The protected GAL-2 interface must not silently switch to raw host time.
safe_to_consume is authoritative.
Applications should not infer safety solely from the descriptive
mode field.
23) What happens when fresh upstream GAL-2 Time becomes unavailable?
GAL-2 Node can continue from the last valid GAL-2 state under bounded HOLDOVER policy while uncertainty grows according to the declared model.
HOLDOVER is not raw host-time substitution and is not an independent recreation of the Protected Core.
If safe consumption can no longer be justified,
the protected path transitions to
safe_to_consume=false and can FAIL_CLOSED.
24) What happens when fresh upstream GAL-2 Time returns?
Recovery is controlled.
If the fresh GAL-2 state can be safely accepted without reconciliation, the Node may return directly to LIVE. If reconciliation is required, the Node can use REJOIN before returning to normal LIVE operation.
REJOIN is therefore used when reconciliation is needed; it is not required for every recovery.
25) Does GAL-2 remediate Y2038?
Yes, at GAL-2's declared application boundary: Y2038 application-state remediation at the commit boundary.
Platform remediation fixes the underlying time representation:
operating systems, kernels, firmware, runtimes, database schemas,
legacy binaries, and 32-bit time_t dependencies still
require their appropriate platform-level remediation.
GAL-2 operates at a separate layer. For enrolled application paths, the Time Contract provides an explicit governed decision before a Y2038-style timestamp failure can become trusted or committed application state.
26) Does GAL-2 address leap-second-like discontinuities?
GAL-2 can govern application behavior around timing discontinuities for consumers enrolled through the protected GAL-2 path.
Controlled fault-injection experiments have evaluated leap-like duplicate/stall behavior, backward and forward time displacement, and a frozen upstream source at the governed application-facing path.
These experiments characterize application-facing fault containment. They should not be interpreted as an independent metrological claim about arbitrary UTC-reference error correction by the Protected Core.
27) Can applications bypass GAL-2 and still be protected?
No.
GAL-2 protects enrolled application paths. If software bypasses the supported GAL-2 interface, reads raw system time independently, and uses that value for protected state-changing operations, that behavior is outside the GAL-2 protection boundary.
28) What public evidence exists today?
GAL-2 has public evidence covering governed timeline continuity, bounded HOLDOVER and recovery behavior, FAIL_CLOSED behavior, restart continuity, Y2038 application-boundary testing, prospective 72-hour pre-metrology characterization, and controlled application-facing temporal fault injection.
The controlled temporal discontinuity suite evaluates a leap-like duplicate/stall, an explicit backward step, a forward displacement, and a frozen upstream source. The separate 72-hour prospective characterization contains 51,841 samples and captures an unplanned approximately 18.34-hour local Internet outage.
These artifacts support the claims described by their individual experiments. They do not establish UTC(k) traceability, independent metrological validation, universal timing accuracy, or correction of arbitrary upstream reference errors by GAL-2 Time itself.
29) What does the Solstice 7D dataset show?
The Solstice 7D dataset records a seven-day GAL-2 governed timeline characterization with 508,548 observed samples and no reported application-facing backward steps in the published run.
It is continuity evidence under the declared experiment conditions, not a universal metrological accuracy claim.
30) What does the 5-Day Adversarial run show?
The pre-registered 5-Day Time Contract Adversarial Characterization captured 14,397 contract samples and 14,397 consumer rows.
The published results report
0 fetch failures,
0 monotonic_sequence backward steps,
and 0 gal2_time backward steps.
During the hard interruption phase, GAL-2 entered
FAIL_CLOSED with
health=red and
safe_to_consume=false
after hard policy expiration.
31) What should a serious GAL-2 evaluation measure?
A serious evaluation should characterize the actual protected application path: contract safety decisions, application-facing monotonic behavior, local decision latency, HOLDOVER progression, uncertainty growth, recovery behavior, FAIL_CLOSED behavior, restart continuity, SHM and Provider behavior where used, source lineage, release integrity, and raw-versus-GAL-2 application behavior under the same controlled impairment.
A stronger scientific evaluation should additionally use an independent timing reference, a common measurement timebase, and an explicit uncertainty budget appropriate to the measurement claim being tested.
32) What would make GAL-2 fail an evaluation?
A protected GAL-2 path should be considered failed if it silently substitutes raw host time, permits a contract-declared unsafe value to proceed as though it were safe, violates required progression or monotonic guarantees, continues beyond declared policy without the required unsafe/fail-closed outcome, materially misrepresents contract state, or cannot support its claimed behavior with evidence.
33) Is the GAL-2 Protected Core public?
No.
The protected mathematical model, governance engine, backend implementation details, credentials, and protected IP are not distributed as customer source code inside GAL-2 Node.
Customers interact with supported GAL-2 surfaces: the API, GAL-2 Node, Time Contract, SHM publication, SDK Provider, signed release artifacts, policy information, and public validation evidence.
34) How should a protected core be evaluated?
Through observable behavior and independently inspectable evidence.
Engineers can characterize Time Contract fields, safety decisions, state progression, HOLDOVER limits, uncertainty behavior, recovery, FAIL_CLOSED behavior, source lineage, local Provider behavior, release hashes, signed artifacts, public datasets, and reproduced outputs without requiring disclosure of protected IP.
35) Why should engineers trust a controlled implementation?
They should not be expected to trust it merely because GAL-2 says it works. They should test the observable contract.
A serious evaluation should verify whether
safe_to_consume,
mode, reason, validity, uncertainty,
sequence behavior, lineage, HOLDOVER,
recovery, restart behavior, and FAIL_CLOSED outcomes
match observed system behavior.
The trust model is evidence-backed: frozen release identity, hashes, signed release artifacts, public datasets, and reproducible characterization where available.
36) Are GAL-2 Time Contract responses individually signed?
GAL-2 Node release packages are distributed with release-integrity mechanisms appropriate to their platform, including exact SHA-256 package identity, Linux signing artifacts, and Apple signing and notarization for the macOS package.
That should not be confused with claiming that every individual Time Contract response carries its own cryptographic signature. Per-response signing should only be claimed when that capability is explicitly implemented, documented, and verified.
37) Can GAL-2 be used in regulated or safety-critical environments today?
GAL-2 Node v1.0.0-rc11 is currently a Technical Evaluation Release.
Deployment into 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 deployment-specific review, appropriate independent validation, and any applicable regulatory, certification, or contractual requirements.
A Technical Evaluation Release should not be represented as automatic certification or approval for a regulated or safety-critical environment.
38) Is GAL-2 core IP for sale?
No. GAL-2 core IP, protected mathematical model, Protected Core governance logic, and ownership are not sold as part of standard GAL-2 access.
Commercial access is provided through GAL-2 API plans, GAL-2 Node usage with authorized API access, enterprise agreements, and dedicated partner arrangements where appropriate.
39) Which API plan should I use with GAL-2 Node?
API consumption depends on the Node's configured upstream synchronization cadence and the requirements of the deployment.
Select a GAL-2 API plan with sufficient monthly entitlement for the expected Node request volume. Continuous deployments should include operating margin above their expected monthly request count.
Local application reads from GAL-2 Node do not each consume a separate upstream API request. The Node maintains the upstream GAL-2 API relationship while enrolled applications consume locally.
40) What is the best first commercial step?
Get GAL-2 API access, install GAL-2 Node on a supported RC11 platform, and connect one application workflow where time becomes meaningful state.
Define the raw-time behavior you care about, observe normal GAL-2 LIVE operation, test controlled impairment and recovery, verify the Time Contract decision, and compare the protected application path with the raw-time path.