feat(dRAG): Decentralized GraphRAG V1 — verifiable, cross-node, monetizable answering (OT-RFC-55)

[branarakic]

feat: Decentralized GraphRAG (dRAG) V1 — verifiable, cross-node, monetizable answering (OT-RFC-55)

Implements OT-RFC-55 as a working V1 on main (v10.0.0): ask one natural-language
question and get a grounded answer whose every fact is independently auditable
against the chain — answered locally, or fanned out across the nodes serving a
public Context Graph and re-verified by the asker, with an x402 payment seam
wired for monetization.

Built in four layered, independently-shippable increments. Each was validated on a
live 4-node devnet.

What's in it

P1 — Verifiable citation core (core/crypto/citation.ts, agent/drag/citation.ts)
Composes the already-shipped V10 primitives into one auditable citation object
{UAL, node, author-sig, merkle, on-chain}:

• Merkle inclusion over the keccak V10 structured tree (buildV10ProofMaterial),
  re-anchored to the live on-chain getLatestMerkleRoot(kaId) — so a citation that
  verifies offline verifies on-chain by construction.
• Content-binding: the proof binds to the exact cited triple (tripleContentV10).
• EIP-712 author-seal recovery (recoverCitationAuthor), with the chain-verified
  on-chain author as the authoritative fallback when the _meta seal is absent.

P2 — dkg_answer single-node (agent/dkg-agent-drag.ts, cli/routes/drag.ts, mcp-dkg)
question → keyword retrieval over per-KA verifiable-memory graphs → canonical triples → a citation per fact. No node-side LLM required (keyword/structural
baseline; LLM synthesis is a future enhancement). New POST /api/answer,
DkgClient.answer(), and the dkg_answer MCP tool.

P3 — Cross-node fan-out (scope:"network")
findNodesServingCG reads the contextGraphsServed phonebook (the §5.1
context-oracle index); a new PROTOCOL_DRAG_ANSWER libp2p protocol lets a peer
answer over a public CG (ACL = the same isContextGraphPublicOnChain
fail-closed gate as query-remote). dragAnswerNetwork fans out, dedups, and —
crucially — re-verifies every citation against the asker's own chain, so the
asker trusts no serving node's self-reported verdict and can answer over knowledge
it does not hold. Optional explicit peers override for not-yet-gossiped CGs.

P4 — x402 payment seam (cli/daemon/payment.ts)
Public CGs are free in V1, but the HTTP-402 challenge + X-PAYMENT wire format
and a pluggable PaymentVerifier (MockPaymentVerifier for dev/CI) are in place so
the real Coinbase/USDC facilitator drops in behind one interface. simulatePrice
exercises the full 402 → pay → 200 + receipt flow. Localized in the drag route —
does not touch the central request chain.

Validation

• Unit: 18 citation tests (core+agent) + 14 payment tests (cli). Full suites
  green for every touched package (core 1092, mcp-dkg 325, agent ~1740, cli ~2120).
• Live devnet (4 nodes): combined run, 9/9 —
  • local cited answer, every citation author-sig ✓ merkle ✓ on-chain ✓;
  • priced request returns 402, then 200 + settlement receipt with a valid
    X-PAYMENT, paid answer still fully verified;
  • an asker holding no copy of the CG assembled a multi-fact answer from
    remote serving nodes, every citation re-verified against its own chain.

Security hardening (adversarial review)

A multi-dimension adversarial review of the diff confirmed 10 findings (3 high,
3 medium, 3 low), all addressed in the hardening commit:

• Remote handler DoS — the unauthenticated PROTOCOL_DRAG_ANSWER verb is now
  per-peer rate-limited and clamped to a small remote cost ceiling.
• Asker fan-out bounds — peer fan-out is capped + concurrency-bounded (no
  caller-driven reflection); per-peer citation re-verification is bounded.
• Malformed-peer isolation — each peer response is shape-validated and each
  citation is guarded, so one bad/version-skewed peer can't fail the whole answer.
• CG-scope binding — re-verification confirms each citation's KA belongs to
  the asked context graph (getKAContextGraphId); a peer can't pass off a
  verifiable fact from a different KA, and the asker never trusts the remote's
  scope fields.
• Verdict integrity — the verdict cache is keyed on the proof and dedup
  prefers a verified citation, so a bad proof can't poison/suppress an honest one.
• Defense-in-depth — validateContextGraphId before SPARQL interpolation;
  the leaf count is re-anchored against chain (the pure check was tautological).

