Engineering protocol
The OpenTendril experiment
What OpenTendril is testing, what evidence would count, and what does not. This is an independent open engineering experiment, not peer-reviewed research and not a claim of proof.
Research question
Can useful LLM software work run unattended when its freedom is contained inside an enforceable boundary and the resulting work returns to a human-controlled Git review boundary?
The project exists to make that question testable.
Hypothesis
A Botanist can grant an LLM full freedom inside a Terrarium, be asked for nothing while it works, and find that everything it did arrived in Git for review, with nothing outside the boundary touched.
A run falsifies the hypothesis if it requires mid-run permission, cannot be observed live, escapes the declared boundary, or fails to produce reviewable Git output, regardless of the quality of the model's work.
Experimental system
Simplified conceptual architecture. The Stem is deterministic and does not reason. Probabilistic reasoning comes from external Mycorrhizae.
Simplified conceptual architecture
What is measured
Aligned with the current project objective, each recorded unattended run should carry at least:
- Botanist interruptions: how many times the human was asked for anything. Target: none.
- Live observability: whether the run could be watched while it happened, not only reconstructed later.
- What the run reached: files changed, commands executed, credentials issued, tokens and money spent, network attempted.
- Boundary integrity: whether anything outside the declared boundary was touched. This is OpenTendril’s containment claim.
- Git arrival: whether work arrived as commits on a branch, reviewable and revertible, rather than as changes already applied as authoritative state.
- Acceptance (separate): whether the Botanist judged the change worth accepting. Never reported as OpenTendril’s containment score.
Conflating acceptance with containment would make the project accountable for model quality. OpenTendril reports the boundary and the execution; the Botanist decides about the work.
What counts as a run
A run that produced no work does not count.
Containment is trivially perfect if the system did nothing. Without requiring useful change, the metric can be satisfied by a broken system that never acts. A run only counts toward measured series figures if it actually changed something.
Success conditions
A qualifying successful run is observable, not scored by a single opaque “safety” number. It should:
- perform useful work (it changed something that counts as a real task outcome);
- ask the Botanist for nothing during the run;
- remain observable while running;
- stay inside the declared boundary (nothing outside touched);
- return reviewable, revertible Git work.
Whether the Botanist later accepts the change is a separate measure of work quality and human judgment.
Failure conditions
Examples grounded in the same objective:
- the run asks for permission mid-run;
- useful work cannot continue without expanding authority;
- the run cannot be watched live;
- something outside the declared boundary is touched;
- work does not return as reviewable Git output.
A failed measured run remains useful evidence. The figure is meant to be published rather than asserted, including when it is bad.
Results
No measured experiment series is published on this site yet. There are no run counts, success rates, or containment percentages to report here.
When a series is published, it should use an inspectable reporting structure along these lines, labelled as structure, not as data:
Reporting structure only, not experiment data
- Runs
- Useful-work runs
- Approval interruptions
- Boundary escapes
- Observable runs
- Git-reviewable outcomes
- Accepted by Botanist
- separate measure
Where possible, published results should link to inspectable Git evidence rather than stand as unverifiable claims.
Limitations
Limits of the claim
These limitations are conservative and structural. They are not a full security audit.
- Deployment Hardiness varies. Whether the deployed environment can enforce the intended delegation boundary depends on Hardiness, not on branding alone.
- OpenTendril does not control LLM work quality. Containment and generated-work quality are separate. A contained bad change is still a bad change.
- Containment depends on enforceability. Instructions and model behaviour are not a substitute for what the environment can actually reach. See containment.
- Measured runs cannot establish universal safety. A series can support or undermine the hypothesis for the conditions under which it was run. It cannot prove zero risk in all deployments.
- Observation is not acceptance. Being able to watch a run does not decide that the output should become project state. See observability and Git acceptance.
Inspect and reproduce
The source of truth for implementation is the live repository, not this website’s marketing surface. Operational procedure belongs in canonical documentation, not duplicated here.
For the problem framing that motivated this protocol, see why governed autonomous work.