---
id: MEM-7
family: GR-MEM
level: core
profiles: [storage-api, runtime]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/gr-mem/mem-7
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# MEM-7 — A refused scope reaches no storage backend

*GR-MEM (Part I) · level: core · profiles: storage-api, runtime · added in 1.0*

The refusal is only worth having if every consumer honours it identically, and if nothing is written on the way out.

## The rule

> **Normative.** This is the rule.
>
> 1. 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.
>
> 2. 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.
>
> 3. The resolved scope identifier reported back is empty.
>
> 4. 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:

```json title="Reading a preference in a refused user scope" verdict="refused"
{ "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:

```json title="Reading the same key in the global scope" verdict="resolved"
{ "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.

## Related rules

- Names: MEM-6, MEM-13
- Referenced by: MEM-6, MEM-12, MEM-13

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.