Planning and verification control for AI coding agents.
Turn one request into reviewable work grounded in the project as it exists now.
Website · Quick start · Installation · Architecture · Releases
Loom is a local-first control layer for AI coding agents. It observes the current project, separates known facts from assumptions, produces a reviewable plan and bounded work orders, keeps implementation authority explicit, and connects completion to evidence from the real work.
The owner-facing surface stays simple:
/loom <request>
Loom keeps its planning intelligence, lifecycle state, verification records, recovery history, and scoped owner context behind that one request.
An AI coding request is only a small part of the working world. The repository may contain local changes, project instructions, architectural constraints, unresolved decisions, and validation that only makes sense in the real runtime.
Loom brings those signals into one lifecycle before implementation begins. The result is work that the owner can inspect, correct, authorize, verify, recover, and complete without losing the connection to the project state that shaped the plan.
Loom can:
- inspect committed, staged, unstaged, untracked, ignored, generated, and owner-authorized local project state through bounded observation;
- distinguish facts, assumptions, unknowns, contradictions, and human decisions;
- scale planning depth with consequence, uncertainty, scope, and domain coverage;
- produce consumer-driven planning artifacts and bounded work orders;
- bind implementation authority to exact plan content and a pre-implementation baseline;
- preserve request identity across its structured host protocol;
- detect project or plan drift before stale authority can be reused;
- connect claims to declared verification evidence;
- record cancellation, recovery, retries, reversibility, and continuation state;
- keep runtime versions separate from encrypted owner state;
- keep general, domain, project, component, temporary, device, and installation memory scoped;
- build a public release from an allowlist and scan the resulting files for private material; and
- verify installation ownership, signed updates, rollback, and removal through explicit receipts.
Loom 1.8.30 is the current signed public release.
| Item | Value |
|---|---|
| Release | v1.8.30 |
| Source | v1.8.30 |
| Canonical plugin | loom-plugin-v1.8.30.zip |
| Plugin SHA-256 | Published in the release's signed SHA256SUMS |
| Licence | Apache-2.0 |
| Runtime | Python 3.10+ |
The release workflow binds source, tag, artifact, hashes, native helpers, and verification metadata to the exact published cut.
flowchart LR
A["Owner request"] --> B["Current project observation"]
B --> C["Reviewable plan and work orders"]
C --> D{"Implementation authority"}
D -->|project or plan changed| E["Reconcile, re-plan, or recover"]
E --> B
D -->|authorized| F["Host implementation"]
F --> G["Outcome verification"]
G -->|more work required| E
G -->|evidence complete| H["Owner-facing completion"]
The key boundary is between a plan and permission to implement it. Loom lets the owner review the proposed work first, then binds any later authority to the exact plan and project state.
- Observe the project, its instructions, local state, and relevant scoped context.
- Plan the artifacts and work orders needed for the requested outcome.
- Review and authorize exact work against a recorded baseline.
- Implement through the connected coding host.
- Verify the requested outcome in its declared medium.
- Recover or complete with a concrete result and one clear next action.
Depending on the request, Loom can provide:
- a bounded project snapshot and world fingerprint;
- a plan contract with dependencies, assumptions, and decisions;
- work orders with likely touch paths and acceptance checks;
- explicit implementation-authority state;
- a proof graph connecting claims to evidence;
- verification and recovery records;
- a reviewer-ready completion report and proof bundle; and
- a plain-language owner message with the result and next action.
Small tasks stay small. Loom selects only the planning artifacts needed for the decision at hand.
Persistent planning stores bounded Loom metadata in the project’s plans/ tree. When the owner
requests zero project writes, Loom stops before creating project-local metadata and explains the
single next action needed to continue.
Proofline keeps the implementation story connected from request to result:
- an intent ledger records what the owner asked for;
- a proof graph connects each completion claim to its evidence;
- scope checks compare authorized work with the final change;
- completion reports summarize outcomes, verification, recovery, and remaining owner decisions;
- trust cards present the important result in plain language; and
- proof bundles preserve reviewer-ready evidence for the exact work.
This gives developers a practical way to review not only what an agent plans to do, but what it actually changed and how the requested outcome was checked.
Download the signed release:
Verify its SHA-256:
(Get-FileHash .\loom-plugin-v1.8.30.zip -Algorithm SHA256).Hash.ToLower()Compare the result with the plugin entry in the release's signed
SHA256SUMS.
The release includes SHA256SUMS, RELEASE-SUBJECT.json, signature metadata, and installation
instructions. Continue with the start guide.
Developers working directly from source can verify the checkout before using the repository tools:
git clone https://github.com/saroo98/loom.git
cd loom
python -B tools/loom_release.py verify . --source-classification public-releaseOpen a project in your coding agent and ask:
/loom <request>
For example, ask Loom to plan a health-check endpoint for the current project. Review the proposed work, likely touch paths, assumptions, authority state, and completion checks. When the plan matches your intent, continue through the connected host.
Loom sends no Loom telemetry. Owner memory, preferences, outcomes, and device state remain in the encrypted local owner vault. Public release construction uses an allowlist and scans the exact cut for private material before publication.
Read PRIVACY.md for the complete data boundary.
| Area | Responsibility |
|---|---|
| Stable launcher and bootstrap | Select and verify the active runtime while keeping owner state separate |
| Project inspection | Freeze the current target, instructions, changes, lifecycle, and relevant scoped context |
| Planning intelligence | Route consequence and domain coverage, select artifacts, and construct the plan contract |
| Authority and orchestration | Seal exact work, enforce continuation rules, and keep planning distinct from execution |
| Proofline and completion | Bind intent, changes, claims, evidence, reviewer outputs, and owner-facing completion |
| Verification and recovery | Record validation, failure, cleanup, quarantine, rollback, and recovery |
| Owner vault and scoped state | Preserve encrypted state, selection boundaries, transfer, merge, and forgetting |
| Host adapters | Translate host surfaces into one bounded local protocol |
| Release boundary | Build, scan, inventory, sign, verify, update, roll back, and uninstall exact artifacts |
See docs/architecture.md for the detailed contract map.
| Path | Contents |
|---|---|
loom/ |
Shipped planning, verification, memory, and host-facing instructions |
tools/ |
Runtime, lifecycle, release, evaluation, and test modules |
scripts/ |
Stable bootstrap and installed entry points |
schemas/ |
Persisted and exchanged JSON contracts |
contracts/ |
Versioned policy and fact contracts |
templates/ |
Planning and lifecycle artifact templates |
docs/ |
GitHub Pages site, architecture, start guide, and generated technical evidence |
vault-helper/ |
Native encrypted-vault helper and its Rust tests |
.github/workflows/ |
Pull-request, compatibility, Pages, and release workflows |
- Create an isolated branch and worktree from the intended base.
- Use disposable homes, runtime directories, vaults, and installation targets in tests.
- Make the smallest coherent change for the relevant contract.
- Run focused tests for changed behavior before wider gates.
- Regenerate committed evidence only through repository tools.
- Review the exact diff, privacy boundary, compatibility, and recovery path.
- Treat release promotion as a separate operation bound to exact-main evidence.
Useful bounded checks:
python -B tools/loom_test.py fast --max-seconds 30 --output fast-test-timings.json
python -B tools/loom_docs.py generate --root .
python -B tools/loom_readiness.py . --check
python -B tools/loom_version.py .Read CONTRIBUTING.md. Contributions must preserve local-first privacy, least
authority, explicit evidence classes, compatibility, and recoverable lifecycle behavior.
Loom is licensed under the Apache License 2.0.
Plan from the current world. Verify in the real one.
Local-first · no Loom telemetry · Python 3.10+ · Apache-2.0