Policy — วางสิทธิ์ก่อนความมั่นใจPut Policy Before Confidence

Part 5 of twelve. Encode permissions in deterministic policy; a confident answer never grants permission to send or modify data.

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/policy.mjs. Expected gate states describe content and continuation; no state sends a message or changes a real account.

Old functions and the new boundary

Authorization answers may this application perform this action, not how plausible is the model’s answer. The sample permits draft_reply only. A confident classification of a request as useful does not create send_reply authority. Keep this as a small ordinary function.

The policy file contains two different kinds of rule. Action allowlists are hard boundaries; uncertainty thresholds are unvalidated teaching parameters that need domain validation. A configuration file is convenient storage, but it does not make either kind of rule correct by itself.

Check permissions both before generation and on the returned draft. A model or adapter can propose an action different from the input. This example never executes any external action even after acceptance; production authorization would need a separate authenticated boundary.

Seven practical steps

Step 1

Read authorizeInput without looking at confidence fields. Its entire input requirement is the requested action. Make a truth table for draft_reply and every other string.

Step 2

Run the policy command for V001 and V004. Both inputs are structurally valid, but only V001 has an allowed action. This separates invalid data from valid data asking for forbidden work.

Step 3

Run the full V004 pipeline and inspect the history. It should stop at authorization before semantic input or generation. Zero provider calls is part of the observable contract.

Step 4

Read authorizeDraft and imagine a generator returning send_reply. The downstream action check must reject that object rather than trusting the earlier authorization result for a different action.

Step 5

Inspect validatePolicy and its uncertainty-band checks. A no boundary above a yes boundary makes interpretation incoherent. Treat malformed application configuration as an operator problem, not a model answer to repair.

Step 6

Run the hard-failure quality test. Even perfect rubric values must yield reject when hardFailure is set. An average quality score cannot buy back permission.

Step 7

Document what accept permits: storage or display of a draft artifact within this exercise. Do not describe the absence of a sending implementation as proof that a future production integration will enforce the same boundary.

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/policy.mjs · Matching tests · This lesson’s exercise

import {gate,probability} from './contracts.mjs';
export function validatePolicy(p) {
  probability(p.choiceMin);probability(p.yesMin);probability(p.noMax);
  if(p.noMax>=p.yesMin||p.noMax>=.5||p.yesMin<=.5) throw new Error('invalid uncertainty band');
  for(const k of ['maxCalls','maxDrafts','timeoutMs'])
    if(!Number.isSafeInteger(p[k])||p[k]<1) throw new Error('invalid '+k);
  if(!Number.isSafeInteger(p.transportRetries)||p.transportRetries<0||p.transportRetries>2)
    throw new Error('invalid retry bound');
  if(typeof p.fallback!=='boolean') throw new Error('invalid fallback');
  return p;
}
export function authorizeInput(input) {
  return input.requestedAction==='draft_reply'?gate('accept'):gate('reject',['action_not_authorized']);
}
export function authorizeDraft(draft) {
  return draft?.action==='draft_reply'?gate('accept'):gate('reject',['output_action_not_authorized']);
}

Offline commands:

node src/cli.mjs policy --case V001
node src/cli.mjs policy --case V004
node src/cli.mjs run --case V004
node --test --test-reporter=spec test/gates.test.mjs

Expected output and verification

Policy V001 returns accept; V004 returns reject with action_not_authorized. Full V004 has calls0 and externalEffects0. The quality hard-failure test also rejects despite high rubric values.

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

Checking only the input action is insufficient: a generated object can change action. The output-side guard is a distinct hard check. Removing it is a regression even if every current happy-path fixture asks only for drafts.

Exercise in a disposable copy

Add a table-driven test for send_reply, refund and delete_account. All must reject before a provider runs. Do not add those actions to the allowlist just to make an example look successful.

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 a request unexpectedly fails, read action_not_authorized separately from unknown_input_field. One is a policy refusal, the other a shape violation. Changing confidence thresholds cannot repair either.

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 · Next lesson →

Sources and version notes

Key takeaways