A machine-readable rulebook for AI coding agents, and the build checks that enforce it.
AI proposes a change. The file's own toolchain proves it. The build refuses what skipped a check.
Measured: 99% right answers with Thea vs 59% blind (2,409 questions, 11 models), 89% fewer tokens (evidence). Agents start at llms.txt; chats at CHAT.md.
What it does
Thea tells an AI coding agent which commands prove a change to a file, and fails the build when a
change skipped them. One declaration, atlas.yaml, answers what proves this change
is correct?
---
config:
theme: base
themeVariables:
primaryColor: "#e6f2e7"
primaryBorderColor: "#6f9f73"
primaryTextColor: "#14301a"
lineColor: "#7f9483"
fontSize: "15px"
flowchart:
padding: 6
nodeSpacing: 14
rankSpacing: 18
---
flowchart TB
accTitle: How Thea is built
accDescr: the contract says what must be checked and what counts as proof, one core resolves the file, selects its gates, runs the checks and records the verdict, and the CLI, MCP, hooks with CI and the TheaOS all reach that one core
R[contract · atlas.yaml<br>what counts as proof] --> C[one core: resolve, gate,<br>check, record the verdict]
C --> doors
subgraph doors [ ]
direction TB
L[CLI<br>commands] ~~~ H[hooks · CI<br>commit, merge]
P[MCP<br>agent tools] ~~~ B[TheaOS<br>results, history]
end
classDef core fill:#cfe9d2,stroke:#4f9a58,color:#103d17
class C core
classDef band fill:none,stroke:#6f9f73,stroke-dasharray:4 3
class doors band
$ thea gate scripts/doctor.py
1. formatter: ruff format --check scripts/doctor.py
2. compiler_or_typechecker: python3 -c 'import ast,sys; [ast.parse(open(f, encoding="utf-8").read(), f) for f in sys.argv[1:]]' scripts/doctor.py
3. unit_tests: pytest
Not an app framework or a runtime optimizer.
Quickstart
# no checkout
uv tool install thea-software && thea doctor
# or, editable
git clone --depth 1 --branch v3.56.0 https://github.com/HLIntel/thea-software ~/thea && uv tool install --editable ~/thea && thea doctor
cd ~/thea
thea port scripts/doctor.py # route, gates, lessons
thea gate scripts/doctor.py # what proves a change
thea verify # exit 0 only if all PASS
Read-only MCP: thea-mcp. Other repos: CONSUMING.
$ thea port scripts/doctor.py --line
◉ scripts/doctor.py │ ⠟backend │ python │ ⌂scripts │ ✓3 │ ⚠1 │ → thea gate scripts/doctor.py
$ thea port scripts --line
◎ scripts │ ⠟110 │ ⌂scripts │ → thea brainstorm
$ thea port . --line
○ . │ ⠟138 ⠿4 ⠁3 │ → thea check
What it measurably buys
Recorded runs, each naming its instrument: evidence for routing and refusals, not for end-to-end task success (limits).
With Thea the model sees what thea gate prints; blind it sees only the language names.
Right answers, with Thea vs blind (abtest.py v3.49.0, 76 questions per Claude model)
- Opus: 100% vs 41%; 90% fewer tokens.
- Sonnet: 100% vs 39%; 90% fewer tokens.
- Haiku: 100% vs 39%; 91% fewer tokens.
- Claude Code start-up: 221 tokens (
CLAUDE.mdand its imports). - All 11 models (5 providers, 2,409 questions, v2.27.0 / v2.28.0 / v3.49.0): 99% vs 59% (95% intervals 98–99, 55–63); weakest 97%; a random guess 2.8%.
Beyond routing (blind → with Thea, taskbench.py v2.29.0)
- Name a failure from its symptom: Opus 93% → 100% · Sonnet 57% → 100% · Haiku 64% → 96%
- List the checks a change needs: Opus 12% → 100% · Sonnet 12% → 100% · Haiku 0% → 100%
- Spot a line the build refuses (coin flip: 50%): Opus 60% → 100% · Sonnet 60% → 100% · Haiku 40% → 100%
- Hand off with the right checks (schema only → with Thea,
workflowbench.py): Opus 0/6 → 6/6 · Sonnet 0/6 → 6/6 · Haiku 0/6 → 6/6 - Not measured: visual design, open-ended strategy, arithmetic — nothing declares a right answer.
Failures caught
- 17/17 planted breaks refused at commit, in 12 of 42 languages; 11 have an example not yet trialled, 19 none (
enforce.pyv3.53.0). - 524 mistake kinds planted in the tests, each refused.
- 113 failure shapes recorded from real runs: 197 sightings, 45 recurred, 96 now guarded.
- 245 refusals in daily use (26 shapes, 166 re-fired); verify 21 pass / 40 fail; 46/48 lands armed; 139 lessons shown (
agents.py --fieldv3.54.0). - 24/24 solo commits clean with or without the hook; a planted broken commit is refused.
- 6 agent controls block, never warn: narrow_tools, sandbox, budget, approval, effects, audit.
Cost
- 1,734 tokens read before routing; 206 more documents (631 KiB) load only when a route names one.
- 89% fewer tokens than pasting every tool list; 51% fewer than blind.
- 10 KiB install: 1 module, 1 dependency.
Coverage
- 378 language × check pairs (42 × 9), all answered: 143 by a command, 235 by a declared no tool, 0 silent.
For agents
- Plug in with
thea port <file>, or parse .agent/bootstrap.json; load only what it names. - Read machine output, not this page. Add
--jsonto any command: one record per gate, frozen in tools/atlas-output.schema.json. - Before a shell command,
thea shell --json "<cmd>": exit 3 means its verdict would be misread. - Land with
python scripts/branchstate.py --land; askthea landed <branch>before deleting one. - Judgments answer on rules, teacher or a keyless student.
- When something breaks, file it the same turn with the
theaskill.
Counts, computed
Every number here is generated on each build; check fails when one drifts. Sites and dashboards
read the same figures from .agent/facts.json.
- 401 tool entries — across 42 manifests and 5 kinds, validated against
tools/tools.schema.json - 333 agreement edges — each a file tied to the declaration it answers for
- 80 instruments — each stating what it proves, what it does not, and what closes the gap
- 8 change classes — and 14 task profiles, in
atlas.yaml - 110 harness Python files — every one held by
lint·format·typecheck - 3.56.0 contract version —
VERSION, asserted in 7 other files
Find your way
- Every document: docs index · wiki
- Languages: atlas · routing · verification
- Agents: harness ·
.thea· runtimes - Why a rule exists:
thea why·thea failures· instruments - Security: policy · OpenSSF
Project
The version tracks the contract, not the content: docs/VERSIONING.md.
Built by HLIntel LLC, public on purpose: no secret, private path or internal host enters
it (ABOUT.md). Contributions pass thea verify. MIT License.
Metadata
Release files for thea-software 3.56.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| thea_software-3.56.0.tar.gz | 18.9 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| thea_software-3.56.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 30.3 kB
Release files / thea_software-3.56.0.tar.gz
| Download URL | thea_software-3.56.0.tar.gz |
|---|---|
| Size | 18.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
712ba173b056225ad14b75eb136327a95613617e19771fd40b304da86a56ce4c
|
|
BLAKE2b-256 checksum How to use checksums |
37644bece7177cfc47081663a9a490544e2dc78af74afa7361fa3d7211e38969
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
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.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.
Transparency logRelease files / thea_software-3.56.0-py3-none-any.whl
| Download URL | thea_software-3.56.0-py3-none-any.whl |
|---|---|
| Size | 11.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
42bdfdf1c1587785a701567c692b5bcadb43d7d04779b8ff333a4a61540956f2
|
|
BLAKE2b-256 checksum How to use checksums |
d0e7a3714fec88391ae3dc02c1442c9045f129c263e93f00ae6bf2b3ae237170
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
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.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.
Transparency log