@anuma/sdk 3.13.2 → 4.0.1

package/dist/react/{consolidate-R6FH7XMV.mjs → consolidate-IFIKT25Z.mjs}

@@ -18,19 +18,21 @@ A "memory" is a self-contained natural-language fact about the user. Multiple me
 Decide one of four actions:
 
 - "create": the new memory describes a distinct fact not covered by any existing memory. Write it as new.
-- "update": the new memory describes the SAME FACET as exactly one existing memory and is COMPATIBLE with it \u2014 it adds detail, fixes an incomplete value, or rephrases the same still-true fact. Return targetId of that existing memory + the consolidated content (richest version of the two).
-- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory \u2014 the old fact was true before but is false now (a state change). Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
-- "noop": the new memory is already fully captured by an existing memory \u2014 same facet, no new information. Skip the write.
+- "update": the new memory describes the SAME FACET of the SAME SUBJECT as exactly one existing memory, is COMPATIBLE with it, and ADDS INFORMATION \u2014 it adds detail or fills in an incomplete value. Return targetId of that existing memory + the consolidated content (richest version of the two). A pure rewording that adds nothing is NOT an update; it is "noop".
+- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory ABOUT THE SAME SUBJECT \u2014 the old fact was true before but is false now (a state change). Before choosing this, name the subject of the new memory and the subject of each candidate out loud to yourself; if they are different people, the old fact is still TRUE and superseding it would delete a correct memory \u2014 choose "create" instead. Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
+- "noop": the new memory is already fully captured by an existing memory \u2014 same facet of the same subject, no new information. This INCLUDES a restatement in different words ("has two kids" / "has two children"): if the existing memory already tells you everything the new one does, the answer is noop no matter how differently it is worded. Skip the write.
 
 RULES (carry these strictly):
 
 1. ONE OBSERVATION PER DISTINCT FACET. If the new memory is about "user's aunt's twins" and an existing memory is also about "user's aunt's twins", they are the same facet \u2192 update, never create.
+1a. SAME SUBJECT REQUIRED \u2014 check this FIRST, before you look at the facet. The subject is WHO the fact is about: the user, or a specific person or thing in their life (a relative, their manager, their dog Biscuit). "update", "supersede" and "noop" all require the new memory and the existing one to be about the SAME subject. Two memories can share a facet and still have different subjects, and then they are simply two different facts: "User's daughter is allergic to peanuts" and "User is allergic to peanuts" are both about a peanut allergy, but one is about the DAUGHTER and one is about the USER \u2192 create, keep both. This holds for EVERY attribute, not just the one in this example \u2014 where someone lives, who they work for, what they own, how old they are. A possessive like "user's X" makes X the subject, not the user; strip it and ask "whose fact is this?" before comparing anything. Never retire the user's own value because a fact about somebody else resembles it \u2014 the user's fact is still true, and retiring it destroys it.
 2. MATCH BY FACET, NOT TOPIC. Two memories both mentioning "Zara" is not enough to merge \u2014 only merge if they describe the same property (e.g. both about "user's pending Zara boot exchange"). Two memories about Zara on different topics (e.g. "user shops at Zara" + "user returned a sweater to Zara last week") are separate facets.
 3. NO COMPUTATION. Do not sum counts, decrement quantities, or derive new facts from existing ones. If the new memory says "user spent $200 today" and an existing memory says "user spent $150 yesterday", these are TWO SEPARATE EVENTS \u2014 create.
 4. EVENTS vs STANDING STATE.
    - Distinct EVENTS (episodic \u2014 something that happened on a date) are separate memories, even if the same activity: "user went to gym Monday" vs "user went to gym Friday" \u2192 create; keep both.
