topic-memory 0.1.0 → 0.1.1

package/README.zh-CN.md

@@ -1,387 +1,132 @@
 # Topic Memory
 
-**给现有 LLM 应用加上一层可插拔的长期对话记忆。**
+**按话题找回原始对话，让旧细节重新进入上下文。**
 
-[English](./README.md) · [详细接入指南](./docs/USAGE.zh-CN.md) · [架构与容量说明](./docs/ARCHITECTURE.zh-CN.md)
+[English](./README.md) · [接入指南](./docs/USAGE.zh-CN.md) · [效果验证](./docs/EVALUATION.md) · [架构说明](./docs/ARCHITECTURE.zh-CN.md)
 
-Topic Memory 是一个独立的 TypeScript SDK。它解决的不是“让模型拥有更大的 context window”，而是另一个更实际的问题：**当一段对话持续几百、几千轮以后，怎样让模型在需要时找回旧信息，而不是每次都把完整聊天记录重新塞进 prompt。**
+Topic Memory 是面向聊天应用和 AI Agent 的 TypeScript SDK。它把历史对话整理成话题，根据新问题选择相关话题，再恢复当时的原始对话，交给你已有的主模型使用。
 
-它会保留完整的 Canonical Transcript，把较早的 completed exchanges 按 topic 组织成可检索的长期记忆；新消息到来时，只打开与当前问题相关的旧 topic，最后把恢复出的上下文作为 `memoryContext` 交给你自己的 Main LLM。
+例如，用户曾决定去东京时住在**上野，每晚预算 14,000 日元**。之后聊过饮食、项目和天文学，当用户再次问起酒店计划时，SDK 可以重新打开那段对话，并保留可检查的原文依据。
 
-> **它是什么：** LLM 应用的长期记忆插件 / SDK。  
-> **它不是什么：** 聊天机器人、模型供应商，也不会替代你的 Main LLM。
-
-## 它可以用来做什么？
-
-适合需要长期连续性的聊天、AI 朋友、Agent 或长期项目助手，例如记住：
-
-- 用户长期偏好、习惯、人物、地点和个人背景；
-- 几百甚至几千个 exchange 以前做过的决定；
-- 项目历史、需求变更、以前尝试过的方法和未完成事项；
-- 某次旧对话的具体措辞、事件顺序或时间信息；
-- 任何不适合永久占用 Main LLM context window、但未来可能需要重新找回的信息。
-
-它和“只维护一份不断覆盖的聊天摘要”不同：Topic Memory 会保留原始 Canonical Transcript。检索命中一个 topic 后，可以根据这个 topic 保存的 transcript spans 重新打开当时的原始对话，而不是只能依赖一段已经压缩过的 summary。
-
-## 先搞清楚三个角色
-
-这是 v0.1 最容易被误解的地方。
-
-### Topic Worker
-
-Topic Worker 不负责回复用户。
-
-它在对话进行过程中整理已经完成的 exchanges，把属于同一个讨论主题的连续或相关对话归到一个 topic 下，并保存：
-
-- topic keywords；
-- retrieval terms；
-- 对应的原始 transcript spans；
-- topic status；
-- 时间信息。
-
-它更像一个后台“记忆整理员”。
-
-### Memory Selector
-
-Memory Selector 也不回复用户。
-
-新消息到来时，它会看：
-
-- 当前用户消息；
-- 最近 5 个 completed exchanges；
-- Topic Directory。
-
-然后最多选择 3 个可能相关的旧 topic。
-
-SDK 再根据 topic 保存的 spans 回到 Canonical Transcript，恢复当时的原始对话细节，并生成 `memoryContext`。
-
-### 你的 Main LLM
-
-真正给用户写回复的仍然是你自己的 **Main LLM**。
-
-**v0.1 默认可以只配置一个 Memory LLM，让同一个 Memory LLM 同时承担 Topic Worker 和 Memory Selector。这个 Memory LLM 不是 Main LLM。**
-
-你当然也可以在自己的产品里让 Memory LLM 和 Main LLM 使用同一个底层模型供应商甚至同一个 model name，但在架构上它们的职责仍然分开：
-
-```text
-Memory LLM
-├─ Topic Worker：整理记忆
-└─ Memory Selector：寻找记忆
-
-Your Main LLM
-└─ 根据当前消息 + memoryContext 生成最终回复
-```
-
-Topic Memory SDK 不会调用或接管你的 Main LLM。
-
-## 工作原理
-
-v0.1 的流程可以理解成六步。
-
-### 1. Canonical Transcript：先保存原始事实
-
-每一轮对话都会先进入 Canonical Transcript，并处于：
-
-- `pending`
-- `completed`
-- `failed`
-
-其中 completed exchange 才会被当作可靠的长期对话证据。
-
-### 2. Topic Worker：把旧对话整理成“目录”
-
-当至少存在 6 个 completed exchanges 后，Topic Worker 开始处理 active tail。
-
-它不会简单地“一轮生成一个记忆”。它会把属于同一主题的多轮对话归为一个 topic，并记录这个 topic 对应原始对话的准确 span。
-
-### 3. Topic Directory：只保留轻量索引
-
-长期历史不会整段塞给 Selector。
-
-Selector 先看到的是 Topic Directory——类似一本书的目录：它告诉模型“过去聊过什么”，但不会先把几千轮原文全部加载进来。
-
-### 4. Memory Selector：定位可能相关的旧 topic
-
-用户发来新消息后，Selector 根据当前问题、最近 5 个 exchanges 和 Topic Directory，最多选择 3 个相关 topic IDs。
-
-### 5. Opened Topic Packet：回到原始对话
-
-选中 topic 后，SDK 根据它保存的 spans，从 Canonical Transcript 中恢复真正的原始 user / assistant 对话。
-
-如果用户问“什么时候”“当时”“多久以前”之类的问题，还可以一起恢复时间元数据。
-
-### 6. Main LLM：拿到恢复出的记忆再回复
-
-最终 SDK 返回：
-
-```ts
-retrieved.memoryContext
-```
-
-你的 Main LLM 可以把这段内容作为额外上下文使用。
+## 安装
 
