YNOT lets development agents build, qualify and reuse executable capabilities. A job can leave behind tested code that later jobs can use, under checks and permissions owned by the host.
This is an experimental Orchestra offering, developed and internally validated by Hyperdrift. The foundation example repairs an API schema compatibility failure, saves a passing implementation and reuses it on unseen inputs in a fresh process.
- A host-owned contract checks generated Python in a Deno/Pyodide interpreter. Passing code receives an identity tied to its source, contract, scope and execution policy.
- A local store validates that identity on reuse and blocks revoked capabilities. Candidate code cannot rewrite the host's acceptance checks.
- Accepted capabilities can be composed in order under a new contract without generating code; a revoked or changed member blocks the composite.
- Four development jobs use the same lifecycle: repairing OpenAPI nullability, normalising a generated schema for a strict structured-output client, migrating draft-04 schemas to 2020-12, and a fourth that composes the first two. Holdout cases are written separately from the prompts and controls.
- A supervisor creates and executes DSPy ReAct workers from approved model and tool registries when the job needs them.
- The host validates worker configurations and enforces model-call and tool-call allowances. Findings, tool observations and stopping reasons remain inspectable.
- The service adviser checks supplied evidence against requirements. Its examples support scripted controls, saved sources and an optional Codex research integration.
The foundation is experimental. Its capability executor bounds time and output but does not separately meter memory. The store assumes a trusted local owner and one writer. Existing registered supervisor tools remain trusted Python callbacks. Persistent hosted customer agents and connection provisioning remain proposed work. Internal comparisons do not establish customer demand or a general quality or cost advantage.
Read the mission, direction and evidence, the evaluation design, its Track A record and the continuation record for the current boundaries and next step.
Use a fresh Python environment. The distribution is named ynot-ai; it includes the retained dspy engine namespace, so do not install a separate DSPy distribution in the same environment. These instructions install this checkout; there is no package-publication workflow.
git clone https://github.com/hyperdrift-io/YNOT.git
cd YNOT
python -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev,deno]'
python -m examples.ynot.capability_lifecycle --store /tmp/ynot-capabilitiesThe default demonstration rejects a faulty candidate, qualifies a working one, reuses it in a new process and verifies revocation. It is a deterministic control. --case strict-structured-output runs the second job. Add --live for independent runs through Codex using your existing login, and --arms direct,dspy,ynot to include a plain current-DSPy baseline; every arm can test, save and reuse code. This makes real model calls. Run examples from the checkout because they are not included in the wheel. The executor currently requires a POSIX host and the optional Deno runtime; first use may download its interpreter assets.
The earlier runtime example and service adviser guide remain available, with their scripted inputs and live-research limits stated separately.
The reusable API starts with from ynot import CapabilityContract, CapabilityStore, PyodideExecutor. The foundation guide covers the full lifecycle and comparison. Supervisor, Allowance and WorkerSpec are also public; existing example imports remain compatible.
Run the focused offline checks from the checkout:
python -m pytest tests/ynot -q
ruff check ynot examples/ynot tests/ynotContributing covers setup, validation and reporting a problem. Use YNOT issues for this repository.
YNOT retains DSPy's engine and Git history. The original MIT licence and Stanford Future Data Systems copyright remain in LICENSE. Upstream and attribution explains the package boundary, bundled components and retained compatibility checks. DSPy documentation describes the upstream framework; it is not YNOT product documentation.