The two refuted findings (a "second-order IRI injection" and a "dedup delimiter
collision") were verified non-exploitable (the store's serialization boundary and
the terminal-field key layout, respectively).

Reasoned, not unit-tested (validated by code review + the live happy path, but
without a dedicated adversarial test): the off-scope citation drop (a malicious
peer returning a fact from a different KA — the CG-scope binding is confirmed
active on the non-subscriber path, since ontology id-mappings sync network-wide),
the verdict-cache collision fix, and the dkg_answer MCP stdio tool path (the
underlying /api/answer endpoint is live-validated). The CG-scope check fails
open (facts stay cryptographically verified, scope unconfirmed) only when the
asker cannot resolve the CG's on-chain id — surfaced explicitly in the answer.

Honest scope / deferred (NOT in V1)

• Confidential / ZK answering (RFC §5.3) — citations are over public (VM)
  facts; private-data answering and the ZK layers are future work.
• Private-CG routing — fan-out is public-CG only (the phonebook deliberately
  advertises only public, subscribed CGs).
• Real x402 settlement — MockPaymentVerifier only; no live facilitator / USDC
  (the node has no USDC and is ethers-only; not CI-runnable).
• LLM synthesis + question→CG auto-routing — the keyword baseline is the V1
  headline; LLM is a clean seam (no key on devnet). The caller names the CG.
• Phonebook propagation latency — contextGraphsServed advertisements integrate
  into peers' agents-CG on the profile-heartbeat cadence, so discovery can lag a
  just-created CG; the explicit peers override is the deterministic fast-path.

How to try it

./scripts/devnet.sh start 4
# create a public CG, publish a KA, then:
curl -s localhost:9201/api/answer -H "Authorization: Bearer $TOKEN" \
  -d '{"question":"...","contextGraphId":"<cg>","scope":"network"}'

🤖 Generated with Claude Code

---

Production hardening (this update)

Following the V1 above, this update moves dRAG from "PR-stage" to "releasable" in six steps, each committed and kept behind a green release-gate suite:

1. Integration suite — devnet/drag-v1/ (pnpm test:devnet:drag-v1): P1 client-side verify + tamper-rejection, P2 cited answer, P3 cross-node re-verify, P4 payments-off default, and the keyword↔semantic split. 7/7 on a live devnet.
2. Config + clean public API — a config.drag.* schema; the public answer param is now retrieval: default|keyword|semantic. The raw embedder/simulatePrice knobs are gated behind config.drag.experimentalOverrides, keeping demo affordances out of the public contract.
3. x402 OFF by default — config.drag.payments.enabled (default false); a priced request is answered for free unless explicitly enabled.
4. Embedder story — config-driven: local Ollama / hosted OpenAI via embedderBaseURL (no heavy dependency), offline MiniLM as the opt-in. Documented in docs/use-dkg/verifiable-answers-drag.md.
5. Indexing — incremental (a re-scan embeds only newly-published entities) + publish-time index warm. Brute-force cosine retained (fine to ~100k vectors/node) with the sqlite-vec/pgvector upgrade documented.
6. Observability + optional synthesis — GET /api/answer/metrics, stats.latencyMs, and a retrievalDegraded signal that distinguishes "no embedding model" from "no matches". Optional grounded prose synthesis (synthesize:true) composes from only the verified facts and never mutates facts/citations — those stay the authoritative, machine-readable answer.

Adversarial self-review

A multi-agent review of the productionization diff raised 20 findings (13 confirmed, one empirically reproduced); all addressed in 3664c70b7. Notably:

• HIGH — the incremental-index freshness gate compared distinct subjects to distinct (graph, subject) pairs, so once a subject recurred across KAs the gate stayed satisfied and freshly-published entities were silently never embedded. Fixed to count pairs; regression test reproduces it.
• HIGH — the node-UI panel still sent the now-gated embedder knob, making its retrieval dropdown a silent no-op. Migrated to the public retrieval param.
• HIGH (test) — a new adversarial unit test proves the P3 trustless property: the asker rejects a lying peer's verified:true on a tampered triple, drops a genuinely-verifiable but off-scope citation (CG-scope-swap defense), and isolates a throwing peer.

Test status

core 1092 · mcp 325 · cli 2122 · agent 156 files · dRAG units (retriever / embedder / synthesize / citation / network-trustless) · devnet/drag-v1 7/7 — all green.

