feat(memory): add versioned Source evidence declarations and neutral lifecycle projection #1975

Scope

Implement the P0 Source prerequisite from RFC #1652: a versioned, reconstructible evidence declaration and neutral Atomic Memory lifecycle projection. This makes source authority/verification explicit for future quality, diversity, and usage-feedback work without changing current retrieval order or Memory write authority.

The first slice targets the Atomic Memory path that powers current Runtime recall: builtin/artifacts/atomic_memory, builtin/persistence/atomic_memory_index*, and builtin/runtime/atomic_memory_rebuild.py. Do not retrofit legacy builtin/artifacts/memory, Topic Memory, Experience, Skill, Handoff, or a public Artifact-family base class in this issue.

Current GenerationSourceAccess correctly decides whether a Source is eligible to enter a generation operation, including lineage_only handling. Eligibility is not a trust declaration: current Source/SourceDefinition contracts do not state whether material is user-asserted, repository-attested, system-attested, verified, or unknown.

Implementation map

• Extend the Source Definition contract at sources/definitions.py (SourceDefinition, AdapterSourceDefinition, and SourceDefinitionRegistry) rather than adding a second registry.
• Preserve the historic Definition manifest seam in builtin/persistence/source_definitions.py; its exact (name, version, fingerprint) record is the reconstructible registration evidence.
• Persist/rebuild the Atomic Memory-derived projection through the existing index schema and backend adapters, not through entry-body JSON, entry hashes, or an ad hoc side store.
• Reuse the existing Runtime rebuild path and add matching SQLite/OceanBase fixtures. A coding agent should first trace these seams and the Atomic Memory add/revise projection path before choosing column/table shape.

Required behavior

• Add a versioned MemoryEvidenceDeclaration contract to Source registration/SourceDefinition resolution. Its stable, reconstructible fields are:
  • authority: untrusted, user_asserted, repository_attested, or system_attested;
  • verification: unknown, verified, or not_verified;
  • a declaration version that identifies the contract used for the exact historical Source materialization.
• The declaration is supplied only by a trusted adapter or registration configuration. A SourceRef, Source body, Artifact body, candidate text, model output, or retrieval rank must never manufacture a stronger declaration.
• On an Atomic Memory add or evidence-backed revise, snapshot the resolved declaration and exact Source materialization into rebuildable, bounded projection data keyed to the exact Atomic Memory entry version. Projection rebuild must use the historical snapshot, not today's registry result.
• Missing, invalid, unavailable, or unverifiable declarations resolve to neutral untrusted/unknown. They do not block ordinary writes or generation eligibility and do not enable any quality ranking.
• Add only the neutral projection/rebuild/conformance facts required for this snapshot. With every lifecycle option disabled or neutral, current search, RRF, reranking, Context Pack, public score, and write behavior remain unchanged.
• Preserve lineage_only semantics in RFC 1458. This work neither creates a new Source access mode nor reclassifies automation/subagent Sources by inference.

Acceptance criteria

• Built-in and third-party Source definitions can declare the contract through one documented, versioned adapter boundary.
• An Atomic Memory entry version's derived evidence snapshot identifies the exact Source materialization and declaration version that supported it; rebuild produces the same projection after later registry changes.
• Historical Sources without a declaration remain readable and generation-eligible under their existing rules, but project neutral untrusted/unknown values.
• Atomic Memory entry bodies, entry content hashes, Artifact Revisions, citations, Handoff citation identity, and public Memory search schemas do not change.
• A projection rebuild and conformance suite verifies equivalent semantics on SQLite and OceanBase.
• Tests demonstrate that untrusted input text and model output cannot upgrade authority or verification, and that Scope isolation is maintained throughout resolution and rebuild.

Non-goals

• No Source content rewrite, automatic source rejection, model-generated trust score, ranking bonus, candidate suppression, automatic deactivation, retention action, HTTP/OpenAPI field, or user-visible Memory score change.
• No source schema guessed from SourceRef, source name, content type, provenance prose, or which host submitted it.
• No implementation of receipt-linked usage feedback; this declaration is a prerequisite, not a substitute for an observed delivery/use contract.

Dependencies and follow-up

This is the prerequisite before enabling the RFC #1652 quality policy. It also supplies one required safety input for lineage-diversity experiments and any later recall-event aggregation. #1698 remains responsible for the broader authorization and diagnosable-recall program.

Validation

Run focused Source registration/materialization, Atomic Memory add/revise, projection rebuild, and SQLite/OceanBase conformance tests. Include historical-source, registry-change, cross-Scope, and authority-upgrade-negative cases.

References

• RFC docs: add memory quality,forgetting and lifecycle RFC #1652, "Source authority and verification prerequisite" and delivery sequence item 1
• RFC docs(rfc): standardize source access for artifact generation #1458
• feat: strengthen memory governance, provenance, and diagnostics #1698
• evaluation(recall): measure lineage concentration and near-duplicate occupancy #1977