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:
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: 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.
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

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