LiveFreev0.1.1MIT

Repository & release governance / 02

Artifact Admission

Turn repository evidence into an explicit admit-or-deny decision before an implementation artifact enters a governed stage.

Download package Browse source
01Exact inputs

Subject, evidence, verifier source, and selected receipt are bound by SHA-256.

02Fail-closed evaluation

Missing, malformed, stale, future, ambiguous, mismatched, or escaping inputs deny admission.

03Machine-readable result

A deterministic decision records the policy result and exact selected-receipt byte digest.

Use it when

Evidence exists, but the promotion rule is still a conversation.

Artifact Admission is for teams that need a repeatable local gate between “the checks ran” and “this exact implementation may advance.” A declarative policy names the subject, evidence, allowed lifecycle state, freshness window, and verifier identity. The evaluator either admits the exact combination or records why it does not.

Workflow

Policy, receipt, decision.

01 / Policy

Declare what may advance

Bind the subject path and digest, required evidence, lifecycle state, age limit, deny markers, and allowed verifier tuple.

Inspect policy contract
02 / Receipt

Bind the verification

Select exactly one bounded receipt matching the subject, stage, policy, evidence digests, and approved verifier source.

Inspect receipt contract
03 / Decision

Record ADMIT or DENY

Write a structured create-only result with evaluation checks and the SHA-256 of the exact selected receipt bytes.

Inspect decision contract

Quick start

Evaluate the bundled synthetic workspace.

npm install https://kaldenframelabs.com/downloads/kaldenframe-labs-artifact-admission-0.1.1.tgz 
node src/cli.mjs verify \
  --policy examples/valid/policy.json \
  --root examples/valid/workspace

Exit status 0 means ADMIT, 1 means policy denial, and 2 means invalid invocation or an unexpected runtime failure.

Included

A complete local admission surface.

  • Library and CLIVerify a workspace, hash a subject, and optionally write a create-only decision record.
  • Three JSON SchemasMachine-readable contracts for policy, lifecycle receipt, and admission decision.
  • Synthetic verifierRegenerate the bundled neutral receipt at a fixed time for reproducible orientation.
  • Adversarial testsCoverage for duplicate keys, containment, symlinks, ambiguity, freshness, mutations, and output conflicts.

Attestation ≠ admission

A signed build claim and a promotion decision answer different questions.

Artifact Admission begins after any signature or attestation verification you choose to require. It turns exact local files, evidence, one bounded receipt, and a declared policy into ADMIT or DENY. It does not perform the cryptographic verification itself.

01 / Byte identity

Are these the exact bytes named by the record?

A SHA-256 digest can bind a subject or evidence file to exact bytes.

Establishes
Equality to the named digest at the moment read.
Still separate
Authorship, build origin, signature identity, safety, and fitness.
02 / Verified attestation

Does a signed claim bind the subject to a build context?

An external attestation system can bind a subject digest to repository, workflow, commit, signer, or other predicate claims.

Requires
Cryptographic verification of signatures, timestamps, and signer identity with an authoritative verifier.
Still separate
Whether the verified claim satisfies your promotion policy or proves the artifact secure.
GitHub attestation boundary
03 / Local admission

May this exact subject advance under this exact policy now?

Artifact Admission evaluates exact subject and evidence hashes, one unambiguous lifecycle receipt, allowed state, freshness, and an approved verifier tuple.

Produces
A deterministic, schema-identified ADMIT or DENY decision bound to the selected receipt bytes.
Trust input
The policy and receipt-producing verifier remain trusted configuration outside this utility.
Inspect the handoff
04 / Broader assurance

Is the artifact correct, secure, compliant, and fit for use?

That conclusion needs evidence and controls beyond a digest, attestation, or local admission record.

May include
Vulnerability analysis, source review, testing, deployment policy, operational monitoring, and regulated assessment.
Not claimed
No KaldenFrame utility turns one narrow decision into universal assurance.

Integration boundary

An external verifier may produce a receipt. No adapter is bundled.

A release workflow can verify an attestation with the platform or trust-root tooling appropriate to that attestation. If a team wants that result to participate in Artifact Admission, a separately reviewed adapter can translate the verified result into the utility's strict receipt contract.

The adapter has to bind the exact subject digest, policy and stage, required evidence digests, verifier name and version, exact verifier source digest, lifecycle state, and verification time. Artifact Admission then checks that receipt locally. It does not re-check the signature, signer identity, transparency log, OIDC claim, or attestation predicate.

GitHub's own guidance says attestations must be verified and are not a guarantee that an artifact is secure. See the official verification guide and attestation API verification boundary.

  1. 01
    Build and attest externallyCreate the signed claim in the system that owns the build identity.
  2. 02
    Verify with authoritative toolingValidate signature, timestamp, signer identity, subject digest, and required predicate claims.
  3. 03
    Emit one bounded receiptUse a separately reviewed adapter; none is included with Artifact Admission.
  4. 04
    Evaluate local promotion policyArtifact Admission records ADMIT or DENY for the exact policy, files, evidence, and receipt.

Buyer FAQ

Keep provenance and promotion claims separate.

The answers below match the machine-readable FAQ and the v0.1.1 product boundary.

01Does Artifact Admission verify GitHub artifact attestations?

No. Artifact Admission does not create or verify signatures, trust roots, OIDC identities, transparency-log entries, SLSA provenance, Sigstore bundles, or GitHub artifact attestations. It evaluates its own strict local policy, files, evidence digests, and bounded lifecycle receipt.

02Does a verified attestation mean an artifact should be promoted?

No. A verified attestation can support a provenance claim about an exact subject digest and build context. The promotion decision still depends on a separately declared policy, required evidence, lifecycle state, freshness, verifier identity, and the risk decision being made.

03Can an attestation verifier feed Artifact Admission?

Yes, but Artifact Admission does not include an attestation adapter. An independently reviewed adapter would have to verify the attestation first and emit a strict bounded lifecycle receipt that binds the exact subject digest, policy, stage, evidence digests, verifier identity, and verification time.

04Does ADMIT prove provenance, security, or fitness?

No. ADMIT records that declared local inputs met declared policy at evaluation time. It does not establish signature validity, provenance truth, vulnerability status, source correctness, safety, compliance, or fitness.

05What if the release workflow boundary is still unclear?

The fixed $450 Release Boundary Review applies related evidence, attempt, provenance, and admission reasoning to one named release path in one public GitHub repository. It returns a repository-specific decision map, findings, and implementation roadmap, but no code changes, security audit, or deployment approval.

Repository-specific diagnosis

Map the attestation, receipt, and admission boundary in one public release path.

Check review fit View synthetic report

Earlier or later in the workflow

Document the claim first—or distinguish a stopped preflight from a consumed attempt.

Evidence Preflight Attempt Boundary Full workflow Release control guide