[DOC] Add Ejentum cognitive harness recipe to examples/use_with

[ejentum]

Summary

Adds a use_with/ejentum/ recipe demonstrating how to wrap the Ejentum cognitive harness (memory mode) around a Chroma collection in two patterns:

1. Pre-storage filter. Call the memory harness before collection.add(...) to decide whether a candidate document deserves indexing. Keeps the collection lean.
2. Post-recall scoring. After collection.query(...) returns top-k by similarity, use the harness as a reranker that flags hits as materially useful versus lexically similar. Similarity is not the same as relevance for the user's current question.

Both patterns are plain-Python composition over Chroma's public client and Ejentum's public REST gateway. Nothing replaces or wraps Chroma APIs; the harness sits outside the store as a perception layer.

Files

• examples/use_with/ejentum/README.md: explains the two patterns, when each helps, and links to the runnable demo. Matches the shape of examples/use_with/ollama.md.
• examples/use_with/ejentum/harness_around_chroma.py: end-to-end runnable demo that exercises both patterns against a small in-memory Chroma collection.

Slot follows the existing examples/use_with/{cohere,jina,roboflow}/ and examples/use_with/ollama.md pattern: per-vendor folder with a short README and (optionally) a runnable artifact.

Why this fits

The Ejentum memory harness returns perception scaffolds (what to attend to, what to suppress, what to verify) for deciding what to store and scoring what to retrieve. It does not store or retrieve anything itself. That makes it a clean complement to Chroma, not a competitor. The recipe is explicit about this: Chroma stays the storage primitive; the harness shapes the gates around it.

Affiliation

I maintain ejentum-mcp. Submitting this recipe because the pre-storage-filter pattern is a real use we've shipped against mem0 in a sibling cookbook (mem0ai/mem0#5238) and it generalises cleanly to any vector store. Chroma's examples/use_with/ is the right surface for this shape. Ejentum has free and paid tiers; the README links to the dashboard for keys, not to a checkout.

Test plan

• Mirrors the structure of existing examples/use_with/{cohere,jina,roboflow,ollama} entries.
• Voice scrubbed (no em dashes).
• Demo script uses only documented Chroma APIs (Client, get_or_create_collection, add, query, get).
• No new top-level dependencies beyond chromadb, openai, requests.
• Local python harness_around_chroma.py against live OPENAI_API_KEY + EJENTUM_API_KEY (cannot run in this environment with live keys; happy to follow up if the reviewer spots an issue).

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)