Known deferred: a live-daemon route-level synthesis test (the synthesizeAnswer function is unit-tested); decentralized semantic routing over the public catalog (Phase 2); a real x402 facilitator + USDC settlement (the wire format + mock verifier are in place behind the off-by-default flag).

[otReviewAgent]

🔴 Bug: Network answers can accept citations from the wrong context graph when scope cannot be resolved

What's wrong
The network answer contract is scoped by contextGraphId, but this path skips KA-to-CG binding whenever the requester cannot resolve the CG id locally. That lets a malicious or mistaken peer return a real, chain-verifiable citation from a different context graph and have it included as a verified answer for the requested graph.

Example
A node asks scope: "network" for new-cg before its local ontology mapping is synced, so getContextGraphOnChainId('new-cg') returns null. A peer returns a cryptographically valid citation for a KA in other-cg; the citation is re-verified against the chain and included with stats.verified = 1 because the off-scope check is skipped. Expected behavior: no credited facts unless the KA is proven to belong to new-cg.

Suggested direction
Require CG scope enforcement before crediting network citations. If the asker cannot resolve the requested CG id, return an error or no citations instead of counting provenance-unconfirmed facts as verified.

For Agents
In dragAnswerNetwork, fail closed when the requested CG on-chain id cannot be resolved or when getKAContextGraphId is unavailable. Preserve remote citation re-verification, but only add facts after KA-to-requested-CG binding succeeds. Add a test where getContextGraphOnChainId returns null and a remote peer supplies a valid off-scope citation; the result should contain no verified facts.

[otReviewAgent]

🔴 Bug: Network answers fail open when the requested CG id cannot be resolved

What's wrong
The code only enforces the cross-CG scope binding when the asker can resolve the requested context graph's on-chain id. If that lookup fails or is stale, it still accepts and returns chain-valid citations without proving they belong to the requested CG, which breaks the endpoint contract that the answer is scoped to contextGraphId.

Example
Node A asks scope: network for contextGraphId: supply-cg with an explicit serving peer, but its ontology sync has not resolved supply-cg yet. A peer returns a valid citation from other-cg. Because askedCgId is null, the scope check is skipped, the citation is re-verified cryptographically, and the answer can include facts from the wrong CG.

Suggested direction
Treat unresolved askedCgId as a hard error for scope: network, or at minimum do not count or return citations as verified for the requested context graph until KA scope can be checked.

For Agents
Look at dragAnswerNetwork around askedCgId resolution and the KA scope check. Preserve trustless verification, but fail closed or return no citations when the requested CG cannot be resolved or when getKAContextGraphId is unavailable. Add a network aggregation test where getContextGraphOnChainId returns null and a peer offers an otherwise valid off-scope citation.

[otReviewAgent]

🔴 Bug: Paid answer challenges are replayable because the server does not enforce its nonce

What's wrong
The payment challenge includes a nonce, but verification honors whatever nonce the payer sends. That removes the replay protection the nonce is meant to provide, so one accepted payment header can be reused for later priced answers with the same amount/network/asset/payTo.

Example
Client gets a 402 challenge for question A with nonce n1, pays, and receives an answer. The same X-PAYMENT header with nonce n1 can then be reused for question B: the route creates a new nonce n2, but resolvePayment replaces it with n1 before verification, so the mock verifier accepts and returns another paid receipt. Expected behavior: stale or mismatched challenge nonces should be rejected or settled idempotently against a stored challenge/payment record.

Suggested direction
Keep the challenge nonce authoritative. Either persist/derive nonce state so the retry can validate the original nonce, or make the payment payload bind to a deterministic request-specific challenge and reject mismatches/replays.

For Agents
In packages/cli/src/daemon/payment.ts, bind PaymentPayload.nonce to the server-issued challenge nonce instead of replacing the required nonce with the payer's value. Update MockPaymentVerifier to reject nonce mismatches, and add a route/payment test proving a reused X-PAYMENT header from an earlier challenge is rejected.

[otReviewAgent]

🟡 Issue: Payment verification accepts the payer's nonce as the required nonce

What's wrong
The server-generated nonce is meant to bind a payment to a specific challenge, but the code substitutes the client-supplied nonce into the requirement before verification. That removes replay protection from the mock x402 gate and would make future verifier implementations easy to wire incorrectly.

Example
A client obtains one X-PAYMENT payload for 0.01 USDC and then reuses the same header on a later priced /api/answer request. The route creates a new nonce, but resolvePayment passes the old payload nonce as the required nonce, so the verifier has no chance to reject the replay.

