Maintainer of cognicore-env (open-source, MIT, MCP-compatible memory layer, no vector database required).
Haystack pipelines produce and consume knowledge, but memory between pipeline runs and across deployments is either the team's own glue or nothing. Nothing in the component ecosystem carries verified state with provenance from one pipeline to another, or from a Haystack deployment to an external agent.
Proposal: a memory store component with export/import. The bundle format carries, per memory: proof (command, result, exit code, output hash), chain of custody across agents, observed-until-reverified import semantics, trust decay, validity intervals, and owner-per-concept conflict rules — the last two from a public design review with multi-team operators, where the measured failure without them was models confidently reporting the wrong team's facts instead of declining.
Use case: an indexing pipeline's agent learns verified facts about data sources (schema quirks, refresh schedules, with the query outputs as proof); a downstream QA pipeline imports those memories as observed and promotes them after its own verification. Pipelines compound knowledge instead of each starting cold.
I can contribute the store integration and a documentation example. The transfer machinery is implemented and tested across four platforms. Would this fit the component catalog, and is there a preferred store interface to target?
Maintainer of cognicore-env (open-source, MIT, MCP-compatible memory layer, no vector database required).
Haystack pipelines produce and consume knowledge, but memory between pipeline runs and across deployments is either the team's own glue or nothing. Nothing in the component ecosystem carries verified state with provenance from one pipeline to another, or from a Haystack deployment to an external agent.
Proposal: a memory store component with export/import. The bundle format carries, per memory: proof (command, result, exit code, output hash), chain of custody across agents, observed-until-reverified import semantics, trust decay, validity intervals, and owner-per-concept conflict rules — the last two from a public design review with multi-team operators, where the measured failure without them was models confidently reporting the wrong team's facts instead of declining.
Use case: an indexing pipeline's agent learns verified facts about data sources (schema quirks, refresh schedules, with the query outputs as proof); a downstream QA pipeline imports those memories as observed and promotes them after its own verification. Pipelines compound knowledge instead of each starting cold.
I can contribute the store integration and a documentation example. The transfer machinery is implemented and tested across four platforms. Would this fit the component catalog, and is there a preferred store interface to target?