UnisonHow do I avoid remembering the same content twice?
Use sourceRef to make conversation capture (remember) idempotent — re-sending the same sourceRef is a no-op.
My worker retries failed calls. How do I prevent the same conversation from being stored multiple times?
Pass a sourceRef — a stable, unique string identifying the source record. If you call remember with the same sourceRef twice, the second call is a no-op: the job returns successfully but no duplicate notes or facts are written.
How to use it
curl -X POST https://brain.unisonlabs.ai/v1/brain/remember \
-H "Authorization: Bearer $UNISON_TOKEN" \
-H 'content-type: application/json' \
-d '{
"dump": { "turns": [...] },
"sourceRef": "chat-session-7f3a9b2c"
}'The sourceRef can be any stable string: a database row ID, a session UUID, a content hash, a webhook event ID.
What makes a good sourceRef
- Stable: The same logical record always produces the same
sourceRef. - Unique: Two different records never share a
sourceRef. - Opaque to the brain: Unison doesn't parse or index it — it's purely for deduplication.
A content hash (sha256(rawText)) is a reliable choice when you don't have a natural record ID.
Document writes are naturally idempotent
If you're writing documents with PUT /v1/brain/doc or POST /v1/brain/ingest (type: "document"), idempotency is built-in: writing the same path twice overwrites the first, and the brain tracks versions. Re-ingesting the same sourceRef on a document item is also idempotent. You don't need a separate dedupe strategy for document writes.
Should I use remember or document ingest for this?
Know when to use conversation capture via remember (async curation) vs. document ingest/writes (synchronous, precise) in Unison.
How do I correct a wrong fact in the brain?
Correct incorrect facts in Unison by writing the corrected version — the brain uses bitemporal supersession, so old facts are retired, not deleted.