Follow the requirements behind a gate
See repository gates, the check library, a refusal, and the history of approved changes.
Follow along
Goal: trace one repository decision back to its requirements and evidence, then see how the platform manages more than one gate.
Before you start
Use a platform account with access to a test product and connected repository. Complete the push walkthrough so there is a decision to inspect. The platform data model defines the underlying objects.
1. Start with a particular change
In the repository, copy the commit identifier:
git rev-parse HEAD
cilock pushgate status --remote origin --wait
Expected: a delivery result for that same commit. Save the repository, ref, commit, and decision identifier. These let you find a specific event rather than relying on the latest activity in a busy project.
2. Inspect the gate
Open the connected repository in Pushgate and inspect its policy assignment. Record the immutable policy release selected for the repository, the required checks, and Block or Warn behavior. A policy displayed in the library is not necessarily active at this gate.
Expected: you can identify which requirements governed this particular request. A current assignment may differ from the historical assignment used for an older decision.
3. Inspect the policy and evidence
Open the corresponding policy release in the platform. Follow the decision's evidence references and compare their step names, subjects, producers, and results with the policy. Use the identifiers bound to the decision rather than a similarly named policy or the newest evidence entry.
Expected: an explanation of why this request met or failed its configured requirements. Evidence existence alone does not imply policy success.
4. Compare another gate
Repeat steps 1–3 for a second connected test repository if you have one. The platform is the shared control plane; each gate applies requirements at its own checkpoint. Do not assume that every existing CI or deployment tool is automatically connected or enforcing the same requirements.
5. Review a proposed policy change
An agent may prepare a draft, explain its effect, and identify the target release. Have the authorized human review and approve the repository assignment in Pushgate. Publishing the signed policy and activating it at a repository are separate actions.
Expected: the selected immutable release is visible after assignment, and the next request is evaluated under that assignment. Do not infer approval from an agent's description or a successful policy upload.
Troubleshooting and next steps
If a policy is visible but has no effect, check the repository assignment. If evidence cannot be connected to the decision, treat the explanation as incomplete. Follow the trust architecture for decision binding and the platform model for technical-control mappings. This guide covers repository gates; configure other gates and control mappings separately.