Release — ปล่อย workflow ทั้งชุดพร้อมหลักฐานและทางย้อนกลับRelease the Whole Workflow with Evidence and a Rollback

1. The engineering problem

We began with a source string and end with an evidence-carrying draft. The architecture now has exact input checks, authenticated policy, typed Jev decisions, reviewed skills, bounded context, structural output validation, independent behavior tests, a separate quality gate and finite recovery. Its final accepted_draft still causes zero external effects. That boundary is a feature of the teaching workbench. A production coding service must add independently reviewed execution and effect mediation before gaining more authority.

A runtime gate answers whether one candidate may proceed under an existing release. A release gate answers whether a version of the workflow is approved to serve traffic. The companion's release_gate is explicitly a toy checklist: held-out evidence, manifest match, rollback readiness and human signoff must all be present. It does not authenticate a release authority or verify a CI artifact. Missing evidence returns review even when a runtime draft passes. In production, require signed or otherwise authenticated evidence, protected approvals and an immutable release record.

2. The boundary to design

The manifest identifies policy, skill, routing questions, quality questions, decision model, context and budgets. The fixture mode is identified too. A production manifest must additionally pin the application commit, generator model and prompt, runtime dependencies, retrieval snapshot, evaluator configuration and evaluation dataset hashes. Preserve traces with stage and reason codes while minimizing sensitive text. Monitor accepted errors, review backlog, coverage, latency and full task cost. Google SRE's monitoring guidance supplies the operational foundation [1]; this course adds AI-specific quality and escalation signals.

3. Read the implementation

Implementation excerpt from the companion. Run the complete lesson below with its imports and fixtures.

def release_gate(report):
    required = {"held_out", "manifest_match", "rollback_ready", "human_signoff"}
    if not isinstance(report, dict) or not required.issubset(report):
        return Gate("review", "release_evidence_missing")
    if not all(report[k] is True for k in required):
        return Gate("review", "release_not_ready")
    # Toy checklist only: real evidence must be verified by an independent CI/release authority.
    return Gate("pass", "tutorial_release_checklist")

Compose the complete workflow

from workbench.runtime import run, request, FixtureProvider
from workbench.core import release_gate

result = run(request(), FixtureProvider())
assert result["state"] == "accepted_draft"
assert result["external_effects"] == 0
print(result["trace"])
print(release_gate({}).state)  # review: missing release evidence

Migrate in stages. First run beside the old workflow with effects disabled and compare labeled outcomes. Next allow maintainers to consume drafts while keeping the existing review path. Increase authority only after the held-out and operational evidence justify it. Keep a kill switch and a known deterministic or human fallback. Assign owners for the skill catalog, policy, evaluation and review queue. Your new engineering responsibility is a system whose decisions, permissions and outcomes can be inspected. The model is one dependency inside that system; the architecture is the work that makes it usable.

4. Compare the outcomes

The following output comes from scripted fixtures that verify architecture behavior. It is not a measurement of live Jev accuracy, latency, or cost.

{
  "runtime": "accepted_draft",
  "manifest": "1cf6cb85fa575b38a8966615bde05f6f4622d1eaffdd49fa40f77010e1fd334c",
  "external_effects": 0,
  "production_release": "review"
}

5. Run, break, and explain

Part 15 code · Implementation · Tests: test_release_separate_from_runtime · Exercise

git clone https://github.com/Anirach/ai-core-engineering-workbench.git
cd ai-core-engineering-workbench
git checkout 18cdfcd4156d3d02acb8badf3b3a0a823113e0ed
python3 -m workbench.lesson 15
python3 -m unittest tests.test_boundaries.BoundaryTests.test_release_separate_from_runtime -v

Your turn

Write a shadow-release plan with owners, stop conditions and a rollback target. Identify every behavior-changing artifact your release must pin.

Keep three artifacts: the input you tried, the resulting state and reason, and an explanation of which boundary owns that result. Do not change an expected result merely to make a test pass.

6. Sources and limits