Release controls · Four distinct questions

A green workflow is not one answer.

Before trusting a release, separate four questions: Is the claim reviewable? Did the intended command begin? May these exact artifact bytes advance? Where does the repository-specific release path outrun its record? KaldenFrame offers three complete MIT utilities for the first three boundaries and one fixed-scope paid review for the fourth.

Choose the boundary Check review fit locally Inspect public evidence

01 / ExplainIs the claim reviewable?

Make scope, evidence, comparison, failure criteria, limitations, and decision use explicit.

02 / AttemptDid execution begin?

Distinguish a stopped bounded preflight from an invoked command and consumed attempt.

03 / AdmitMay these bytes advance?

Evaluate exact subject, evidence, receipt, freshness, and verifier fields under one declared policy.

04 / ReviewWhere is the release path weak?

Trace one public repository and one named path into evidence-referenced implementation work.

Where a green check stops

Four questions that should not collapse into one.

Release question	Smallest matching control	Retained record
Can another reviewer see what the claim depends on?	Evidence Preflight 1.3.2 Checks whether required evidence-documentation fields are present and well formed.	A Markdown evidence card or schema-identified JSON record. It does not establish that the claim is true.
Was the job rejected before execution or actually invoked?	Attempt Boundary 0.1.0 Runs one bounded preflight before one configured command and records invocation state.	A create-only JSON attempt receipt. It does not prove absence of side effects or make the command safe.
Does this exact artifact satisfy this declared promotion policy?	Artifact Admission 0.1.1 Evaluates exact local files, evidence digests, one lifecycle receipt, freshness, and verifier tuples.	A schema-identified ADMIT or DENY record. It does not verify signatures, provenance, security, or fitness.
How do these boundaries fit one real release path?	Release Boundary Review Applies repository-specific analysis to one public GitHub repository and one named release path.	A decision map, evidence-referenced findings, and prioritized roadmap. It does not include implementation or a security audit.

Control map

Start with the missing answer, then choose the record.

01Documentation

$0 · Complete MIT utility
The result sounds persuasive, but its evidence contract is implicit.
Use Evidence Preflight when reviewers cannot quickly identify the claim's scope, provenance, comparison, failure criteria, limitations, or intended decision use.
Bring
One evidence-card JSON document or the browser worksheet fields.
Keep
Readable Markdown or schema-identified JSON.
Stops before
Truth, causality, statistical validity, safety, and fitness.
Inspect Evidence Preflight
02Execution

$0 · Complete MIT utility
A retry is unsafe until you know whether the prior command began.
Use Attempt Boundary when a stopped preflight must be distinguishable from an invoked command and the attempt receipt itself must be create-only and inspectable.
Bring
A reviewed plan, workspace root, command, resource limits, and protected paths.
Keep
Invocation, consumption, bytes, hashes, and bounded observations.
Stops before
Sandboxing, non-access proof, host trust, correctness, and safety.
Inspect Attempt Boundary
03Promotion

$0 · Complete MIT utility
Checks ran, but promotion still needs one exact local decision.
Use Artifact Admission when exact subject bytes, named evidence, a bounded lifecycle receipt, freshness, and verifier identity must satisfy a declared rule before promotion.
Bring
A policy, workspace, exact subject and evidence files, and one lifecycle receipt.
Keep
A deterministic ADMIT or DENY record tied to exact digests.
Stops before
Signature verification, provenance truth, security, compliance, and fitness.
Inspect Artifact Admission
04Architecture

$450 · Fixed-scope paid review
The uncertainty crosses workflow files, artifact identity, evidence, and the final decision.
Use Release Boundary Review when a reusable local control is not the missing piece and one real public release path needs repository-specific diagnosis and implementation ordering.
Bring
One public GitHub repository, one named release path, one decision, and non-sensitive context.
Receive
A written decision map, evidence-referenced findings, and prioritized roadmap within five business days after the start gates.
Stops before
Private access, code changes, security testing, certification, deployment approval, and guarantees.
Inspect the paid review

Why the free tools stay free

Reusable controls invite inspection. Tailored diagnosis is the paid work.

