Skip to main content

jev-factory

jev-factory turns the process nvsh used to build its Tool-Jev model into a reusable factory for jev-like models. It adds explicit knobs and a recorded decision step after every run. It then fine-tunes its own jev-like model to make those decisions (self-hosting).

Status: scaffold. Nothing of the factory is built yet. What exists today is the agent scaffold described under What's here now. The build brief is issue #1.

What "jev-like" means

A jev-like model is a small, calibrated candidate scorer (OpenJev-style, nvsh's "Track B"), not a generative tool caller. It works like this:

  • It reads one request plus up to 52 lettered candidate actions (A) <name>: <description>). Two controls are always offered: explain and escalate.
  • It produces a probability distribution over those candidates, then calibrates it (a temperature, plus an optional per-label vector).
  • A gate with separate thresholds for read-only and mutating actions turns the calibrated distribution into propose / explain / escalate / abstain.
  • Action arguments are grounded deterministically, outside the model.
  • The choice must survive reordering, re-lettering, subsetting and paraphrasing of the candidates (the permutation-probe robustness bar).

nvsh's reference build is scorer-r3b on Qwen/Qwen3.5-0.8B, served as GGUF Q4_K_M. It scored 0 wrong mutating proposals and ECE 0.016 after calibration on the test side, at about 355 ms per decision on an AGX Orin. The recipe is in nvsh's docs/scorer-finetune-playbook.md. Other model families are planned too, such as the GLiNER2.5-Decide encoder (nvsh#67). The factory treats the backbone as a pluggable adapter behind the same candidates → calibrated distribution → gate contract.

The plan (three layers)

  1. Factory. nvsh's staged pipeline, made domain-generic through a declarative domain module: actions with read_only flags, grounding, prompts, seed corpus and escalation reasons. The stages run from pre-registering the bars and seeding the corpus through train, select, quantize, recalibrate, one final run, bundle and a private upload. Each stage is resumable and writes an artifact manifest. The first acceptance test is parity: reproduce nvsh's scorer-r3b selection verdict from its frozen data. This builds on nvsh's domain-module seam, nvsh#62.
  2. Decision surface. jev decide <run> applies a pre-registered rule to a run's metrics. It emits a verdict (ship, more or fewer epochs, targeted augment, fix the grader, recalibrate, heal the quant, refit the gate, or escalate to a human) as an append-only decision record. A human override is recorded as a deviation.
  3. Self-hosting. The factory builds a jev-like decider whose candidates are those verdicts, using real nvsh decisions as the sealed set. The decider drives the loop (jev decide --model <bundle>) only after it beats the rule with 0 wrong mutating verdicts. Below its gate it falls back to the rule or the human.

These honesty rules are enforced in code, not exposed as knobs:

  • Sealed held-out and test sets are touched once.
  • The gate is fit on the fit fold only.
  • Leakage fails closed.
  • Every write verb is dry-run unless you pass --apply.
  • Publishing is private-first. Going public is always a human decision.

Planned CLI: jev init <domain>, jev run <stage>, jev status and jev decide. Training dependencies will stay out of the base install, behind an extra or an external venv.

What's here now

  • An agent-first CLI, jev, cited from teken (afi-cli). The runtime package has no third-party dependencies.
  • A mesh identity: culture.yaml (suffix: jev-factory, backend: claude) and the matching resident prompt CLAUDE.md.
  • Four harness prompt files, each read by exactly one harness (see below).
  • The guildmaster skill kit under .claude/skills/, vendored cite-don't-import. See docs/skill-sources.md.
  • A build and deploy baseline: pytest, lint, the agent-first rubric gate, a per-harness smoke check, and PyPI Trusted Publishing in GitHub Actions.

Prompt files by harness

Four harnesses, four root files, no shared base — each file is read by exactly one harness:

Harness File(s)
Claude Code CLAUDE.md
Pi / associate AGENTS.override.md + .pi/SYSTEM.md
colleague AGENTS.colleague.md
Qwen Code QWEN.md

Claude Code — CLAUDE.md is the fullest write-up of the repo's conventions; read it first.

Pi / associate — AGENTS.override.md replaces this directory's AGENTS.md/CLAUDE.md in Pi's context layer, so Pi does not inherit CLAUDE.md. .pi/SYSTEM.md replaces Pi's default system prompt with the non-coding associate identity (read/find/summarize only).

colleague — colleague's prompt cascade is AGENTS.md → AGENTS.colleague.md → AGENTS.colleague.<model>.md. This repo ships only the middle layer: there is no AGENTS.md (a shared base across harnesses was considered and rejected) and no per-model override file.

Qwen Code — Qwen Code reads QWEN.md and AGENTS.md; since there is no AGENTS.md, QWEN.md is its sole source of guidance.

There is intentionally no AGENTS.md at the root — each harness gets an unrelated file rather than cascading from a shared base.

Two selections, not one

It is tempting to read "switch harness" as one decision. It is actually two, and this repo's layout exists partly to keep them separate:

  1. The interactive harness — which binary you run (claude, pi, colleague, qwen). cd into the clone and run any of them; all four are live simultaneously, and none of them requires editing a file or flipping a switch. A harness can be force-selected for one invocation (e.g. a CI smoke check) without ever touching culture.yaml — see docs/automation-contract.md.
  2. The mesh resident — the single backend culture.yaml declares, which is what the Culture daemon starts and what steward doctor checks. guild harness use <name> changes only this.

culture.yaml's backend affects (2) only. It never affects which harness you can invoke interactively in (1). See docs/harness-selection.md for the full writeup, including who reads this config and why existing siblings are not retrofitted by this arc.

Quickstart

uv sync
uv run pytest -n auto                 # run the test suite
uv run jev whoami                     # identity from culture.yaml
uv run jev learn                      # self-teaching prompt (add --json)
uv run teken cli doctor . --strict    # the agent-first rubric gate CI runs

The command is jev, the import package is jev_factory, and the PyPI distribution is jev-factory.

CLI

Verb What it does
whoami Report this agent's nick, version, backend, and model from culture.yaml.
learn Print a structured self-teaching prompt.
explain <path> Markdown docs for any noun/verb path.
overview Read-only descriptive snapshot of the agent.
doctor Check the agent-identity invariants (prompt-file-present, backend-consistency).
cli overview Describe the CLI surface itself.

Every command supports --json. Results go to stdout, and errors and diagnostics go to stderr (never mixed). Exit codes: 0 success, 1 user error, 2 environment error, 3+ reserved.

Contributing

See CLAUDE.md for the full conventions: the jev-like invariants, the nvsh source material, version-bump-every-PR, and the cicd PR lane. Every PR bumps the version (/version-bump), and CI blocks merge otherwise.

License

Apache 2.0 — see LICENSE.

Metadata

Release files for jev-factory 0.9.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for jev-factory 0.9.1
File Size Uploaded Provenance
jev_factory-0.9.1.tar.gz 243.4 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for jev-factory 0.9.1
File Interpreter ABI Platform
jev_factory-0.9.1-py3-none-any.whl Python 3 none any Details

Total release size: 269.6 kB

Release files / jev_factory-0.9.1.tar.gz

Download URL jev_factory-0.9.1.tar.gz
Size 243.4 kB
Tags Source
SHA-256 checksum
How to use checksums
29d7e8bbce3279b9ac8e8f53c1e24702a4a6a7dbf1f12eec75b2f7a7e9b9cfc3
BLAKE2b-256 checksum
How to use checksums
f431f1604a85695b71be7d07902741616808ca57074e2a8bf0761e4c5b263a14
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via uv/0.12.19 {"installer":{"name":"uv","version":"0.12.19","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}

Release files / jev_factory-0.9.1-py3-none-any.whl

Download URL jev_factory-0.9.1-py3-none-any.whl
Size 26.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
b2e679cdf6de02213c6e61dbe86adf30ebb4b5645c03c4b5d06f9ff9a034946d
BLAKE2b-256 checksum
How to use checksums
51b33681077a582a88781c1021462a31d24baf8c1b7d6cb38c1655c82a361103
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via uv/0.12.19 {"installer":{"name":"uv","version":"0.12.19","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}

Security for jev-factory 0.9.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page