Skip to main content
A memory system that recalls confidently but wrongly is worse than no memory at all. Xynthis attaches an explicit trust signal to every recalled fact, re-checks facts against their sources at recall time, and lets you cryptographically sign the facts that matter, producing an audit trail you can verify offline.

​
Trust chips

Every recalled fact carries a trust score in [0, 1]. Surfaces that hand memory to a model (the MCP brief tool in your editor) render it as a chip: 
◆ trust 0.94 · grounded · the production database is postgres 16
◇ trust 0.71 · prefers tabs over spaces
· trust 0.34 · may be moving to Berlin
The chip precedes the fact text: glyph, the score, grounded or drifted when a grounding check ran, and ✓ signed for confirmed facts. ◆ means trust ≥ 0.80, ◇ means 0.50-0.80, · means below 0.50. A downstream model picks up the cue without any prompting: it states high-trust facts plainly and hedges low-trust ones. The score is a weighted blend of five components, computed at recall time:
ComponentWeightWhat it measures
Confidence0.25How the fact was stated at ingest: direct statement vs. hedge vs. inference
Quality0.20Specificity of the original perception
Decay0.20Time since the fact was last reinforced, on a per-predicate half-life
Corroboration0.15Independent knowledge-graph edges supporting the same claim
Learned0.20The recall reranker’s judgment from your usage history
Decay is predicate-aware: where you were born has a half-life of years, what you are currently working on decays in weeks, a stated preference in about a year. An old, never-reinforced “currently using X” fades on its own instead of being recalled forever at full strength. The trust score is a calibrated heuristic, not a proof. It tells you how much the system believes a fact and why; the cryptographic layer below is what makes a fact provable.

​
Grounding

Facts that reference a file are re-checked against the live filesystem at recall time: does the file still exist, and does it still mention what the fact claims? A fact whose source has drifted (file deleted, symbol gone) is demoted by a multiplicative penalty on its trust score rather than served as if nothing changed. The check is a stat plus a content probe, cached for 5 seconds per path, so it costs microseconds, not a re-index. The same demote-don’t-serve principle applies to superseded facts: when a newer fact contradicts an older one, the older one is marked stale and filtered out of recall (see Memory).

​
Confirmations

Trust scores say what the system believes. Confirmation is you vouching, cryptographically. 
xynthis confirm 42

✓ confirmed fact #42
  signed by    : did:key:z6Mk...
  log_seq      : 17
  confirmed_at : 1767052800
  content_hash : blake3:8f3a9c01d2e4b7a6…
Confirming a fact signs it with a per-device Ed25519 key. The key lives at ~/.xynthis/bmc/identity.ed25519 (file mode 0600); the brain generates it the first time it boots, so every install has one before any confirmation happens. Your device identity is the key’s did:key DID: a pure function of the public key, no registry, no account. The signed payload binds the fact id, a blake3 hash of the fact’s live text, the confirmation timestamp, and your DID. Because the hash is taken over the live text at signing time, any later modification of the stored fact invalidates the signature: a tampered fact cannot masquerade as a confirmed one. Only facts you explicitly confirm are signed. Automatic bulk signing would make the signal meaningless; a signature means a human vouched.

​
The witness log

Each confirmation is appended to ~/.xynthis/bmc/witness.log, an append-only Merkle log (RFC 6962 construction, blake3 hashing). Every row chains to the previous Merkle root, and the brain validates the entire chain when it opens the log: a truncated or edited log is a hard error, not a silent repair. There is no delete operation; retracting a confirmation means appending a new row, so the full history stays intact.

​
Auditing a fact

xynthis why 42

Witness audit · fact #42
  signed by    : did:key:z6Mk...
  log_seq      : 17
  confirmed_at : 1767052800
  content_hash : blake3:8f3a9c01d2e4b7a6…
  signature    : ed25519:44aa19c0b1e2d3f4…
  tree_root    : 9b2f6e11a0c4d8e2…
  proof        : 5-hop audit path against tree of size 17
The output is everything a verifier needs: the signed payload, the Ed25519 signature, and a Merkle inclusion proof against the log’s root. Verification needs only the public key and the proof: no network, no Xynthis servers, no trust in the machine that produced it. Recompute the audit path, check the signature, compare the content hash against the fact’s text. If the underlying fact was edited after signing, the hash comparison fails and the audit says so. A fact that has never been confirmed returns no witness on file: the system does not pretend unconfirmed memories carry proofs.

​
What each layer buys you

LayerQuestion it answers
Trust chipHow much should the model hedge when using this fact?
GroundingIs the source this fact came from still there and still saying it?
SupersessionHas a newer fact replaced this one?
Confirmation + witness logCan anyone prove this exact fact was vouched for, by this device, at this time, and that nobody changed it since?