Loom Continuity
loom_continuity is a durable coordination and knowledge-state runtime.
It is not an agent framework.
It is designed to sit underneath application harnesses and agent frameworks.
It answers one question: a value was derived from some evidence; is that evidence still current, and if not, who may recompute it without duplicating the work, committing a stale result, or losing the notice that state changed.
The package does not choose the application shape. A caller reads knowledge, checks validity, claims a repair, commits only if the evidence versions still match, and leaves a durable notification. A web app, a worker, a graph runtime, a batch job, or a plain function decides when to make those calls.
Using it
The first mode is a library inside one process. An application opens SqliteKnowledgeStore, SqliteOutbox, and SqliteRepairLease on one database file. A request looks up a fact. VALID returns the stored value. MISSING computes it. STALE claims the lease, computes outside the database transaction, and commits only if the dependency versions are unchanged. FastAPI, or any other process, is just a client of that runtime. Importing the package does not pull FastAPI in.
The production shape splits roles across processes that share the file. The request process writes evidence and can return before the expensive work. A worker finds stale or missing facts, claims the lease, computes, and commits. A dispatcher delivers pending outbox events and re-reads the current value. Any one of those processes can die. The fact, the pending obligation, and the lease expiry remain in the file.
Several processes can see the same stale key. One claim is ACQUIRED. The others are DENIED until the lease expires or is released, then they read the repaired value. That is the coordination, not a database wrapper. The SQLite implementation is for one shared file. Several machines should not share that file. The protocols are KnowledgeStore, Outbox, and RepairLeaseStore; a later backend would be a new implementation, not a change to the caller's questions.
An agent framework sits above this. A graph or agent node asks for a fact and skips the expensive chain while the lookup is VALID. It runs only when the fact is STALE or MISSING, then writes the result with provenance. Reuse lasts until the evidence version changes. It is not a time-to-live cache.
A batch job can do the same without a server: get_valid_fact for each item, skip what is still VALID, repair what is STALE, compute what is MISSING. A scheduler such as Temporal or Celery can start the activity. This package does not replace that scheduler. The scheduler decides when to run. The runtime decides whether the result is still current and whether the write is still safe.
A later HTTP service can wrap the same calls for other languages. That service is not this package. Callers that can import Python should use the library.
An agent tool can hide the protocol and return the current fact, or report STALE and leave repair to an orchestrator. Several agents can share one store. When evidence moves, the derived fact becomes STALE for all of them. That is shared institutional knowledge, not conversation history.
The compute step can be a Python function. Nothing in the core requires a model.
The distribution version is declared once, in pyproject.toml. This cut is 0.1.0.
The base install has no FastAPI, torch, or model-runtime dependency.
What it guarantees
- Versioned knowledge survives process death. A later process can reopen the same store.
LookupStatus.VALIDmeans every provenance dependency version is still current, including transitive dependencies.- A fact whose dependency moved is
STALE. The stored revision is not deleted. - If
A -> B -> CandAchanges,Cis stale even whenB's revision number has not changed. - The store does not repair itself. A caller claims a per-scope, per-key lease, computes outside any database transaction, and commits only if the dependency versions still match.
- A lease expires. After the owner process dies, another worker can acquire it. The lease is not held as a long transaction across the computation.
- A repair computed against old dependency versions is rejected. That result never becomes the current committed value.
- A fact revision and its outbox obligation commit in one transaction. A crash after commit leaves both. A crash before commit leaves neither.
- Delivery is at-least-once. Pending events remain until the consumer returns.
- Reopen, stale detection, single-owner repair, rejected stale commits, crash boundaries, and current-state delivery are covered by
loom_continuity_e2e.
What it does not guarantee
VALIDdoes not mean semantically correct, true, safe, approved, or high confidence. A wrong value isVALIDwhile its dependency chain is current.- Delivery is not exactly-once.
- The package does not deduplicate consumer side effects.
- Outbox events are not an event log of authoritative values. This is not event sourcing.
- There is no agent loop, tool framework, conversation memory, or semantic/vector memory.
- There is no auth, UI, or deployment framework.
Not in this cut
v0.1 is one SQLite file and process coordination around it. It is not a city. These are outside the frozen contract:
- identity service
- permissions
- scheduler
- service discovery
- policy enforcement beyond provenance freshness
- a second storage backend
- coordination across nodes
KnowledgeStore, Outbox, and RepairLeaseStore are protocols with a SQLite implementation. Another backend is an open slot, not a delivered adapter. scope is a namespace string, not an identity. Lease TTL is an expiry, not a scheduler.
scope
scope is the isolation namespace for independent knowledge state.
It may name a tenant, workflow, project, incident, job, or another application domain.
It is not a conversation id.
Public methods take scope. The SQLite primary key column is already scope. There is no session_id column and no schema migration in this cut.
Public import surface
from loom_continuity import (
KnowledgeStore,
SqliteKnowledgeStore,
FactRevision,
ProvenanceRef,
Lookup,
LookupStatus,
Outbox,
SqliteOutbox,
OutboxEvent,
OutboxStatus,
commit_fact_with_event,
commit_fact_with_event_if_versions_match,
dispatch_pending,
RepairLeaseStore,
SqliteRepairLease,
Lease,
ClaimStatus,
ClaimResult,
LLMBackend,
StatefulLLMBackend,
)
KnowledgeStore is the storage protocol. SqliteKnowledgeStore is the SQLite implementation.
FactRevision is the only fact value type. There is no separate Fact alias.
Lease is the only lease value type. claim returns ClaimStatus.DENIED and does not raise.
commit_fact_with_event and commit_fact_with_event_if_versions_match are the public atomic write and conditional-commit operations. They are not private helpers.
LLMBackend and StatefulLLMBackend are dependency-free call contracts. Model runtimes are not part of the base package.
Current-State Notification Semantics
An outbox event identifies that state changed. It carries scope, key, version, and a stable event_id. It does not carry the authoritative fact value.
The consumer re-reads the current value from SqliteKnowledgeStore.
If revision 1 then revision 2 were committed, delivering the newer event and then the older event still reads revision 2 both times.
A delayed older notification cannot restore an older value.
This is not event sourcing.
Consumer idempotency
Dispatch is at-least-once. The same event_id can be handed to the consumer more than once, including after a crash before acknowledgement.
The package does not suppress that repeat. A consumer that must apply a logical effect once deduplicates on event_id itself, for example with INSERT OR IGNORE.
Install and acceptance
From a clean environment, install the package, then run the acceptance suite from a checkout of this repository. The suite is not inside the wheel, and the runner does not put the source tree on PYTHONPATH.
python -m venv /tmp/loom-continuity-accept
source /tmp/loom-continuity-accept/bin/activate
pip install loom-continuity
python loom_continuity_e2e/run_all.py
Expected result: 10/10 PASS, and loom_continuity.__file__ under that environment's site-packages.
Package-local unit checks, from this directory:
python -m unittest discover -s tests -v
A separate minimal consumer lives at examples/minimal_consumer/ in the repository. It imports only the public package API.
Metadata
Release files for loom-continuity 0.1.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 | |
|---|---|---|---|
| loom_continuity-0.1.0.tar.gz | 14.4 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| loom_continuity-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 29.3 kB
Release files / loom_continuity-0.1.0.tar.gz
| Download URL | loom_continuity-0.1.0.tar.gz |
|---|---|
| Size | 14.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
04a0c41e4642cf04f58b0d2bc242844e0c442cb527e2a4a68c8fe4dc6a74cd34
|
|
BLAKE2b-256 checksum How to use checksums |
bade454e70d520b5e3cab68433c071ddafe1a6f75955d0b777ec61c63bb261bf
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.6
|
Release files / loom_continuity-0.1.0-py3-none-any.whl
| Download URL | loom_continuity-0.1.0-py3-none-any.whl |
|---|---|
| Size | 14.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
1125f4c210f4b5234a18f0fccfabd0ab6c04db340f75468a272c62ba0a86c853
|
|
BLAKE2b-256 checksum How to use checksums |
3af393a492c99efdd213d4d325fb400a2c49980ccfd30195997cc8d73b400c23
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.6
|