-```text
-Canonical Transcript
-        │
-        ▼
-   Topic Worker
-        │
-        ▼
-    Topic Store ─────→ Topic Directory
-                          │
-当前用户消息 ─────────────┤
-最近 5 个 exchanges ──────┤
-                          ▼
-                   Memory Selector
-                          │
-                    最多 3 个 topic
-                          │
-                          ▼
-                  Open Topic Packets
-                          │
-                          ▼
-                     memoryContext
-                          │
-                          ▼
-                    你的 Main LLM
+```bash
+npm install topic-memory
 ```
 
-如果 Selector 出错，SDK 会安全降级为长期 `memoryContext` 为空，而不是让整个聊天流程崩掉。
+使用 ES modules。SDK 要求 Node.js 18+；下方真实模型示例使用 `--env-file`，要求 **Node.js 20.6+**。2026-09-13 已在全新 Node 24 项目中安装并运行公开的 `topic-memory@0.1.0`。
 
-## 理论上能把“记忆跨度”提高多少？
-
-Topic Memory 并不会魔法般扩大模型本身的 context window。它做的是把：
-
-> **“总共保存了多少历史”**
-
-和
-
-> **“这一次请求真正送进模型多少历史”**
-
-拆开。
-
-以一个说明性的 128k context 场景为例：如果给历史记录大约 120k tokens，每个 completed exchange 平均约 200 tokens，那么传统“完整历史全部塞回 prompt”的方案大约在 **600 exchanges** 左右就已经接近预算。
-
-如果使用 Topic Memory，并假设：
-
-- 总历史：5,000 exchanges；
-- 平均 8 exchanges 被整理成一个 topic；
-- 每个 Topic Directory entry 平均约 60 tokens；
-- 最近上下文保留 5 exchanges；
-- 每次最多打开 3 个 topic；
-
-那么这 5,000 exchanges 对应的 memory retrieval prompt，在这组假设下大约仍只有 **43k–45k tokens**。
-
-也就是说，在这个示例模型里，能够被系统索引和按需恢复的历史跨度大约从 600 扩展到 5,000 exchanges，约 **8.3×**；同时不需要在每次回复时重放 5,000 exchanges 的全部原文。
-
-**这不是硬上限，也不是性能 benchmark。** 它只是根据 v0.1 当前数据结构做的容量推算。真实结果取决于消息长度、tokenizer、平均 topic 大小、模型 context window 和 Topic Directory 的增长速度。
-
-实际上，5,000 也不是存储层的最大值。v0.1 更早遇到的扩展瓶颈通常会是 Topic Directory 随 topic 数量线性增长。详细公式、假设和相关 long-context memory 研究放在 [架构与容量说明](./docs/ARCHITECTURE.zh-CN.md)，不会影响正常安装和使用。
-
-## 安装
-
-当前版本以源码形式公开，可 clone 使用，也可以通过 `npm pack` 生成 tarball。
+## 先试一下：不需要 API Key
 
 ```bash
