> ## Documentation Index > Fetch the complete documentation index at: https://docs.xynthis.com/llms.txt > Use this file to discover all available pages before exploring further. # Truthful memory > Trust scores, grounding checks, and cryptographic confirmation: why you can rely on what Xynthis recalls. 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: | Component | Weight | What it measures | | ------------- | ------ | --------------------------------------------------------------------------- | | Confidence | 0.25 | How the fact was stated at ingest: direct statement vs. hedge vs. inference | | Quality | 0.20 | Specificity of the original perception | | Decay | 0.20 | Time since the fact was last reinforced, on a per-predicate half-life | | Corroboration | 0.15 | Independent knowledge-graph edges supporting the same claim | | Learned | 0.20 | The 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](/concepts/memory)). ## Confirmations Trust scores say what the system believes. Confirmation is you vouching, cryptographically. ```bash theme={null} 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 ```bash theme={null} 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 | Layer | Question it answers | | -------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Trust chip | How much should the model hedge when using this fact? | | Grounding | Is the source this fact came from still there and still saying it? | | Supersession | Has a newer fact replaced this one? | | Confirmation + witness log | Can anyone prove this exact fact was vouched for, by this device, at this time, and that nobody changed it since? |