Research: capture-event provenance envelope for passive memory imports

[ajdelaguila]

Source signal

Today's outreach around passive memory capture surfaced a recurring design point:

• feat(automem): Passive Memory Capture via Claude Code mcp_tool Hooks verygoodplugins/mcp-automem#172: hook-captured tool events should be evidence first, not authoritative memory.
• AutoBot-AI#11137: external coding-agent transcripts need provenance, privacy scope, and a promotion path before they become institutional memory.
• OpenSearch ml-commons#4859: retention, currentness, and authority are distinct axes.

Problem

Data Olympus already supports proposed memory, evidence on proposals, status-aware retrieval, and governed promotion. What is not yet first-class is a normalized capture provenance envelope for integrations that ingest passive hooks, external transcripts, or other automated event streams.

Without that envelope, downstream integrations can blur three different things:

• a raw captured event;
• a candidate memory distilled from that event;
• accepted guidance that may influence future agent behavior.

Proposed research / design

Define an optional capture provenance envelope that can be attached to proposed memories or future import APIs. Candidate fields:

• capture_event_id
• capture_source such as claude_code.hook, codex.transcript, external_session
• source_session
• source_event_hash
• derived_memory_hash
• raw_retention: discarded, redacted, retained
• classification: fact, decision, preference, task_state, noise
• privacy_scope: project, user, global
• candidate_memory_id or target document path
• promotion_decision_ref
• why_durable

Acceptance criteria

• Data Olympus can represent a proposed memory as derived from a captured event without treating that event as accepted guidance.
• kb_list_pending and proposal review surfaces show enough provenance to answer “why did the agent remember this?”
• The schema keeps the invariant explicit: captured event is evidence, candidate memory is proposed, accepted guidance is promoted.
• Existing evidence fields from Research: expose authority and provenance state for retrieved and proposed knowledge #109 are reused or extended rather than duplicated.
• Documentation includes examples for passive hook ingestion and external-session transcript ingestion.

Non-goals

• Do not build a Claude Code hook collector in this issue.
• Do not store raw transcripts by default.
• Do not create a new authority vocabulary that conflicts with status / in_force.

[ajdelaguila]

Another data point for the where-does-the-envelope-attach question, from a database maintainer this week (ArcadeDB, ArcadeData/arcadedb#4859). Their position was that the MCP transport should stay schema-agnostic and not impose a governance vocabulary, since that differs per database, and that provenance and lifecycle fields belong in the business-logic layer, a skill or hook, where agents filter on them like any other property.

That argues for keeping the capture-provenance envelope transport-neutral: stored as ordinary fields, returned on read, interpreted by the client rather than by the protocol. The interoperability value is then mostly in a shared field vocabulary (capture_event_id, capture_source, capture_method, confidence, review_state) so different ingestion paths and backends stay comparable without teaching each transport what the fields mean.

This does not change the research question here, it sharpens the boundary: define the envelope and its vocabulary, leave interpretation to the promotion and retrieval policy. The same separation is being drawn independently in OpenSearch ml-commons#4859 (retention versus currentness versus authority) and epicsagas/alcove#37 (temporal freshness rides the recall backend, authority state stays out) this week.