-npm install
-npm run build
-npm pack
+git clone https://github.com/ziningshu-code/memory-system-mvp.git
+cd memory-system-mvp
+npm ci
+npm run demo
 ```
 
-## 配置 Memory LLM
+示例载入 **24 轮虚构对话**，找回较早的酒店话题，并打印原始对话。它使用真实 SDK 和**预设的整理、选择响应**，用于展示流程，不代表真实模型的检索准确率。
 
-内置 adapter 使用 OpenAI-compatible `/chat/completions` 协议：
+查看可切换中英文的网页演示：
 
 ```bash
-MEMORY_LLM_BASE_URL=https://your-openai-compatible-endpoint.example/v1
-MEMORY_LLM_API_KEY=replace-me
-MEMORY_LLM_MODEL=your-memory-model
+npm run build:site
+npm run preview
 ```
 
-不要把付费 API Key 放进公开前端 bundle。生产环境建议通过自己的后端或可信代理调用。
+打开 `http://127.0.0.1:4173`，选择酒店、饮食、项目或未记录信息场景，检查选中的话题和找回的原文。这个预设演示完全在浏览器本地运行，不需要账号、API Key，也不调用模型。
+
+## 快速接入
 
-## 5 分钟接入
+你的应用配置一个负责记忆的模型，同时保留自己原有的主模型。主模型应同时收到**最近对话**和**找回的旧证据**：
 
 ```ts
-import {
-  createMemory,
-  createOpenAICompatibleMemoryLlm,
-  InMemoryStorage,
-} from 'topic-memory';
-
-const memoryLlm = createOpenAICompatibleMemoryLlm({
-  baseUrl: process.env.MEMORY_LLM_BASE_URL!,
-  apiKey: process.env.MEMORY_LLM_API_KEY,
-  model: process.env.MEMORY_LLM_MODEL!,
-});
+import { createMemory, createOpenAICompatibleMemoryLlm, InMemoryStorage } from 'topic-memory';
 
 const memory = createMemory({
   storage: new InMemoryStorage(),
-  llm: memoryLlm,
+  llm: createOpenAICompatibleMemoryLlm({
+    baseUrl: process.env.MEMORY_LLM_BASE_URL!,
+    apiKey: process.env.MEMORY_LLM_API_KEY,
+    model: process.env.MEMORY_LLM_MODEL!,
+  }),
 });
 
-async function handleUserMessage(userMessage: string) {
-  const pending = await memory.begin(userMessage);
-
-  try {
-    const retrieved = await memory.retrieve({ userMessage });
-
-    // 这里是你自己原本就有的主聊天模型调用。
-    const assistantReply = await myOwnMainLlm({
-      userMessage,
-      memoryContext: retrieved.memoryContext,
-      recentContext: retrieved.recentContext,
-    });
-
-    await memory.completeExchange({
-      exchangeId: pending.id,
-      assistantText: assistantReply,
-    });
-
-    await memory.maybeRunTopicWorker();
-    return assistantReply;
-  } catch (error) {
-    await memory.failExchange({
-      exchangeId: pending.id,
-      failureReason: error instanceof Error ? error.message : String(error),
-    });
-    throw error;
-  }
-}
-```
-
-SDK **不会**调用 `myOwnMainLlm`。这个函数只是代表你现有 App 里的 Main LLM 调用。
-
-完整接法请看 [docs/USAGE.zh-CN.md](./docs/USAGE.zh-CN.md)。
-
-## 正确调用顺序
-
-```text
-用户消息
-→ memory.begin()
-→ memory.retrieve()
-→ 你的 Main LLM
-→ memory.completeExchange()
-→ memory.maybeRunTopicWorker()
-```
-
-如果 Main LLM 在 `begin()` 之后调用失败，使用 `memory.failExchange(...)`。
-
-## 前 6 个 completed exchanges
-
-Topic Worker 在至少存在 **6 个 completed exchanges** 之前不会运行。
-
-此时：
-
-- Canonical Transcript 仍然正常保存；
-- `recentContext` 仍然可用；
-- 因为还没有 topic，`memoryContext` 可能为空。
-
-这是正常行为。
-
-## Public API
-
-```ts
-createMemory
-MemoryEngine
-InMemoryStorage
-IndexedDbMemoryStorage
-createOpenAICompatibleMemoryLlm
-```
-
-主要方法：
-
-```ts
-begin
-beginExchange
-completeExchange
-failExchange
-maybeRunTopicWorker
-retrieve
-listExchanges
-listTopics
-getLatestTopicWorkerRun
-clear
+const pending = await memory.begin(userMessage);
+const context = await memory.retrieve({ userMessage });
+// 你的主模型接收当前消息、context.recentContext、context.memoryContext。
+const assistantReply = await yourMainModel(userMessage, context);
+await memory.completeExchange({ exchangeId: pending.id, assistantText: assistantReply });
+await memory.maybeRunTopicWorker();
 ```
 
