Accept and release

ActionsArtifactVerify

Task and place

Acceptance decides whether the package may be released, and release records exactly what was released. It sits after both reviews: semantic review has spoken on meaning, technical review on build soundness, and now the maintainer weighs readiness against known limits, assembles a local release candidate, and writes down its identity. Nothing here publishes anywhere — the artifact stays local by design.

Inputs

• The semantic opinions with findings EAI-R1 and EAI-R3 opened and closed: the filled EAI review record, the candidate review record, and the R3 review record.
• The engineering opinion on the exact version with its recorded runs.
• The scope card, source inventory, and decision records behind the covered norms: the candidate scope card, candidate source inventory, EAI tariff decision, EAI threshold decision, and EAI premium-base decision.
• The candidate directory itself, unchanged since the reviews ran.

Actions

• Confirm readiness item by item: scope card complete, pins holding, suites green with fixed expectations, both opinions written, no open finding that changes an answer. A finding fixed only in a review copy still blocks: the candidate carries the fix or carries the block.
• Write down the limits beside the verdict: uncovered branches, unreviewed provisions, unofficial source standing, review kind, and the single tool release behind every result.
• Assemble the local candidate: manifest, lock file, model files, suites with their recorded results, pinned source bytes, scope and inventory records, decision records, and both review opinions — one directory, nothing fetched.
• Record the exact identity: package name and version, namespace, lock root hash, edition and materialization labels, tool release with its binary hash, the candidate snapshot id over the file bytes, and the suite tally.
• Prove two separate assertions, never one blurred into the other. First, these bytes are the reviewed bytes: recompute the snapshot id and match it character for character. Second, these bytes reproduce the results: re-run check and test in the pinned environment and match the tallies. A matching tally alone never proves the first assertion — different files pass the same suite every day.

Decisions

• Accept, accept with noted findings, or refuse: the verdict names the version and lists every finding that travels with it. An open answer-changing finding and an accept verdict never share one record — one of them moves.
• What the identity covers: the candidate as assembled — a later edit, however small, is a different candidate with a different snapshot id. The lock file pins the dependency closure and names a root content hash; the snapshot id pins the files listed in the candidate identity record byte by byte, and only the snapshot recompute below is demonstrated end to end.
• Who may rely on the release and for what: the recorded limits answer this, not the verdict alone.

Artifact

The artifact is the local release-candidate assembly with its identity record: a directory holding every input above plus one page stating the verdict, the identity, and the limits. No external publication belongs to this stage — the command list of this tool release shows no publish step, and none was run.

EAI example

The running example is the employee accident insurance package: name kz.corpus.employee_accident_insurance, version 0.1.0, language 0.2, zero dependencies, explicit local imports. The accepted candidate covers the employer duty to insure, the twenty-two-class tariff with premium base as insured sum times rate plus the minimum floor, insurer payout for capacity loss from thirty through one hundred percent, employer reimbursement for loss five through twenty-nine, and penalty as unpaid times 0.015 times days. Sources are pinned to edition EAI_EDITION with materialization PINNED_UNOFFICIAL_COPY — an Adilet API copy retrieved 2026-09-13, sha256 pinned, local copy kept in the package. The static check reports OK and all thirty-seven candidate checks pass. The per-row tariff checks trip EAI-D1, the two boundary pairs trip EAI-D2, the fractional probe trips EAI-D3, the three premium-base probes trip EAI-D4.

Identity record for the candidate, every value read from the reviewed files or from observed tool output: package kz.corpus.employee_accident_insurance at version 0.1.0, namespace urn:kz:corpus:clir:employee-accident-insurance, lock root hash sha256:857647ad88ed96d916401cecebe83937704b79a647002b4586f7e2069c09b37b, edition EAI_EDITION at PINNED_UNOFFICIAL_COPY, candidate snapshot id 7635d197162f485ca5befe613670b0a8febb07a1c610151601f9b45fc822ec78 over fifteen files, tool release law 0.1.0 with semantics law.core/0.2 on two builds — published (binary hash sha256:c56e69e761c20f9019753c4b22c9dc7e810e290512ac763d7bb89c69ef93210d) and local (binary hash sha256:78dea06ce928547e87bd9875a2556cc663def37cbb78c8b04aa0da57839c95d7) — suite tally thirty-seven of thirty-seven on both. Findings EAI-R1 and EAI-R3 are closed in the candidate: their rules, probes, and inventory rows are part of the snapshot, and the source snapshot stays behind as the before-state, not the release. (The pre-R3 snapshot was 8e3297de…fea912 over fourteen files; its review stays on file as history.)

