# Follow the requirements behind a gate

Source: https://www.testifysec.com/docs/platform/gates-walkthrough

See repository gates, the check library, a refusal, and the history of approved changes.

See repository gates, the check library, a refusal, and the history of approved changes.

[Jump to the written guide ↓](https://www.testifysec.com/docs/platform/gates-walkthrough#follow-along)

## 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](https://www.testifysec.com/docs/pushgate/walkthrough) so there is a decision to inspect. The [platform data model](https://www.testifysec.com/docs/platform/data-model) defines the underlying objects.

 

### 1. Start with a particular change

 

In the repository, copy the commit identifier:

 

```sh
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](https://www.testifysec.com/docs/pushgate/trust-architecture) for decision binding and [the platform model](https://www.testifysec.com/docs/platform/data-model) for technical-control mappings. This guide covers repository gates; configure other gates and control mappings separately.

[Browse the other walkthroughs](https://www.testifysec.com/resources#walkthroughs)