-`retrieve()` 返回：
-
-```ts
-{
-  recentContext,
-  topicDirectory,
-  selectedTopicIds,
-  openedTopicPackets,
-  memoryContext,
-  needsTimeMetadata,
-  trace,
-}
-```
+上面的 `yourMainModel` 代表应用自己的调用。**可以直接运行的完整实现**在 [examples/chat.mjs](./examples/chat.mjs) 和 [provider.mjs](./examples/provider.mjs)，包含真实请求、最近上下文注入、失败处理和对话状态管理。
 
-## 存储
+## 使用真实模型
 
-Demo / 测试：
+在克隆的项目中，把 `.env.example` 复制为 `.env`，填写支持 OpenAI-compatible 协议的服务地址、模型和 API Key。配置文件只保存在本地。示例会向你配置的服务发送对话，并可能消耗付费额度。
 
-```ts
-new InMemoryStorage()
+```bash
+npm run demo:chat
 ```
 
-浏览器持久化：
+也可以先载入虚构对话，再直接提问酒店计划：
 
-```ts
-new IndexedDbMemoryStorage()
+```bash
+npm run demo:chat -- --seed
 ```
 
-服务端生产环境可以实现导出的 `MemoryStorage` interface，接入自己的数据库。
+对话素材是虚构的；话题整理、选择和最终回答都使用**实际配置的模型**。输入 `/exit` 退出。示例使用内存存储，退出后数据清空。
 
-## 高级配置
+## 现在验证到了哪一步？
 
-默认只需要一个 Memory LLM：
+| 检查 | 结果及含义 |
+| --- | --- |
+| npm 公开软件包 | 已在全新 Node 24 项目安装，并恢复旧对话 |
+| SDK 状态、存储、适配器和检索 | 由 CI 自动检查 |
+| 四个预设演示场景 | 检查原文恢复和信息不存在时的空记忆；[查看记录](./docs/evaluation/scripted.json) |
+| 真实模型对照 | 已提供可运行的测试工具；**暂不声称有真实模型性能结论** |
 
-```ts
-createMemory({ storage, llm: memoryLlm })
-```
+`npm run evaluate` 运行预设检查。`npm run evaluate:live` 使用同一个真实主模型，对比**最近五轮上下文**、**完整历史**和**话题检索**，记录原始回答、字面事实评分、请求耗时，以及服务实际返回的 token 用量。[查看方法和边界](./docs/EVALUATION.md)。
 
-这个 Memory LLM 同时处理 Topic Worker 和 Selector。
+此前的 **8.3 倍**是容量假设示例，**不是实测的准确率提升或有效记忆提升**。公式和前提保留在[架构与容量说明](./docs/ARCHITECTURE.zh-CN.md)。
 
-也可以拆成两个：
+## 工作流程
 
