# Policy decisions

Source: https://www.testifysec.com/docs/pushgate/trust/policy

The immutable policy identity, repository assignment, and signed decision contract enforced by Pushgate.

Pushgate treats policy authorship, repository assignment, evaluation, and enforcement as separate operations.

 

**Diagram: Immutable policy selection and evaluation**

A signed policy release is selected by its immutable identity tuple. A repository assignment and evidence for the exact commit enter platform evaluation. The stored signed decision is checked again by Pushgate before enforcement.

Policy publication, repository assignment, evaluation, and enforcement are separate acts joined by immutable identifiers.

**Mermaid source**

```
flowchart LR
    R[Signed policy release tuple] --> A[Repository assignment]
    E[Evidence for exact commit] --> V[Platform evaluation]
    A --> V
    V --> S[Stored signed VSA]
    S --> P[Pushgate binding checks]
    P --> D{Enforce decision}
```

 

## Immutable policy identity

 

A published policy release is identified by four authoritative values:

 

json

 

```
{
  "definition_id": "canonical-lowercase-uuid",
  "release_id": "canonical-lowercase-uuid",
  "policy_gitoid": "64-lowercase-hex",
  "policy_digest": "64-lowercase-hex"
}
```

 

`policy_gitoid` identifies the exact raw DSSE envelope bytes. `policy_digest` identifies the exact decoded policy payload bytes. Names, descriptions, and release tags help people navigate a catalog; they never replace this identity or mean “latest.”

 

## Assignment is separate from authorship

 

Signing and publishing a policy does not activate it. Pushgate stores the exact selected policy authority on the connected repository. A signed-in human reviews and applies that assignment; an agent can prepare the release, explain its effect, and direct the human to the exact review.

 

## How CI/lock policy aligns with in-toto policy

 

**Diagram: How CI/lock policy aligns with in-toto policy**

Classic in-toto Layout policy and in-toto Witness policy provide two related policy models. CI/lock uses the Witness requirements model inside an immutable signed PolicyRelease. The platform evaluates an exact attestation collection and produces a Pushgate-specific signed verification summary for edge admission and receipt lifecycle handling.

CI/lock follows the signed-requirements model while Pushgate adds immutable repository assignment, admission context, and delivery lifecycle. The dotted arrow is conceptual alignment, not Layout wire compatibility.

**Mermaid source**

```
flowchart LR
    L[Classic signed in-toto Layout] -. concept map .-> C[Signed CI/lock PolicyRelease]
    W[Signed in-toto Witness policy] --> C
    E[Exact attestation collection] --> V[Exact platform evaluator]
    C --> V
    V --> S[Pushgate verification summary]
    S --> A[Edge admission + receipt lifecycle]
```

 

The [in-toto Attestation Framework](https://github.com/in-toto/attestation/blob/v1.2.0/spec/v1/README.md) standardizes Predicate → Statement → Envelope; it does not define one universal policy language. Two official in-toto policy families provide useful comparison points:

 

- The [classic in-toto Layout specification](https://github.com/in-toto/specification/blob/v1.0/in-toto-spec.md) defines a project-owner-signed layout with ordered steps, authorized functionaries, material and product artifact rules, client inspections, and expiration.
 - The [in-toto Witness policy model](https://github.com/in-toto/witness/blob/main/docs/concepts/policy.md) defines signed requirements over attestation collections: expected attestations, trusted public keys or certificate roots, timestamp authorities, artifact chaining, and Rego checks.

 

CI/lock policy uses the Witness requirements model. It is not a byte-for-byte classic Layout, so the following table is a semantic map rather than a format-compatibility claim.

 

| CI/lock and Pushgate | Classic Layout analogue | Witness policy analogue |
| --- | --- | --- |
| Requirements grouped into policy steps | Required supply-chain steps | Steps and expected attestation types |
| Trusted certificate constraints and public keys | Authorized functionaries | Functionaries, roots, and public keys |
| Commit and evidence subjects | Materials and products | Collection subjects plus `artifactsFrom` chaining |
| Predicate constraints and Rego | Artifact rules and client inspections serve an analogous gate role | Per-attestation Rego and cross-step constraints |
| Immutable signed PolicyRelease | Project-owner-signed layout | DSSE-signed Witness policy |
| Exact platform evaluator | Consumer runs `in-toto-verify` | Consumer verifies the attestation collection against policy |
| Signed Pushgate decision | No direct Layout field | Portable verification-result pattern |

 

### Pushgate orchestration fields

 

These are TestifySec orchestration and security fields, not core in-toto Statement or classic Layout fields: tenant and immutable repository binding, the release UUID + gitoid + payload digest tuple, push nonce scope, RFC 3161 requirements, repository activation and admission mode, and the receipt lifecycle.

 

#### Pushgate’s own verification-summary predicates

 

The standard [SLSA Verification Summary Attestation](https://github.com/in-toto/attestation/blob/main/spec/predicates/vsa.md) records a SLSA decision. The newer [in-toto Simple Verification Result](https://github.com/in-toto/attestation/blob/main/spec/predicates/svr.md) carries generic verified properties and policy references.

 

Pushgate has five typed predicates of its own, carried inside an in-toto/DSSE envelope:

 

text

 

```
https://pushgate.dev/verification_summary/v0.1
https://pushgate.dev/verification_summary/v0.2
https://pushgate.dev/verification_summary/v0.3
https://pushgate.dev/verification_summary/v0.4
https://pushgate.dev/verification_summary/v0.5
```

 

The platform signs whichever of them the asking gate said it can read, so a gate is never handed a version it cannot parse. They differ only additively:

  

v0.2

adds the observed coding-agent record.

 

v0.3

adds the base-ancestry observation on top of it.

 

v0.4

adds, on a failed release verdict, each failed step with the command that produces its evidence.

 

v0.5

adds, on each passing release step, the evidence that satisfied it, separate from every input the evaluator examined.

  

They follow the same portable-result pattern while binding the repository and fresh push context that Pushgate must verify. They do not claim either standard predicate schema.

 

#### What a signed FAILED means, and what it does not

 

A failed verdict names its own cause. Under every version each of them is the same kind: the evidence was cryptographically verified, and its content did not satisfy the policy.

 

The one other failed verdict is about the release, not the evidence. A trusted release past its expiry is answered FAILED with "release expired, re-sign it", so a Warn assignment warns and a Block assignment refuses.

 

Anything short of that is never signed at all. An envelope that could not be fetched, an expired certificate, a signature that does not verify: each is a refusal to answer rather than a verdict.

 

Widening a signed FAILED to also cover evidence that was read and found cryptographically invalid, so that a dead attestation yields an answer instead of a refusal, would be a new meaning needing a version of its own. It is not in effect today, and the predicate version is what tells a reader which meaning applies.

 

## Policy decision contract

 

The platform evaluates evidence for one exact commit and policy question. A signed decision is usable only when it binds all of the following:

 

- tenant
- canonical repository route
- immutable repository ID
 - commit
- fresh push nonce and nonce scope
- exact policy authority or digest
 - outcome
- bounded evidence descriptors

 

### Decision outcomes

 

A valid VSA carries `PASSED` or `FAILED`. Operational errors are not rewritten as a passing or failing policy result, and Pushgate does not reconstruct a missing signed decision at the edge. This keeps “the policy denied this commit” distinct from “there is no trustworthy decision to enforce.”

 

## Override boundary

 

An authorized, bounded human override targets the exact failed signed decisions for one push. It does not manufacture passing decisions and cannot authorize missing, malformed, mismatched, or unstored decision provenance.

Reference generated from the product documentation. Match commands and support details to your installed release.