Pitfall

Releasing a nearby version instead of the reviewed one. A last-minute tidy — one comment added, one label reworded — produces a candidate the opinions never read, and the suite will not catch it: a scratch copy with one comment line added still passes thirty-seven of thirty-seven. The snapshot id catches it instead, moving from 7635d197… to 03e177d8… on that single line. Freeze the directory before the reviews, recompute the id, and re-run the suite: if either differs from the records, the candidate is new and the reviews reopen. A second trap is a verdict without limits: “accepted” alone invites reliance the package never earned. The EAI verdict travels with the named limits, listed below.

Verify

The stage is done when both assertions hold on fresh output: the bytes match by id, and the results match by re-run. First assertion — the same bytes (pinned tool, published build, law 0.1.0):

Terminal

$ law version

Output

law 0.1.0
semantics: law.core/0.2
std for language 0.2: 0.2.0
lawql: lawql/1 (queryResult 0.1)
binary hash: sha256:c56e69e761c20f9019753c4b22c9dc7e810e290512ac763d7bb89c69ef93210d

Run every command below from the unpacked bundle root, where the candidate sits at eai-candidate/ (the author-repository equivalent path is noted inside the script):

Terminal

$ python3 - <<'EOF'
import hashlib, sys
from pathlib import Path
d = Path('eai-candidate')  # author repo: docs/handbook/files/fixtures/eai-candidate
assert d.is_dir(), f'Candidate directory not found: {d}'
lines = []
for p in sorted(d.rglob('*')):
    if p.is_file() and p.name != 'README.md':
        lines.append(f'{p.relative_to(d).as_posix()}:{hashlib.sha256(p.read_bytes()).hexdigest()}')
assert lines, 'No candidate files collected - wrong working directory?'
digest = hashlib.sha256(('\n'.join(lines) + '\n').encode()).hexdigest()
print(f'{len(lines)} files: {digest}')
expected = '7635d197162f485ca5befe613670b0a8febb07a1c610151601f9b45fc822ec78'
if digest != expected:
    print(f'MISMATCH: expected {expected}', file=sys.stderr)
    sys.exit(1)
print('identity: MATCH')
EOF
15 files: 7635d197162f485ca5befe613670b0a8febb07a1c610151601f9b45fc822ec78
identity: MATCH

The two asserts are the point: from a wrong directory the script fails with AssertionError: Candidate directory not found: eai-candidate (exit 1) instead of hashing an empty file set into a plausible-looking digest.

Second assertion — the same results:

Terminal

$ law engine check eai-candidate
check OK: eai-candidate
$ law test eai-candidate
total: 37 checked, 37 passed, 0 failed, 0 not run; code 0

Criterion: the recomputed id matches the identity record character for character, the version string, the binary hash, the static check, and the suite tally all match, and the assembly holds every record the verdict cites. Any mismatch reopens the reviews instead of amending the record — and a matching tally with a moved id is still a mismatch.

Limits

The EAI candidate carries six honest limits. First, coverage: five branches across five articles modeled, every other unit of the act excluded by name. Second, review kind: all three opinions are AGENT reviews with no human approval. Third, source standing: PINNED_UNOFFICIAL_COPY pins bytes without official status. Fourth, tooling scope: the verdict covers law 0.1.0 only — the debug 0.1.1 build answers neither on all twenty-eight Money checks, recorded as finding EAI-R2 with the decision to support 0.1.0 only. Fifth, assumptions: the S ≥ F input constraint is assumed, not enforced. Sixth, answers: the answer-collection commands were not run on this package — the collection command refuses without a named collection, and the replay command takes a saved calculation directory this run does not produce — so the candidate offers no prebuilt answers, only reproducible runs.

Next step

Continue with Revisit after change, which replays the pipeline when the act, the model, or a dependency moves.

Sources

• Technical review — the engineering opinion this verdict builds on.
• Semantic review — finding EAI-R1 and its re-run.
• Workflow — where release sits in the pipeline.
• Why this can be trusted — what a recorded verdict does and does not promise.
• Command line — the version, check, and test commands used above.
• Diagnostics — reading refusals and warnings.

For publication after a recorded acceptance, follow Check and release a package. Keep this candidate’s tool version, source standing, review kind and other limits with its artifacts.