Suggested direction
Do not overwrite the server-generated required.nonce with payment.nonce; validate they match and track nonce use, or delegate replay prevention to a real facilitator while keeping the server-side challenge binding explicit.

Confidence note
This is gated behind config.drag.payments.enabled plus experimentalOverrides, but it affects the payment flow added in this PR when that path is enabled.

For Agents
Look at resolvePayment and the route's challenge creation. Preserve the 402 -> retry flow, but bind the presented payment to the server challenge nonce, either with a short-lived nonce store or a verifier contract that receives the original required nonce and checks/replays it. Add a test that reuses an old X-PAYMENT against a new challenge and expects another 402.

[otReviewAgent]

🟡 Issue: Keep presentation rendering out of the agent answer model

What's wrong
The agent layer now owns transport/UI formatting even though it already returns structured facts, citations, and per-node data. That makes the API harder to evolve because consumers have to know the agent's Markdown layout instead of relying on typed fields.

Example
If the agent renderer renames ## Sources to ## Citations, the structured citation cards still exist, but the UI prose extraction no longer strips the sources block and the panel renders duplicate source information.

Suggested direction
Make the agent return structured domain data plus a plain prose summary, and let MCP/UI/CLI render their own Markdown from facts/citations/per-node data.

For Agents
Look at packages/agent/src/dkg-agent-drag.ts renderAnswer/renderNetworkAnswer and packages/node-ui/src/ui/views/DragAskView.tsx. Preserve the facts/citations/stats payload, but move Markdown rendering to adapter layers or return a structured answerSummary/sections model. Add a focused UI/client test proving consumers do not parse sentinel markdown headings.

[otReviewAgent]

🟡 Issue: Keep Markdown presentation out of the agent result contract

What's wrong
This pushes UI presentation into the agent layer and then forces the UI to recover structure by string parsing. That makes a typed API feel untyped at the exact boundary where the PR otherwise adds good structured fields, and it couples clients to incidental Markdown headings instead of the citation model.

Example
A future copy tweak from ## Sources to ## Citations, or a synthesized answer that legitimately contains ## Sources, changes UI behavior even though facts, citations, and perNode are already structured in the response.

Suggested direction
Make the agent/domain layer produce structured answer data only, with answer reserved for prose if needed. Put renderAnswer/renderNetworkAnswer behind client/UI renderers or a separate presentation helper, and remove heading-based parsing from the UI.

For Agents
In packages/agent/src/dkg-agent-drag.ts, preserve the API fields and citation behavior but stop embedding Sources/Network presentation into answer. Return structured sources/network data plus a plain digest/summary, then move Markdown rendering to UI/MCP/client helpers. Add/adjust a route or UI test proving citations render from structured fields without parsing section headings.

[otReviewAgent]

🟡 Issue: Make retriever state per-call and context-owned instead of global mutable state

What's wrong
The route introduces hidden process-wide state for a dependency that is actually tied to a specific vector store and triple store, while the retriever interface exposes availability through a mutable side channel. This is a brittle boundary: callers must reason about object reuse and call ordering to understand a single answer.

Example
Two daemon contexts in the same process that use the same model string can share the same cached retriever even though they have different vectorStore or agent.store instances. Concurrent semantic requests can also overwrite degraded while another request is still deciding whether an empty result means no matches or no model.

Suggested direction
Return retrieval status explicitly from retrieve() and keep retriever instances owned by the daemon context that created their store dependencies.

For Agents
Update EntityRetriever.retrieve to return a result object such as { anchors, degraded } or throw a typed unavailable error. Move retriever caching/ownership into daemon lifecycle or request context keyed by the actual vector store, triple store, and provider config. Preserve semantic/keyword behavior and add a test with two retrievers or overlapping calls proving status is per-call.

[otReviewAgent]

🟡 Issue: Do not grow dRAG provider implementations inside the vector-store primitive

What's wrong
The PR turns a general SQLite vector-store module into a mixed storage plus embedding-provider module. That makes a core utility absorb dRAG/model-specific concerns and increases future churn in the wrong file.

Example
Adding another embedding backend would require editing the low-level SQLite vector-store module even though the storage/search primitive does not need to know anything about model providers.

Suggested direction
Keep VectorStore as a storage/search abstraction and put model provider implementations behind a separate provider module owned by daemon configuration.

