Publish PRISM-Memory adapter bundle

README.md

@@ -137,6 +137,7 @@ More held-out examples live in
 - [docs/release/datasets.md](docs/release/datasets.md)
 - [docs/release/extraction-examples.md](docs/release/extraction-examples.md)
 - [docs/release/extraction-skill.md](docs/release/extraction-skill.md)
+- [docs/release/memory-scenarios.md](docs/release/memory-scenarios.md)
 - [docs/release/release-results.md](docs/release/release-results.md)
 - [docs/release/technical-blog.md](docs/release/technical-blog.md)
 - [results/confirmed_exp15_summary.json](results/confirmed_exp15_summary.json)

docs/release/memory-scenarios.md

@@ -0,0 +1,105 @@
+# PRISM-Memory End-To-End Scenarios
+
+These are compact product-style scenarios built from the public release
+artifacts.
+
+- The first two use the released held-out extraction examples.
+- The last two use confirmed held-out benchmark cases from
+  [../../results/scenario_comparisons.json](../../results/scenario_comparisons.json).
+
+The point is not just that the extractor matches GPT-4.1-style labels. The
+point is that a later system can ask a concrete question and get back a useful,
+inspectable answer from stored memory.
+
+## 1. Keep hard limits and notification preferences
+
+**Conversation turn**
+
+> yeah, I think starting with incremental scans and parallel matrix jobs makes sense. We have 20 concurrent jobs max on GitHub Actions currently. Also want to keep Slack notifications from Snyk consistent with other pipeline alerts, aggregated and concise.
+
+**Stored memory**
+
+- GitHub Actions concurrency limit: 20 concurrent jobs
+- Snyk Slack notifications should be aggregated and concise
+
+**Later question**
+
+What is our GitHub Actions concurrency limit, and how should Snyk alerts look?
+
+**Answer from memory**
+
+20 concurrent jobs. Snyk alerts should be aggregated and concise.
+
+**Why it matters**
+
+This is the kind of operational detail that gets buried in chat but needs to
+survive into later workflow drafts and agent actions.
+
+## 2. Keep current state separate from the roadmap
+
+**Conversation turn**
+
+> yeah good point about resource overhead, we set CPU limits for all sidecars and monitor with Prometheus now. no mTLS yet, but it’s on the roadmap for phase two. as for routing, we want to start with canary deployments and traffic splitting, maybe some basic fault injection for testing.
+
+**Stored memory**
+
+- Sidecar CPU limits set and monitored via Prometheus
+- Istio mTLS planned for phase two
+- Routing strategy: canary deployments and traffic splitting; basic fault injection planned
+
+**Later question**
+
+Did we already enable mTLS, and what rollout strategy are we planning?
+
+**Answer from memory**
+
+mTLS is not enabled yet; it is planned for phase two. The rollout plan is
+canary deployments and traffic splitting, with basic fault injection planned.
+
+**Why it matters**
+
+Memory systems often blur the current state with the planned state. This is the
+kind of distinction that matters in deployment and incident work.
+
+## 3. Answer dated questions instead of only remembering themes
+
+**Question**
+
+Which hobby did Sam take up in May 2023?
+
+**Retrieved memory**
+
+- Sam: [18 May 2023] Sam is considering trying painting as a new hobby.
+- Sam: [24 May 2023] Sam has been considering trying painting as a new hobby.
+
+**Answer from memory**
+
+painting
+
+**Why it matters**
+
+A useful memory system should not just remember that someone talked about
+hobbies. It should recover the dated fact that actually answers the later
+question.
+
+## 4. Refuse unsupported claims instead of inventing a reason
+
+**Question**
+
+Why did Dave get his guitar customized with a shiny finish?
+
+**Retrieved memory**
+
+- Dave: That guitar has a gorgeous purple hue. Why did you make it so shiny?
+- Good pick! The customized purple glow gives it a unique look that really stands out.
+- Dave: The guitar was in bad condition when Dave found it.
+
+**Answer from memory**
+
+None / unsupported
+
+**Why it matters**
+
+Memory systems are more useful when they can refuse cleanly. Here the retrieved
+context talks about the guitar and the finish, but it never actually supports
+the premise that Dave customized it for a specific reason.

docs/release/technical-blog.md

@@ -6,6 +6,9 @@
 dialogue into proposition-level memory and retrieves it with an inspectable
 hybrid stack.
 
+The point is not that a 7B model chats well. The point is that a 7B open model
+can write memory records that another system can actually use later.
+
 This package now ships one public extraction skill and one public checkpoint:
 
 - **Checkpoint:** `exp15_sft_qwen7b_4ep`
@@ -17,6 +20,70 @@ The public hook is simple:
 
 **PRISM-Memory turns conversations into durable, searchable memory.**
 
+## Why This Is Useful In Practice
+
+A memory writer is only interesting if a later system can ask a pointed
+question and get back a useful answer without rereading the original chat. The
+public release artifacts already show that pattern.
+
+### 1. Keep hard limits and preferences available for later work
+
+The extractor can turn a single conversational turn into stable memory like:
+
+- GitHub Actions concurrency limit: `20` concurrent jobs
+- Snyk Slack notifications should be aggregated and concise
+
+That means a later system can answer:
+
+> What is our GitHub Actions concurrency limit, and how should Snyk alerts look?
+
+with:
+
+> `20` concurrent jobs. Alerts should be aggregated and concise.
+
+That is a real product use case. Teams mention constraints and preferences once,
+then expect downstream tools and agents to remember them.
+
+### 2. Keep current state separate from the roadmap
+
+The released extractor can also preserve the difference between what is true
+now and what is only planned:
+
+- sidecar CPU limits are already set and monitored
+- mTLS is planned for phase two
+- rollout strategy is canary deployments plus traffic splitting
+
+So a later question like:
+
+> Did we already enable mTLS, and what rollout strategy are we planning?
+
+can be answered without confusing the present state with the future plan.
+
+This is a core memory problem, not a style problem. Chat history tends to blur
+these states together.
+
+### 3. Answer dated questions with dated evidence
+
+One confirmed held-out benchmark case asks:
+
+> Which hobby did Sam take up in May 2023?
+
+The retrieved memory contains explicit dated propositions about Sam trying
+painting in May 2023, and the released system answers:
+
+> painting
+
+That matters because the useful behavior is not “remember that hobbies were
+discussed.” The useful behavior is “recover the dated fact that actually
+answers the later question.”
+
+There is a fourth practical behavior that matters too: refusal. On the held-out
+adversarial guitar case, the released model returns `None` instead of inventing
+a reason for an unsupported premise. That is also part of being useful.
+
+For the compact scenario version of this story, see
+[memory-scenarios.md](memory-scenarios.md).
+
 ## What The Repo Actually Contributed
 
 The core contribution is not another opaque memory model. The repo showed that a