MIN_TRUST_PATH_RATIO gate in LOAD_CORE: unsorted lookup and no re-evaluation at later depths

[tkuhn]

The MIN_TRUST_PATH_RATIO gate in LOAD_CORE differs from the IDEBT algorithm as specified, in two ways. Both were found while checking the ISWC 2026 paper's pseudocode against the implementation.

Relevant code (Task.java, as of e86e484):

// LOAD_CORE, ~line 474
trustPath = getOne(s, "trustPaths_loading",
        new Document("depth", depth)
                .append("agent", agentId)
                .append("pubkey", pubkeyHash)
);
...
// ~line 493
} else if (trustPath.getDouble("ratio") < MIN_TRUST_PATH_RATIO) {
    set(s, "accounts_loading", agentAccount.append("status", skipped.getValue()));

1. The gated lookup is unsorted, which can break reproducibility

getOne is find(filter).first() with no sort, so when an account has several trust paths at its discovery depth, which one is compared against MIN_TRUST_PATH_RATIO depends on MongoDB's natural order. Two Registries that ingested the same nanopublications in a different order could therefore make different skip decisions, and so publish different trust states and different trust state hashes.

This matters because determinism is a guaranteed property of IDEBT: two Registries running it with the same setting over the same nanopublications should produce identical paths, scores, and trust state hashes. EXPAND_TRUST_PATHS already selects its path deterministically:

).sort(orderBy(descending("ratio"), ascending("sorthash"))).first();

so this gate looks like the only place where path selection is left to storage order.

Suggested fix: apply the same orderBy(descending("ratio"), ascending("sorthash")) to the LOAD_CORE lookup.

2. A skipped account is never reconsidered at a later depth

An account is inserted once, at its discovery depth, and LOAD_CORE(d) only processes accounts with depth == d. Once marked skipped it is never loaded, never expanded, and never scored — even if a better path to it appears later.

That can happen, because ratio is not monotone in depth: each hop multiplies by (1 - SELF_SHARE) / n_agents / n_keys, so a longer chain through low-fanout endorsers can carry more ratio than a shorter one through a high-fanout endorser.

A worked example, with SELF_SHARE = 0.1, so that each hop multiplies by 0.9 / n_agents / n_keys:

• The seed expands to two agents A and B, one key each. Both depth-1 paths carry 1.0 × 0.9 / 2 = 0.45.
• A endorses 100 agents, one of which is X. The depth-2 path to X carries 0.45 × 0.9 / 100 = 0.00405.
• B endorses only C, so the depth-2 path to C carries 0.45 × 0.9 / 1 = 0.405. C in turn endorses two agents, one of which is X. The depth-3 path to X carries 0.405 × 0.9 / 2 = 0.18225.

X is discovered at depth 2 on a path worth 0.00405 and is gated there, but its depth-3 path is worth 45 times as much. Under the current code that stronger path is never taken into account: X was inserted with depth == 2, so if it was marked skipped there, LOAD_CORE(3) does not look at it again. The numbers above illustrate the ordering rather than a literal threshold crossing — with MIN_TRUST_PATH_RATIO at 1e-10 the fanout would have to be far more extreme — but the shape of the situation is what matters.

The effect compounds, because an account's ratio is the sum over all of its paths. A single high-fanout endorser dilutes every account it touches, and the accounts sitting behind one are precisely those most likely to be discovered early on a weak path, so early discovery correlates with a low first ratio rather than with low standing overall.

The algorithm as specified re-evaluates each account at every depth: frontier selection considers the paths of the current length that end at accounts which have no primary path yet, so an account below the threshold at one depth still gets a fresh chance at the next. The gate bounds peer fetches in both variants — it is applied before any core is loaded — so re-evaluating costs only a comparison.

Suggested fix: when an account is skipped for a low ratio, allow it to be re-queued at subsequent depths rather than terminally marking it, so the threshold is tested against the best path currently known.

Impact

Probably small in the deployed network: MIN_TRUST_PATH_RATIO is 1e-10, and a recent snapshot of registry.knowledgepixels.com had every path within five hops of the seed with over three quarters of the conservation budget unused, so few accounts sit near the threshold. Issue 1 is nevertheless worth fixing on its own, since reproducibility is meant to hold by construction rather than by luck of insertion order.