A refused scope reaches no storage backend
The refusal is only worth having if every consumer honours it identically, and if nothing is written on the way out.
The rule
- When a memory scope refuses, every consumer of it returns its neutral result and the storage backend is not called at all, for neither a read nor a write-back.
- A read returns its configured default and reports that nothing was found; a write and a delete report failure; a conversation-buffer append returns an empty buffer with a count of zero, dropping the turn rather than appending it to a shared history.
- The resolved scope identifier reported back is empty.
- Each refusal emits exactly one warning identifying the node, the pipeline and the workflow, and the refusal is decided in one place so the consumers cannot diverge.
What it means
A refused scope and a scope that legitimately resolves to an empty
identifier can look the same from one field alone — both report an empty
resolved_scope_id — so the rule is what makes them distinguishable as a
whole response. A refusal's read reports a fixed default and found: false
on top of the empty identifier; a non-identity scope resolving to the same
empty identifier because it has nothing else to resolve to reports whatever
was actually stored there, found included. Neither the fixed default nor
the stored value crosses paths with the other, because a refusal never calls
the storage backend at all.
Example
A user scope with no usable identity, reading a key with a fallback
default:
{ "value": "fallback", "found": false, "scope": "user", "resolved_scope_id": "" }A global scope — not identity-scoped — legitimately resolves to the same
empty identifier, and reads normally:
{ "value": "val", "found": true, "scope": "global", "resolved_scope_id": "" }The empty resolved_scope_id is identical in both; only found and the
value tell them apart.