Turn verified claims into a consistent admission decision

Begin with the deployment's candidate digest and platform, then specify accepted signer identities and issuers, approved builders, required predicate types, and relevant source and build parameters. An image signed by an otherwise valid identity should not pass if that identity lacks authority for this repository or environment. Likewise, provenance naming the expected builder does not satisfy a source-revision constraint automatically. Give policy inputs precise meanings and versions so reviewers can test concrete examples. Avoid a generic score that lets many irrelevant successful checks compensate for one required failed condition.

Evaluate evidence only after verifying its signature, subject binding, and understood semantics. Join an SBOM or test result to the intended artifact rather than any file sharing the release name. Where a policy uses advisory or inventory information, state the scope and uncertainty it accepts instead of inventing an absolute harmlessness claim. Keep rejected and unavailable outcomes distinguishable in logs: an unauthorized builder and a temporarily unreachable evidence store require different investigation, even if both currently prevent admission. The requirements reflect an organization's chosen deployment contract, not a universal claim that every service must adopt identical rules.

After approval, ensure the runtime requests and verifies the approved content digest instead of resolving a mutable tag again. Otherwise the tag can move between checking and pulling, creating a time-of-check/time-of-use gap. An index-based approval must specify how relevant platform children are selected and checked. Observe the actual deployed identities so an incident can find running instances, not just deployment manifests. Later model downloads, dynamic plugins, or scripts fetched at startup lie outside an image-only decision unless the execution contract explicitly binds and enforces those additional identities.

Cached decisions require more than an artifact digest as the key. A formerly approved builder may be distrusted, a policy version may tighten a parameter rule, or verification material may expire. Include the relevant policy, trust, evidence, and expiry context and arrange invalidation or reevaluation when it changes. A cache hit is justified only for the same decision question within its allowed lifetime. Large cache capacity reduces misses but cannot correct an incomplete key. Persist enough decision context to explain which rules and trust material authorized an old deployment.

Missing attestations, malformed evidence, unsupported required predicates, unavailable trust updates, and explicit denials should have documented outcomes. A system configured to require verification cannot silently reinterpret an evidence-store outage as authorization. If an emergency exception is part of the authorized policy, scope its artifact and environment, limit its lifetime, record the approver and reason, and make its use observable. Test both rejection and infrastructure-failure paths before rollout. Evaluate availability effects and operational recovery alongside the enforcement goal, because an untested gate can disrupt releases even while its successful path looks correct.

The cache lab demonstrates only reuse and eviction under a fixed request stream. For each separate view, Reset, set both capacity C and stride s=4, predict the initial counts, then inspect. C=4 yields twelve hits and four misses; C=2 yields sixteen misses. The instrument has no policy or trust versions, so it cannot detect a stale authorization key. Use that limitation to identify the implementation requirement: actual decision caching must govern validity as well as retention. A high hit rate is an efficiency observation, never proof that the returned allow decision remains applicable.