The GitHub utilities are complete enough to adopt, inspect, test, fork, and use under MIT. They demonstrate KaldenFrame's boundary discipline without publishing paid software implementations or the private review method. The review earns its price by tracing one accepted repository and returning repository-specific findings and sequencing.

01 / Public utility

Repeat one narrow local decision

Economics: $0, MIT licensed
Subject: Material you supply locally
Analysis: No repository-specific diagnosis

02 / Paid review

Diagnose one named release path

Economics: $450 USD, fixed and one time
Subject: One accepted public GitHub repository
Analysis: Repository-specific map, findings, and roadmap

03 / Still separate

Add assurance controls when the risk requires them

Not bundled: Identity, signatures, provenance, and trusted time
Not tested: Vulnerabilities, compliance, safety, and fitness
Not promised: Rollback, idempotence, correctness, or release success

Worked release scenario

A retry question, an artifact question, and an architecture question are not interchangeable.

A release job fails. First, the team inspects an Attempt Boundary receipt: the configured command was never invoked, so this wrapper did not consume the attempt. That fact does not prove every external system is side-effect free.

On the next run, the command is invoked and produces an artifact. Artifact Admission then evaluates the exact bytes and named evidence under a declared local policy. An ADMIT record still does not prove provenance or security. If the repository does not make the relationship between workflow identity, evidence, artifact, and final release decision clear, the remaining problem is repository-specific and may fit the paid review.

01
Document the intended claimEvidence fields and limitations are explicit
02
Record whether execution beganStopped preflight and invoked command remain distinct
03
Evaluate exact artifact bytesDeclared policy produces ADMIT or DENY
04
Escalate only cross-workflow ambiguityOne public repository receives tailored diagnosis

Combined boundary

Four records still do not become one universal proof.

The utilities are independent and optional. One utility's output is not automatically valid input for another, and the paid review does not certify their use. None of these surfaces establishes identity, authorship, signatures, provenance truth, complete lineage, non-access, side-effect absence, sandboxing, trusted time, vulnerability status, compliance, safety, correctness, reproducibility, release success, or fitness. Add those controls separately when the decision requires them.

Buyer FAQ

Keep the control claim smaller than the release claim.

These answers preserve the exact public-product and fixed-review boundaries.

01Do I need all three public utilities?

No. Each utility answers a different bounded question and can be used independently. Adopt only the boundary that resolves the uncertainty in front of you; no automatic interoperability or required sequence is claimed.

02Are the public utilities teaser editions for the paid review?

No. Evidence Preflight, Attempt Boundary, and Artifact Admission are complete narrow MIT-licensed utilities. The paid review is different because it applies release-boundary reasoning to one named path in one public GitHub repository and returns repository-specific findings and an implementation roadmap.

03Does Attempt Boundary prove a command had no side effects?

No. It records whether its bounded preflight stopped execution or the configured command was invoked, plus declared resource and protected-path observations. It is not a sandbox and cannot prove what unrelated processes did, what an invoked command read, or that execution was safe or correct.

04Does an Artifact Admission ADMIT decision prove a build is trustworthy?

No. ADMIT means the exact declared local inputs met the declared local policy at evaluation time. It does not create or verify signatures, establish provenance or source truth, find vulnerabilities, or prove safety, compliance, correctness, or fitness.

05When is the Release Boundary Review the better fit?

Use the fixed $450 review when the uncertainty crosses workflow files, artifact identity, evidence admission, attempt accounting, and the final release decision in one public repository. The deliverable is a repository-specific decision map, evidence-referenced findings, and prioritized roadmap; implementation and security testing are not included.

06Can I send a private repository, credentials, or customer data for the review?

No. The fixed review accepts one public GitHub repository, one named release path, one decision, and non-sensitive context. It does not accept credentials, private source, internal logs, customer data, or private-system access.

Need repository-specific diagnosis?

Check fit locally, then request the review.

The fit check fetches no repository and transmits no answers. Scope, intake, and payment are confirmed in writing before work begins.

Check review fit Request the $450 review View fictional sample