Bernstein 3.23.0 prevents artifact tasks from producing a signed success receipt when their acceptance criteria fail. The release also preserves completion declarations through plan loading, adds stronger evidence checks and documents several upgrade hazards for teams running multiple AI coding agents.
The 3.23.0 release notes list 105 changes since 3.22.0. They carry no publication date; October 25, 2026 is the earliest verified crawl date available for this report, not a confirmed release timestamp.
Bernstein sits above command-line coding agents. According to the project homepage, its deterministic Python scheduler runs agents in separate Git worktrees, checks their changes and merges passing work. The project describes itself as beta software built by one primary maintainer.
This article analyzes the published documentation, without independently testing the controls. The key operational question is whether a run’s completion decision, acceptance criteria and evidence remain connected from planning through certification.
Artifact Completion Now Checks the Contract
Bernstein 3.23 enforces criteria declared in artifact_spec alongside completion signals. The release notes state:
“A failed criterion cannot produce a signed success receipt”
That closes a specific gap: an artifact could appear finished without satisfying the conditions attached to its delivery. The new behavior makes those criteria part of the completion decision. The change is documented under issue #6638 in the release notes.
For operators, the practical consequence is that previously successful-looking workflows may now fail certification. That can expose an incomplete deliverable, an unrealistic requirement or a stale contract. Those possibilities need different remedies, so treating every newly rejected task as a regression would miss the point.
I’d make artifact-contract review the first migration task. A stricter gate is useful only when the declared criteria describe the intended result. Signing provides evidence about the recorded outcome; the quality of that outcome still depends on what the contract requires.
This distinction matters for research dossiers, datasets and audit packs as well as code. A completion signal and a satisfied artifact contract answer different questions, and 3.23 checks both.
Plans Preserve Signals, While Policy Failures Stop Startup
Plan loading now preserves all eleven native completion-signal types. Malformed declarations fail before dispatch, according to the release notes. Operators can therefore catch a declaration problem before agents begin work.
The release also gives manager, planner and backlog task bodies a shared builder that preserves completion signals and allowed context metadata. Together, these changes address two separate risks: accepting invalid declarations and losing valid ones as tasks move between components.
A separate policy fix preserves the selected absolute seed path across server launch, supervisor restart and watchdog recovery. An unavailable or invalid policy causes refusal.
That detail deserves attention during upgrades. A successful initial launch is only one operating condition; a restarted service must retain the same policy selection. A sensible staging check is therefore to exercise recovery paths with the configured policy location, including the expected refusal when that policy is unavailable.
Administrative Runs Add Audited Grouping Without Workers
New administrative runs group manually claimed tasks under an audited container without starting a planner or worker. Certification checks membership, tenant boundaries and aggregate completion against the installation audit chain.
The documentation explicitly warns that the receipt hash alone cannot authenticate the aggregate. The practical implication is that checking a container’s hash is insufficient: certification also depends on evidence about its membership and completion.
Bare MCP and REST tasks can now enter the signed claim/completion lifecycle without duplicate backlog rows. These changes extend the documented lifecycle to work initiated outside the usual orchestrated flow. They do not make administrative runs an execution engine. Source: Bernstein 3.23.0 release notes
Audit Evidence Separates Matching Hashes From Attestation
Run archives can now anchor their manifest digest in a verified HMAC audit log. Bernstein reports file-hash checks separately from attestation: a rewritten manifest remains unattested even if its recomputed hashes agree.
The distinction is consequential. Matching hashes can show that files agree with a manifest. If someone rewrites both, that agreement alone cannot show that the manifest is the previously recorded one. Anchoring its digest in the verified audit chain supplies a separate check.
The release notes also say installed packages now include the standalone audit-receipt verifier, allowing both receipt-verification commands to work outside a source checkout.
Bernstein’s homepage describes two different key requirements:
- HMAC audit-chain verification needs the key used to write the chain.
- Ed25519 receipt verification can work from the receipt without the HMAC key or local
.sdd/state. A pinned public key provides the provenance reference.
Receipt creation requires a signing key. Installing 3.23 is therefore separate from configuring signed evidence and arranging how another person will verify it.
My reading is that the archive change provides one of the release’s clearest governance improvements: it explicitly separates internal consistency from attestation. Operators should preserve that distinction in dashboards and review procedures instead of reducing every result to a single “verified” label.
Tool-Effect Evidence Requires Explicit Wiring
An attestation interlock can record toolcall.effect after a connector returns, hashing the actual response bytes. The gateway does not enable this interlock by default, and a missing effect remains unobserved.
Hardware evidence has similarly narrow semantics. Offline verification covers pinned PIV chains and retained FIDO2 enrollment/assertion evidence, but touch proves presence, not informed intent. It does not automatically authorize actions or raise the TRACE trust level. These are limits stated in the release documentation, so operators should avoid turning either record into a broader approval claim.
Leakage Checks Cover Named Outputs
The new leakage-v1 control checks seeded secrets in emitted benchmark, pack, archive, log and PR-projection bytes. Receipts retain bytes and nonces for rescanning.
The release notes identify the tested surfaces and the omissions:
| Surface or control | Documented scope |
|---|---|
| Benchmark, pack, archive, log and PR-projection bytes | Included in seeded-secret leakage checks |
| Journal, receipt, telemetry and environment surfaces | Explicitly unexercised omissions |
| PII exemptions | Apply to the benign value, not its entire line |
| Persisted DLP verdicts | Include effective policy in their cache keys |
These details appear in the evidence and policy changes. The narrower PII exemption prevents a harmless placeholder from hiding an adjacent credential. Including effective policy in a verdict’s cache key ties the cached result to the policy under which it was assessed.
Seeded-secret checks provide evidence about the exercised outputs. They cannot answer whether an omitted telemetry or environment surface leaked something. Teams should map these surfaces against their own export paths before treating a passing result as sufficient.
Scanner Provenance and Test Expansion Have Different Jobs
Bandit and Checkov adapters now record deterministic findings and invocation provenance. Checkov isolates home configuration and refuses configurations that load external checks or modules. Those restrictions make the scanner invocation more controlled, though the release explicitly describes this as part of the scanner work, not the full catalog.
Frequently Asked Questions
3 questions
1Does Bernstein 3.23 Enable Every Evidence Control?
No. Tool-effect attestation requires explicit wiring, audit and signing need configuration, and some checks remain optional. Leakage checks also have documented surface omissions.