-```ts
-createMemory({
-  storage,
-  topicWorker: topicWorkerLlm,
-  selector: selectorLlm,
-});
+```text
+保存的对话 → 话题整理 → 话题目录
+新问题 + 最近对话 + 目录 → 选择器
+选中的话题 ID → 原始对话片段 → 你的主模型
 ```
 
-无论哪种配置，都不会替代宿主应用自己的 Main LLM。
-
-## 失败降级
+整理和选择可以使用同一个记忆模型，也支持分别配置。SDK 不生成最终回复，也不替换主模型，不要求 embedding 或向量数据库。
 
-- **Main LLM 调用失败：** 使用 `failExchange`；
-- **Topic Worker provider 失败：** 记录失败并保留已有 topics；
-- **Topic Worker 输出结构不合法：** 直接拒绝，不写入 Topic Store；
-- **Selector 失败：** 长期 `memoryContext` 降级为空；
-- **当前问题不需要旧记忆：** `memoryContext` 本来就应该为空。
+## 当前边界
 
-## 验证
+- 至少完成 **6 轮对话**才开始生成长期话题；之前最近上下文仍可使用。
+- 每次最多选 **3 个话题**，可能漏掉证据，可检查 `retrieve().trace`。
+- 选择器出错时返回空长期记忆；应用仍需处理请求超时和存储失败。
+- `InMemoryStorage` 不持久化；浏览器可使用 `IndexedDbMemoryStorage`；后端数据库和用户／会话隔离需要实现 `MemoryStorage`。
+- 同一个存储中的对话和整理任务应串行执行，SDK 没有协调并发写入。
+- 目录会随历史增加；v0.1 没有总 token 预算限制。
+- 历史内容应作为不可信的证据处理，不能提升为系统指令。
 
-仓库 CI 会按真实第三方项目的使用方式验证 package：
+## 开发检查
 
 ```bash
+npm ci
 npm run build
 npm run typecheck
 npm test
-npm pack --dry-run
 npm run smoke:consumer
