Abstract
This document discloses a deploy-time admission mechanism that decides whether a candidate build artifact may be applied to a running service by reasoning over the source-control commit graph (the Git directed acyclic graph, or DAG) at the moment of deployment, rather than over pipeline serial numbers, build clocks, image push order, or semantic version strings. A candidate commit is admitted only when two independent DAG relationships both hold: (1) the candidate is an ancestor-or-equal of the integration-branch HEAD (i.e. it is genuinely merged, not divergent or unmerged work), and (2) the candidate is not strictly behind the last-successfully-deployed commit that the target cluster itself records in a live state object. The decision is deliberately three-valued — PASS, REJECT, and ERROR — where REJECT signals a legitimacy failure (the deploy is disallowed by policy) and ERROR signals an evaluability failure (ancestry cannot be proven because the required commit objects are absent locally, as on a shallow or partial clone). ERROR is surfaced only after explicit object-existence probes and is never collapsed into REJECT, which eliminates the false-reject failure mode while remaining fail-closed. The mechanism additionally provides an audited break-glass override and a canary-validation protocol that replays a real historical backwards-deploy incident against the guard. This publication establishes dated, enabling public prior art over the mechanism and its salient variations. Empirically-tuned operational constants are withheld as trade secret and are not required to practice the disclosed decision procedure.
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 License.
Recommended Citation
Assuncao, gustavo matthew, "Monotonic Deploy Guard via Git-DAG Ancestry Against a Cluster-Recorded Live Commit", Technical Disclosure Commons, ()
https://www.tdcommons.org/dpubs_series/10954