AyniReproducible quality evidence for AI-edited repositories

The core model ​

Quality contract       Managed environment       Signal execution
.ayni.toml          +  .ayni.lock / OCI image  → check / verify / impact
"What is healthy?"    "Where does it run?"       "What did we measure?"

Ayni keeps these responsibilities separate and reviewable:

1. Define policy. .ayni.toml selects languages, signals, thresholds, structural rules, and optional runtime capabilities.
2. Lock execution. .ayni.lock records exact tools, native dependency inputs, preparation state, and an immutable base image.
3. Measure code. check, verify, and impact run launch managed environments automatically and produce normalized evidence.

Installing the CLI is separate from provisioning a repository environment. Ayni never silently creates a lock or rebuilds an image during a quality run.

Start with a reviewable proposal ​

After installing Ayni:

ayni init --dry-run
ayni init --write
ayni env show
ayni env lock
ayni env build
ayni check

init proposes a minimal test-only policy from adapter-owned project discovery; it never guesses thresholds and --write refuses to overwrite existing policy.

Commit .ayni.toml, .ayni.lock, and your native dependency/tool locks. Keep .ayni/ and the generated OCI image local.

Follow the complete quickstart →

A quality loop for humans and agents ​

Use a focused command while developing:

ayni verify test
ayni impact run --base origin/main

Then run the complete repository contract before integration:

ayni check

These commands use the managed environment directly. Optional, read-write env run and env shell access is documented only under advanced development access.

Supported language adapters ​

Unsupported project variants fail explicitly instead of silently falling back to host tools. Signal depth also varies: consult the adapter capability matrix. The --host option is labeled as an evaluation path and is not provenance-equivalent to managed evidence.