+npm run evaluate
+npm run build:site
 ```
 
-`smoke:consumer` 会把 SDK 打包，安装进一个全新的临时 Node 项目，只通过 public package exports 导入，然后运行完整 memory pipeline，并验证模拟的宿主 Main LLM 最终收到非空 `memoryContext`。
-
-## 非目标
+## 参与试用
 
-v0.1 不管理 Persona、Big Five、Relationship、Proactive Messaging、UI、embedding、vector database，也不管理宿主应用的 Main LLM。
+在自己的开发场景中试一个对话，再[反馈体验](https://github.com/ziningshu-code/memory-system-mvp/issues/new?template=try-it.yml)：希望记住什么、安装是否顺利、哪里帮上了忙或第一次失败。公开反馈前请去掉密钥和私人对话。
 
 ## License
 
-MIT
+MIT

package/docs/EVALUATION.md

@@ -0,0 +1,65 @@
+# Evaluation / 效果验证
+
+## Current evidence
+
+On 2026-09-13, the public `topic-memory@0.1.0` package was installed into a fresh Node 24 project and used to retrieve an old hotel exchange with a scripted model adapter. The source build, 14 existing SDK tests and fresh-consumer tarball test passed locally on Windows. See CI for checks against the latest revision.
+
+The checked-in [scripted result](./evaluation/scripted.json) covers four cases: Tokyo hotel details, a food allergy, a project decision, and an unknown passport number. The three positive facts occur outside the most recent five exchanges.
+
+**These checks demonstrate mechanics. They do not establish real-model accuracy, latency, token savings, production readiness, or performance on long conversations.** No real-model result is published here yet.
+
+中文：已验证公开包的安装和预设响应下的原文恢复。预设测试不等于真实模型效果；目前还没有发布真实模型的准确率、速度或费用结论。
+
+## Reproduce the scripted checks
+
+```bash
+npm ci
+npm run evaluate
+```
+
+The SDK ingests a public, synthetic, 24-exchange conversation. Its actual topic validation and span recovery run normally. Worker topic boundaries and selector choices are scripted. This makes the walkthrough stable and useful for debugging the integration, while explicitly removing model quality from the test.
+
+For the missing fact, the scripted selector chooses no topic and the SDK returns an empty `memoryContext`. This does not prove that an arbitrary main model will abstain.
+
+## Run the real-model comparison
+
+Requires Node 20.6+. Copy `.env.example` to `.env`, configure your provider, then run:
+
+```bash
+npm run evaluate:live
+```
+
+The command makes real provider requests and may incur charges. It sends only the checked-in synthetic dataset and questions, not private chat history. The API key stays in the request header and is not written into the report. Output is saved locally to the ignored `benchmark-results/live.json` file.
+
+The small comparison uses the **same final-answer model, system instruction and question** for:
+
+1. **Recent five:** only the latest five exchanges.
+2. **Full transcript:** all 24 exchanges.
+3. **Topic memory:** the latest five exchanges plus SDK-retrieved original topic packets.
+
+The live worker constructs topics in one batch over the archive. The selector uses the actual model for each question. Questions are independent: their answers are not added back into the archive. Expected answers and scoring rules are never included in the model's input.
+
+The run normally makes 1 worker request, 4 selector requests and 12 main-model requests (17 total). If topic construction fails, the report records this and the memory method can fall back to recent context; it is not silently counted as success.
+
+## What the report measures
+
+- Raw model answers for each question and method.
+- A transparent literal check for the expected facts. For the unknown fact, a conservative English abstention pattern is checked. Read the answers: this is not a semantic judge and may score a valid paraphrase incorrectly or miss a contradiction.
+- Selected topic IDs, recovered source text, expected evidence sequence numbers, and selector errors.
+- Per-request elapsed milliseconds, including network latency.
+- Input and output token usage **only when the provider reports it**. Missing usage is `null`, not zero.
+
+For a fair total token comparison, count the one-time worker construction cost, all selector requests and all topic-memory main-model requests. Show construction separately if amortizing it across later queries. Do not compare the topic method's main-model tokens alone against a baseline's total spend. Prices are not hard-coded; apply the provider's actual rates to recorded usage if you need a monetary estimate.
+
+The `memoryCharacters` and `selectorInputCharacters` fields are string lengths, **not token estimates**.
+
+## Limits and next experiments
+
+Four hand-written questions over 24 synthetic exchanges are a small integration evaluation. They are not representative of hundreds or thousands of turns. There is one run per method, no confidence interval, no summary/vector-search baseline, and no continuous-ingestion measurement.
+
+Before making performance claims, add held-out conversation sets with updates to facts, interleaved topics, similar names, time questions, irrelevant questions, and materially longer archives. Repeat runs and disclose the models, prompts, failures and complete provider usage. Compare against a rolling-summary or retrieval baseline appropriate to the host application.
+
+## The earlier 8.3× figure
+
+The [architecture appendix](./ARCHITECTURE.md) contains a capacity calculation under assumed message and topic sizes. It is not an empirical result and must not be presented as measured memory accuracy or capacity improvement.
+

package/docs/TRYOUT.md

@@ -0,0 +1,24 @@
+# First-user try-out
+
+Ask 5–10 developers who are already building a chat app or agent to try one task. This is a proposed recruitment plan, not a claim that users have already tested the project.
+
+1. Give them the README and demo link without explaining the architecture first.
+2. Ask what they think the SDK does and whether it fits a problem they already have.
+3. Let them install and run the no-key example.
+4. If relevant, let them connect their own provider and try a sanitized conversation.
+5. Record the first confusing step, time to first successful retrieval, and whether they would use it again.
+
+Use the repository's first-use feedback issue form for voluntary public feedback. Keep private conversations and credentials out of issues. Outreach messages are provided below for the maintainer to send to people they choose; none have been sent automatically.
+
+## Invitation / 邀请文案
+
+I'm testing Topic Memory, a small TypeScript SDK that finds older conversation topics and reopens the original messages for an existing chat model. There's a no-key walkthrough and a runnable real-model example. If you're building a chat app or agent, would you try one conversation and tell me the first point that feels confusing or fails? I'm looking for usability and retrieval feedback, not a Star exchange.
+
+我做了一个 TypeScript 记忆 SDK：从旧对话中找到相关话题，再把当时的原文交给已有的聊天模型。现在有无需 API Key 的演示和可以接入真实模型的例子。如果你正在做聊天应用或 Agent，想请你试一个对话，告诉我第一个让你困惑或失败的地方。我主要想了解它是否好接入、能否找回你需要的信息。
+
+## What to record
+
+| Date | Relevant use case | Install succeeded | First retrieval succeeded | Main obstacle | Would use again |
+| --- | --- | --- | --- | --- | --- |
+
+Read repository Traffic as a separate funnel signal. Low traffic suggests investigating discovery; visitors who fail installation suggest onboarding work; successful trials that do not help suggest product/effectiveness work. Stars are a secondary signal and do not establish any of these alone.