Release — รวม pipeline แล้วตรึงรุ่นCompose the Pipeline and Release Gate

Part 12 of twelve. Compose the full workflow, preserve audit evidence and distinguish runtime acceptance from the release gate.

Default decisions and draft text are authored mocks, not live Jev results. Use the tutorial with the matching companion code, tests and exercise linked to a fixed GitHub version.

Outcome and prerequisites

Use Node22.18+ and a terminal. Clone the GitHub companion using its README, or download the complete ZIP, extract it and enter ai-core-functional-lab. No npm install, API key or network inference is needed. The reading-time label excludes about25–45 minutes of hands-on work. Keep one reference copy and make exercises in another.

Download companion ZIP · README / lesson map

This part focuses on src/pipeline.mjs. Expected gate states describe content and continuation; no state sends a message or changes a real account.

Old functions and the new boundary

A composed workflow is a graph of explicit contracts, not one long prompt. Every stage has a reason to exist and a state that controls continuation. The pipeline makes the order reviewable and returns an audit trail instead of hiding uncertain or failed operations.

The runtime acceptance gate evaluates one candidate under the current policy. The release gate evaluates a frozen system against held-out evidence. Passing one request can never establish that a new model, threshold or fact revision should be deployed to all users.

The author’s existing AI-Core context emphasizes contracts, constraints and verification. This lab applies those ideas while leaving authority over effects in code. Merely calling Jev inside a function does not prove that a deployed system is autonomous or that the model is indispensable to its core.

Seven practical steps

Step 1

Read the pipeline from input_code to quality_gate and identify every early return. Make sure reject and human_review stop work, revise is bounded and accept returns a draft artifact rather than an external operation.

Step 2

Run V001 and record its four provider calls. Then run V008 and compare its terminal review and revision history. Success and controlled refusal are both expected system behaviors.

Step 3

Inspect config/release.json alongside report context. Freeze the model ID, question version, policy, facts, dataset and implementation hashes. A label such as v1 without the corresponding bytes is not a reproducible experiment.

Step 4

Run the held-out release command and accept that the reference gate rejects. H010 exposes a false accept, so a green unit-test suite is insufficient to release this candidate. Do not loosen the release rule to make the demo green. Its process exit code is2; shell/CI must treat every non-accept as a failed release gate, while the test suite verifies that this refusal is correct.

Step 5

Read the release-gate tests for a validation split and unknown total cost. Validation cannot approve release; missing cost can require review even when false accepts are zero. The toy coverage threshold is a teaching rule, not a production acceptance standard. Required metrics are validated before comparisons: absent, nonfinite, wrong-typed or contradictory counts, ratios and cost fields reject the report instead of silently passing.

Step 6

Prepare an operational checklist for a future authorized shadow run: independent labels, language slices, timeout/retry traces, human review ownership, rollback trigger and no external effects. This repository implements no deployment or public publishing command.

Step 7

Run the complete test suite and preserve the report with its source hashes. Keep this local companion and tutorial review together. Publishing code and publishing the website are separate actions that remain pending approval.

Files and runnable commands

Open the exact source and read its dependencies before editing. This is runnable reference code, not a fictional AI-Core SDK. The source links point to a fixed version of the public GitHub companion.

src/pipeline.mjs · Matching tests · This lesson’s exercise

import {gate,parseDecision} from './contracts.mjs';
import {checkInput} from './input.mjs';
import {authorizeInput,validatePolicy} from './policy.mjs';
import {requestShape} from './questions.mjs';
import {semanticInput,semanticOutput} from './semantic.mjs';
import {checkOutput} from './output.mjs';
import {qualityGate} from './quality.mjs';
import {traditionalReply} from './generation.mjs';
import {CallBudget} from './budget.mjs';
export async function runPipeline(raw,{provider,facts,policy,signal}={}) {
  validatePolicy(policy);
  const budget=new CallBudget(policy,{signal}),history=[];
  const finish=g=>({...g,history,attempts:budget.attempts,calls:budget.used,externalEffects:0});
  const record=(stage,g)=>{history.push({stage,state:g.state,reasons:g.reasons});return g};
  try {
    if(signal?.aborted) return finish(gate('human_review',['cancelled']));
    let g=record('input_code',checkInput(raw));if(g.state!=='accept')return finish(g);
    const input=g.value;
    g=record('authorization',authorizeInput(input));if(g.state!=='accept')return finish(g);
    const judge=async(stage,draft)=>parseDecision(stage,await budget.call(stage,requestShape(stage,input,facts,draft),provider));
    g=record('input_semantic',semanticInput(await judge('input'),policy));if(g.state!=='accept')return finish(g);
    for(let draftNo=1;draftNo<=policy.maxDrafts;draftNo++) {
      const fallback=draftNo>1&&policy.fallback;
      const draft=fallback?traditionalReply(input,facts):await budget.call('generate',{input,facts,draftNo},provider);
      history.push({stage:'generation',draftNo,provider:fallback?'deterministic_template':'mock_generator'});
      g=record('output_code',checkOutput(draft,input,facts));
      if(g.state==='reject')return finish(g);
      if(g.state==='accept') {
        g=record('output_semantic',semanticOutput(await judge('output',draft),policy));
        if(g.state==='reject'||g.state==='human_review')return finish(g);
        if(g.state==='accept') {
          g=record('quality_gate',qualityGate(await judge('quality',draft),policy));
          if(g.state==='accept')return finish(gate('accept',['artifact_accepted_not_authorized_to_send'],draft));
          if(g.state==='human_review'||g.state==='reject')return finish(g);
        }
      }
      if(draftNo===policy.maxDrafts)return finish(gate('human_review',['revision_budget_exhausted']));
    }
  } catch(e) {return finish(gate('human_review',[e.code??'invalid_response_or_provider_failure']))}
  return finish(gate('human_review',['no_terminal_result']));
}

Offline commands:

node src/cli.mjs run --case V001
node src/cli.mjs run --case V008
node src/cli.mjs release --split heldout
node --test --test-reporter=spec

Expected output and verification

V001 accepts an artifact; V008 reviews after two drafts; held-out release rejects with heldout_false_accepts. The full suite should pass because it verifies those specified behaviors, including refusal. No deployment or message sending is implemented by the lab. The release command exits2 by design; the complete passing test suite exits0. Exit1 means a command/evaluator error.

Inspect reasons, history and every attempt rather than only the final label. Unknown usage must remain unknown. A green test demonstrates the specified code path, not universal semantic safety.

A failure to understand

A team may mistake all tests pass for ready to release. Here a deliberately weak semantic fixture passes its runtime gates but fails the held-out release criterion. The release rejection is the intended educational result, not a broken test to delete.

Exercise in a disposable copy

Draft a release record for a hypothetical fact change. Specify what must be revalidated and how you would roll back. Keep the original held-out report unchanged and create a new validation version before considering another candidate.

Follow the matching exercise file, retain the original and restore the reference before the next chapter. Do not use held-out results to choose a threshold.

Troubleshooting

If the report lacks source hashes or per-case traces, do not certify the release from a copied screenshot. Reproduce the run from the exact local companion version and retain the full evidence file. An exit2 from the documented held-out release demo is expected; do not change it to exit0 merely to make a command runner green. Command verification must check the expected status explicitly.

Next checkpoint

Before continuing, name the property that code checks exactly, the judgment that may be wrong, the state that stops work and the evidence needed before release.

← Previous lesson · Return to series

Sources and version notes

Key takeaways