For Agents
Move OpenAIEmbeddingProvider, HashingEmbeddingProvider, and LocalEmbeddingProvider into a dedicated embedding provider module, leaving vector-store.ts focused on persistence/search plus the EmbeddingProvider interface if needed. Update imports in lifecycle, route modules, and tests; existing vector-store tests should still exercise only storage/search behavior.

[otReviewAgent]

🟡 Issue: Remote dRAG public-only gate is not verified

What's wrong
The new libp2p dRAG responder is unauthenticated and relies on this public-only gate, but the added tests only prove public fan-out and mocked aggregation. They do not prove that private or unregistered context graphs are denied before local answering runs.

Example
A regression that moves dragAnswerLocal before the isPublic check, or treats an on-chain lookup error as public, could leak an answer for contextGraphId: "private-cg" while the current tests still pass because they never invoke the remote handler denial path.

Suggested direction
Cover the responder ACL directly, including private/unregistered fail-closed cases, because this is the boundary that prevents unauthenticated peers from reading non-public context graphs.

For Agents
Add a unit test around the PROTOCOL_DRAG_ANSWER registered handler in packages/agent/src/dkg-agent-lifecycle.ts: stub isContextGraphPublicOnChain to return false or throw, send a valid JSON request, assert the decoded response is an error and dragAnswerLocal is not called. Keep the existing public-path behavior covered separately.

[otReviewAgent]

🟡 Issue: Paid /api/answer flow is not verified at the route boundary

What's wrong
The tests verify the pure payment helper and the payments-off default, but not the actual /api/answer behavior when payments are enabled. The route contains additional logic that can break independently of resolvePayment.

Example
A route regression such as dropping paymentsEnabled from the condition, reading the wrong X-PAYMENT header, or forgetting to attach { settlement } after a paid retry would not be caught by the current helper-only tests.

Suggested direction
Keep the existing payment helper tests, but add endpoint-level coverage for the config gates and response shaping around them.

For Agents
Add route-level tests for handleDragRoutes or an HTTP-level daemon harness: with { drag: { payments: { enabled: true }, experimentalOverrides: true } }, assert priced /api/answer returns 402 without X-PAYMENT, returns 200 with a valid encoded payment, includes settlement, and still leaves the disabled default path free.

[otReviewAgent]

🟡 Issue: The x402 payment behavior is only tested below the route that implements it

What's wrong
The changed user-facing payment contract lives in the dRAG HTTP route, but the added tests stop at resolvePayment and MockPaymentVerifier. This leaves the config gates, simulatePrice handling, HTTP 402 response, retry header plumbing, and final settlement response unverified.

Example
A regression that makes priceStr always undefined, removes the jsonResponse(res, 402, ...) branch, or drops settlement from the final JSON response would still pass the current payment tests.

Suggested direction
Cover the /api/answer payment flow itself, not just the payment helper functions.

For Agents
Add a focused route test around packages/cli/src/daemon/routes/drag.ts: create a minimal RequestContext with drag.payments.enabled=true and experimentalOverrides=true, call POST /api/answer with simulatePrice, assert the first response is 402 with an x402 accepts challenge, retry with X-PAYMENT, and assert 200 includes settlement while preserving the answer shape.

[otReviewAgent]

🔴 Bug: Reasoning can derive false closed-world conclusions from a silently truncated CG

What's wrong
The reasoning layer claims it reasons over the complete verified fact set, but the new gather path limits the graph list before invoking EYE and does not report that truncation. Any rule using absence, such as collectAllIn ... length 0, can become wrong when the omitted KAs contain the missing evidence.

Example
A CG has 201 verifiable-memory KAs. The first KAs contain D1 changes validateToken, validateToken inModule authModule, and authModule securityCritical true; the 201st KA contains the senior review for D1. With the default cap, gatherVerifiedFacts omits that senior review and a negation-as-failure rule can derive D1 violatesReviewPolicy true even though the complete CG says it should not.

Suggested direction
Either require a complete fact gather for reasoning, return a truncation note and skip negation-as-failure rules, or carry a truncated flag through ReasoningResult so callers cannot treat the derivation as sound.

For Agents
Look at gatherVerifiedFacts and the /api/answer reasoning path. Preserve the compute bounds, but make truncation explicit and prevent closed-world/NAF conclusions from being returned as authoritative when the fact set is incomplete. Add a test where the disconfirming fact is beyond reasoningMaxKas and prove the response warns/fails instead of deriving the violation.

[otReviewAgent]

🔴 Bug: Author-seal verification does not bind the seal to the cited KA

