Backend data + intelligence layer for competitive ruliology (strategy graphs, payoff/fitness storage, GNN opponent models)

Companion issue (ruvnet/ruflo): https://github.com/ruvnet/ruflo/issues/2314

Summary

Following Stephen Wolfram's Games Between Programs: The Ruliology of Competition,
there's a companion effort in Ruflo to add competitive execution to swarms — arenas,
tournaments, and co-evolution of program strategies (see the Ruflo issue). That work produces a
lot of structured, queryable intelligence: strategy spaces, opponent behavior, payoff
landscapes, fitness curves, and evolutionary histories.

This proposes that RuVector own the data + intelligence layer for it, while Ruflo owns
execution and all visualization. RuVector ships no UI — only data and compute services
(MCP tools, query endpoints, RVF artifacts).

What's proposed

1. Strategy graphs + opponent modeling (GNN) — model strategies as nodes and
   beats/loses-to/mutated-from edges in a property graph (ruvector-graph, Cypher); embed
   strategies via ruvector-gnn/ruvector-attention into HNSW for "who plays like X" queries;
   per-opponent next-move models; proof-gated lineage via ruvector-verified. (ADR-196)
2. Payoff / fitness / evolution storage — competitive arrays as sparse matrices
   (ruvector-solver), fitness curves as downsampled time series, evolutionary lineage as an
   append-only log, packaged as portable RVF run artifacts for replay/sharing. (ADR-197)
3. Backend data + tooling for visualization — versioned read-model APIs, streaming feeds,
   and server-side graph layout/downsampling that feed the Ruflo dashboards — explicitly
   no rendering, no front-end, no auth UI in RuVector. (ADR-198)

Cross-cutting (shared with Ruflo — see companion issue)

• Verified distillation of winning LLM strategies into compact programs (coherence-checked,
  proof-gated). (ADR-199 ↔ Ruflo ADR-151)
• Integration layer — ingestion APIs, canonical schemas + shared ID namespace, query/stream
  endpoints, RVF exchange. (ADR-200 ↔ Ruflo ADR-152)
• Safe compute governance — bounded budgets, proof-gated mutation so evolved strategies
  can't corrupt verified state, validated ingestion, WASM sandbox for untrusted RVF. (ADR-201 ↔ Ruflo ADR-153)
• Visualization split + governance — RuVector = data/intelligence; Ruflo = UI; paired
  ADRs, versioned contracts. (ADR-202/203 ↔ Ruflo ADR-154/155)

Why RuVector

This is squarely RuVector's wheelhouse — the graph-transformer stack (ADR-046), proof-gated
mutation (ADR-047), verified training (ADR-049), HNSW + quantization, RVF cognitive containers
(ADR-029/030), and the pi.ruv.io brain. The Ruflo prototype currently fakes this layer with a
local file/AgentDB RunStore; the intent is to graduate it to RuVector once there's appetite.

Proposed phasing

• Phase 1: define the read-model + ingestion contract (with Ruflo) so the Ruflo prototype
  can target it; store competitive arrays + fitness curves (RVF). (ADR-197/200)
• Phase 2: strategy graph + GNN embeddings + opponent models. (ADR-196)
• Phase 3: verified distillation + safe-compute governance. (ADR-199/201)

Questions for maintainers

1. Is a competitive-ruliology data/intelligence layer something you'd want in RuVector?
2. New crate (e.g. ruvector-arena) vs. composing existing crates (ruvector-graph +
   ruvector-gnn + ruvector-solver)?
3. RVF as the run-artifact format — right call, or prefer another store?
4. Preferred contract surface to Ruflo — MCP tools, HTTP endpoints, or both?

Full ADR set (RuVector ADR-196–203) and the cross-repo map are drafted in the ruliad
meta-repo (INTEGRATION-ADRS.md). Scope is flexible — happy to start with just the storage
contract if that's the most useful first step.

Start with INTEGRATION-ADRS.md in the ruliad meta-repo and review ADR-196–203, then inspect the ruvector-graph, ruvector-gnn, ruvector-solver, and RVF components named in the issue. Confirm a narrow phase and acceptance criteria with maintainers before coding, since no concrete files, tests, or definition of done are provided.