Repository navigation
feat(memory): evidence-backed claims and a relationship graph #178
Description
Problem
Entities and sightings exist, but the system lacks a durable representation for learned facts such as a person working on a project, a repository belonging to an application, or a document being related to an earlier author. Similarity retrieval alone cannot safely represent truth or corrections.
Scope
Add an append-only claim model and relationship projection grounded in evidence.
Acceptance criteria
- A claim records subject, predicate, value/object, workspace/app scope, valid time, confidence, state, evidence refs, creator, and supersession/correction refs.
- Claims support provisional, confirmed, corrected, rejected, and superseded states.
- User corrections outrank inferred claims without deleting the original inference or evidence.
- Relationships among people, projects, repositories, pull requests, documents, and organizations are queryable.
- Repeated evidence may strengthen a claim through a recorded derivation; it does not silently mutate confidence.
- Lexical, temporal, vector, and graph indexes are rebuildable projections rather than truth stores.
- Similarity results always return the supporting claims/evidence and scope.
- Cross-workspace retrieval is denied unless the active AppInstance has an explicit memory grant.
- Fixture: separate screen and audio observations link a repository, pull request, teammate, and project with inspectable evidence.
Non-goals
- Treating embeddings as facts.
- Automatic external actions.
- Learning sensitive relationships without visible provenance and correction controls.
Dependencies and related work
Depends on ContextPackets and #116. Builds on entity contracts #72-#75 and the currently reserved graph store.
Activity
feat(memory): evidence-backed claims and relationship-graph substrate (…
Merge pull request #239 from Ambisphaeric/feat/178-claims-s1
Ambisphaeric commentedon Jul 17, 2026
Slice 1 (substrate) landed via PR #239, merged
62cc1f4(CI green). #178 stays OPEN.Fresh-eyes verified end-to-end pre-merge (scratch worktree at head
d73acb0, baseab4ece1):Claim.evidenceisminItems:1at the contract (generatedClaim.jsoncarries it +required), the store re-validates onsaveClaim, and a test pins rejection of an evidence-less claim + content-smuggling + a closed evidence-source set.resolveClaimHeads, keyed by the corrected pair): a user REJECT survives (a) re-derivation with MORE evidence and (b) a supersession revision; (c) corrections are append-only and derived can never clobber user state; originals retained underincludeSuperseded. The critical reject-survives-re-derivation test is explicit.JSON.stringifybyte-identical claims; the content-id hash excludes the clock (idempotent even under a 2099 clock); evidence/pairs/participants all sorted (store read order cannot change output).node:crypto+ contract types; hardcodesco-occurs-with(the semantic kinds and therelates-tofallback are typed but never emitted by slice 1).claimIds; the served routes (/claims,/claims/related,/claims/build,/claims/correct) are driven end-to-end through the real auth boundary.Later slices (still OPEN):
Minor test-coverage gap noted (not a blocker): there is no walk-specific "reject a pair then walk" test — the property is covered transitively (the walk consumes
listClaims→resolveClaimHeads, which drops rejected pairs). Worth a dedicated test in a later slice.