-   - A STANDING ATTRIBUTE (an ongoing state: where the user lives/works, relationship status, current role) has ONE current value. When the new memory changes that value ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true).
-5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory; then choose supersede. Over-merging loses information; a live contradiction is worse than either.
+   - A STANDING ATTRIBUTE (an ongoing state: where someone lives/works, relationship status, current role) has ONE current value PER SUBJECT. When the new memory changes that value FOR THE SAME SUBJECT ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true). A different subject holding the same attribute is not a value change at all \u2192 create.
+5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory ABOUT THE SAME SUBJECT; then choose supersede. Two facts about different subjects never contradict each other, however similarly they read. Over-merging loses information; a live contradiction is worse than either.
+6. When in doubt between update and noop, ask whether the existing memory ALONE already answers everything the new one would. If it does, choose noop \u2014 a write that changes only the wording costs a re-embed and makes an old fact look newly observed.
 
 OUTPUT \u2014 strict JSON, no prose:
 {

package/dist/react/index.cjs

@@ -8847,19 +8847,21 @@ A "memory" is a self-contained natural-language fact about the user. Multiple me
 Decide one of four actions:
 
 - "create": the new memory describes a distinct fact not covered by any existing memory. Write it as new.
-- "update": the new memory describes the SAME FACET as exactly one existing memory and is COMPATIBLE with it \u2014 it adds detail, fixes an incomplete value, or rephrases the same still-true fact. Return targetId of that existing memory + the consolidated content (richest version of the two).
-- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory \u2014 the old fact was true before but is false now (a state change). Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
-- "noop": the new memory is already fully captured by an existing memory \u2014 same facet, no new information. Skip the write.
+- "update": the new memory describes the SAME FACET of the SAME SUBJECT as exactly one existing memory, is COMPATIBLE with it, and ADDS INFORMATION \u2014 it adds detail or fills in an incomplete value. Return targetId of that existing memory + the consolidated content (richest version of the two). A pure rewording that adds nothing is NOT an update; it is "noop".
+- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory ABOUT THE SAME SUBJECT \u2014 the old fact was true before but is false now (a state change). Before choosing this, name the subject of the new memory and the subject of each candidate out loud to yourself; if they are different people, the old fact is still TRUE and superseding it would delete a correct memory \u2014 choose "create" instead. Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
+- "noop": the new memory is already fully captured by an existing memory \u2014 same facet of the same subject, no new information. This INCLUDES a restatement in different words ("has two kids" / "has two children"): if the existing memory already tells you everything the new one does, the answer is noop no matter how differently it is worded. Skip the write.
 
 RULES (carry these strictly):
 
 1. ONE OBSERVATION PER DISTINCT FACET. If the new memory is about "user's aunt's twins" and an existing memory is also about "user's aunt's twins", they are the same facet \u2192 update, never create.
+1a. SAME SUBJECT REQUIRED \u2014 check this FIRST, before you look at the facet. The subject is WHO the fact is about: the user, or a specific person or thing in their life (a relative, their manager, their dog Biscuit). "update", "supersede" and "noop" all require the new memory and the existing one to be about the SAME subject. Two memories can share a facet and still have different subjects, and then they are simply two different facts: "User's daughter is allergic to peanuts" and "User is allergic to peanuts" are both about a peanut allergy, but one is about the DAUGHTER and one is about the USER \u2192 create, keep both. This holds for EVERY attribute, not just the one in this example \u2014 where someone lives, who they work for, what they own, how old they are. A possessive like "user's X" makes X the subject, not the user; strip it and ask "whose fact is this?" before comparing anything. Never retire the user's own value because a fact about somebody else resembles it \u2014 the user's fact is still true, and retiring it destroys it.
 2. MATCH BY FACET, NOT TOPIC. Two memories both mentioning "Zara" is not enough to merge \u2014 only merge if they describe the same property (e.g. both about "user's pending Zara boot exchange"). Two memories about Zara on different topics (e.g. "user shops at Zara" + "user returned a sweater to Zara last week") are separate facets.
 3. NO COMPUTATION. Do not sum counts, decrement quantities, or derive new facts from existing ones. If the new memory says "user spent $200 today" and an existing memory says "user spent $150 yesterday", these are TWO SEPARATE EVENTS \u2014 create.
 4. EVENTS vs STANDING STATE.
    - Distinct EVENTS (episodic \u2014 something that happened on a date) are separate memories, even if the same activity: "user went to gym Monday" vs "user went to gym Friday" \u2192 create; keep both.
-   - A STANDING ATTRIBUTE (an ongoing state: where the user lives/works, relationship status, current role) has ONE current value. When the new memory changes that value ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true).
-5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory; then choose supersede. Over-merging loses information; a live contradiction is worse than either.
+   - A STANDING ATTRIBUTE (an ongoing state: where someone lives/works, relationship status, current role) has ONE current value PER SUBJECT. When the new memory changes that value FOR THE SAME SUBJECT ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true). A different subject holding the same attribute is not a value change at all \u2192 create.
+5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory ABOUT THE SAME SUBJECT; then choose supersede. Two facts about different subjects never contradict each other, however similarly they read. Over-merging loses information; a live contradiction is worse than either.
+6. When in doubt between update and noop, ask whether the existing memory ALONE already answers everything the new one would. If it does, choose noop \u2014 a write that changes only the wording costs a re-embed and makes an old fact look newly observed.
 
 OUTPUT \u2014 strict JSON, no prose:
 {
@@ -18265,7 +18267,8 @@ function configMatches(a, b) {
   return a.redacted === b.redacted && a.facetsSignature === b.facetsSignature && (a.reviewedMemoryIdsSignature ?? "") === b.reviewedMemoryIdsSignature && a.scopes.length === b.scopes.length && a.scopes.every((s, i) => s === b.scopes[i]);
 }
 function reviewedMemoryIdsSignature(ids) {
-  if (ids === void 0 || ids.length === 0) return "";
+  if (ids === void 0) return "";
+  if (ids.length === 0) return "\0gated-empty";
   return [...new Set(ids)].sort().join("\n");
 }
 function facetsSignature(facets) {
@@ -18375,7 +18378,16 @@ async function synthesizeFacet(facet, ctx, options, prior) {
   const factTypeWeights = { ...DEFAULT_PROFILE_FACT_TYPE_WEIGHTS, ...options.factTypeWeights };
   const proofCountAlpha = options.proofCountAlpha ?? DEFAULT_PROFILE_PROOF_ALPHA;
   const reviewed = options.reviewedMemoryIds;
-  const hasReviewGate = reviewed !== void 0 && reviewed.length > 0;
+  const hasReviewGate = reviewed !== void 0;
+  if (hasReviewGate && reviewed.length === 0) {
+    return {
+      key: facet.key,
+      label: facet.label,
+      text: "",
+      sourceMemoryIds: [],
+      generatedAt: Date.now()
+    };
+  }
   const recalled = await recall(facet.query, ctx, {
     scopes,
     limit: hasReviewGate ? RECALL_MAX_LIMIT : limit,

package/dist/react/index.d.mts

@@ -8949,10 +8949,20 @@ interface SynthesizeProfileOptions extends PortalLlmAuth {
      */
     proofCountAlpha?: number;
     /**
-     * When non-empty, intersect each facet's recalled evidence with this id set
-     * before the LLM runs (publish-review gate). Empty intersection → empty
-     * section (legitimate no-evidence), not a stale fallback. Omit / empty →
-     * no gate.
+     * Publish-review gate: when SUPPLIED, each facet's recalled evidence is
+     * intersected with this id set before the LLM runs, so synthesis can only draw
+     * on memories the user approved for publication. Empty intersection → empty
+     * section (legitimate no-evidence), not a stale fallback.
+     *
+     * Pass the user's published set (e.g. `getAllVaultMemoriesOp(ctx, { visibility:
+     * ["public"] })`) to keep a published profile derivable only from published
+     * memories — People Nearby's two-tier model treats `private` memories as never
+     * leaving the device, and a summary derived from them is a derivative that does.
+     *
+     * `[]` means "nothing approved" and gates everything OUT (no recall, no LLM
+     * call, empty sections). **Omitting the field is the only way to run ungated**
+     * — that asymmetry is deliberate, so a caller computing a published set can
+     * never accidentally disable the gate by finding it empty.
      */
     reviewedMemoryIds?: readonly string[];
 }

package/dist/react/index.d.ts

@@ -8949,10 +8949,20 @@ interface SynthesizeProfileOptions extends PortalLlmAuth {
      */
     proofCountAlpha?: number;
     /**
-     * When non-empty, intersect each facet's recalled evidence with this id set
-     * before the LLM runs (publish-review gate). Empty intersection → empty
-     * section (legitimate no-evidence), not a stale fallback. Omit / empty →
-     * no gate.
+     * Publish-review gate: when SUPPLIED, each facet's recalled evidence is
+     * intersected with this id set before the LLM runs, so synthesis can only draw
+     * on memories the user approved for publication. Empty intersection → empty
+     * section (legitimate no-evidence), not a stale fallback.
+     *
+     * Pass the user's published set (e.g. `getAllVaultMemoriesOp(ctx, { visibility:
+     * ["public"] })`) to keep a published profile derivable only from published
+     * memories — People Nearby's two-tier model treats `private` memories as never
+     * leaving the device, and a summary derived from them is a derivative that does.
+     *
+     * `[]` means "nothing approved" and gates everything OUT (no recall, no LLM
+     * call, empty sections). **Omitting the field is the only way to run ungated**
+     * — that asymmetry is deliberate, so a caller computing a published set can
+     * never accidentally disable the gate by finding it empty.
      */
     reviewedMemoryIds?: readonly string[];
 }

package/dist/react/index.mjs

@@ -161,7 +161,7 @@ import {
   updateVaultMemoryOp,
   useEncryption,
   vaultMemoryToStored
-} from "./chunk-XXCZVG4Z.mjs";
+} from "./chunk-BAJL46NX.mjs";
 import {
   PiiRedactor,
   createStreamingDeAnonymizer,
@@ -7490,7 +7490,7 @@ async function tryConsolidate(trimmed, ctx, options, prepared) {
     content: m.content,
     similarity: m.similarity
   }));
-  const { consolidateMemory: doConsolidate } = await import("./consolidate-R6FH7XMV.mjs");
+  const { consolidateMemory: doConsolidate } = await import("./consolidate-IFIKT25Z.mjs");
   const decision = await doConsolidate(trimmed, candidates, consolidateOptions);
   if (decision.action === "create") return null;
   if (decision.action === "supersede" && decision.content) {
@@ -9036,7 +9036,8 @@ function configMatches(a, b) {
   return a.redacted === b.redacted && a.facetsSignature === b.facetsSignature && (a.reviewedMemoryIdsSignature ?? "") === b.reviewedMemoryIdsSignature && a.scopes.length === b.scopes.length && a.scopes.every((s, i) => s === b.scopes[i]);
 }
 function reviewedMemoryIdsSignature(ids) {
-  if (ids === void 0 || ids.length === 0) return "";
+  if (ids === void 0) return "";
+  if (ids.length === 0) return "\0gated-empty";
   return [...new Set(ids)].sort().join("\n");
 }
 function facetsSignature(facets) {
@@ -9146,7 +9147,16 @@ async function synthesizeFacet(facet, ctx, options, prior) {
   const factTypeWeights = { ...DEFAULT_PROFILE_FACT_TYPE_WEIGHTS, ...options.factTypeWeights };
   const proofCountAlpha = options.proofCountAlpha ?? DEFAULT_PROFILE_PROOF_ALPHA;
   const reviewed = options.reviewedMemoryIds;
-  const hasReviewGate = reviewed !== void 0 && reviewed.length > 0;
+  const hasReviewGate = reviewed !== void 0;
+  if (hasReviewGate && reviewed.length === 0) {
+    return {
+      key: facet.key,
+      label: facet.label,
+      text: "",
+      sourceMemoryIds: [],
+      generatedAt: Date.now()
+    };
+  }
   const recalled = await recall(facet.query, ctx, {
     scopes,
     limit: hasReviewGate ? RECALL_MAX_LIMIT : limit,

package/dist/react/{recall-KTJCUAXN.mjs → recall-R3VX2UST.mjs}

@@ -1,6 +1,6 @@
 import {
   recall
-} from "./chunk-XXCZVG4Z.mjs";
+} from "./chunk-BAJL46NX.mjs";
 import "./chunk-ILAWDQDE.mjs";
 import "./chunk-GYKJOWEO.mjs";
 export {

package/dist/server/{consolidate-4VEAS3YN.mjs → consolidate-GRMEDWKK.mjs}

@@ -18,19 +18,21 @@ A "memory" is a self-contained natural-language fact about the user. Multiple me
 Decide one of four actions:
 
 - "create": the new memory describes a distinct fact not covered by any existing memory. Write it as new.
-- "update": the new memory describes the SAME FACET as exactly one existing memory and is COMPATIBLE with it \u2014 it adds detail, fixes an incomplete value, or rephrases the same still-true fact. Return targetId of that existing memory + the consolidated content (richest version of the two).
-- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory \u2014 the old fact was true before but is false now (a state change). Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
-- "noop": the new memory is already fully captured by an existing memory \u2014 same facet, no new information. Skip the write.
+- "update": the new memory describes the SAME FACET of the SAME SUBJECT as exactly one existing memory, is COMPATIBLE with it, and ADDS INFORMATION \u2014 it adds detail or fills in an incomplete value. Return targetId of that existing memory + the consolidated content (richest version of the two). A pure rewording that adds nothing is NOT an update; it is "noop".
+- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory ABOUT THE SAME SUBJECT \u2014 the old fact was true before but is false now (a state change). Before choosing this, name the subject of the new memory and the subject of each candidate out loud to yourself; if they are different people, the old fact is still TRUE and superseding it would delete a correct memory \u2014 choose "create" instead. Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
+- "noop": the new memory is already fully captured by an existing memory \u2014 same facet of the same subject, no new information. This INCLUDES a restatement in different words ("has two kids" / "has two children"): if the existing memory already tells you everything the new one does, the answer is noop no matter how differently it is worded. Skip the write.
 
 RULES (carry these strictly):
 
 1. ONE OBSERVATION PER DISTINCT FACET. If the new memory is about "user's aunt's twins" and an existing memory is also about "user's aunt's twins", they are the same facet \u2192 update, never create.
+1a. SAME SUBJECT REQUIRED \u2014 check this FIRST, before you look at the facet. The subject is WHO the fact is about: the user, or a specific person or thing in their life (a relative, their manager, their dog Biscuit). "update", "supersede" and "noop" all require the new memory and the existing one to be about the SAME subject. Two memories can share a facet and still have different subjects, and then they are simply two different facts: "User's daughter is allergic to peanuts" and "User is allergic to peanuts" are both about a peanut allergy, but one is about the DAUGHTER and one is about the USER \u2192 create, keep both. This holds for EVERY attribute, not just the one in this example \u2014 where someone lives, who they work for, what they own, how old they are. A possessive like "user's X" makes X the subject, not the user; strip it and ask "whose fact is this?" before comparing anything. Never retire the user's own value because a fact about somebody else resembles it \u2014 the user's fact is still true, and retiring it destroys it.
 2. MATCH BY FACET, NOT TOPIC. Two memories both mentioning "Zara" is not enough to merge \u2014 only merge if they describe the same property (e.g. both about "user's pending Zara boot exchange"). Two memories about Zara on different topics (e.g. "user shops at Zara" + "user returned a sweater to Zara last week") are separate facets.
 3. NO COMPUTATION. Do not sum counts, decrement quantities, or derive new facts from existing ones. If the new memory says "user spent $200 today" and an existing memory says "user spent $150 yesterday", these are TWO SEPARATE EVENTS \u2014 create.
 4. EVENTS vs STANDING STATE.
    - Distinct EVENTS (episodic \u2014 something that happened on a date) are separate memories, even if the same activity: "user went to gym Monday" vs "user went to gym Friday" \u2192 create; keep both.
-   - A STANDING ATTRIBUTE (an ongoing state: where the user lives/works, relationship status, current role) has ONE current value. When the new memory changes that value ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true).
-5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory; then choose supersede. Over-merging loses information; a live contradiction is worse than either.
+   - A STANDING ATTRIBUTE (an ongoing state: where someone lives/works, relationship status, current role) has ONE current value PER SUBJECT. When the new memory changes that value FOR THE SAME SUBJECT ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true). A different subject holding the same attribute is not a value change at all \u2192 create.
+5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory ABOUT THE SAME SUBJECT; then choose supersede. Two facts about different subjects never contradict each other, however similarly they read. Over-merging loses information; a live contradiction is worse than either.
+6. When in doubt between update and noop, ask whether the existing memory ALONE already answers everything the new one would. If it does, choose noop \u2014 a write that changes only the wording costs a re-embed and makes an old fact look newly observed.
 
 OUTPUT \u2014 strict JSON, no prose:
 {

package/dist/server/index.cjs

@@ -23361,19 +23361,21 @@ A "memory" is a self-contained natural-language fact about the user. Multiple me
 Decide one of four actions:
 
 - "create": the new memory describes a distinct fact not covered by any existing memory. Write it as new.
-- "update": the new memory describes the SAME FACET as exactly one existing memory and is COMPATIBLE with it \u2014 it adds detail, fixes an incomplete value, or rephrases the same still-true fact. Return targetId of that existing memory + the consolidated content (richest version of the two).
-- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory \u2014 the old fact was true before but is false now (a state change). Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
-- "noop": the new memory is already fully captured by an existing memory \u2014 same facet, no new information. Skip the write.
+- "update": the new memory describes the SAME FACET of the SAME SUBJECT as exactly one existing memory, is COMPATIBLE with it, and ADDS INFORMATION \u2014 it adds detail or fills in an incomplete value. Return targetId of that existing memory + the consolidated content (richest version of the two). A pure rewording that adds nothing is NOT an update; it is "noop".
+- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory ABOUT THE SAME SUBJECT \u2014 the old fact was true before but is false now (a state change). Before choosing this, name the subject of the new memory and the subject of each candidate out loud to yourself; if they are different people, the old fact is still TRUE and superseding it would delete a correct memory \u2014 choose "create" instead. Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
+- "noop": the new memory is already fully captured by an existing memory \u2014 same facet of the same subject, no new information. This INCLUDES a restatement in different words ("has two kids" / "has two children"): if the existing memory already tells you everything the new one does, the answer is noop no matter how differently it is worded. Skip the write.
 
 RULES (carry these strictly):
 
 1. ONE OBSERVATION PER DISTINCT FACET. If the new memory is about "user's aunt's twins" and an existing memory is also about "user's aunt's twins", they are the same facet \u2192 update, never create.
+1a. SAME SUBJECT REQUIRED \u2014 check this FIRST, before you look at the facet. The subject is WHO the fact is about: the user, or a specific person or thing in their life (a relative, their manager, their dog Biscuit). "update", "supersede" and "noop" all require the new memory and the existing one to be about the SAME subject. Two memories can share a facet and still have different subjects, and then they are simply two different facts: "User's daughter is allergic to peanuts" and "User is allergic to peanuts" are both about a peanut allergy, but one is about the DAUGHTER and one is about the USER \u2192 create, keep both. This holds for EVERY attribute, not just the one in this example \u2014 where someone lives, who they work for, what they own, how old they are. A possessive like "user's X" makes X the subject, not the user; strip it and ask "whose fact is this?" before comparing anything. Never retire the user's own value because a fact about somebody else resembles it \u2014 the user's fact is still true, and retiring it destroys it.
 2. MATCH BY FACET, NOT TOPIC. Two memories both mentioning "Zara" is not enough to merge \u2014 only merge if they describe the same property (e.g. both about "user's pending Zara boot exchange"). Two memories about Zara on different topics (e.g. "user shops at Zara" + "user returned a sweater to Zara last week") are separate facets.
 3. NO COMPUTATION. Do not sum counts, decrement quantities, or derive new facts from existing ones. If the new memory says "user spent $200 today" and an existing memory says "user spent $150 yesterday", these are TWO SEPARATE EVENTS \u2014 create.
 4. EVENTS vs STANDING STATE.
    - Distinct EVENTS (episodic \u2014 something that happened on a date) are separate memories, even if the same activity: "user went to gym Monday" vs "user went to gym Friday" \u2192 create; keep both.
-   - A STANDING ATTRIBUTE (an ongoing state: where the user lives/works, relationship status, current role) has ONE current value. When the new memory changes that value ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true).
-5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory; then choose supersede. Over-merging loses information; a live contradiction is worse than either.
+   - A STANDING ATTRIBUTE (an ongoing state: where someone lives/works, relationship status, current role) has ONE current value PER SUBJECT. When the new memory changes that value FOR THE SAME SUBJECT ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true). A different subject holding the same attribute is not a value change at all \u2192 create.
+5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory ABOUT THE SAME SUBJECT; then choose supersede. Two facts about different subjects never contradict each other, however similarly they read. Over-merging loses information; a live contradiction is worse than either.
+6. When in doubt between update and noop, ask whether the existing memory ALONE already answers everything the new one would. If it does, choose noop \u2014 a write that changes only the wording costs a re-embed and makes an old fact look newly observed.
 
 OUTPUT \u2014 strict JSON, no prose:
 {
@@ -29956,7 +29958,8 @@ function configMatches(a, b) {
   return a.redacted === b.redacted && a.facetsSignature === b.facetsSignature && (a.reviewedMemoryIdsSignature ?? "") === b.reviewedMemoryIdsSignature && a.scopes.length === b.scopes.length && a.scopes.every((s, i) => s === b.scopes[i]);
 }
 function reviewedMemoryIdsSignature(ids) {
-  if (ids === void 0 || ids.length === 0) return "";
+  if (ids === void 0) return "";
+  if (ids.length === 0) return "\0gated-empty";
   return [...new Set(ids)].sort().join("\n");
 }
 function facetsSignature(facets) {
@@ -30066,7 +30069,16 @@ async function synthesizeFacet(facet, ctx, options, prior) {
   const factTypeWeights = { ...DEFAULT_PROFILE_FACT_TYPE_WEIGHTS, ...options.factTypeWeights };
   const proofCountAlpha = options.proofCountAlpha ?? DEFAULT_PROFILE_PROOF_ALPHA;
   const reviewed = options.reviewedMemoryIds;
-  const hasReviewGate = reviewed !== void 0 && reviewed.length > 0;
+  const hasReviewGate = reviewed !== void 0;
+  if (hasReviewGate && reviewed.length === 0) {
+    return {
+      key: facet.key,
+      label: facet.label,
+      text: "",
+      sourceMemoryIds: [],
+      generatedAt: Date.now()
+    };
+  }
   const recalled = await recall(facet.query, ctx, {
     scopes,
     limit: hasReviewGate ? RECALL_MAX_LIMIT : limit,

package/dist/server/index.d.mts

@@ -8356,10 +8356,20 @@ interface SynthesizeProfileOptions extends PortalLlmAuth {
      */
     proofCountAlpha?: number;
     /**
-     * When non-empty, intersect each facet's recalled evidence with this id set
-     * before the LLM runs (publish-review gate). Empty intersection → empty
-     * section (legitimate no-evidence), not a stale fallback. Omit / empty →
-     * no gate.
+     * Publish-review gate: when SUPPLIED, each facet's recalled evidence is
+     * intersected with this id set before the LLM runs, so synthesis can only draw
+     * on memories the user approved for publication. Empty intersection → empty
+     * section (legitimate no-evidence), not a stale fallback.
+     *
+     * Pass the user's published set (e.g. `getAllVaultMemoriesOp(ctx, { visibility:
+     * ["public"] })`) to keep a published profile derivable only from published
+     * memories — People Nearby's two-tier model treats `private` memories as never
+     * leaving the device, and a summary derived from them is a derivative that does.
+     *
+     * `[]` means "nothing approved" and gates everything OUT (no recall, no LLM
+     * call, empty sections). **Omitting the field is the only way to run ungated**
+     * — that asymmetry is deliberate, so a caller computing a published set can
+     * never accidentally disable the gate by finding it empty.
      */
     reviewedMemoryIds?: readonly string[];
 }

package/dist/server/index.d.ts

@@ -8356,10 +8356,20 @@ interface SynthesizeProfileOptions extends PortalLlmAuth {
      */
     proofCountAlpha?: number;
     /**
-     * When non-empty, intersect each facet's recalled evidence with this id set
-     * before the LLM runs (publish-review gate). Empty intersection → empty
-     * section (legitimate no-evidence), not a stale fallback. Omit / empty →
-     * no gate.
+     * Publish-review gate: when SUPPLIED, each facet's recalled evidence is
+     * intersected with this id set before the LLM runs, so synthesis can only draw
+     * on memories the user approved for publication. Empty intersection → empty
+     * section (legitimate no-evidence), not a stale fallback.
+     *
+     * Pass the user's published set (e.g. `getAllVaultMemoriesOp(ctx, { visibility:
+     * ["public"] })`) to keep a published profile derivable only from published
+     * memories — People Nearby's two-tier model treats `private` memories as never
+     * leaving the device, and a summary derived from them is a derivative that does.
+     *
+     * `[]` means "nothing approved" and gates everything OUT (no recall, no LLM
+     * call, empty sections). **Omitting the field is the only way to run ungated**
+     * — that asymmetry is deliberate, so a caller computing a published set can
+     * never accidentally disable the gate by finding it empty.
      */
     reviewedMemoryIds?: readonly string[];
 }

package/dist/server/index.mjs

@@ -5445,7 +5445,7 @@ async function tryConsolidate(trimmed, ctx, options, prepared) {
     content: m.content,
     similarity: m.similarity
   }));
-  const { consolidateMemory: doConsolidate } = await import("./consolidate-4VEAS3YN.mjs");
+  const { consolidateMemory: doConsolidate } = await import("./consolidate-GRMEDWKK.mjs");
   const decision = await doConsolidate(trimmed, candidates, consolidateOptions);
   if (decision.action === "create") return null;
   if (decision.action === "supersede" && decision.content) {
@@ -6991,7 +6991,8 @@ function configMatches(a, b) {
   return a.redacted === b.redacted && a.facetsSignature === b.facetsSignature && (a.reviewedMemoryIdsSignature ?? "") === b.reviewedMemoryIdsSignature && a.scopes.length === b.scopes.length && a.scopes.every((s, i) => s === b.scopes[i]);
 }
 function reviewedMemoryIdsSignature(ids) {
-  if (ids === void 0 || ids.length === 0) return "";
+  if (ids === void 0) return "";
+  if (ids.length === 0) return "\0gated-empty";
   return [...new Set(ids)].sort().join("\n");
 }
 function facetsSignature(facets) {
@@ -7101,7 +7102,16 @@ async function synthesizeFacet(facet, ctx, options, prior) {
   const factTypeWeights = { ...DEFAULT_PROFILE_FACT_TYPE_WEIGHTS, ...options.factTypeWeights };
   const proofCountAlpha = options.proofCountAlpha ?? DEFAULT_PROFILE_PROOF_ALPHA;
   const reviewed = options.reviewedMemoryIds;
-  const hasReviewGate = reviewed !== void 0 && reviewed.length > 0;
+  const hasReviewGate = reviewed !== void 0;
+  if (hasReviewGate && reviewed.length === 0) {
+    return {
+      key: facet.key,
+      label: facet.label,
+      text: "",
+      sourceMemoryIds: [],
+      generatedAt: Date.now()
+    };
+  }
   const recalled = await recall(facet.query, ctx, {
     scopes,
     limit: hasReviewGate ? RECALL_MAX_LIMIT : limit,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anuma/sdk",
-  "version": "3.13.2",
+  "version": "4.0.1",
   "description": "",
   "main": "./dist/index.cjs",
   "module": "./dist/index.mjs",
@@ -159,7 +159,7 @@
   "homepage": "https://github.com/anuma-ai/sdk#readme",
   "packageManager": "pnpm@10.23.0",
   "dependencies": {
-    "@anuma/portal": "1.0.0-next.20260727223242",
+    "@anuma/portal": "1.0.0-next.20260728181242",
     "@babel/parser": "^7.29.2",
     "@babel/types": "^7.29.0",
     "ai": "6.0.202",