Proposal: define project-scoped BYODB conversation identity and trace/provenance metadata

Is your feature request related to a problem?

Yes. The review on closed PR #508 surfaced a real design gap in the BYODB/local path: Memori does not yet have a settled model for project-scoped conversations or for optional per-message trace/provenance metadata in local storage.

The most important safety concern is conversation reuse. If session-based lookup can reuse an active conversation and then update its project_id, that creates a risk of mixing or relabeling history across projects.

Before attempting smaller follow-up PRs, it would be useful to define the expected conversation-scoping rules and the intended storage/migration shape for this metadata.

The Solution

The useful next step seems to be defining the contract for this part of BYODB/local storage before implementation is split into smaller PRs.

The main design questions are:

1. Conversation/project scoping

• Should project_id be immutable once a conversation is created?
• If session lookup finds an active conversation whose project_id differs from the current context, should Memori create a new conversation rather than reuse the existing one?
• Should project scoping be treated as part of conversation identity rather than mutable conversation metadata?

1. Trace/provenance metadata

• Should local BYODB storage support optional per-message trace, source, and signal fields?
• If so, should trace be stored as opaque JSON/text, or is a stricter shape preferred?
• Which of these fields are intended to be stable storage/API surface versus internal implementation detail?

1. Implementation sequencing

• If this direction is desirable, what split would maintainers prefer for follow-up work?
• For example, would it make sense to separate:
  • schema/migration groundwork
  • Python storage/driver support
  • TypeScript storage support
  • native binding support
  • later behavior changes that consume the metadata

The goal of this issue is to align on the expected shape first so that any follow-up implementation can be kept smaller and fit the project’s preferred boundaries.

Alternatives Considered

A few alternatives came up while working on #508:

1. Leave BYODB conversations unscoped and avoid persisting project/provenance metadata locally.

• This keeps the local path simpler, but it also limits future scoped local workflows.

1. Treat project_id as mutable metadata on an already-active conversation.

• This appears unsafe because it can relabel or mix history across projects.

1. Start with a narrower first step such as schema-only groundwork.

• That may still be the right path, but it would be better to first align on the intended model so the groundwork matches the expected design.

1. Keep trace/provenance data out of local BYODB entirely.

• This avoids cross-stack storage changes, but it also leaves the local path with less context than future local memory workflows may need.

Affected Components

Database Schema, Vector Store / Memory, Other

Participation

• I am willing to submit a pull request for this feature.