Trust chips
Every recalled fact carries a trust score in [0, 1]. Surfaces that hand memory to a model (the MCPbrief tool in your editor) render it as a chip:
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 came from an ingested corpus are re-checked against the live filesystem at recall time: does the collection’s root folder still exist? If it is gone, the fact’s trust score takes a multiplicative penalty rather than the fact being served as if nothing changed. The check is a filesystem stat on the collection’s root, cached for 5 seconds per path, so it costs microseconds, not a re-index. It does not look at individual files or read their contents: a file deleted or edited under a root that still exists is not currently detected as drifted. Per-chunk symbol mapping is not built yet. 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/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
no witness on file: the system does not pretend unconfirmed memories carry proofs.