Jev Lab — ตั้งแล็บก่อนวัดผลBuild the Lab — AI-Core + Jev in Practice

Part 1 of ten: Run the offline Node lab, separate Codex authoring from Jev runtime decisions, and define the experiment before claiming speed or savings.

Local review draft • Default code uses offline fixtures. Numbers are fictional scenarios, not measured Jev results. Faster performance and lower cost remain hypotheses.

Outcome and prerequisites

git clone https://github.com/Anirach/ai-core-jev-tutorial.git
cd ai-core-jev-tutorial
node src/cli.mjs doctor

Start with the companion repository and its detailed README. The website ZIP remains an alternative offline snapshot; run the same Node commands from either project root. GitHub repository · README / Quickstart

Use the same Support Ticket Decision Lab throughout the series. Have Node 22.18+, a terminal and a writable directory. Run commands from the cloned ai-core-jev-tutorial root, or the extracted ai-core-jev-lab folder if using the website ZIP. Offline work needs no npm install. Allow roughly 20–40 minutes for experiments; the article reading-time label excludes hands-on work.

Download the complete code and tests (ZIP) · Project README

This chapter focuses on src/questions.mjs. Fixture outputs test the integration mechanics only. The author did not install the SDK or use an API key while preparing the lab. The separately documented live path has not been tested against the API.

How this boundary works

Treat this as an engineering lab, not a promise that a cheaper model makes an application better. We build one support-ticket workbench in which code owns schemas, permissions, evaluation and effects. Codex can help author that code. Jev is a separately called runtime decision component. Our starting application produces proposals; it cannot refund money, contact customers or change an external help desk.

The existing Engineering AI-Core Systems series supplies the assurance principles. Reusing those principles does not make every classification endpoint an autonomous AI-core system. In this lab, human approval bounds the action path. Classify the authority and indispensability of your eventual deployed system using the original series, rather than giving this teaching example a stronger label than its behavior supports.

Download the complete reference implementation once and keep the same folder through all ten parts. The repository already contains the solution so every chapter can be reproduced independently; the learning task is to trace, modify and test one boundary at a time. Offline fixtures are hand-authored responses, not captured Jev inference. No SDK installation, API account or paid call is needed for the default path.

Seven practical steps

Step 1 — Get the project

Get the project. Clone the companion repository and enter ai-core-jev-tutorial, or use the website ZIP and enter ai-core-jev-lab. Run terminal commands there, not inside the website blog directory. The commands below target macOS/Linux or a comparable shell; Windows users can use a suitable terminal without changing the JavaScript modules.

Step 2 — Check the runtime

Check the runtime. doctor rejects Node versions below 22.18, validates all ticket IDs and texts, and reports MOCK as the default. A successful check says the environment can run the exercises; it says nothing about model quality or whether an API account is eligible for access.

Step 3 — Map the files

Map the files. data/tickets.json contains synthetic inputs and evaluation labels. providers.mjs receives only validated input fields; the labels stay in the evaluator. config/policy.json controls abstention, while prices.example.json contains explicit scenario assumptions. Keeping these concerns separate prevents a label or price from silently becoming model context.

Step 4 — Inspect one request before running it

Inspect one request before running it. The request command prints a pinned model ID, one ticket text and two named questions. It performs no inference. Confirm that goldRoute, goldHuman and internal pricing are absent. This small inspection is more useful than assuming a well-typed object cannot leak evaluation answers.

Step 5 — Run T-001 in baseline mode

Run T-001 in baseline mode. Read the evidence label first: this is a simulated generative-response fixture. The returned billing route is a proposal, not a completed action. Keep its trace as a reference before adding the Jev branch, so later changes have something concrete to compare against.

Step 6 — Run the same ticket in hybrid mode

Run the same ticket in hybrid mode. For this fixture, the Jev-shaped response is sufficiently concentrated under our demonstration policy and no baseline fallback is called. Read attempts rather than guessing from the final route; two pipelines can return the same answer while making different numbers of calls.

Step 7 — Run the tests before editing

Run the tests before editing. The tests cover invalid values, refusal paths, unknown usage, label leakage and approval boundaries. Make one deliberately invalid local change only in a disposable copy, observe a failing test, and restore it. A green suite is a starting artifact, not evidence that a live model is correct.

Files and commands

Companion code on GitHub: ai-core-jev-tutorial · README. Use the companion repository as the default working copy. These file links pin the tested revision. src/questions.mjs · src/cli.mjs

Compare this file with the source in the ZIP before editing. The listing is the implementation used by the lab, not pseudocode. Model output is input to validation and routing code; it grants no permission to bypass approval.

src/questions.mjs

export const ROUTES = Object.freeze({billing:'Invoices, payments, or subscription charges',technical:'Software defects or integration failures',other:'Neither billing nor technical'});
export const ROUTE_QUESTION='Which support team best fits this ticket?';
export const HUMAN_QUESTION='Does the customer explicitly request a human agent?';
export function requestShape(ticket) {
  return {model:'jev-1.13.0',state:{ticket:ticket.text},questions:{route:{type:'choice',instructions:ROUTE_QUESTION,criteria:{...ROUTES}},wantsHuman:{type:'noul',instructions:HUMAN_QUESTION}}};
}

Run these offline commands without an SDK installation or API key:

node src/cli.mjs doctor
node src/cli.mjs request --ticket T-001
node src/cli.mjs demo --mode baseline
node src/cli.mjs demo --mode hybrid
node --test --test-reporter=spec

Verify the expected behavior

doctor should report 40 tickets, MOCK, and zero paid calls. Both T-001 demonstrations propose billing; only the hybrid fixture uses the Jev-shaped provider. Do not compare the scenario latency values with your CPU wall time: one is fictional input, the other is the local harness runtime.

Read the named tests and refusal paths, not just the exit code or final label. Unknown values must remain unknown, and every report must distinguish simulation inputs from real measurements.

Troubleshooting

If Node cannot find src/cli.mjs, check the current directory before reinstalling anything. If the SDK is missing in offline mode, inspect imports: only liveJev may dynamically import it. If a test count changes after an exercise, read the named failure rather than treating the total as the requirement.

When previewing with Python http.server, use the .html continuation links below when needed. Extensionless series chips rely on GitHub Pages resolution; that documented preview limitation is separate from the Node example.

Change one thing, then test

Add one new synthetic ticket in a disposable copy. Give it a new valid ID and observe that the fixture provider refuses an ID without a prediction. Add its canned prediction explicitly instead of teaching the provider to read gold labels. This extends the dataset plumbing, not model intelligence.

Make changes in a disposable copy, retain the reference files for comparison, and restore them before the next chapter. If you later use a real provider, create a new experiment record rather than overwriting the fixture transcript.

Next checkpoint

Before moving on, identify the contract file, the policy file, what was observed in a run, and what remains untested against a real model. Keeping those four things separate matters more than making the demo look effortless.

Next chapter →

References and evidence

Key takeaways