What's wrong
The EIP-712 author seal includes reservedKaId, but the verifier ignores it. That lets a seal from another KA be reported as a valid author signature for this citation as long as the signer and merkle root match, overstating the citation's author proof.

Example
An author has a valid seal for KA 1 with merkle root R. A citation for KA 2 with the same root R and same on-chain author can attach KA 1's seal. recoverCitationAuthor returns the expected author and the root matches, so authorSig becomes true even though the EIP-712 seal was not issued for KA 2.

Suggested direction
Include the reserved KA id in the author-signature verdict, and prefer loading the seal for the specific KA rather than by merkle root alone.

For Agents
Update citation production and verification in packages/agent/src/drag/citation.ts to require BigInt(seal.reservedKaId) === BigInt(kaId). Add a test that copies a valid seal to a citation with a different kaId but same root/author and expects authorSig: false and verified: false if a seal is present.

[otReviewAgent]

🟡 Issue: Split the dRAG route before it becomes the feature switchboard

What's wrong
handleDragRoutes is accumulating unrelated orchestration concerns in a single POST branch. The implementation works as a first pass, but structurally it creates the exact spaghetti growth pattern this endpoint is likely to suffer from as dRAG gains more retrieval, payment, and reasoning modes.

Example
Adding another answer mode now means editing the same HTTP handler in the payment block, retrieval block, answer block, post-processing block, and metrics block. The route already has several feature flags (scope, retrieval, embedder, synthesize, reason, simulatePrice) competing in one function.

Suggested direction
Make the HTTP route mostly parse, delegate, and serialize. Move payment resolution, retrieval strategy resolution, post-processing, reasoning, and metrics into named functions or a dedicated service so each new mode has one canonical home.

For Agents
In packages/cli/src/daemon/routes/drag.ts, keep request/response behavior stable but extract a typed request parser plus a DragAnswerService/use-case that composes payment, retriever resolution, answer execution, synthesis, reasoning, and metrics through small helpers. Route tests should still cover 402, keyword/semantic, synthesis, and reasoning responses.

[otReviewAgent]

🟡 Issue: Use one explicit retriever ownership boundary

What's wrong
The daemon-owned semantic retriever leaks into the core agent as optional mutable state, while explicit semantic requests use a second global cache. That obscures the dependency boundary and makes retriever lifetime/configuration harder to reason about than it needs to be.

Example
There are now two ownership paths for the same dependency: the lifecycle-attached retriever for default/network serving, and a route-global cache for explicit semantic requests. A maintainer has to know which path applies before they can reason about retriever lifetime, store ownership, and model configuration.

Suggested direction
Avoid a mutable optional dependency on the base agent plus a separate route-level singleton cache. Put retriever lifetime behind a dedicated dRAG service or an explicit retrieval-strategy parameter so the daemon remains the owner of vector-store/embedder state.

Confidence note
This is a maintainability concern rather than proof of a current behavioral failure; the risk grows if more daemon instances, tests, or retriever types share one process.

For Agents
Review DKGAgentBase.entityRetriever, attachEntityRetriever, and retrieverCache. Prefer one ownership model: either construct a dRAG service in the daemon with a retriever factory, or pass a retrieval strategy explicitly into answer execution. Preserve keyword fallback and network serving behavior; add a focused test that two distinct retriever configurations do not share stale store/provider state.

[otReviewAgent]

🟡 Issue: Do not model N3 rule attribution with regex string matching

What's wrong
The reasoner correctly delegates derivation to EYE, but then reconstructs rule attribution and support using ad-hoc regexes over N3 source text. That is a magical boundary in a proof-carrying feature and makes the implementation harder to extend or audit than a typed rule model would be.

Example
A rule body/head that uses the same local predicate name under different prefixes, nested braces, comments, or a predicate local name that appears in another token still flows through the same string heuristics. Even if behavior is acceptable for the demo rules, the implementation makes the reasoning proof boundary depend on incidental text shape rather than a parsed rule model.

Suggested direction
Use a real rule/proof representation: preferably EYE justifications, or at least parse rules into explicit head predicate and body predicate terms once. Then proof support can operate over typed terms instead of local-name substring heuristics.

For Agents
In packages/cli/src/daemon/drag-reasoner.ts, preserve current reasoning output but replace regex/string matching with either EYE justification output or a small parsed rule representation built by an N3/RDF parser. Tests should cover multiple prefixes with the same local name and rules containing nested/log constructs while preserving existing derivations.