nooa-memory: owner does gate graph spread (answers Open Question 3)

[Yeriahz]

Re: the open question in the write-up, "Does owner gate the graph spread, or can activation flow through a memory the reader cannot see?"

It gates, on both paths.

packages/nooa-memory/src/nooa_memory/retrieval.py, _spread() at line 245. The visibility check is in the innermost loop, so it runs for every edge at every hop:

for e in edges[: cfg.per_hop_fanout]:
    if not _visible(e.target_id):
        continue
    ...
    spread[e.target_id] = spread.get(e.target_id, 0.0) + contrib
    nxt[e.target_id] = nxt.get(e.target_id, 0.0) + contrib

_visible() returns True when owner is None; otherwise it looks up store.owner_of(mid) and applies owner_matches, memoized in a per-call cache.

The part that answers the "flow through" half: continue fires before nxt is written, not just before spread. An invisible memory therefore never enters the next hop's frontier, so it cannot act as a relay between two visible memories connected only through it. The docstring claims both ("an edge must not leak — or amplify through — another agent's memory in an owner-scoped recall") and the control flow delivers both.

Scope: this is a code reading at current main. I have not written a test that builds a cross-owner graph and asserts the path is dead, so I can't say whether the existing memory tests cover it.

[neoneye]

Confirmed, and thank you — this is exactly the kind of report the open questions are there to attract. It's now in the report, credited to you: Retrieval Mechanics. Open Question 3 is gone.

I re-read it at the atlas's pinned commit f22805b5 rather than only at main, since a report that answers a question at a different commit than it publishes is a new drift problem. Same code: _visible at :258, the guard at :275, both accumulator writes at :281–282. So the answer holds at the published pin and nothing needed re-pinning.

Your central point is the one that matters and it's right: the continue sits before nxt as well as before spread, so an invisible memory never joins the next hop's frontier. Most systems in this atlas that carry the scope_enforced mark apply the key to the rows they return, and a graph traversal doing only that would still read the foreign node in order to drop it. Gating the frontier is the stronger form, and it's the reason the docstring's "or amplify through" half is true rather than aspirational.

Two things I'd add, neither of which changes your conclusion.

is not None is guarding a different case than it looks like. Your paraphrase has _visible returning true for owner is None and otherwise doing owner_of + owner_matches, which reads as though an unowned memory (owner_of → None) would be dropped — contradicting the docstring's "that owner + unowned". It isn't, because the column is owner TEXT NOT NULL DEFAULT '' (store.py:71) and owner_of returns None only when the row doesn't exist. An unowned memory returns "", and owner_matches("", scope) is true for every scope (schema.py:109). So mem_owner is not None is really a dangling-edge check — an edge pointing at a deleted memory — which it drops, and which is the right answer there too.

On your scope caveat, there are tests, and they cover one half. test_spread_does_not_leak_foreign_memories (test_memory_owner.py:126) and test_spread_confined_to_role (test_memory_owner_roles.py:128) each build a single edge across an owner boundary and assert the far node is absent from recall. Both are two-node graphs, so they pin the leak half. Neither builds the three-node own → foreign → own case, which means the relay property you identified — the thing that makes the continue's position load-bearing rather than incidental — is delivered by the control flow and asserted nowhere. That's the test worth having: it's the one that would fail if someone later moved the visibility check to just before the spread write, which is a plausible refactor that looks harmless and quietly reopens the path.

Recorded as a code reading either way, not as a test result — same standing as the rest of the report.

[neoneye]

It was Claude that replied on my behalf, lol.

[Yeriahz]

Following up on your point about the relay case being asserted nowhere: I wrote that test and opened it upstream as NVIDIA-NeMo/labs-OO-Agents#73.

It asserts on _spread rather than through recall. Two earlier attempts through the public API were unusable, and the reason turned out to be the interesting part: the property isn't observable there. A relay target owned by a third party gets gated on its own merits, and one owned by the reader is retrieved directly regardless of the graph, with a small corpus and default k, alice gets alice_c whether or not any edge exists. What a relay changes is activation, and therefore ranking, which only exists inside _spread.

So the test builds alice_a -> bob -> alice_c, asserts the two-hop path is live unscoped (positive control, otherwise the scoped assertion could pass because nothing was reachable), then asserts scoped spread returns neither bob nor alice_c. Unscoped gives 0.36 for bob and 0.07776 for alice_c; scoped returns {}.

Worth noting the default is hops: 1, so the relay path isn't reachable out of the box. It's a guard for the configured hops: 2+ case rather than a live exposure, that's exactly the refactor risk you described, since the check's position looks incidental until someone moves it.

Thanks for the pointer on mem_owner is not None being a dangling-edge guard. I had that half wrong.

[neoneye]

You wrote the test. That's the part of this exchange that mattered, and it landed somewhere more useful than this repository.

The report is updated — afe5cd0, in Retrieval Mechanics. Three things changed, and two of them are yours rather than mine.

I verified the activations arithmetically instead of taking them. per_hop_decay = 0.6 and an associative type_w of 0.6 against a unit seed give 0.6 × 0.6 = 0.36 at hop one and 0.36 × 0.36 × 0.6 = 0.07776 at hop two. Both of your numbers, exactly, from the committed constants — which is a nice property of a deterministic spread: the positive control is checkable without running it.

While doing that I noticed a margin worth having in the record. activation_floor is 0.05. Your hop-two contribution is 0.07776, so a two-hop relay clears the floor by about 55% of the floor itself. Drop the edge weight to 0.8 and the contribution falls to 0.0498 and the relay is discarded before visibility is ever consulted. So even at hops: 2 the amplify path only exists in a fairly narrow band of edge weights — which does not weaken the guard, but it does mean a test that used a lower weight would pass for the wrong reason. Yours uses 1.0 and is fine.

The hops: 1 default is a correction to what I published, not a footnote to it. My text implied the relay property was protecting something live. It isn't: the second hop doesn't run out of the box. The report now says the continue's position is a guard for the configured hops: 2+ case, and — this is the part I think you have right and I'd underweighted — that makes the refactor risk worse rather than better. A check whose removal breaks nothing at default configuration is a check that survives review on the reviewer's goodwill. Your test is the thing that changes that, and it's the reason to want it merged rather than merely written.

The observability finding is the one I'd have missed entirely. You went looking for a way to assert through recall, failed twice, and worked out that the failure was the answer: a relay target owned by a third party is gated on its own merits, one owned by the reader is retrieved directly regardless of the graph, and what a relay actually changes is activation and therefore ranking — which only exists inside _spread. A security property that can only be asserted against a private function is a fact about the design, not a compromise in the test. That's now in the report as the more interesting half of §6, credited to you.

For whatever it's worth to the upstream review: testing the private function is correct here and I'd defend it. The public-API alternative would either assert nothing (the outcome is identical with and without the edge) or would have to construct a corpus large enough that k truncation makes ranking observable — which buys a fragile test that fails for unrelated reasons the first time anyone touches the scorer.

Nothing further needed from me. Thanks for coming back with the harder half.