Reuse validated knowledge without losing provenance
When compatible sibling stores contain similar evidence, TRW can mark entries cross-validated and merge eligible candidates into relevant recall. Nothing is copied everywhere by default, and project boundaries remain explicit.
Illustrative local recall path
PROVENANCE PRESERVED- 01
PROJECT STORES
Keep provenance local
Active entries remain scoped to their project namespaces and retain their source.
- 02
CROSS-VALIDATE
Compare sibling evidence
When embeddings exist, similar entries in discovered sibling stores can cross-validate.
- 03
RELEVANT RECALL
Merge eligible candidates
High-importance, cross-validated entries join recall only when query and tags match.
Eligibility is not propagation
A sibling match makes an entry eligible for relevant org recall. It does not copy every learning into every project or guarantee that every future query will surface it.
Depth versus breadth
Memory preserves one project across sessions. Sharing lets eligible evidence participate across configured project boundaries. Complementary, not the same thing.
Knowledge scoped to one context window does not compound
By default, AI-agent memory is scoped narrowly — to a single conversation, a single user, or a single project. A gotcha you solved in one repo stays locked there. The next repo rediscovers the same Pydantic v2 migration quirk, the same SQLAlchemy session-management trap, the same timezone-offset bug. Every rediscovery burns tokens, session time, and the trust the team places in the agent.
TRW can compare project-scoped entries across configured sibling stores. A strong match records cross-project evidence on both entries; later recall may merge an eligible org candidate when its importance, query, tags, and score all qualify.
SCOPE
Sibling project namespaces
Only discovered, configured on-disk stores participate in local comparison.
TRIGGER
Stored entry + embedding
Cross-project validation fails closed when an embedding or project scope is unavailable.
OUTCOME
Eligible org recall
Relevant, high-importance cross-validated entries can join local results with source intact.
How cross-validation works
When a project-scoped entry includes an embedding, the memory engine can compare it with active entries from discovered sibling project stores. Similarity greater than 0.92 marks the matched entries cross_validated: True and records the sibling project as evidence, and applies a +0.05 importance boost. Org recall considers only cross-validated entries with importance at least 0.8, then still applies the current query, tags, and minimum-score filters. See the trw_learn tool reference for call signature and parameters.
The standalone memory engine
Cross-project sharing is powered by trw-memory — a standalone Python package built on SQLite with optional sqlite-vec acceleration. It handles hybrid retrieval, knowledge-graph traversal, semantic deduplication, and tiered storage. When vector support is unavailable, canonical memory operations remain available and retrieval degrades to keyword-capable paths.
pip install trw-memorySQLite primary storage; optional sqlite-vec and embedding extras. No external service is required.
Note: this installs only the standalone memory engine. The full TRW framework installs via install.sh — see the quickstart.
- LangChain memory adapter
- LlamaIndex reader/writer
- CrewAI component
- OpenAI-compatible adapter
Delivery can publish a local knowledge index
After core delivery succeeds, TRW runs a fail-open knowledge-topic step. Once the local entry count reaches knowledge_sync_threshold, it then clusters active entries and writes human-readable topic documents. This is local organization—not automatic replication into sibling projects. See the cross-project knowledge reference.
.trw/knowledge/01 // COUNT
Count default-namespace entries except system canaries against the threshold.
02 // CLUSTER
Group the default namespace by configured Jaccard similarity.
03 // RENDER
Write browsable topic Markdown under .trw/knowledge/.
04 // REPORT
Return generated topics and any errors without failing delivery.
Topic generation may skip below threshold or report errors. It must not turn a successful delivery into a failure, and its documents do not prove cross-project recall occurred.
What sharing does not do
No universal broadcast: cross-validated entries remain subject to importance, query, tag, and score filters.
No vector evidence without embeddings: cross-project validation returns no match when the store path has no embedding.
No provenance erasure: shared candidates retain their source, namespace, and project evidence.
No automatic remote-account sharing: local sibling-store discovery and hosted synchronization are separate concerns.
Pairs with
Memory
Sharing is Memory applied across project boundaries. Single-project memory is the foundation; sharing is what lifts it into a network.
Workstreams
Workstream handoffs can cite persisted, relevant learnings without erasing the project that produced them.
Requirements
A requirement or PRD can cite reusable evidence explicitly; cross-project recall does not replace traceability.
Common questions
Does cross-project sharing require the hosted platform?
What counts as the "same" learning?
Can I keep projects siloed?
Make reusable knowledge explicit, relevant, and inspectable.
Start locally. Preserve provenance. Share only the entries that meet your configured evidence and recall rules.