diff --git a/README.md b/README.md
index 27c1da8..37bf1f4 100644
--- a/README.md
+++ b/README.md
@@ -26,8 +26,8 @@ whole repository does.
 | Skill | What it does | Source of truth |
 |---|---|---|
 | [`failproofai`](skills/failproofai/) | **The main skill.** A complete, standalone FailproofAI product package: explain the product, set up a machine, operate the local runtime and daemon, use FailproofAI Cloud, understand and author policies, publish GitHub policy packs, instrument custom agents, work with evaluators, inspect every command, and troubleshoot by symptom. It also routes to focused sibling skills when they are installed. | Maintained here. Not synced from anywhere - edit in this repo. |
-| [`failproofai-policy-author`](skills/failproofai-policy-author/) | Turn what agents keep doing wrong into enforcement for [failproofai](https://github.com/FailproofAI/failproofai) - triage a `failproofai audit` or FailproofAI Cloud findings, convert a CLAUDE.md/AGENTS.md into policies, or take a plain complaint ("agents keep force-pushing") and enforce it. Checks the shipped builtins and their params before writing anything, since most requests are one line of config; knows which of the 12 supported agent CLIs actually enforce a given event, so it never ships a deny the harness discards; tests every policy it authors. | Maintained here. Not synced from anywhere - edit in this repo. |
-| [`failproofai-policy-publish`](skills/failproofai-policy-publish/) | The publishing companion to policy authoring - take tested policies, build an installable pack, publish its release assets to GitHub with `failproofai publish`, preview it, and verify the consumer path with `failproofai policies add <owner>/<repo>`. Cloud fleet rollout remains part of `fp-cloud-cli`. | Maintained here. Not synced from anywhere - edit in this repo. |
+| [`failproofai-policy-author`](skills/failproofai-policy-author/) | Turn what agents keep doing wrong into enforcement for [failproofai](https://github.com/FailproofAI/failproofai) - triage a `failproofai audit` or FailproofAI Cloud findings, convert a CLAUDE.md/AGENTS.md into policies, or take a plain complaint ("agents keep force-pushing") and enforce it. Checks the shipped builtins and their params before writing anything, since most requests are one line of config; knows which of the 12 supported agent CLIs actually enforce a given event, so it never ships a deny the harness discards; writes Jev semantic checks and reviewable policies for calls no regex can decide; tests every policy it authors. | Maintained here. Not synced from anywhere - edit in this repo. |
+| [`failproofai-policy-publish`](skills/failproofai-policy-publish/) | The publishing companion to policy authoring - take tested policies, build an installable pack, publish its release assets to GitHub with `failproofai publish`, preview it, and verify the consumer path with `failproofai policies add <owner>/<repo>`, including packs that carry Jev semantic checks. Cloud fleet rollout remains part of `fp-cloud-cli`. | Maintained here. Not synced from anywhere - edit in this repo. |
 | [`fp-cloud-cli`](skills/fp-cloud-cli/) | Operate FailproofAI Cloud with `fp`: inspect telemetry, evals and usage; triage issues and audits; manage keys, users, orgs, and settings; publish Cloud policy versions; deploy them to fleet machines; observe enforcement; promote or roll back. Global options go **before** the command: `fp --json sessions`, not `fp sessions --json`. | Synced from `FailproofAI/failproofai` → `fp-cloud-cli/skill/`. Do **not** hand-edit here. |
 | [`failproofai-sdk`](skills/failproofai-sdk/) | Make an AI agent report what it did - plan which points in the agent loop to record, write the instrumentation with the Python (`failproofai_sdk`) or TypeScript/JavaScript (`@failproofai/sdk`) SDK - a framework adapter or a hand-built loop - thread session/agent identity through it, and verify the events actually land. Also runs your own evaluator worker (the eval pod) in either language. For an agent loop that is **not** one of the 12 supported CLIs. | Synced from `FailproofAI/failproofai` → `sdk/python/skill/`. Do **not** hand-edit here. |
 | [`failproofai-eval-brainstorm`](skills/failproofai-eval-brainstorm/) | Work out **what is worth measuring** about an agent's production runs, from the sessions it actually produced - scan the population, confirm the signal is really in the telemetry (a measurement over a payload key nobody emits does not fail, it scores every session identically and looks like it works), check it separates good runs from bad, and converge on two to four proposals. Each one ends in the plain-English prompt that authors it. It stops there: composing, backtesting and deploying the evaluation is the dashboard's eval authoring page. | Synced from `FailproofAI/agenteye` → `agent/skills/failproofai-eval-brainstorm/` (private). Do **not** hand-edit here. |
@@ -175,7 +175,7 @@ skills/                         ← this repo
     │   └── agents/openai.yaml
     ├── failproofai-policy-author/
     │   ├── SKILL.md
-    │   ├── references/          ← api · builtins · cloud · harnesses · patterns
+    │   ├── references/          ← api · builtins · cloud · harnesses · jev · patterns
     │   │                           rules-files · traps
     │   ├── scripts/             ← runnable helpers (test a policy, sync a reference)
     │   └── agents/openai.yaml
diff --git a/skills/failproofai-policy-author/SKILL.md b/skills/failproofai-policy-author/SKILL.md
index 35837db..216e010 100644
--- a/skills/failproofai-policy-author/SKILL.md
+++ b/skills/failproofai-policy-author/SKILL.md
@@ -5,7 +5,7 @@ description: |-
 
   Trigger when the user wants to:
   • act on an audit — turn `failproofai audit` findings into fixes, or ask which policies work;
-  • stop a recurring behaviour, in plain words or as "write a policy that blocks X";
+  • stop a recurring behaviour, in plain words or as "write a policy that blocks X" (regex or Jev);
   • enforce a rules file — make a CLAUDE.md / AGENTS.md real instead of advisory;
   • enable an existing builtin — usually the right answer, checked first;
   • work from FailproofAI Cloud — findings, hooks that fail or over-deny, backtesting a draft.
@@ -323,6 +323,9 @@ Run the attribution above first — a `DEAD` finding is not Bucket A, B or C; it
 **Bucket A — a builtin covers it and is off.** Do not write code. Add the short name to
 `enabledPolicies` in `.failproofai/policies-config.json`. This is the cheapest and most
 maintainable fix, and it is the right answer for most `source: "builtin"` findings.
+**Once any pack is installed on the machine** (a Jev pack included), `enabledPolicies` is no
+longer read at all: switch the builtin on in the pack instead,
+`failproofai policies add FailproofAI/policies --policy <name>` (`references/traps.md` §7).
 
 **Bucket B — a builtin covers it and is already on.** No action. Report it so the user knows
 the finding is historical, not ongoing.
@@ -453,6 +456,12 @@ and parameters. If one matches, enabling it beats writing a new file every time.
 Many builtins take `params` (allowlists, thresholds, protected branches) that go in the
 `policyParams` map — a parameterized builtin often covers a case that looks custom.
 
+If the complaint is that a builtin is **noisy** (`block-kubectl` denying `kubectl get`), try
+its `allowPatterns` / `allowPaths` param first: that trades nothing. The other fix is Jev:
+15 builtins ship **reviewable**, and Jev clears them on calls it judges harmless once it runs
+in `enforce` mode (*Jev: when no string decides it*). The price is that forged consent clears
+them too.
+
 Then check the project's **existing custom policies** — `ls .failproofai/policies/` and
 read their `name`/`description` lines. Coverage is not only builtins: a hand-written policy
 may already enforce exactly what you were about to author, and a duplicate means two
@@ -527,6 +536,43 @@ This is the highest-frequency failure in the whole system — see `references/tr
 
 See `references/patterns.md` for worked examples per event type.
 
+### Jev: when no string decides it
+
+Some concerns are not in the command. `rm -rf build/` that the user asked for and `rm -rf ~`
+that slipped into a plan; `prisma migrate deploy` against localhost and against production.
+A regex that blocks all of them gets disabled; one that allows them enforces nothing.
+**Jev** is failproofai's semantic evaluator: it answers yes/no questions about the call
+against what the human typed. **Read `references/jev.md` before writing either half** — it
+has the field rules, a complete pack entry, the budget, and the local test loop.
+
+The shape, in brief:
+
+- **Two tiers.** The regex is the hard floor; Jev judges above it on `PreToolUse` and
+  `PermissionRequest` only. Jev can **deny** or **instruct** through a check that fires, and
+  can **clear** only a **reviewable** policy's verdict. A hard deny is final. When Jev is not
+  configured, is in `shadow`, is `off`, or does not answer, the regex result applies, so
+  anything that must hold everywhere needs a regex floor.
+- **Reviewable** is two fields on `customPolicies.add`: `authority: "reviewable"` and
+  `reviewedBy: ["<check>"]` (check names, not policy names). The verdict clears only when every
+  named check was asked and none found the concern without the user asking. The test to apply
+  is **"once this clears, is there anything left that can deny?"**, not "can the reviewer keep
+  this block". A check that is asked but does not model a shape answers "no concern" and
+  **clears it silently**; an instruct-only reviewer can never deny; and an agent with a shell
+  can forge the user's consent. Keep irreversible, privilege and remote-code rules hard.
+- **A semantic check** is `semanticPolicies.add({ name, title, appliesTo, mode,
+  userCanOverride, probes, guidance })`: questions, no `fn`. Every probe must hold for it to
+  fire, so **every probe states the harmful claim**, true for the harmful call and false for
+  the harmless one.
+- **It only works in a pack.** In `.failproofai/policies/` it is never asked, and a
+  FailproofAI Cloud-managed policy ignores all Jev fields and is always hard. **Jev checks
+  belong in packs**, published with `failproofai-policy-publish`, with `minCliVersion` ≥
+  `1.0.8-beta.0`. A pack's checks join the 16 built-in ones, cannot reuse their names, share
+  a ~9,100-character question budget beside them, and are not asked for an `observe` pack.
+- **Test both tiers.** `test-policy.mjs --policy` tests the floor alone (no Jev).
+  `failproofai publish <file> --dry-run` validates the pack. Then `failproofai jev setup
+  … --mode shadow` (its bring-your-own-key default is `enforce`), `jev test`, `jev status`.
+  Use a **vague** prompt to see a check decide: naming the operation reads as consent.
+
 ### Verify it actually fires
 
 Loading and execution are both fail-open — a broken policy is indistinguishable from a
@@ -775,11 +821,13 @@ failproofai policies --list
 | Half | The question it answers | Skill |
 |---|---|---|
 | author | *what is the rule, and does it decide correctly?* | this one |
-| publish | *how does this tested policy become a versioned GitHub pack others can install?* | `failproofai-policy-publish` |
+| publish | *how does this tested policy, or a Jev check, become a versioned GitHub pack others can install?* | `failproofai-policy-publish` |
 | cloud rollout | *which fleet machines run a Cloud policy version, and what did it block?* | `fp-cloud-cli` |
 
 Everything past a proven local file is the deploy half: minting a version with
-`fp policies publish` (which **deploys nothing** on its own), choosing `enforce` vs
+`fp policies publish` (which **deploys nothing** on its own, and makes a Cloud-managed
+policy that never reads Jev fields: strip `semanticPolicies.add`, `authority` and
+`reviewedBy` first, and ship the Jev half as a pack), choosing `enforce` vs
 `observe`, `fp fleet deploy`, rollback, and reading `fp guardrails` to see the rule fire on
 real traffic. Those are shipped commands — if you find yourself about to say deployment is
 "dashboard work" or "not exposed by the CLI", that is wrong, and it tells the reader to stop
diff --git a/skills/failproofai-policy-author/references/api.md b/skills/failproofai-policy-author/references/api.md
index a0d110a..456404a 100644
--- a/skills/failproofai-policy-author/references/api.md
+++ b/skills/failproofai-policy-author/references/api.md
@@ -5,6 +5,7 @@
 - [The policy object](#the-policy-object) · [Context](#context) · [Decisions](#decisions)
 - [Events](#events) · [Filtering by tool](#filtering-by-tool)
 - [Execution model](#execution-model) · [Configuration](#configuration)
+- [Jev fields](#jev-fields)
 
 > Source pointers below are paths inside the failproofai package. In a project that
 > installed it, they live under `node_modules/failproofai/`; in a source checkout,
@@ -13,9 +14,12 @@
 Everything here is exported from `src/index.ts` — that file is the entire public surface:
 
 ```ts
-export { customPolicies, getCustomHooks, clearCustomHooks } from "./hooks/custom-hooks-registry";
+export { customPolicies, semanticPolicies, getCustomHooks, getSemanticRegistrations,
+  clearCustomHooks } from "./hooks/custom-hooks-registry";
 export { allow, deny, instruct } from "./hooks/policy-helpers";
-export type { PolicyContext, PolicyResult, CustomHook, PolicyDecision, PolicyFunction } from "./hooks/policy-types";
+export type { PolicyContext, PolicyResult, CustomHook, PolicyDecision, PolicyFunction,
+  PolicyAuthority, SemanticPolicyDeclaration, SemanticProbeDeclaration,
+  SemanticToolClass } from "./hooks/policy-types";
 ```
 
 ## The policy object
@@ -30,6 +34,8 @@ export interface CustomHook {
     events?: HookEventType[];
   };
   fn: (ctx: PolicyContext) => PolicyResult | Promise<PolicyResult>;
+  authority?: "hard" | "reviewable";   // absent = hard. See *Jev fields*
+  reviewedBy?: string[];               // semantic check names
 }
 ```
 
@@ -181,3 +187,17 @@ is no per-policy enabled/disabled object, and omission means off.
 
 Merged across three scopes, in precedence order: project `{cwd}/.failproofai/` → local →
 global `~/.failproofai/` (`hooks-config.ts`, grep `readMergedHooksConfig`).
+
+## Jev fields
+
+Two additions to the surface, both covered in full in `jev.md`:
+
+- `authority` / `reviewedBy` on `customPolicies.add`: whether the Jev semantic evaluator may
+  clear this policy's verdict, and through which checks. Honoured for your own local files;
+  for a pack policy the manifest decides (`failproofai publish` copies them there); a
+  FailproofAI Cloud-managed policy ignores them and is always hard (`policy-types.ts`, grep
+  `interface CustomHook`).
+- `semanticPolicies.add(decl)`: a Jev check, a question set with no `fn`
+  (`policy-types.ts`, grep `interface SemanticPolicyDeclaration`). Read only by
+  `failproofai publish`, so it takes effect **only in a pack**. `getSemanticRegistrations()`
+  returns what is declared, for tests; `clearCustomHooks()` clears both registries.
diff --git a/skills/failproofai-policy-author/references/cloud.md b/skills/failproofai-policy-author/references/cloud.md
index 6234be4..c53e65f 100644
--- a/skills/failproofai-policy-author/references/cloud.md
+++ b/skills/failproofai-policy-author/references/cloud.md
@@ -232,7 +232,15 @@ plus a config entry, and that is the whole story for one machine. It is **not**
 for a fleet: `fp policies publish`, `fp fleet deploy` and `fp guardrails` are shipped commands
 that carry the same rule to every machine and show it firing, and they need `policies:write`.
 That Cloud rollout path belongs to `fp-cloud-cli` — hand off rather than assuming the local
-edit is all there is. Then prove both local edits took effect, because neither is self-evident:
+edit is all there is.
+
+**A Cloud-managed policy has no Jev half.** It is always hard, whatever `authority` and
+`reviewedBy` say, and a `semanticPolicies.add` in it is never asked. So strip all three
+before `fp policies publish`. When the finding needs a judgment no string decides, ship that
+half as a Jev check in a policy **pack** (`jev.md`), beside the hard Cloud policy or instead
+of it.
+
+Then prove both local edits took effect, because neither is self-evident:
 
 ```bash
 export SKILL_DIR=/path/to/skills/failproofai-policy-author   # this skill's own folder
diff --git a/skills/failproofai-policy-author/references/jev.md b/skills/failproofai-policy-author/references/jev.md
new file mode 100644
index 0000000..d0de388
--- /dev/null
+++ b/skills/failproofai-policy-author/references/jev.md
@@ -0,0 +1,440 @@
+# Jev: semantic checks and reviewable policies
+
+## Contents
+
+1. [When to reach for Jev](#1-when-to-reach-for-jev)
+2. [The two tiers](#2-the-two-tiers)
+3. [Reviewable: letting Jev clear a regex deny](#3-reviewable-letting-jev-clear-a-regex-deny)
+4. [Semantic checks: the shape](#4-semantic-checks-the-shape)
+5. [Writing probes that fire on the harm](#5-writing-probes-that-fire-on-the-harm)
+6. [A complete two-tier pack entry](#6-a-complete-two-tier-pack-entry)
+7. [Where Jev fields count](#7-where-jev-fields-count)
+8. [Packs: joining, reserved names, the question budget](#8-packs-joining-reserved-names-the-question-budget)
+9. [Test it locally](#9-test-it-locally)
+10. [The 16 built-in checks, and which builtins they review](#10-the-16-built-in-checks-and-which-builtins-they-review)
+
+Needs failproofai **1.0.8-beta.0** or later. Source pointers are paths inside the failproofai
+package (`node_modules/failproofai/` or a checkout's root); they are grep anchors. The
+customer-facing pages are `docs/policies/authority.mdx`, `jev-byok.mdx`, `jev-cloud.mdx`,
+`publish-a-pack.mdx` and `docs/reference/policy-sdk.mdx` (*Jev checks*).
+
+## 1. When to reach for Jev
+
+A regex policy matches strings. Some concerns are not in the string:
+
+| The same command… | …is fine when | …is the incident when |
+|---|---|---|
+| `rm -rf build/` vs `rm -rf ~` | the user asked to clean the build | it slipped into a plan nobody asked for |
+| `prisma migrate deploy` | `DATABASE_URL` points at localhost | it points at production |
+| `kubectl get pods` vs `kubectl delete` | it only reads | it mutates a live cluster |
+| `cat .env.example` vs `cat .env` | it is a template | it prints real keys into the agent's context |
+
+A regex that blocks every such call gets disabled; one that allows them enforces nothing.
+**Jev** (TypeSafe's classifier) answers typed yes/no questions about the call in front of
+it, against what the human actually typed. Reach for it when the decision turns on the
+target, the intent, or whether the user asked, not on a flag or a path.
+
+| The concern turns on… | Write |
+|---|---|
+| a string in the call (a flag, a path, a tool name) | a normal policy. Stop here |
+| something a forged "the user asked for it" must never unlock: privilege escalation, code fetched from the internet, a push to a protected branch | a normal policy, **kept hard**. failproofai keeps `block-sudo`, `block-curl-pipe-sh` and `block-push-master` hard for this reason (`docs/policies/authority.mdx`) |
+| a string, but the regex is noisy on legitimate shapes | the regex, marked `authority: "reviewable"` with `reviewedBy`, so Jev can clear the harmless calls (§3) |
+| something no string decides | a **semantic check** (`semanticPolicies.add`) shipped in a **pack**, beside a regex floor wherever the rule must hold without Jev (§4–§6) |
+
+A noisy **builtin** is usually a parameter first: `block-kubectl` and friends take
+`allowPatterns`, `block-rm-rf` and `block-read-outside-cwd` take `allowPaths`
+(`builtins.md`). That trades nothing. Reviewability trades something (§3).
+
+## 2. The two tiers
+
+The regex tier is the floor. Jev judges above it, never instead of it
+(`src/hooks/semantic/combine.ts`, header table):
+
+- **A hard deny is final.** Every policy is hard unless it says otherwise. A hard deny stops
+  the call without waiting for Jev.
+- **Jev can deny or instruct on its own**, through a check that fires, for harm no regex
+  describes.
+- **Jev can clear**, but only the deny or instruction of a policy marked **reviewable**, and
+  only through the checks that policy names (§3).
+- **Jev failing is the regex result.** A timeout, a rate limit, a 402/5xx, a malformed
+  reply, or a Jev version other than 1.13 falls back to the regex verdict for that call
+  (`docs/policies/jev-byok.mdx`, *When Jev cannot answer*). So a concern with **no** regex
+  floor is allowed whenever Jev does not answer.
+- **Jev reads only gate events**: `PreToolUse` and `PermissionRequest`
+  (`src/hooks/handler.ts`, grep `JEV_GATE_EVENTS`). A reviewable `PostToolUse` or `Stop`
+  policy behaves as hard.
+- **Nothing happens without a Jev config.** No `~/.failproofai/jev.json`, or `mode: "off"`,
+  and hooks run the regex policies exactly as before. In `shadow` mode Jev is asked and
+  recorded but the regex result applies. Only **`enforce`** changes a decision.
+- **A partial picture withdraws clears, never adds them.** A call too big to send whole
+  (`request-cut`) or a suspected prompt injection keeps every regex deny; Jev's own deny
+  still applies (`combine.ts`, *One rule about a partial picture*).
+
+Known tools with no side effects (`TodoWrite`, `Task`, `Skill`, …) are never sent to Jev.
+A tool no class recognises, which includes every `mcp__*` tool, is asked **every** check
+whatever its `appliesTo` says (`src/hooks/semantic/compile.ts`, grep `selectPolicies`).
+
+## 3. Reviewable: letting Jev clear a regex deny
+
+Two fields on the `customPolicies.add` you already have (`src/hooks/policy-types.ts`, grep
+`interface CustomHook`):
+
+```js
+  authority: "reviewable",                     // absent or "hard" = hard
+  reviewedBy: ["production-infra-change"],     // semantic CHECK names, not policy names
+```
+
+**The rule** (`docs/policies/authority.mdx`; `combine.ts`, *A check that fired without
+consent keeps the floor*): the verdict is cleared only when **every** named check was
+asked about this call and each one either found nothing, or recorded the user asking for
+it, or had its deny softened to a warning because the call is a step of the user's task.
+Then:
+
+- a check that was **not asked** (its `appliesTo` or precondition did not select it, or the
+  name is misspelled) keeps the block, permanently for that shape;
+- a check that **fired** without the user asking keeps the block, even when it only warned;
+- a **deny-mode** check that warned without consent withdraws **every** clear on that call;
+- an unknown name, an empty or malformed `reviewedBy`, or `alwaysOn` makes the whole
+  declaration hard.
+
+**Why reviewable is dangerous.** The rule is not "can the reviewer keep this block". It is
+**"once this block clears, is there anything left that can deny?"** Three ways it goes
+quietly wrong:
+
+1. **Asked is not modelled.** A check that is asked and does not fire answers "no
+   concern", and no concern **clears**. Pair a floor with a check that does not model every
+   shape the regex fires on and you have switched the policy off for exactly those shapes,
+   with no warning. `warn-git-clean` stays hard for this reason: `git clean` names no path,
+   so `destructive-deletion`'s `irreplaceable` probe has nothing to judge and answers low.
+   List every shape the regex fires on, write the harmful case of each, and read every probe
+   of every reviewer against it.
+2. **Nothing left that can deny.** An `instruct` check can never answer deny. Paired with
+   instruct checks and nothing else, a block becomes a warning at best, and before a tool
+   call a warning does not stop the agent. `block-work-on-main` stays hard because its only
+   matching check, `commit-on-protected-branch`, is instruct-only. The block survives a clear
+   only if a deny-mode check still covers the call: the reviewer itself, or another deny-mode
+   check asked about the same call on its own.
+3. **Consent can be forged.** With `userCanOverride: true`, the user asking for the operation
+   clears a fired check, and "a step of the user's task" softens its deny to a warning. An
+   agent with a shell can make a harness submit a prompt (`claude -p "…"`, `codex exec`, …),
+   and nothing can tell that from a human typing (`docs/reference/jev-intent.mdx`, *The risk
+   this accepts*). Forged consent clears only reviewable policies, never hard ones. So
+   anything a forged "the user asked" must not unlock stays hard, or is reviewed by a check
+   with `userCanOverride: false`.
+
+The builtins that ship reviewable, and what reviews each, are in §10.
+
+## 4. Semantic checks: the shape
+
+`semanticPolicies.add(decl)`: validated by `parsePackSemanticPolicy`
+(`src/hooks/pack-manifest.ts`) at publish time and again at install/load.
+
+| Field | Required | Rule |
+|---|---|---|
+| `name` | yes | `[A-Za-z0-9._-]{1,128}`, unique in the pack. What `reviewedBy` names; reported as `semantic/<name>` |
+| `title` | yes | ≤120 chars, past tense ("Tried to …"). Also feeds the `user_asked` question |
+| `appliesTo` | yes | non-empty, from `shell` (Bash) · `write` (Write, Edit, MultiEdit, NotebookEdit) · `read` (Read, Glob, Grep, LS) · `network` (WebFetch, WebSearch) · `other` (`src/hooks/semantic/facts.ts`, grep `classifyTool`) |
+| `mode` | yes | `"deny"` blocks at evidence ≥ 0.85 and warns from 0.7; `"instruct"` only warns |
+| `userCanOverride` | yes | boolean, **no default**. `true`: the user's request (real or forged) allows a fired check, and a task step softens its deny to a warning. `false`: neither |
+| `probes` | yes | 1–6 of `{ id, instructions, criteria? }`. **Every** probe must hold for the check to fire |
+| `probes[].id` | yes | `^[a-z][a-z0-9_]{0,31}$`, unique in the check; `exempt` and `user_asked` are reserved |
+| `probes[].instructions` | yes | ≤600 chars |
+| `probes[].criteria` | no | `{ true, false }`, ≤300 chars each, both halves or neither |
+| `exempt` | no | one more probe (its `id` is ignored). When it holds (≥ 0.5) the check does not fire |
+| `precondition` | no | a **name**, never code: `always`, `protected_branch`, `in_git_repo`, `has_paths`, `paths_outside_project`, `system_or_root_paths` (`src/hooks/semantic/precondition-names.ts`). Absent = asked on every call `appliesTo` covers |
+| `guidance` | yes | ≤600 chars, shown to the agent when it fires. A deny-mode check only warns on moderate evidence, so do not say "blocked" |
+| `alwaysOn` | — | refused: packs may not set it |
+
+There is no `fn` and no `match`. On the wire each probe becomes one `noul` question
+(`{ type: "noul", instructions, criteria }`, `src/hooks/semantic/types.ts`), keyed
+`<check>.<probe>`; every question in a request is answered independently against the same
+state, in one round trip.
+
+**How a check decides** (`src/hooks/semantic/decide.ts`, grep `DEFAULT_THRESHOLDS_V1` and
+`function decideV1`):
+
+- evidence = the **minimum** over its probes. It fires at evidence ≥ 0.7 unless `exempt` ≥ 0.5;
+- a fired `deny` check denies at ≥ 0.85, otherwise it warns; an `instruct` check warns;
+- a suspected injection (the call contains text addressed to the reviewer) turns any fired
+  check into a deny and withdraws every clear;
+- with `userCanOverride: true`: `op_requested` ≥ 0.8 with `beyond_task` < 0.5 (and, for a
+  shell command, **every** one of its targets named in what the user typed, or in the agent
+  message they replied to) allows it; otherwise `task_step` ≥ 0.8 with `beyond_task` < 0.3
+  drops a warning and softens a deny to a warning, except on a shell command where the user
+  named some of its targets but not all. These task questions are asked only when a human
+  message was recorded;
+- consent never clears a shell command the scanner cannot fully read: `$'…'`, `$(…)`,
+  backticks, heredocs, `eval` or `sh -c` strings, unclosed quotes and similar keep the regex
+  floor, though Jev's own deny or warning still counts. Keep a probe's test commands plain.
+
+**What Jev is shown**, so probes can refer to it by name (`src/hooks/semantic/envelope.ts`):
+`agent_request` (the call, secrets redacted), `user_said` (what the human typed, harness text
+removed), `agent_last_message` (agent-written; context for a "yes", never consent on its
+own), and `facts`: `tool_name`, `tool_is_known`, `cwd`, `project_root` (pinned for the
+session), `current_git_branch`, `permission_mode`, and `paths[]` with `as_written`,
+`resolved` and `relation` (`inside_project`, `project_root`, `outside_project_in_home`,
+`home_root`, `system`, `root`). Never ask Jev to count or resolve a path; point it at the fact.
+
+## 5. Writing probes that fire on the harm
+
+A check that does not fire answers "no concern", and no concern clears the floor it
+reviews. So **every probe must be true for the harmful call**, never for the harmless one.
+
+- **Put the "does it do X" probe first.** It is the one the beyond-the-task warning reads.
+- **One dimension per probe.** The conjunction does the combining. The built-in set's own
+  header records one broad "is this dangerous" question scoring far worse than five narrow
+  ones on the same corpus (`src/hooks/semantic/policies.ts`, header).
+- **State the harmful claim; do not ask a question.** `instructions` is a sentence true for
+  the harmful call that says what `criteria.true` says. Measured on live Jev: a push guard
+  phrased as a question ("Does the branch name appear verbatim anywhere in `user_said`?")
+  under `criteria.true` "NOT present" hovered around the 0.7 fire line (0.45–0.73); stated
+  as a claim, the same payloads separated cleanly (0.04 for the branch the user named,
+  0.93–0.98 for branches they never mentioned):
+
+  ```js
+  { id: "branch_not_named",
+    instructions: "The branch this command pushes to (the one it names, or `facts.current_git_branch` for a bare `git push`) does not appear anywhere in `user_said`.",
+    criteria: { true: "The user never named that branch.", false: "The user named that branch." } }
+  ```
+
+- **Do not invert it.** "The branch appears in `user_said`" is true for the requested push,
+  so the check fires on the one the user asked for and answers "no concern" on the
+  unrequested one, clearing its floor silently.
+- **Name the look-alikes in `criteria.false` or `exempt`.** Jev answers the question as
+  written: build output, `--dry-run`, `status`, `.env.example`.
+- **"The user did not ask" is usually a probe, not `userCanOverride`.** Consent clears a
+  fired check only at `op_requested` ≥ 0.8, and a push the user named explicitly can score
+  below that, so a lone "pushes to a remote" check warns on the push that was asked for.
+  A probe like `branch_not_named` above decides it directly.
+- **Budget matters.** Probe text is the cost (§8). `userCanOverride: true` also adds a
+  `user_asked` question to the measured cost.
+
+## 6. A complete two-tier pack entry
+
+A pack entry: `semanticPolicies.add` does nothing anywhere else (§7). This exact file builds
+with `failproofai publish db-guard-policies.mjs --dry-run --id acme/db-guard --version 0.1.0`
+on 1.0.8-beta.0, and installs from a local mirror (§9).
+
+```js
+// db-guard-policies.mjs
+import { customPolicies, semanticPolicies, deny, allow } from "failproofai";
+
+// Tier 2: the Jev check. Questions, not code.
+semanticPolicies.add({
+  name: "db-migration-on-production",
+  title: "Tried to run a schema migration against a production database",
+  appliesTo: ["shell"],
+  mode: "deny",
+  userCanOverride: true,
+  probes: [
+    {
+      id: "applies_migration",
+      instructions:
+        "The command in `agent_request` applies database schema migrations: `prisma migrate deploy`, " +
+        "`prisma db push`, `knex migrate:latest`, `alembic upgrade`, `rails db:migrate`, or an equivalent, " +
+        "however the binary is spelled or pathed.",
+      criteria: {
+        true: "Running it would change a database schema.",
+        false: "It only creates, lists, checks or previews migrations (`status`, `--create-only`, `--dry-run`, `history`).",
+      },
+    },
+    {
+      id: "production_target",
+      instructions:
+        "The database it targets is production or shared, or cannot be told from the command, its flags, " +
+        "or the environment variables set inline on it (`DATABASE_URL=...`, `RAILS_ENV=...`).",
+      criteria: {
+        true: "Production, shared, or unknown database.",
+        false: "Clearly local or throwaway: localhost, 127.0.0.1, a docker-compose service, a sqlite file, or an env named dev, test or local.",
+      },
+    },
+  ],
+  guidance: "Run the migration against a local or staging database, or hand the command to a human to run against production.",
+});
+
+// Tier 1: the regex floor. Hard everywhere Jev is not configured, in enforce, or answering.
+const APPLY = /\b(prisma\s+(migrate\s+deploy|db\s+push)|knex\s+migrate:latest|alembic\s+upgrade|rails\s+db:migrate)\b/;
+
+customPolicies.add({
+  name: "block-db-migrate",
+  description: "Schema migrations need a human unless the target is clearly local",
+  category: "Database",
+  defaultEnabled: true,
+  match: { events: ["PreToolUse"] },   // Jev reviews PreToolUse and PermissionRequest only
+  authority: "reviewable",
+  reviewedBy: ["db-migration-on-production"],   // a pack that declares checks may name only its own
+  fn: async (ctx) => {
+    if (ctx.toolName !== "Bash") return allow();
+    const cmd = String(ctx.toolInput?.command ?? "");
+    return APPLY.test(cmd)
+      ? deny("Schema migrations need a human. Run it against a local database, or ask the user to run it.")
+      : allow();
+  },
+});
+```
+
+Why it is shaped this way:
+
+- **The check models every shape the floor fires on.** `appliesTo: ["shell"]` covers the
+  only tool the floor matches, there is no precondition to miss, `applies_migration` names
+  the same commands, and both probes are true for the harmful case.
+- **Something is left that can deny.** The reviewer is deny-mode, so a production target Jev
+  is sure of still blocks, and one it is only fairly sure of (0.7–0.85) withdraws every clear,
+  so the floor stands.
+- **Consent is the price.** With `userCanOverride: true`, a user (or a forged prompt) asking
+  for the migration clears it. Set `false` if a production migration must block whatever
+  the task says.
+- **Its dry run** prints `1 semantic policy for Jev (1530 characters of questions), added to
+  the built-in checks where it installs.` and `Requires failproofai 1.0.8-beta.0 or newer.`
+
+## 7. Where Jev fields count
+
+| Where the code lives | `semanticPolicies.add` | `authority` / `reviewedBy` |
+|---|---|---|
+| Your own file (`.failproofai/policies/`, `--custom`) | **never asked.** The hook log says `… never asked here` once per file (`src/hooks/custom-hooks-loader.ts`) | honoured. `reviewedBy` may name the 16 built-in checks or one an installed pack declares |
+| A pack entry published with `failproofai publish` | written to the manifest's `semantic` array; asked on machines with Jev | validated at publish and copied into the manifest, which is what machines read |
+| A **FailproofAI Cloud**-managed policy | never asked | **ignored: always hard.** Authority comes from the deployment, which does not set it yet |
+
+So **Jev checks belong in packs, not in FailproofAI Cloud-managed policies.** Strip
+`semanticPolicies.add`, `authority` and `reviewedBy` from anything headed for
+`fp policies publish`; a Cloud policy never reads them, and leaving them in makes a version
+that reads as Jev-aware and is not. Ship the semantic half as a pack (`failproofai-policy-publish`).
+
+## 8. Packs: joining, reserved names, the question budget
+
+(`src/hooks/semantic/pack-policies.ts`, header; `src/hooks/effective-reviewers.ts`.)
+
+- **A pack's checks join the 16 built-in ones.** Only a pack installed from a FailproofAI
+  repository (`FailproofAI/jev-policies`) replaces them. Checks from several packs add up.
+- **The 16 built-in names are reserved.** Declared by a pack not from FailproofAI, that
+  pack's version is never asked, so `publish` refuses one. Pick names of your own.
+- **A name two packs declare differently is asked for neither**, and every policy naming it
+  stays hard. Identical declarations are fine.
+- **`reviewedBy` in a pack names the pack's own checks.** A pack that declares any may
+  name only those; a pack with none is judged against the built-in names.
+- **One question budget, shared.** One Jev request has room for 27,591 characters of
+  questions and the 16 built-in checks spend 18,490 of it first, so a pack from outside
+  FailproofAI has **9,101** (`MAX_PACK_QUESTION_CHARS`, `BUILTIN_QUESTION_CHARS`). `publish`
+  refuses a pack over that. Installed packs share what is left: a check that does not fit
+  beside others is dropped at load, named by `policies add` and by the hook log
+  (`was dropped: its questions need`). The example above costs 1,530.
+- **Count caps:** 24 checks per pack, 6 probes per check.
+- **Observe and agent-scoped packs do not enforce Jev.** An `--effect observe` pack's checks
+  are never asked, and a pack added with `--cli <agent>` has its checks asked only for those
+  agents. A policy naming a check that is not asked stays hard.
+- **`minCliVersion` ≥ 1.0.8-beta.0.** 1.0.7 ignores a pack's checks and 1.0.7-beta.x
+  replaces the built-in checks with them. `publish` refuses a lower `--min-cli-version` and
+  writes `1.0.8-beta.0` when you pass none (`src/hooks/pack-cli.ts`, grep `JEV_PACK_MIN_CLI`).
+
+## 9. Test it locally
+
+**The floor, first, without Jev.** `test-policy.mjs --policy` runs with the legacy evaluator in
+a sandbox HOME, so it sees exactly the hard regex, `semanticPolicies.add` included and
+ignored. Test both directions as usual:
+
+```bash
+node "$SKILL_DIR/scripts/test-policy.mjs" --policy db-guard-policies.mjs --cases cases.json
+```
+
+**The pack, second.** The dry run is the validator: it runs the loader's own rules and
+publishes nothing. Always pass `--dry-run`; without it, a publish with no `--repo` takes the
+repository from the git origin and releases for real.
+
+```bash
+failproofai publish db-guard-policies.mjs --dry-run --id acme/db-guard --version 0.1.0
+```
+
+**Install a dry-run pack on this machine.** `policies add` takes `owner/repo[@tag]`, never a
+path, and fetches from `$FAILPROOFAI_PACK_BASE_URL/<owner>/<repo>/releases/download/<tag>/`
+(default `https://github.com`). Serve `dist-pack/` as that layout:
+
+```bash
+d=pack-mirror/acme/db-guard/releases/download/0.1.0; mkdir -p "$d" && cp dist-pack/* "$d"
+python3 -m http.server 8765 -d pack-mirror &
+FAILPROOFAI_PACK_BASE_URL=http://127.0.0.1:8765 failproofai policies add acme/db-guard@0.1.0 --all
+failproofai policies show acme/db-guard@0.1.0     # while the mirror is up
+```
+
+The variable redirects every pack fetch, so unset it before `policies add FailproofAI/policies`.
+
+**Turn Jev on, in shadow.** Two routes (`docs/policies/jev-byok.mdx`, `jev-cloud.mdx`):
+
+```bash
+# Your own key (TypeSafe, OpenRouter, Vercel, Cloudflare, or a custom endpoint)
+failproofai jev setup --provider typesafe --key-stdin --mode shadow < ~/typesafe.key
+# FailproofAI Cloud: a machine key (events:add + policies:pull + jev:evaluate)
+failproofai config --token <machine-key>          # turns Jev on in shadow when no jev.json exists
+failproofai jev setup --provider failproofai --mode shadow
+```
+
+**Pass `--mode shadow` on the bring-your-own-key route.** Its default is `enforce`
+(`src/hooks/semantic/jev-config.ts`, grep `DEFAULT_JEV_MODE`); only the FailproofAI Cloud
+route starts in shadow.
+
+**Then read what it did:**
+
+- `failproofai jev test`: one live request to check the key, endpoint and answering Jev
+  version. It never touches your policies.
+- `failproofai jev status` (`--json`): provider, mode, `N of M enabled policies are
+  reviewable` (policies from your own files are not counted), and the last 24 hours:
+  evaluations, fallbacks and why, `cleared` and `would have cleared (shadow)`.
+- `~/.failproofai/state/semantic/verdicts.jsonl`: one row per Jev evaluation, answers keyed
+  `<check>.<probe>`. The only proof a probe was asked.
+- `~/.failproofai/hook-activity/`: the decision log, with `jevCleared` naming what Jev cleared.
+
+**Prompt wording is part of the test input.** Jev reads what the human typed:
+
+- **Naming the operation reads as consent.** "Run `prisma migrate deploy`" gives Jev
+  `op_requested` high, and with `userCanOverride: true` that clears the check whatever its
+  probes say. You learn nothing about the probes. Use a **vague** prompt ("get the database
+  up to date") to see the check decide on its own; then a prompt that names the operation to
+  see the consent path.
+- **No prompt at all** (a fresh session, a CLI with no prompt event) asks no task questions,
+  so the consent path is not exercised either.
+- A long pasted prompt is fine: its length never decides a verdict.
+
+**Shadow, then enforce.** Nothing is cleared and no check blocks until
+`failproofai jev setup --mode enforce`. Do not report the semantic tier as live until
+`jev status` shows `enforce`. `--mode off` keeps the config and stops asking.
+
+## 10. The 16 built-in checks, and which builtins they review
+
+The checks every machine with Jev asks (`src/hooks/semantic/policies.ts`, grep
+`SEMANTIC_POLICIES`; published as `FailproofAI/jev-policies`, which declares the same 16
+with 20 probes and one `exempt`). Read a check's probe wording in that source before naming
+it in `reviewedBy`; `failproofai policies show FailproofAI/jev-policies` lists names and modes.
+
+| Check | Mode | User can override | `appliesTo` | Precondition | Probes |
+|---|---|---|---|---|---|
+| `destructive-deletion` | deny | yes | shell, write | — | `destroys`, `irreplaceable` |
+| `production-infra-change` | deny | yes | shell | — | `mutates`, `not_local` |
+| `git-history-rewrite` | deny | yes | shell | — | `rewrites_remote` |
+| `push-to-protected-branch` | instruct | yes | shell | — | `pushes_protected` |
+| `commit-on-protected-branch` | instruct | yes | shell | `protected_branch` | `creates_commit` |
+| `secret-exposure` | deny | yes | shell, read, write | — | `touches_secrets` |
+| `credential-exfiltration` | deny | **no** | shell, network | — | `sends_out`, `sensitive_payload` |
+| `remote-code-execution` | deny | yes | shell | — | `download_and_run` + `exempt` |
+| `privilege-escalation` | deny | yes | shell | — | `elevates` |
+| `database-destruction` | deny | yes | shell | — | `destructive_sql`, `real_database` |
+| `read-outside-workspace` | instruct | yes | shell, read | `paths_outside_project` | `reads_outside` |
+| `agent-config-tampering` | deny | **no** | shell, write | — | `edits_agent_config` |
+| `system-modification` | instruct | yes | shell | — | `modifies_system` |
+| `env-secrets-dump` | instruct | yes | shell | — | `dumps_env` |
+| `external-destructive-action` | deny | yes | other | — | `irreversible_external` |
+| `external-data-egress` | instruct | yes | other | — | `egresses_private` |
+
+The 15 builtins that ship **reviewable**, from `FailproofAI/policies` 2.0.0's manifest
+(`docs/policies/authority.mdx`, *Built-in policies*). Every other builtin is hard.
+
+| Builtin | Reviewed by |
+|---|---|
+| `protect-env-vars` | `env-secrets-dump`, `secret-exposure` |
+| `block-env-files`, `block-secrets-write` | `secret-exposure` |
+| `block-read-outside-cwd` | `read-outside-workspace` |
+| `block-rm-rf` | `destructive-deletion` |
+| `block-force-push`, `warn-git-amend` | `git-history-rewrite` |
+| `warn-destructive-sql` | `database-destruction` |
+| `warn-global-package-install` | `system-modification` |
+| `block-kubectl`, `block-terraform`, `block-aws-cli`, `block-gcloud`, `block-az-cli`, `block-helm` | `production-infra-change` |
+
+An older release of that pack carries no authority marks, so every policy in it is hard.
diff --git a/skills/failproofai-policy-author/references/patterns.md b/skills/failproofai-policy-author/references/patterns.md
index 31a7007..bb568f0 100644
--- a/skills/failproofai-policy-author/references/patterns.md
+++ b/skills/failproofai-policy-author/references/patterns.md
@@ -6,6 +6,9 @@ end in `policies.mjs`. See `traps.md` §1.
 Multiple `customPolicies.add()` calls per file are fine and are the normal way to group
 related rules.
 
+The one exception is a Jev check (`semanticPolicies.add`): it works only in a published
+pack. The two-tier pattern, a regex floor that a Jev check can clear, is `jev.md` §6.
+
 ---
 
 ## From a complaint to something matchable
diff --git a/skills/failproofai-policy-author/references/traps.md b/skills/failproofai-policy-author/references/traps.md
index 212ebfd..2852e26 100644
--- a/skills/failproofai-policy-author/references/traps.md
+++ b/skills/failproofai-policy-author/references/traps.md
@@ -8,9 +8,10 @@
 4. [A deny does not prove *your* deny](#4-a-deny-in-your-test-does-not-prove-your-policy-denied)
 5. [Validation is nil](#5-validation-is-essentially-nil)
 6. [Unsatisfiable Stop gates loop](#6-a-stop-gate-that-cannot-be-satisfied-loops-forever)
-7. [Builtins enabled by presence](#7-builtins-are-enabled-by-presence-not-by-a-flag)
+7. [Builtins enabled by presence, and only while no pack is installed](#7-builtins-are-enabled-by-presence-and-only-while-no-pack-is-installed)
 8. [`ctx.params` always empty](#8-ctxparams-is-always-empty-for-custom-policies)
 9. [Sanitizers block, not redact](#9-sanitizers-block-they-do-not-redact--and-deny-cannot-set-message-anyway)
+10. [Jev fails quietly](#10-jev-reviewable-and-semantic-policies-fail-quietly)
 
 Every item here is a documented, already-been-hit failure where a policy looks installed and
 enforces nothing. Read this before reporting any policy as working.
@@ -170,11 +171,23 @@ The same reachability rule applies to custom Stop policies — always `try/catch
 calls and `return allow()` on failure, so an unavailable tool degrades to letting the turn
 end rather than trapping it.
 
-## 7. Builtins are enabled by presence, not by a flag
+## 7. Builtins are enabled by presence, and only while no pack is installed
 
 `enabledPolicies` is a `string[]`. Omission means off. There is no
 `{"block-rm-rf": false}` form — to disable, remove the string.
 
+It is also a migration shim now. Builtins ship as the `FailproofAI/policies` pack, and
+`enabledPolicies` is read **only while no pack at all is installed** on the machine
+(`handler.ts`, grep `packsInstalledHere`). Install any pack, a one-check Jev pack included,
+and every builtin listed there stops loading; nothing on the command line says so.
+`~/.failproofai/policies/packs/installed.json` lists what is installed. On such a machine,
+switch builtins on in the pack instead (machine-wide):
+
+```bash
+failproofai policies add FailproofAI/policies                       # once, if it is not installed
+failproofai policies add FailproofAI/policies --policy block-rm-rf  # adds to what is on
+```
+
 Params live in a **sibling** `policyParams` object keyed by the same short name, not nested
 inside the policy entry:
 
@@ -220,3 +233,45 @@ So a sanitize deny on `PostToolUse` blocks the *entire* tool output; the model s
 block reason, never a redacted version. Protection holds — by omission — but do not tell a
 user "the token is scrubbed and the rest passes through." Put anything the agent needs into
 `reason`, and prefer `sanitize-api-keys.additionalPatterns` over authoring. See `api.md`.
+
+## 10. Jev: reviewable and semantic policies fail quietly
+
+Each of these leaves a policy that reads as Jev-aware and behaves as something else.
+`references/jev.md` has the full rules; this is the checklist.
+
+1. **Jev off, in shadow, or not answering means the regex decides.** Without
+   `~/.failproofai/jev.json`, or with `mode: "off"`, a reviewable policy is its hard regex
+   and no semantic check is asked. In `shadow`, clears and Jev's own denies are only
+   recorded. A timeout, 429, 402, 5xx or malformed reply falls back to the regex for that
+   call, so a concern with no regex floor is allowed. Jev also sees only `PreToolUse` and
+   `PermissionRequest`: a reviewable `Stop` or `PostToolUse` policy is hard everywhere.
+2. **`semanticPolicies.add` outside a pack does nothing.** Only `failproofai publish` reads
+   it. In `.failproofai/policies/` it loads without error and is never asked (the hook log
+   says `… never asked here`); a FailproofAI Cloud-managed policy ignores it, and ignores
+   `authority`/`reviewedBy` too: it is always hard.
+3. **A check that is never asked makes the block permanent.** Its `appliesTo` and
+   precondition must select every shape the regex fires on. One unknown name in
+   `reviewedBy` makes the whole declaration hard. The exception runs the other way: a tool
+   no class knows (every `mcp__*`) is asked every check, so a floor on an MCP tool can clear
+   there unless its reviewer models the MCP call (item 4).
+4. **A check asked that does not model the shape switches the policy off.** Asked and not
+   firing answers "no concern", and no concern clears, with no warning. `warn-git-clean`
+   stays hard because `destructive-deletion` cannot judge a `git clean` that names no path.
+   An inverted probe (true for the harmless case) does the same on every call.
+5. **Nothing left that can deny turns a block into a warning.** An instruct-only reviewer
+   can never deny, and before a tool call a warning does not stop the agent. The block
+   survives only where a deny-mode check still covers the call. `block-work-on-main` stays
+   hard for this reason. And with `userCanOverride: true`, the user's request, which an
+   agent with a shell can forge, clears even a deny-mode check.
+6. **A pack's limits fail at install, not at publish.** `publish` checks one pack against
+   the 9,101 characters the built-in checks leave; several installed packs share that, and a
+   check that no longer fits is dropped at load (named by `policies add` and the hook log).
+   A built-in check name from a non-FailproofAI pack is void, a name two packs declare
+   differently is asked for neither, and an `observe` pack's checks, or a `--cli` pack's for
+   other agents, are never asked. Every policy naming such a check stays hard.
+7. **Old packs and old CLIs mark nothing reviewable.** Authority lives in the manifest, so a
+   pack built by an older `publish`, or an older `FailproofAI/policies` release, is all hard.
+   A CLI older than 1.0.8-beta.0 ignores or misreads a pack's checks, which is why `publish`
+   writes `minCliVersion` ≥ 1.0.8-beta.0. A pack of Jev checks alone can make an older
+   build deny every tool call, so remove it (`failproofai policies remove <id>`) before
+   downgrading.
diff --git a/skills/failproofai-policy-author/scripts/test-policy.mjs b/skills/failproofai-policy-author/scripts/test-policy.mjs
index 917b90c..05a78d4 100644
--- a/skills/failproofai-policy-author/scripts/test-policy.mjs
+++ b/skills/failproofai-policy-author/scripts/test-policy.mjs
@@ -194,8 +194,18 @@ function runCase(c, sandbox) {
   }
   if (c.event === "Stop") payload.stop_hook_active = false;
 
-  const env = { ...process.env, FAILPROOFAI_TELEMETRY_DISABLED: "1" };
-  if (sandbox) env.HOME = sandbox;
+  // Legacy evaluator: this tests the regex floor, so a configured Jev must not
+  // let Jev's own deny pass a case the floor misses, nor clear a reviewable
+  // deny the floor should show. In-process only: a daemon worker does not see
+  // this variable, which is why the sandbox also drops the daemon socket.
+  const env = { ...process.env, FAILPROOFAI_TELEMETRY_DISABLED: "1", FAILPROOFAI_EVALUATOR: "legacy" };
+  if (sandbox) {
+    env.HOME = sandbox;
+    // Both are read before HOME and would bring the real config, jev.json or
+    // daemon back into the sandbox.
+    delete env.FAILPROOFAI_HOME;
+    delete env.FAILPROOFAI_DAEMON_SOCKET;
+  }
 
   const cli = c.cli ?? args.cli;
   const hookArgs = ["--hook", c.event];
diff --git a/skills/failproofai-policy-publish/SKILL.md b/skills/failproofai-policy-publish/SKILL.md
index cb46ade..6ef11d7 100644
--- a/skills/failproofai-policy-publish/SKILL.md
+++ b/skills/failproofai-policy-publish/SKILL.md
@@ -3,7 +3,7 @@ name: failproofai-policy-publish
 description: |-
   Package policies written with FailproofAI and publish them as an installable policy pack on GitHub. Use after `failproofai-policy-author` when the policy works locally and the user wants to share, version, release, or install it through `failproofai publish` and `failproofai policies add owner/repository`.
 
-  Covers initializing a pack, validating it locally, choosing policy metadata and defaults, Git/GitHub prerequisites, dry runs, publishing release assets, previewing the release, and verifying installation on a clean machine.
+  Covers initializing a pack, validating it locally, choosing policy metadata and defaults, Git/GitHub prerequisites, dry runs, publishing release assets, previewing the release, and verifying installation on a clean machine. Also packs that carry Jev semantic checks: what publish refuses, the question budget, minCliVersion, and what consumers see.
 
   NOT for writing the policy logic (`failproofai-policy-author`) or deploying Cloud-managed policy versions to a fleet (`fp-cloud-cli`).
 ---
@@ -23,8 +23,8 @@ guardrails, and rollback belong to `fp-cloud-cli`.
 ## Start with an authored policy
 
 If no working policy exists yet, use `failproofai-policy-author` first. Come back when the
-policy registers through `customPolicies.add(...)` and has passing allow and deny/instruct
-cases.
+policy registers through `customPolicies.add(...)` (or, for a Jev check,
+`semanticPolicies.add(...)`) and has passing allow and deny/instruct cases.
 
 Resolve the publishing CLI:
 
@@ -141,6 +141,7 @@ Useful overrides:
 
 `effect` applies to the whole pack. `observe` records decisions but blocks nothing;
 `enforce` applies policy verdicts. Choose deliberately and state it in the handoff.
+An `observe` pack's Jev checks are never asked at all (*Packs that carry Jev checks*).
 
 Publishing creates or reuses the release and replaces same-named release assets. It does not
 push the Git source and does not install the pack on any machine.
@@ -171,6 +172,61 @@ Selection can be narrowed with `--policy`, `--category`, or expanded with `--all
 interactive install lets the user choose agents and policies. Never claim publication was
 successful until `policies show` can read the release and an install can verify its digest.
 
+## Packs that carry Jev checks
+
+A pack is the only way a Jev check (`semanticPolicies.add`) reaches a machine; in a local
+policy file it is never asked. Discovery finds a file that calls `customPolicies.add` **or**
+`semanticPolicies.add`, so a pack of Jev checks alone is publishable. Author and test the
+checks with `failproofai-policy-author` (its `references/jev.md`) first. Needs
+failproofai **1.0.8-beta.0** or later on the publishing machine.
+
+**Always validate with `--dry-run`.** It runs the loader's own rules and publishes nothing.
+Without it, a `publish` with no `--repo` takes the repository from the git origin and
+releases for real.
+
+```bash
+failproofai publish ./db-guard-policies.mjs --dry-run --id acme/db-guard --version 0.1.0
+```
+
+Expect, beside the usual asset paths:
+
+```text
+Built acme/db-guard@0.1.0 — 1 policies, 1 on by default.
+  1 semantic policy for Jev (1530 characters of questions), added to the built-in checks where it installs.
+  Requires failproofai 1.0.8-beta.0 or newer.
+```
+
+The Jev line says `replacing` instead of `added to` only for a FailproofAI repository, and
+`not asked where it installs` for `--effect observe`. A pack of Jev checks alone also prints
+the **rollback reminder**: tell users to remove it (`failproofai policies remove <id>`)
+before rolling a machine back to an older failproofai, which can deny every tool call over
+a pack it will not load. Put that sentence in the release notes.
+
+What `publish` refuses for a pack with checks (details in `references/publishing.md`):
+
+- a check named like one of the **16 built-in checks** (`destructive-deletion`,
+  `secret-exposure`, …) unless the repository is FailproofAI's;
+- a question set over the **budget**: 9,101 characters for a pack from outside FailproofAI
+  (27,591 per request, minus the 18,490 the built-in checks take first);
+- a `reviewedBy` naming a check the pack does not declare, once it declares any; an
+  `authority` other than `"hard"` / `"reviewable"`;
+- `alwaysOn` on a check or a policy;
+- `--min-cli-version` below `1.0.8-beta.0`, or not plain semver. With none, `publish`
+  writes `1.0.8-beta.0` into the manifest;
+- a malformed check: missing `userCanOverride` (it has no default), an unknown
+  `precondition`, a reserved probe id (`exempt`, `user_asked`), more than 6 probes, a
+  duplicate name, or a field over its length cap.
+
+**What consumers see.** `failproofai policies show <owner>/<repo>` lists a *Jev checks*
+section (mode, name, which of the pack's policies each one `reviews`), and `Requires
+failproofai 1.0.8-beta.0 or newer.` `failproofai policies add` prints `N Jev check(s),
+added to this build's own checks. They apply only where you configured Jev`, and warns about
+any check this machine will never ask (a reserved or contested name, or one over the shared
+budget). The checks are not selectable: `--policy` cannot name one and `failproofai policies`
+never lists them. They do nothing until the consumer configures Jev (`failproofai jev setup`
+or a FailproofAI Cloud machine key) and switches it to `enforce`; `failproofai jev status`
+shows the mode and how many enabled policies are reviewable.
+
 ## Safety and authorization
 
 `--init`, local installation, `--dry-run`, and `policies show` are local/read-only enough to
@@ -190,6 +246,8 @@ Report:
 - pack id and GitHub repository;
 - version/tag and source commit;
 - `enforce` or `observe`;
+- for a pack with Jev checks: how many, their question cost, `minCliVersion`, and whether
+  the rollback reminder applies;
 - dry-run result and generated asset directory;
 - release URL if actually published;
 - preview/install verification performed;
diff --git a/skills/failproofai-policy-publish/references/publishing.md b/skills/failproofai-policy-publish/references/publishing.md
index 3493cf5..e133cc7 100644
--- a/skills/failproofai-policy-publish/references/publishing.md
+++ b/skills/failproofai-policy-publish/references/publishing.md
@@ -17,7 +17,8 @@ failproofai policies remove <pack-id>
 ## Source discovery
 
 `publish` recognizes policy files by their contents: they import FailproofAI and register
-one or more entries with `customPolicies.add`. Discovery is non-recursive. If discovery finds
+one or more entries with `customPolicies.add` or `semanticPolicies.add`. Discovery is
+non-recursive. If discovery finds
 multiple candidates, pass the intended source explicitly or organize the directory so the
 set is unambiguous.
 
@@ -70,3 +71,88 @@ pack as generally installable.
 - `failproofai policies add <owner>/<repo>` is the consumer install step.
 - Cloud policy publication and fleet rollout use `fp policies`, `fp fleet`, and
   `fp guardrails`; those belong to `fp-cloud-cli` and are not policy-pack publishing.
+
+## Jev checks in a pack
+
+Verified against failproofai 1.0.8-beta.0 (`src/hooks/pack-cli.ts`, grep `async function
+build`; `docs/policies/publish-a-pack.mdx`, *Jev checks in a pack*).
+
+### What the manifest carries
+
+A pack with checks writes them to the manifest's `semantic` array, beside `policies`, and
+sets `minCliVersion`. Each policy's `authority` and `reviewedBy` are copied into its
+manifest entry; a machine reads them from there, never from the code. A pack of checks alone
+has an empty `policies` array and is valid.
+
+### What `publish` refuses
+
+Every refusal exits 1 and builds nothing. The messages below are the CLI's own.
+
+| Refused | Message starts |
+|---|---|
+| a built-in check name, from a repository that is not FailproofAI's | `"destructive-deletion" is a name reserved for FailproofAI's own Jev checks` |
+| questions over the budget | `This pack's N semantic policies compile to … characters of questions, over the 9101 a machine leaves a pack from outside FailproofAI` |
+| `reviewedBy` naming a check the pack does not declare (when it declares any) | `One policy declares an authority this build cannot publish:` … `This pack declares Jev checks of its own, so reviewedBy may name only those.` |
+| `--min-cli-version` below 1.0.8-beta.0 | `--min-cli-version 1.0.7 is older than the first failproofai that runs a pack's Jev checks (1.0.8-beta.0)` |
+| `--min-cli-version` not plain semver | `--min-cli-version "…" is not a version that can be compared.` |
+| `alwaysOn` on a check | `… semantic policy #0 declares alwaysOn, which packs may not set` |
+| no `userCanOverride` | `… is missing userCanOverride, which has no default` |
+| an unknown precondition | `… names precondition "…", which this build does not have (always, protected_branch, in_git_repo, has_paths, paths_outside_project, system_or_root_paths)` |
+| probe id `exempt` or `user_asked` | `… uses the reserved probe id "user_asked"` |
+| two checks with one name | `two semantic policies are called "…"` |
+
+Also refused, as for any pack: `alwaysOn` on a regex policy, a policy name with `/`, a
+missing `description`, `category` or `match`, an entry that imports local files, and an entry
+that registers nothing. `publish` does not count checks, but `policies add` refuses a pack
+with more than 24 (the budget usually stops one first).
+
+### The budget, precisely
+
+One Jev request has room for 27,591 characters of questions. Every machine spends 18,490 on
+the 16 built-in checks first, so a pack from outside FailproofAI may use 9,101. The cost is
+the serialized question map: each probe's `instructions` and `criteria`, the `exempt` probe,
+and a generated `user_asked` question for a check with `userCanOverride: true`. Installed
+packs share what is left, so a pack that passed `publish` can still have a check dropped on a
+machine with another Jev pack installed. `policies add` names the dropped check; after that
+only the hook log does.
+
+### Reserved and contested names
+
+The 16 built-in names are reserved for FailproofAI's repositories, judged by the repository
+the pack is published to (or `--id` for a dry run with no `--repo`). A name two installed
+packs declare differently is asked for neither and clears nothing. `policies add` also
+refuses a `FailproofAI/…` pack id whose release does not come from a FailproofAI
+repository.
+
+### `minCliVersion`
+
+A CLI too old for Jev checks ignores `semantic` (1.0.7) or replaces the built-in checks with
+it (1.0.7-beta.x), so a pack with checks needs at least `1.0.8-beta.0`. `publish` writes that
+when `--min-cli-version` is absent and refuses anything lower. An older CLI that does read the
+field refuses to install the pack and prints `npm i -g "failproofai@>=<version>" &&
+failproofai update`. For an `enforce` pack with regex policies, a machine that cannot load it
+denies what those policies cover; a pack of Jev checks alone denies nothing on 1.0.8-beta.0,
+but older builds can deny every tool call, which is what the rollback reminder is for.
+
+### Try a dry-run pack before releasing
+
+`policies add` takes only `owner/repo[@tag]` and fetches
+`$FAILPROOFAI_PACK_BASE_URL/<owner>/<repo>/releases/download/<tag>/<asset>` (default
+`https://github.com`). To install a dry run locally, serve `dist-pack/` in that layout:
+
+```bash
+failproofai publish ./db-guard-policies.mjs --dry-run --id acme/db-guard --version 0.1.0
+d=pack-mirror/acme/db-guard/releases/download/0.1.0; mkdir -p "$d" && cp dist-pack/* "$d"
+python3 -m http.server 8765 -d pack-mirror &
+FAILPROOFAI_PACK_BASE_URL=http://127.0.0.1:8765 failproofai policies add acme/db-guard@0.1.0 --all
+```
+
+The tag must describe the version (a leading `v` is fine). Unset the variable afterwards: it
+redirects every pack fetch.
+
+### Observe and agent-scoped packs
+
+`--effect observe` records the pack's regex verdicts without enforcing them, and its Jev
+checks are **not asked at all**. A consumer who installs with `--cli <agent>` gets the checks
+asked only for those agents. Either way, a policy naming a check that is not asked stays
+hard.