Policy decisions

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

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:

{
  "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

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 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 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 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.

Pushgate orchestration 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 are TestifySec orchestration and security fields—not core in-toto Statement or classic Layout fields.

The standard SLSA Verification Summary Attestation records a SLSA decision, while the newer in-toto Simple Verification Result carries generic verified properties and policy references. Pushgate’s https://pushgate.dev/verification_summary/v0.1, https://pushgate.dev/verification_summary/v0.2 and https://pushgate.dev/verification_summary/v0.3 are its own typed predicates inside an in-toto/DSSE envelope; the platform signs whichever of them the gate that asked 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, and v0.3 adds the base-ancestry observation on top of it. A failed verdict names its own cause, and under every version each of them is the same kind: the evidence was cryptographically verified, and its content did not satisfy the policy. Anything short of that — an envelope that could not be fetched, an expired certificate, a signature that does not verify — is never signed at all; it 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. 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.

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.