vrr/ruvector
2
0
Fork 0
mirror of https://github.com/ruvnet/RuVector.git synced 2026-08-21 14:44:03 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 20

docs(adr): Perpetual Intelligence Runtime ADRs (PIR program) (#847)

Browse source 
docs(adr): Perpetual Intelligence Runtime ADRs
This commit is contained in:
rUv 2026-08-19 21:47:52 -04:00 • committed by GitHub
commit 0049892cb5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
15 changed files with 2701 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

255
docs/adr/ADR-305-adopt-latentmesh-adr009-control-loop-spine.md Normal file
View file

@ -0,0 +1,255 @@
# ADR-305: Adopt Autogenous ADR-401 and LatentMesh ADR-009 as the Perpetual Intelligence Runtime's Definition and Control-Loop Spine
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-306, ADR-307, ADR-309, ADR-312, ADR-313, ADR-315 (PIR, this program); LatentMesh ADR-009 "Online Causal Control Loop" (LatentMesh repo, 2026-08-18, status Proposed); autogenous ADR-401 "The Perpetual Intelligence Machine" (autogenous repo, 2026-08-16, status Accepted/Partial) and ADR-400 "Self-Evolving Mesh Perpetual Loop" (autogenous repo, status Accepted — Implemented); ruflo ADR-322/322A/322B/322C "Metaharness Flywheel Integration" (ruflo repo, `v3/docs/adr/`, 2026-07-28, status Accepted); see `docs/research/perpetual-intelligence-runtime/04-verification-addendum.md`
- **Tags**: pir, latentmesh, autogenous, control-loop, governance, cross-repo
## Context
This program's brief asked for a new cross-mechanism architecture combining
self-evolving physical intelligence, persistent transactional memory, and
verified latent agent communication. Research for this ADR set (see
`docs/research/perpetual-intelligence-runtime/02-asset-map.md`, compiled
2026-08-19) found that architecture already designed, one day earlier, inside
`ruvnet/LatentMesh`'s own
[`docs/adr/009-online-causal-control-loop.md`](https://github.com/ruvnet/LatentMesh/blob/main/docs/adr/009-online-causal-control-loop.md)
(dated 2026-08-18, status "Proposed"). That ADR names a role for every
component in this program's brief — RuFlo, MetaHarness/Darwin, RuVector,
MidStream, Radio, RVF/RVM, RuView, and Autogenous — inside one loop:
```
execute → transfer latent state → counterfactual audit (LatentMesh ADR-003)
→ measure causal value
→ update edge value/authority ceiling (LatentMesh ADR-008)
→ persist (LatentMesh ADR-005)
→ change topology (LatentMesh ADR-006, Darwin)
→ next execution
```
LatentMesh ADR-009 states plainly what is built and what is not: *"The
statistical primitive (LatentMesh ADR-003) and admission gate (LatentMesh
ADR-008) are implemented; the closed loop across live components is not
wired."* That is the actual gap this program should close — not a greenfield
design problem.
**Verification note (updated)**: a second agent (asset-scout) subsequently
cloned `ruvnet/LatentMesh` directly (HEAD `922ea196`, 2026-08-18) and
confirmed the loop diagram and the "not wired" quote above verbatim against
source, including the per-stage "not implemented" markers on ADR-004 through
ADR-008. **One material correction to the asset map's framing: LatentMesh is
a small research prototype, not a substantial codebase.** The entire
workspace is 1,407 LOC across four crates (`latentmesh-core` 272,
`latentmesh-align` 454, `latentmesh-gate` 534, `latentmesh-bench` 147; 23
tests total) — roughly 1/23rd the size of `ruvector-core` alone. **There is
no network transport crate anywhere in the workspace.** "Adopt LatentMesh
ADR-009 as the spine" means adopting a *design contract* and ~1.4K LOC of
tested primitives (the causal-edge and admission-gate math), not inheriting a
mature system. Every later PIR ADR and work package must be scoped against
that reality — WP5 (wire LatentMesh live, ADR-309) in particular is building
a transport layer that does not exist today, not integrating one.
LatentMesh's maintainers are also still actively revising scope — the asset
map notes ADR-009 itself was revised twice in one day — so this program's
timeline is exposed to their churn (see `03-program-plan.md`, Top Risks §2).
## Reconciliation with autogenous ADR-401 (material finding, added post-draft)
Independent verification of `ruvnet/autogenous` (asset-scout, HEAD `b5c6e838`,
2026-08-19) surfaced a second, materially different finding the original
asset map did not capture: autogenous's ADR sequence runs **391 through 403**
(13 ADRs), not the four the asset map cited (391/392/393/397). The missing
ones include
[`ADR-401-perpetual-intelligence-machine.md`](https://github.com/ruvnet/autogenous/blob/main/docs/adr/ADR-401-perpetual-intelligence-machine.md)
— **"The Perpetual Intelligence Machine," status Accepted (framing +
capability map) · Partial (implementation), dated 2026-08-16** — and
[`ADR-400-self-evolving-mesh-perpetual-loop.md`](https://github.com/ruvnet/autogenous/blob/main/docs/adr/ADR-400-self-evolving-mesh-perpetual-loop.md),
status "Accepted — Implemented (first flywheel turn measured)." This author
independently confirmed ADR-401's content by reading it directly.
ADR-401 defines a 10-capability map (observe→diagnose→propose→execute→measure→revise,
governed self-improvement, cross-organization intelligence, and more), an
operating loop, and a V1 acceptance test — implemented mostly in
`packages/radio-moe/src/*.ts` (6,171 LOC, 3,161 LOC of tests), not the Rust
crates the asset map described. Several of its capabilities are already
**Built and measured** (e.g. peer-loss recovery at 30% mesh loss, p50 0.34ms;
fused-mixture decision quality beating best-single agent 100% vs 66.7%),
while others are honestly marked Partial, Gap, or Narrative — ADR-401 itself
models the same claims-honesty discipline this program has been trying to
adopt from LatentMesh. It also references a third ADR series it labels
"metaharness ADR-322" (flywheel receipts/promotion) — **that citation is a
misattribution**. A fourth research pass located the actual document at
**`ruvnet/ruflo`, `v3/docs/adr/ADR-322-metaharness-flywheel-integration.md`**
— "Adopt `@metaharness/{flywheel,darwin}` as pluggable engines behind
ruflo's ADR-176 self-improvement flywheel," status Accepted (phases 0–2
implemented), dated 2026-07-28. `ruvnet/metaharness` (the renamed
`agent-harness-generator`) has its own 230-ADR series topping out at
ADR-250 — no ADR-322 exists there. **This program cites the dependency as
"ruflo ADR-322" going forward; every reference to it elsewhere in this
program's documents should be corrected to match** (see
`04-verification-addendum.md` §5).
ruflo ADR-322 has a directly load-bearing implementation detail for this
program: its child ADR-322B states, verbatim, *"A proposer produces
untrusted candidates only. It cannot issue promotion decisions or mutate
active policy."* This is the same separation-of-powers boundary autogenous
ADR-401's capability-5 table row describes as "not yet one checked
predicate" — **but that row is stale relative to ADR-401's own Decision
section.** ADR-401's **Update 1 §3, "Converge the promotion invariant to one
predicate," is marked DONE**: `mesh-evolve.ts` exports
`promoteAuthorized(candidate, champion, { authorized, reversible }) →
PromotionDecision`, the single gate `Promote = Better ∧ Safe ∧ Authorized ∧
Reversible`, with each conjunct independently blocking and
`evolveMesh` routing every promotion through it — proven by
`test/promote-authorized.test.ts` (all-four promotes; any three-of-four does
not). This program cites the Decision section, not the stale capability
table, as ADR-401's authoritative status on this point (see ADR-315 for the
corrected scope this implies). ruflo ADR-322A independently implements the
same separation as one atomic transaction (`promoteFlywheelCandidate` as
sole promotion authority, verified under 100 concurrent promotion attempts
producing exactly one commit). This program
adopts that separation-of-powers invariant as a **governing invariant**,
alongside the six carried from the original brief (see Decision §3 below).
**This changes the decision below**: LatentMesh ADR-009 is a *proposed,
unwired, ~1.4K-LOC integration contract*. Autogenous ADR-400/401 are
**Accepted, partially-to-fully implemented, with measured results**, and
ADR-401 is, on its face, largely the same product this program's brief
describes. WP1 must read ADR-401 in full and choose explicitly between
adopting/extending it or stating in writing why the PIR program defines a
parallel Perpetual Intelligence Machine — silently re-deriving an Accepted
ADR-401 across this program's other ten ADRs would be the worst outcome this
program could produce.
## Decision
The Perpetual Intelligence Runtime does **not** define its own product
framing or its own cross-mechanism architecture. It adopts two existing,
already-Proposed-or-Accepted decisions from sibling repos, at two different
levels:
1. **Program definition of record**: PIR adopts autogenous ADR-401's
10-capability map, its "perpetual means operational continuity, not
infallibility" framing, and its V1/30-day acceptance-test structure as the
program's own definition of what is being built and how it will be judged
done. Where a PIR ADR in this set (ADR-306 through ADR-315) covers ground
ADR-401 already scores as Built or Partial, that PIR ADR must say so
explicitly and describe itself as closing ADR-401's named gap, not as
introducing a new capability.
2. **Communication-fabric design contract**: PIR adopts LatentMesh ADR-009's
seven-stage online causal control loop (execute → transfer → counterfactual
audit → measure → update authority → persist → evolve topology) as the
design contract specifically for the Latent Communication Fabric bounded
context (ADR-309, ADR-310, ADR-311) — the one part of ADR-401's capability
map (capability 6/7 boundary-crossing communication) that autogenous's own
repo does not itself implement.
3. PIR work packages are scoped to close the gaps **both** ADRs already
declare — LatentMesh ADR-009's "closed loop not wired" and autogenous
ADR-401's own Partial/Gap rows — not to re-derive either document's
claims. autogenous ADR-400/401 cite "metaharness ADR-322" for flywheel
receipts/promotion; that citation is a misattribution corrected above —
the actual document is **ruflo ADR-322** (Accepted, phases 0–2
implemented), and its child ADR-322B's separation-of-powers invariant
("a proposer produces untrusted candidates only; it cannot issue
promotion decisions or mutate active policy") is adopted here as a
seventh governing invariant alongside the six carried from the brief,
binding on every PIR ADR that defines a mutation-proposal or
promotion-decision mechanism (ADR-306, ADR-313, ADR-315).
4. A coordination channel is opened with both the `ruvnet/LatentMesh` and
`ruvnet/autogenous` maintainers before any ADR in this program assigns a
number, or makes a claim, that could conflict with either repo's own ADR
sequence. Every cross-repo ADR reference in this program's documents must
name the owning repo explicitly (e.g. "LatentMesh ADR-009", "autogenous
ADR-401", "ruvector ADR-134") — the asset map documents an ADR-103
numbering collision across repos (ruvector's ADR-103 is unrelated to the
witness/fix-manifest ADR-103 that lives in claude-flow/Ruflo), and this
program must not create a second instance of that ambiguity.
5. The program's committed first work package (WP1) is, before any other PIR
work starts: (a) read autogenous ADR-401 in full and produce the
explicit adopt/diverge decision required above, (b) confirm LatentMesh
ADR-009's loop against source (done — see Verification note), (c)
confirm ruflo ADR-322/322A/322B/322C against source (**done**: cloned
directly, HEAD `fa13ee4`, 2026-08-15; the separation-of-powers quote,
the 322C canonical-encoding/signature stack including its three signing
domains, and the evidence-grading vocabulary all check out verbatim —
see `04-verification-addendum.md` §8), and (d) apply the **fix-history
verification rule** below to every remaining inherited claim this
program has not yet independently checked.
6. **Fix-history verification rule (added after PR #847 review)**: an
inherited "known bug," "gap," or "not yet implemented" claim from any
source document — the program brief, an upstream ADR, or a prior research
pass in this program itself — must be checked against that path's actual
fix history (`git log` on the named file/module, the owning repo's
release notes or merged PRs) before being repeated in a PIR ADR. It is
not sufficient that the asserting document's prose says the bug is open.
This rule exists because all three of this ADR set's blocking review
findings (ADR-401's promotion predicate, the "metaharness ADR-251"
citation, and the ADR-150 misattribution — see ADR-315, ADR-306, ADR-313)
shared the same root cause: a claim was carried forward from an upstream
document without checking whether upstream's own state had since moved
past it, or whether the citation resolved to a real document at all. The
`ruvllm` HTTP-307 bug ADR-313 originally cited as open (later found
already fixed on `main`, commit `946275a61`) is the concrete instance
that surfaced this pattern.
## Consequences
### Positive
- Avoids duplicating a design that already exists and is already
cross-component-aware; every later PIR ADR gets a concrete loop stage to
attach to instead of inventing placement.
- Forces early cross-repo coordination instead of discovering a conflict
after multiple ADRs and work packages are already built on a diverging
architecture.
- Inherits LatentMesh ADR-009's own honesty discipline (narrowing its novelty
claims against StateBridge/LatentMAS/MANTA/E2-Explainer) as the model for
how this program's own ADRs should be written.
### Negative
- Couples this program's schedule to a repo it does not control, whose
maintainers are still actively revising scope (twice in one day, per the
asset map).
- The loop's accuracy has not been independently verified by this program as
of this ADR — see the Verification note above. If WP1's direct read of
LatentMesh ADR-009 contradicts the asset map's summary, every downstream
PIR ADR that assumes this loop shape needs re-review.
- Adds an explicit dependency: no PIR work package that assigns cross-repo
ADR numbers may proceed until the LatentMesh coordination channel exists.
## Security / Validation Gates
- **Cross-repo ADR-numbering discipline**: every reference to a non-`ruvector`
ADR in any PIR document must name the owning repo. This is a documentation
gate, not a code gate, but it is treated as a blocking requirement for WP1
sign-off given the asset map's documented ADR-103 collision precedent.
- **Hosted-RVM honesty discipline** (carried from ruvector ADR-285): any
claim this program makes about LatentMesh's or RVM's isolation/verification
strength must match what has actually been tested, not what is aspired to.
## Affected Repos
- `ruvnet/LatentMesh` (primary — architecture spine, coordination target)
- `ruvnet/ruvector` (RuVector, RVF, RVM, ruvLLM components named in the loop)
- `ruvnet/rvm` (witness/capability enforcement referenced by the loop)
- `ruvnet/autogenous` (governance role named in the loop)
- `ruvnet/RuView` (sensing role named in the loop)
## Dependencies
None — this is the foundational ADR for the PIR program. ADR-306, ADR-307,
ADR-309, and ADR-312 each depend on this ADR's adoption decision.
## Alternatives Considered
- **Design a new cross-mechanism architecture from scratch**: rejected — the
asset map's headline finding is that this would duplicate work already done
one day earlier in a sibling repo, and would create exactly the kind of
cross-repo architectural conflict this ADR is written to avoid.
- **Fork LatentMesh ADR-009's loop into a `ruvector`-local copy instead of
coordinating with LatentMesh**: rejected — forking invites drift between
the two repos' understanding of the loop, which is the same failure mode
the asset map warns against for the RVM/Autogenous witness-crate
duplication (see ADR-312).

187
docs/adr/ADR-306-dream-machine-sona-darwin-unification.md Normal file
View file

@ -0,0 +1,187 @@
# ADR-306: Dream Machine — Adopt the Consolidating Evaluation Engine, Wired to research-gate and Darwin
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-305 (PIR, depends on); ADR-312 (PIR, shares verification stack); ADR-313 (PIR, downstream consumer); ruvector ADR-282 (research-gate); ruflo ADR-322/322A/322B/322C (flywheel integration, Accepted — verified against source); ruflo ADR-381 (Proposed — stream identity + budget-exhaustion recovery only, not the statistics; see Context); ruflo PR #2956 (the anytime-valid statistics mechanism itself); dream-machine ADR-0001 (Accepted, engine v0.1.0 shipped); metaharness `docs/dream-cycle/` (Nightly Dream Cycle — not an ADR; corrects "metaharness ADR-251," which does not exist); see `docs/research/perpetual-intelligence-runtime/04-verification-addendum.md` §6, §8
- **Tags**: pir, dream-machine, promotion, evaluation, cross-repo
## Context
Invariant 5 of the program is: *"every promoted mutation must outperform its
parent."* This ADR's premise changed twice during research for this program
(see `04-verification-addendum.md` §6 for the full trail):
1. **First pass**: no asset named "Dream Machine" exists; the closest
analogue is SONA's dream-replay engine (`05-MEMORY-DREAMS.md`), and this
would be a from-scratch build.
2. **Second pass**: real, CI-wired, cryptographically-signed statistical
promotion machinery already exists inside `ruvector` under a different
name — `scripts/research-gate/` + `.github/workflows/research-*.yml`,
backed by `crates/ruvector-sota-bench/harness` (`statistics.ts` paired
bootstrap, `vetoes.ts` hard vetoes, `flywheel.ts` Ed25519-signed replay
bundles), documented in ruvector ADR-282. This significantly de-risked
what had been flagged as the program's top risk.
3. **Third pass (this ADR)**: **a literal `ruvnet/dream-machine` repo
exists**, is real, public, published to npm, and its own **ADR-0001** is
Accepted with engine v0.1.0 shipped (compile / ledger / witness /
schedule / memory modules, CLI/TUI, 85 tests, ~2,558 LOC). Its thesis:
*"Freeze the model. Evolve the harness. **Evaluation is not promotion —
the machine never merges; a human does.**"* It composes
`@metaharness/flywheel`, `@metaharness/darwin`, `@metaharness/redblue`,
the `metaharness` CLI, `ruvector`, and `agentdb` as optional/peer
dependencies, and its own text names two prior instances it
**subsumes**: `ruvnet/ruflo`'s nightly dream cycle and, per its own
"Prior instances" line, "metaharness ADR-251 (MetaHarness Nightly Dream
Cycle)." **That second citation does not exist and this ADR does not
restate it as fact**: `ruvnet/metaharness`'s ADR series is 230 files
topping out at `ADR-250-sota-proof-ladder.md` — no ADR-251. Its Nightly
Dream Cycle material instead lives in `docs/dream-cycle/`
(`2026-08-13-gist.md`, `2026-08-14-gist.md`, `LEDGER.md`), not as an ADR.
The bad citation is inherited from dream-machine ADR-0001's own text,
noted here as its provenance rather than independently verified.
**"Dream Machine" therefore now exists in four places**, and this program
must name which is canonical for which layer rather than building a fifth:
| Layer | Canonical implementation |
|---|---|
| Generalized, product-level evaluation engine (compile/ledger/witness/schedule/memory, CLI/TUI) | `ruvnet/dream-machine` ADR-0001 (Accepted, v0.1.0 shipped) |
| Statistical significance + hard vetoes + signed replay bundles, already CI-wired inside `ruvector` | `ruvector` ADR-282 (`scripts/research-gate/`, `crates/ruvector-sota-bench/harness`) |
| Evaluation↔promotion transaction model, separation of proposer vs. promotion authority | ruflo ADR-322/322A/322B (Accepted — implemented; see ADR-305, ADR-313) |
| Sequential/anytime-valid statistical evidence across adaptively-chosen candidates | ruflo **PR #2956** (the mechanism: `α_k = α_total·6/(π²k²)`, 0.6% measured family-wise false-promotion rate over 1,000 simulated nulls, bound holds **per epoch**); ruflo **ADR-381** (Proposed — governs stream identity and budget-exhaustion recovery *over* that mechanism, not the statistics themselves) |
| Earlier reference instances, now subsumed | `ruvnet/ruflo` nightly dream cycle; `ruvnet/metaharness` `docs/dream-cycle/` (not an ADR — see above) |
**Version drift**: `ruvnet/dream-machine` composes `@metaharness/darwin`
0.9.1 / `@metaharness/flywheel` 0.1.10; `ruvector` currently pins `darwin`
0.8.0 / `flywheel` 0.1.7. This program's WP0b (MetaHarness
dependency-compliance remediation) should account for this drift when it
fixes the `optionalDependencies` non-compliance documented in
`METAHARNESS-README.md` (see ADR-313 for the source citation — the policy is
ruflo ADR-150, "MetaHarness Integration Surfaces in `npx ruflo`," Implemented
2026-06-16; neither `ruvector`'s nor `metaharness`'s own ADR-150 is the right
document, both being unrelated).
## Decision
The Perpetual Intelligence Runtime does not build a new evaluation service.
It **adopts `ruvnet/dream-machine`'s engine (ADR-0001) as the evaluation
core**, wired to `ruvector`'s already-CI-integrated statistical layer:
1. `ruvnet/dream-machine`'s compile/ledger/witness/schedule/memory pipeline
becomes the orchestration layer for PIR's mutation-evaluation cycle,
consuming Darwin mutation proposals (`@metaharness/darwin`, per ADR-313)
and producing evidence-gated verdicts.
2. `ruvector` ADR-282's `research-gate` (`statistics.ts` paired bootstrap,
`vetoes.ts` hard vetoes, `flywheel.ts` Ed25519-signed replay bundles)
supplies the statistical significance layer dream-machine's own engine
calls into for `ruvector`-hosted mutation evaluation — this program does
not reimplement paired-bootstrap significance testing a second time.
3. SONA's dream-replay engine (`05-MEMORY-DREAMS.md`) remains an optional
pre-filter feeding candidates into this pipeline before the more
expensive statistical evaluation runs, not a replacement for it.
4. The evaluation↔promotion transaction boundary follows ruflo ADR-322A/
322B: an evaluation verdict is advisory input, never a promotion
decision in itself.
5. **Dream-machine's constitutional principle is adopted and is not
negotiable within this program: "Evaluation is not promotion — the
machine never merges; a human does."** This exact sentence is verbatim in
dream-machine's `README.md` (L19–20) and `packages/cli/README.md`, not in
ADR-0001 itself — ADR-0001 §2.4 states the same substance in its own
words: *"Evaluation is not promotion. The session never merges, never
self-promotes flywheel state…"* and *"Promotion is a human act."* This
ADR cites the README's phrasing because it is the more quotable form, and
attributes it to the repo rather than to ADR-0001 specifically. Automated
gates (research-gate's statistics, dream-machine's ledger/witness
pipeline, ruflo's promotion transaction) may recommend promote/reject;
only a human-authorized action performs the final merge into an active
policy or codebase. This constrains the frozen-weights-and-governed-mutation
loop this program builds (ADR-313, ADR-315) — no PIR work package may
wire an unattended `/loop`-style auto-merge path, mirroring ADR-0001's
own explicit phase-3/4 gating of unattended promotion pending separate
privilege, spend, and rollout controls.
## Consequences
### Positive
- Converts what was the program's single largest identified risk (building
a promotion-evaluation system from nothing) into a consolidation task
across four already-Accepted-or-implemented pieces of prior art.
- Inherits ruflo PR #2956's measured statistical guarantee (0.6% family-wise
false-promotion rate, per epoch) instead of needing to re-derive or
re-validate a sequential-testing scheme from scratch; ADR-381 (Proposed)
layers stream-identity and budget-recovery governance on top of that
already-implemented mechanism.
- The "evaluation is not promotion, a human merges" principle gives
invariant 5 a hard human-in-the-loop backstop, directly addressing the
acceptance test's "zero unapproved capability expansion" requirement
(ADR-315) at the evaluation layer as well as the constitutional layer.
### Negative
- Four separate prior instances (dream-machine, ruflo dream cycle,
metaharness `docs/dream-cycle/`, ruvector research-gate) must be reconciled into one
coherent pipeline for this program; no repo checked by this program's
research passes has published that reconciliation yet — it is WP1/WP2's
deliverable, not a pre-existing fact this ADR can cite.
- Adds a real external dependency (`ruvnet/dream-machine`, v0.1.0, a young
shipped engine) to `ruvector`'s promotion pipeline, with its own version
churn risk on top of the already-identified `@metaharness/*` version
drift.
- The "a human merges" principle is a deliberate throughput ceiling: it
rules out a fully unattended 30-day acceptance run unless the acceptance
harness (WP12) is itself designed around scheduled human checkpoints
rather than continuous autonomous promotion — a scope clarification this
ADR surfaces but does not resolve.
## Security / Validation Gates
- **Proof-gated promotion**: `ruvector-proof-gate`/`rvm-proof` (ruvector
ADR-227 and sibling RVM ADRs) still gates every promotion; dream-machine's
verdict and research-gate's statistical result are inputs to that gate,
never a bypass of it.
- **Witness-chain requirement**: every verdict (promote or reject) emits an
RVM witness record (ruvector ADR-134 schema); this program's shared
witness/anchoring contract (ADR-312) is the mechanism that makes
dream-machine's own ledger/witness modules and RVM's witness chain
cross-verifiable.
- **Human-merge constitutional gate**: no CI or scheduled-worker path may
execute a final merge/promotion without an explicit human-authorized
action recorded in the witness chain, per ADR-0001's principle adopted
above.
- **Standard repo gate**: `npx @claude-flow/cli@latest security scan` after
any change to the promotion pipeline's signing or verification code.
## Affected Repos
- `ruvnet/dream-machine` (adopted engine, external dependency)
- `ruvnet/ruvector` (`scripts/research-gate/`, `crates/ruvector-sota-bench/harness`, ADR-282; SONA dream-replay)
- `ruvnet/ruflo` (ADR-322/322A/322B transaction model — Accepted, verified verbatim against source; PR #2956 — the sequential-statistics mechanism; ADR-381 — Proposed, stream-identity/budget-recovery governance only)
- `ruvnet/metaharness` (`docs/dream-cycle/`, prior reference instance — not an ADR)
## Dependencies
Depends on ADR-305 (adopts the control-loop and cross-repo coordination
posture this evaluation core plugs into). Shares its verification stack with
ADR-312. ADR-313 (SHAPER-pattern evolution loop) depends on this ADR —
Darwin's mutation proposals need a verdict from this pipeline before
promotion.
## Alternatives Considered
- **Build a new evaluation service from scratch** (the program's original
framing): rejected — three separate research passes converged on the fact
that this would duplicate at least four existing pieces of prior art, the
newest of which (`ruvnet/dream-machine`) is already shipped and Accepted.
- **Adopt only `ruvector` ADR-282's research-gate and ignore
`ruvnet/dream-machine`**: rejected — research-gate is a strong statistical
layer but does not provide dream-machine's orchestration (compile/ledger/
schedule/memory/CLI-TUI) layer, and ADR-0001 explicitly positions itself
as the consolidating design other implementations should align with.
- **Allow unattended promotion once statistical significance is met**:
rejected — contradicts ADR-0001's explicit constitutional principle and
autogenous ADR-401's own admission that its `Better ∧ Safe ∧ Authorized ∧
Reversible` promotion predicate is not yet fully closed; keeping a human
merge step is the safer default until that predicate is fully wired and
independently audited.

142
docs/adr/ADR-307-three-level-persistent-memory-livemem-tarl.md Normal file
View file

@ -0,0 +1,142 @@
# ADR-307: Three-Level Persistent Memory Architecture (LiveMem + TARL Pattern) on RuVector
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-305 (PIR, depends on); ADR-309 (PIR, depends on this)
- **Tags**: pir, memory, livemem, tarl, rvf, rvm, witness
## Context
Invariants 1 and 2 of the program require: *"every observation may change
memory"* and *"every memory change is transactional."* Per
`docs/research/perpetual-intelligence-runtime/01-evidence-review.md`, two
grade-A primary sources ground the design of a persistent memory tier:
- **LiveMem** — [arXiv:2608.02515](https://arxiv.org/abs/2608.02515),
"LiveMem: Maintaining Memory State Continuity in Long-Running LLM
Inference," submitted 2026-08-03 (v1), revised 2026-08-07 (v2). Confirms a
fixed-capacity memory state whose lifetime is independent of the active
context, maintained via a parallel memory branch (Gated DeltaNet-2
backbone) alongside a bounded KV attention window, reframing long-running
inference as "computational state preservation." The system can answer
questions from memory state after supporting evidence has left the context
window. Grade A — evidence review flags a name collision with an unrelated
consumer iOS app ("LiveMem – Live Photo Editor"); this ADR always means the
arXiv paper.
- **TARL (Transaction-Aware Reliable Ledgers)** —
[arXiv:2608.03699](https://arxiv.org/abs/2608.03699), "TARL:
Transaction-Aware Reliable Ledgers for Executable Memory Management in
Long-Term Agents," submitted 2026-08-04 (v1), revised 2026-08-11 (v2).
Confirms a five-operation executable ledger — add / ignore /
revise-outdated-belief / reject-unreliable / defer-for-verification — with
accepted, pending, and rejected ledgers, explicitly framed as reducing
"memory pollution" and limiting cumulative corruption. Grade A. **This name
is heavily overloaded in prior literature** (Taint Analysis and
Reinforcement Learning, arXiv:2005.03813; Target-Aligned Reinforcement
Learning, arXiv:2603.29501; an unrelated `xushoukai/TARL` GitHub repo) —
none of which relate to agent memory ledgers. "TARL (Transaction-Aware
Reliable Ledgers)" is spelled out here on first use, and every subsequent
reference to TARL in this program's documents should do the same.
RuVector already provides the durable substrate these two patterns need:
RVF (`crates/rvf` — append-only crash-safe segments, progressive indexing,
post-quantum signatures, canonical format per ruvector ADR-029) and RVM
(`crates/rvm` — mandatory hash-chained witness records for every privileged
action, per ruvector ADR-134).
**Revised scope (per the deep-researcher's asset-map revision)**: the
three-tier architecture below is not a from-scratch build. Each tier already
has a concrete home in `ruvector`'s existing memory stack, and proof-gated
writes for that stack **already exist** (ruvector ADR-194, ADR-047) — meaning
"sign every memory transition via RVM witness records" is largely already
built for the underlying gate, not net-new. The net-new work this ADR
actually scopes is the TARL five-operation ledger *states and semantics*
layered on top of that existing proof-gate, not the gate itself.
## Decision
Implement three explicit memory tiers, formalizing components that mostly
already exist in `ruvector` rather than building three new stores:
1. **Working context** — maps to `ruvllm`'s `working_memory` module,
unchanged by this ADR.
2. **Continuous latent state** — maps to `ruvllm`'s
`episodic_memory`/`semantic_cache`/`agentic_memory` modules, formalized to
follow LiveMem's fixed-capacity recurrent-state design (arXiv:2608.02515):
capacity is bounded and independent of context length, so state can
outlive whatever evidence originally produced it.
3. **Transactional RuVector memory** — maps to `ruvector-agent-memory`
(ruvector ADR-252) plus `reasoning_bank` and `ruvector-temporal-coherence`
(ruvector ADR-211), extended with TARL's five-operation ledger
(arXiv:2608.03699): every incoming statement maps to exactly one of add /
ignore / revise-outdated-belief / reject-unreliable / defer-for-verification,
with accepted, pending, and rejected ledger states persisted via RVF and
signed via the RVM witness records this tier's writes already produce
(ruvector ADR-194, ADR-047, ADR-134 schema).
No incoming observation writes directly to the transactional tier without
passing through the TARL-style operation classification — this is what makes
invariant 2 ("every memory change is transactional") enforceable rather than
aspirational, on top of the write-path proof-gating that already exists.
## Consequences
### Positive
- Both source patterns are grade-A, independently verifiable primary sources
— this ADR can cite concrete published mechanisms rather than inventing an
architecture from the brief's prose alone.
- The TARL ledger's reject/defer states give the program a structural answer
to memory poisoning (invariant 2), not just an append-only log that trusts
every write.
- Reuses RVF/RVM's existing durability and witness primitives rather than
building a parallel persistence layer.
### Negative
- Neither paper's reference implementation is open-sourced as of the
evidence review; this program is implementing the *pattern* described in
each paper's abstract and methodology, not integrating existing code — the
behavioral fidelity to each paper's reported properties is unverified until
this program's own implementation is tested against comparable benchmarks.
- Three explicit tiers add operational complexity (three storage/lifecycle
policies to reason about) versus a single undifferentiated memory store.
- The middle (continuous latent state) tier's fixed capacity means it can
legitimately forget — this is a design tradeoff, not a bug, but it must be
documented clearly so downstream consumers (e.g. ADR-309's latent
communication fabric) do not assume unbounded retention.
## Security / Validation Gates
- **Witness-chain requirement**: every state transition in this tier —
every TARL ledger operation (add/ignore/revise/reject/defer) and every
continuous-latent-state checkpoint — must emit an RVM witness record
(ruvector ADR-134 schema) before it is considered committed. No RVF write
without a corresponding witness entry.
- **Standard repo gate**: `npx @claude-flow/cli@latest security scan` after
any change to the ledger's write path, since it is a direct target for the
memory-poisoning attacks this design is meant to resist.
## Affected Repos
- `ruvnet/ruvector` (`crates/rvf`, `crates/rvm`, `crates/ruvector-core`)
- `agentdb` (memory subsystem consumer of this tiering)
## Dependencies
Depends on ADR-305 (adopts the control-loop this tier is embedded in). ADR-309
(wiring LatentMesh live) depends on this ADR for RVF/RVM provenance wiring on
the memory-ledger side of latent communication.
## Alternatives Considered
- **A single undifferentiated memory store instead of three tiers**:
rejected — collapses the working-context/continuous-state/transactional
distinction that both source papers treat as load-bearing, and removes the
structural basis for enforcing invariant 2.
- **Build the transactional ledger without the TARL five-operation
classification (plain accept-or-reject)**: rejected — TARL's
revise-outdated-belief and defer-for-verification states are what let the
ledger correct itself over time rather than only ever accumulating or
discarding; a binary scheme loses that self-correction path.

118
docs/adr/ADR-308-worldcycle-verification-physical-action-loop.md Normal file
View file

@ -0,0 +1,118 @@
# ADR-308: WorldCycle-Style Verification for the Physical Action Loop
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-313 (PIR, depends on); ADR-306 (PIR, downstream consumer)
- **Tags**: pir, worldcycle, verification, physical-action, evaluation
## Context
Invariant 6 of the program requires: *"every physical action produces new
evidence."* Per
`docs/research/perpetual-intelligence-runtime/01-evidence-review.md`, this is
grounded in a grade-A source:
- **WorldCycle** — [arXiv:2608.04964](https://arxiv.org/abs/2608.04964),
"WorldCycle: Self-Verifiable Reinforcement Learning for Long-Horizon Video
World Models," submitted 2026-08-05. The abstract states verbatim:
"WorldCycle reduces state returning drift by up to 44% and lifts
composite-action accuracy nearly 4x over the base model." A diagnostic
benchmark, CycleBench, ships alongside it. The mechanism: verification
signals derived from reversible/closed action cycles — an action sequence
plus its inverse should return to the initial state — used for
annotation-free supervision. Grade A, exact figure match against the
program brief; no name collision found in the evidence review's search.
This paper's reversible-action-sequence verification is exactly the kind of
"new evidence" invariant 6 asks for: an executed action either returns the
world to a predictable state (when composed with its inverse) or it does not,
and that discrepancy is itself evidence usable for supervision, independent
of any external label.
## Decision
Adopt WorldCycle's reversible-action-sequence verification (arXiv:2608.04964)
as an explicit stage in the physical action loop, positioned between
"observe consequences" and "Dream Machine evaluation" (ADR-306). Concretely:
1. For every executed physical action sequence where a reasonable inverse
exists, construct the inverse sequence and measure state-return drift
against the pre-action state.
2. Use the drift measurement as an annotation-free verification signal fed
into the mutation's evaluation record, alongside whatever supervised or
task-specific signals already exist.
3. Adopt the paper's reported figures — **up to 44% long-horizon drift
reduction and ~4x composite-action accuracy** over an unverified baseline —
as the acceptance bar for this program's Phase 3 world-model component.
This program has not yet run its own CycleBench-equivalent benchmark; the
44%/4x figures are the paper's reported results on its own benchmark, not
yet confirmed against this program's task set. This ADR commits to
re-measuring against CycleBench or an internal equivalent before treating
the figures as validated in this program's context.
## Consequences
### Positive
- Gives invariant 6 a concrete, annotation-free verification mechanism
instead of relying solely on external task-success labels, which are
expensive and may not exist for every physical action.
- The reversible-action-cycle technique composes cleanly with Dream Machine
(ADR-306): drift measurements are exactly the kind of pre-filter signal
Dream Machine's dream-replay stage is meant to cheaply evaluate.
- Grade-A, exact-figure-match evidence — this ADR can cite a concrete
acceptance bar rather than an aspirational one.
### Negative
- Not every physical action has a well-defined, safe-to-execute inverse
(e.g. destructive or irreversible actions); this ADR does not specify a
fallback verification path for that case, which is an open implementation
question for the owning work package (WP10).
- The 44%/4x figures come from CycleBench, a benchmark this program has not
reproduced; treating them as this program's acceptance bar before
re-measurement risks anchoring on numbers that may not transfer to PIR's
actual task distribution.
- Adds execution cost: every verified action sequence now also requires
executing (or simulating) its inverse, which is not free in a physical or
physically-simulated environment.
## Security / Validation Gates
- **Proof-gated promotion**: drift-verification results feed into the same
`ruvector-proof-gate`/`rvm-proof` promotion path as Dream Machine's verdict
(ADR-306) — this ADR does not introduce a separate, unaudited promotion
path.
- **Structural frozen-weights enforcement** (shared with ADR-313): the
verification stage must not introduce a code path that could be mistaken
for a fine-tuning signal on the frozen foundation model — drift
measurements feed the mutation-evaluation record, never a gradient update.
- **Witness-chain requirement**: each drift-verification result is logged to
the witness chain (ruvector ADR-134 schema) as part of the mutation's
evaluation record, so it is auditable alongside the eventual promotion
decision.
## Affected Repos
- `ruvnet/ruvector` (`crates/ruvector-nervous-system`; new crate
`ruvector-worldcycle-verify`, per `03-program-plan.md`'s Crates section)
## Dependencies
Depends on ADR-313 (SHAPER-pattern skill/harness evolution loop) — this
verification stage sits inside the physical action loop that ADR-313's
mutation surfaces produce candidates for. ADR-306 (Dream Machine) is a
downstream consumer of this stage's drift-verification signal.
## Alternatives Considered
- **Rely only on external task-success labels for invariant 6**: rejected —
labels are expensive, not always available for physical actions, and do
not by themselves establish that "new evidence" was produced by the action
as invariant 6 requires.
- **Adopt WorldCycle's full video-world-model architecture, not just its
verification signal**: rejected as out of scope for this ADR — the program
brief and evidence review both frame WorldCycle's contribution to this
program narrowly as its annotation-free verification mechanism, not a
replacement for PIR's own physical-action execution stack.

132
docs/adr/ADR-309-latentmesh-greenfield-crates-wire-format-coordination.md Normal file
View file

@ -0,0 +1,132 @@
# ADR-309: Build LatentMesh Integration Inside ruvector as New Crates, Coordinated on Wire Format
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-305 (PIR, depends on); ADR-307 (PIR, depends on); ADR-310, ADR-311 (PIR, depend on this); LatentMesh ADR-003, ADR-005, ADR-006, ADR-008 (LatentMesh repo); ruvector ADR-159 (rvagent-a2a)
- **Tags**: pir, latentmesh, greenfield, cross-repo, transport
## Context
Invariant 3 of the program requires: *"every agent communication is
attributable."* The original framing of this work package described it as
"wiring LatentMesh live" — implying an existing integration that merely
needed its remaining pieces connected. Direct verification (see
`04-verification-addendum.md` §1) corrects that framing on two points:
1. **Inside `ruvector`, there is zero existing wiring to `ruvnet/LatentMesh`
today.** The only trace is an unmerged branch, `origin/docs/link-latentmesh`.
It is not cloned locally and not integrated with RuVector in any shipped
form.
2. **`ruvnet/LatentMesh` itself is a small research prototype**, not a
mature system to integrate against: 1,407 LOC across four crates
(`latentmesh-core` 272, `latentmesh-align` 454, `latentmesh-gate` 534,
`latentmesh-bench` 147; 23 tests total), and **there is no network
transport crate anywhere in its workspace**. LatentMesh's own ADR-009
confirms this: the statistical primitive (ADR-003) and admission gate
(ADR-008) are implemented, but network transport, RVF packaging, and RVM
enforcement wiring are all explicitly marked "not implemented" —
externally, not just inside `ruvector`.
This changes the work's nature: this is greenfield engineering inside
`ruvector`, coordinated against an external, evolving, small-scale design
contract — not an integration task against existing code on either side.
## Decision
Build the `ruvector`-side LatentMesh integration as **new crates**, not as a
completion of an existing integration:
1. House the new crates under `crates/rvAgent/`, alongside the existing
`rvagent-a2a` (ruvector ADR-159), or as a new `latentmesh` crate family —
the exact placement is an implementation decision for the owning work
package, not fixed by this ADR.
2. Implement, inside `ruvector`, the three pieces LatentMesh's own ADRs mark
as not implemented anywhere: network transport, RVF packaging (model
identity, transform, permitted recipients, provenance, witness history as
artifact metadata, per LatentMesh ADR-008), and RVM `rvm-cap` admission
enforcement.
3. Open an explicit, standing coordination channel with the
`ruvnet/LatentMesh` maintainers so the two sides converge on one wire
format rather than diverging — this program does not unilaterally define
a wire format LatentMesh's own crates (`latentmesh-core`,
`latentmesh-align`, `latentmesh-gate`) must then be retrofitted to match.
4. The acceptance bar for this work package is a live multi-agent task
running LatentMesh's causal-edge verification (LatentMesh ADR-003)
end-to-end for the first time from `ruvector` — per LatentMesh ADR-009,
this has never been run against a live multi-agent task anywhere, inside
or outside `ruvector`.
## Consequences
### Positive
- Scoping this as greenfield construction (not integration) sets accurate
expectations for the owning work package's effort and timeline — a
transport layer does not exist on either side of this coordination and
must be built, not merely wired.
- A live first run of LatentMesh's causal-edge verification would be a
genuine first for the mechanism anywhere in the `ruvnet` org, not just for
this program.
- Coordinating on wire format from the start avoids the two sides
independently building incompatible transports and discovering the
mismatch late.
### Negative
- This is real, unstarted engineering effort on a mechanism (causal-edge
latent communication) with no live precedent anywhere — schedule risk is
the program's own top-ranked risk as of this research pass (see
`03-program-plan.md`, Top Risks §1).
- LatentMesh's maintainers are still actively revising scope (its own
ADR-009 was revised twice in one day); a wire-format coordination channel
reduces but does not eliminate exposure to that churn.
- LatentMesh's small scale (1,407 LOC) means this program may end up writing
substantially more `ruvector`-side code than exists in the entire upstream
repo it is coordinating against — a proportion worth surfacing to
reviewers who assume "integrating with an existing project" implies a
smaller `ruvector`-side footprint.
## Security / Validation Gates
- **Causal-audit CI gate** (shared with ADR-310): any PR touching the new
`latentmesh`-integration crates or downstream consumers must pass a
controlled-replacement causal audit before merge.
- **Witness-chain requirement**: RVF packaging for every latent frame
includes provenance and witness history as artifact metadata (LatentMesh
ADR-008's own requirement), anchored via this program's shared witness
contract (ADR-312).
- **RVM admission enforcement**: no latent frame is accepted without passing
`rvm-cap` admission — this is the concrete implementation of invariant 3
("every agent communication is attributable") for this bounded context.
- **Hosted-RVM honesty discipline** (ruvector ADR-285): if any part of this
transport layer runs in a hosted (non-bare-metal) mode, it must not claim
bare-metal isolation strength.
## Affected Repos
- `ruvnet/ruvector` (new crates, primary build location)
- `ruvnet/LatentMesh` (wire-format coordination, primary as design contract)
- `ruvnet/rvm` (`rvm-cap` admission enforcement)
## Dependencies
Depends on ADR-305 (adopts LatentMesh ADR-009 as the design contract this
work implements) and ADR-307 (RVF/RVM provenance wiring the memory-ledger
side of this transport depends on). ADR-310 (causal-attribution gate) and
ADR-311 (anomaly quarantine) both depend on this ADR — neither has a
transport layer to gate or quarantine until this ADR's crates exist.
## Alternatives Considered
- **Wait for `ruvnet/LatentMesh` to build its own transport layer before
starting `ruvector`-side work**: rejected — LatentMesh's own maintainers
have not committed to a timeline, and this program's acceptance test
depends on a live run of the causal-edge verification mechanism; waiting
indefinitely is not compatible with the program's schedule.
- **Build a `ruvector`-only latent-communication mechanism instead of
coordinating with LatentMesh's wire format**: rejected — this is exactly
the "parallel architecture" ADR-305 already rejected at the program level;
a `ruvector`-only mechanism would not benefit from LatentMesh's existing
causal-edge verification math (`latentmesh-align`, `latentmesh-gate`) and
would fragment the `ruvnet` org's latent-communication story further.

127
docs/adr/ADR-310-causal-attribution-gate-latent-communication.md Normal file
View file

@ -0,0 +1,127 @@
# ADR-310: Causal-Attribution Gate for Latent Communication
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-309 (PIR, depends on); ADR-311 (PIR, downstream consumer); ruflo PR #2956 (anytime-valid sequential-evidence mechanism); ruflo ADR-381 (Proposed — stream identity + budget-exhaustion recovery over that mechanism)
- **Tags**: pir, causal-audit, ci-gate, latent-communication, security
## Context
Invariant 3 of the program requires: *"every agent communication is
attributable."* Per
`docs/research/perpetual-intelligence-runtime/01-evidence-review.md`, this is
grounded in a grade-A source, cited here with a corrected date:
- **Causal audit of latent multi-agent communication** —
[arXiv:2607.26773](https://arxiv.org/abs/2607.26773), "Do Latent Channels
Actually Communicate? A Causal Audit of Latent Multi-Agent LLM
Communication." **Submission date: 2026-07-29** (arXiv's own timestamp).
The program brief's original citation of "Aug 5" is incorrect and is not
used anywhere in this program's documents. Grade A. The paper's core
finding: end-task performance gains alone do not establish that a receiver
actually used task-relevant information passed through a latent (KV-cache)
channel — a controlled-replacement causal audit is needed to distinguish
genuine communication from confounded correlation. Tested on Qwen3-4B/8B
over GSM8K, ARC-C, and MATH-500.
This paper is the evidentiary basis for invariant 3: without a causal audit,
"agent A's latent message caused agent B's behavior change" is exactly the
kind of unfalsifiable claim the paper's methodology exists to test.
## Decision
Every latent-channel deployment inside this program's Latent Communication
Fabric context (built per ADR-309) must pass a controlled-replacement causal
audit, modeled on arXiv:2607.26773's methodology, before its performance
claims can justify further rollout. Concretely:
1. This becomes a **required CI gate** on any pull request touching
`latentmesh-align` (or its `ruvector`-side consumers built under ADR-309),
the anomaly-quarantine module (ADR-311), or any downstream consumer of
latent-channel output — not a one-time paper reproduction run once and
forgotten.
2. The audit runs against benchmark families equivalent in structure to the
paper's own (GSM8K/ARC-C/MATH-500-style internal tasks), using a
controlled-replacement methodology: replace the latent channel's content
with a control (unrelated or null) payload and confirm the receiving
agent's behavior changes accordingly when the real payload is restored.
3. Statistical claims produced by this gate (e.g. "the latent channel's
effect on receiver behavior is significant") follow ruflo PR #2956's
anytime-valid e-process scheme (`α_k = α_total·6/(π²k²)` per-test
allocation, so `Σα_k = α_total` holds across arbitrarily many
adaptively-chosen PRs) when the gate runs repeatedly over time, rather
than treating each PR's audit as an independent, uncorrected significance
test. Ruflo ADR-381 (Proposed) is the governance layer over that
mechanism — per-project stream identity and an audited,
`confirm: true`-gated evidence-epoch reset for budget exhaustion. **The
false-promotion bound this composition provides is per-epoch, not
global**: after a reset, the guarantee is family-wise false-promotion
probability ≤ `α_total` for that epoch, and this gate's own statistical
claims must be stated the same way.
4. A CI failure on this gate blocks merge; it does not merely warn.
## Consequences
### Positive
- Gives invariant 3 an enforcement mechanism that runs on every relevant
change, not just once at program kickoff — a latent channel that "worked"
at audit time but silently stops actually communicating (only correlating)
after a later change would otherwise go undetected.
- Reuses a peer-reviewed, grade-A methodology instead of inventing an
in-house causal-attribution test from scratch.
- Composing with ruflo PR #2956's sequential-evidence scheme (governed by
ADR-381) keeps the gate's statistical claims sound, per epoch, even as it
runs many times over the program's lifetime, rather than accumulating
false-positive risk across repeated single tests.
### Negative
- A controlled-replacement causal audit is more expensive to run than a
simple end-task performance comparison; this adds CI latency to every PR
touching the gated modules.
- The gate's benchmark families are internal analogues of GSM8K/ARC-C/
MATH-500, not the exact published benchmarks — fidelity to the paper's
original methodology needs independent validation before the gate's
results are treated as equivalent-strength evidence to the paper's own.
- Gating on this gate alone does not itself catch anomalous or malicious
latent payloads — that is ADR-311's scope; a channel can pass causal
attribution and still carry a tampered payload.
## Security / Validation Gates
- **Causal-audit CI gate** (this ADR's core mechanism): blocking, not
advisory, on every PR touching the scoped modules.
- **Witness-chain requirement**: every audit run and its verdict are
witness-logged (this program's shared anchoring contract, ADR-312), so
the audit history for any given latent-channel change is queryable
end-to-end.
- **Sequential-evidence discipline**: statistical claims from repeated gate
runs follow ruflo PR #2956's e-process scheme (governed by ADR-381) rather
than compounding uncorrected significance tests, and are stated as
per-epoch bounds, not global ones.
## Affected Repos
- `ruvnet/ruvector` (CI workflow, the new LatentMesh-integration crates from ADR-309)
- `ruvnet/LatentMesh` (`latentmesh-align`, if the gate is also adopted upstream — coordination item, not required by this ADR)
## Dependencies
Depends on ADR-309 (there is no latent-channel code to gate until the
greenfield transport/RVF-packaging work exists). ADR-311 (anomaly
quarantine) is a downstream consumer — quarantine decisions are informed by,
but distinct from, this gate's causal-attribution verdict.
## Alternatives Considered
- **A one-time causal-audit reproduction at program kickoff, not a
standing CI gate**: rejected — a static audit cannot catch regressions
introduced by later changes to `latentmesh-align` or its consumers, which
is exactly the failure mode invariant 3 is meant to prevent on an ongoing
basis.
- **Use end-task performance improvement alone as the attribution signal**:
rejected — this is precisely the confounded-correlation failure mode
arXiv:2607.26773 documents; performance gains do not establish that the
latent channel itself was the causal mechanism.

149
docs/adr/ADR-311-anomaly-quarantine-latent-channels-net-new.md Normal file
View file

@ -0,0 +1,149 @@
# ADR-311: Anomaly Quarantine for Latent Channels (Net-New Work — Not "LATTE")
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-309, ADR-310 (PIR, depends on both); ADR-312 (PIR, shares provenance chain)
- **Tags**: pir, quarantine, latent-communication, security, net-new
## Context
**"LATTE" is not a real paper.** Per
`docs/research/perpetual-intelligence-runtime/01-evidence-review.md` item 6,
this program's original brief cited "LATTE" as prior art for anomaly
quarantine of multi-agent latent communication. An extensive search effort —
direct phrase search across all major combinations — found eight or more
unrelated papers using "LATTE" as an acronym (a latent diffusion transformer
for video, atomic environment descriptors, hyperbolic Lorentz attention for
EEG, a robotics trajectory transformer, quantum error-correction decoding,
federated test-time adaptation, bank-transaction embeddings, linear-time
attention) — **none of which relate to multi-agent latent-communication
anomaly quarantine.** No paper under this name, in this domain, was found to
exist. This ADR states that explicitly and permanently: **any future
reference to "LATTE" as prior art for this quarantine mechanism is
incorrect, and this ADR's decision must never be described as "implementing
LATTE."**
The closest genuine match on topic is grade-graded separately in the
evidence review:
- [arXiv:2606.28958](https://arxiv.org/abs/2606.28958), "When Latent Agents
Lie: KV-Cache Integrity in Multi-Agent LLM Collaboration" — confirmed to
use an HMAC-SHA256 manifest-based integrity/tamper-detection scheme (774
honest payloads accepted, 295 tampered rejected in the paper's own
evaluation). This is related in spirit — it is about detecting
compromised latent-channel payloads — but it is a **different mechanism**:
cryptographic integrity verification via HMAC manifest, not statistical
anomaly quarantine, and it does not use the name "LATTE" anywhere.
**This ADR's quarantine mechanism is original work informed by
arXiv:2606.28958, not an implementation of "LATTE" or any other paper.**
Where this program needs statistical/behavioral anomaly detection beyond
what a cryptographic integrity manifest alone provides, that half of the
mechanism has no external prior art to lean on and is being built for the
first time by this program.
## Decision
Build anomaly quarantine for latent-channel updates as a first-party
contribution, combining two elements this program can cite concretely:
1. **Integrity verification**: adopt arXiv:2606.28958's HMAC-manifest
approach for detecting tampered latent-channel payloads — a manifest
binds a payload to an expected hash, and a mismatch is rejected before
the payload reaches a receiving agent.
2. **Provenance chaining**: bind quarantine decisions into this program's
shared witness/anchoring contract (ADR-312), specifically anchoring
quarantine verdicts through `rvm-witness`/autogenous `witness` provenance
chains, so a quarantine decision is auditable alongside the rest of the
mutation/promotion history.
3. **Statistical anomaly detection** (the genuinely novel half): design and
implement statistical/behavioral anomaly scoring for latent-channel
updates that HMAC integrity checking alone cannot catch (e.g. a
cryptographically valid but behaviorally anomalous payload from a
compromised-but-still-signing agent). This is explicitly documented, in
this ADR and in every derived design document, as original work with no
existing paper to validate it against — its effectiveness must be
established empirically by this program's own test suite, not cited from
a source that does not exist.
4. Every quarantine ADR, design doc, code comment, or status report produced
by this program must describe this mechanism as "net-new anomaly
quarantine informed by arXiv:2606.28958," never as "LATTE" or an
implementation of it.
## Consequences
### Positive
- Gives the quarantine mechanism a concrete, citable foundation for its
integrity-verification half (arXiv:2606.28958's measured 774/295
accept/reject split) rather than an unsupported claim.
- Being explicit that the statistical-anomaly half is novel work sets
accurate expectations for validation effort — this program budgets time
to build and test an anomaly-scoring mechanism, not to integrate an
existing one.
- Prevents a specific, identified credibility risk: an ADR or status report
citing "LATTE" as if it were real prior art would be discovered as false
by any reviewer who searches for the paper, undermining trust in this
program's other, genuinely grade-A-cited claims.
### Negative
- The statistical-anomaly-detection half has no published baseline to
benchmark against — this program must define its own success criteria and
validation methodology from scratch, which is a real, unbounded design
task rather than a scoped integration.
- Combining a cryptographic mechanism (HMAC manifest, deterministic) with a
statistical mechanism (anomaly scoring, probabilistic) in one quarantine
pipeline introduces two different failure/false-positive regimes that need
separate tuning and separate testing.
- This work package (WP7, per `03-program-plan.md`) explicitly depends on
ADR-309 and ADR-310 both landing first — there is no latent-channel
transport to quarantine, and no causal-attribution baseline to compare
against, until those exist.
## Security / Validation Gates
- **Integrity gate**: every latent-channel payload is checked against its
HMAC-SHA256 manifest before delivery; a mismatch quarantines the payload
and never delivers it to the receiving agent.
- **Statistical anomaly gate**: payloads that pass integrity verification
but score above the anomaly threshold are also quarantined, pending
further review — the exact threshold and scoring methodology are an
implementation detail for the owning work package, not fixed by this ADR.
- **Witness-chain requirement**: every quarantine decision (pass, integrity
failure, or anomaly hold) is anchored via this program's shared witness
contract (ADR-312), making quarantine history auditable.
- **Causal-audit interaction**: a quarantined payload does not count toward
a latent channel's causal-attribution evidence (ADR-310) — quarantine and
causal audit are complementary, not substitutes for each other.
## Affected Repos
- `ruvnet/ruvector` (new quarantine module, built on ADR-309's crates)
- `ruvnet/rvm` (`rvm-witness` provenance anchoring)
- `ruvnet/autogenous` (`witness` provenance anchoring, per ADR-312's shared contract)
## Dependencies
Depends on ADR-309 (latent-channel transport must exist before it can be
quarantined) and ADR-310 (causal-attribution gate — quarantine and causal
audit are complementary controls on the same channel). Shares its provenance
mechanism with ADR-312.
## Alternatives Considered
- **Describe this mechanism as an implementation of "LATTE"** (the
program's original framing): rejected outright — no such paper exists;
doing so would be a factually false citation in a permanent architecture
record.
- **Skip statistical anomaly detection and rely on HMAC integrity checking
alone**: rejected — integrity checking only catches *tampered* payloads
signed incorrectly; it does not catch a validly-signed but behaviorally
anomalous payload from a compromised agent that still holds valid signing
credentials, which is exactly the gap statistical anomaly scoring is meant
to close.
- **Wait for external prior art on multi-agent latent-channel anomaly
quarantine before building this**: rejected — the evidence review already
confirms none exists after a genuine search effort; waiting indefinitely
is not compatible with invariant 3's enforcement needs.

193
docs/adr/ADR-312-shared-witness-schema-anchoring-contract.md Normal file
View file

@ -0,0 +1,193 @@
# ADR-312: Shared Witness Record Schema and Cross-Layer Anchoring Contract (rvm-witness ↔ autogenous witness)
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-305 (PIR, depends on); ADR-306, ADR-307, ADR-309, ADR-315 (PIR, consumers); ruflo ADR-322/322C (flywheel receipt/ledger/verification protocol, Accepted — implemented, verified verbatim against source); ruflo PR #2956 (anytime-valid sequential-evidence mechanism); ruflo ADR-381 (Proposed — stream identity + budget-exhaustion recovery over that mechanism); ruvector ADR-134 (witness schema/log format); see `docs/research/perpetual-intelligence-runtime/04-verification-addendum.md` §3, §5, §8
- **Tags**: pir, witness, provenance, security, cross-repo
## Context
The program's original framing (from `03-program-plan.md`'s initial draft)
proposed resolving a perceived duplication: `ruvnet/rvm`'s `rvm-witness`
crate and `ruvnet/autogenous`'s `witness` crate both implement an
append-only, hash-chained, tamper-evident log, described as having
"near-identical framing." The proposed decision was to make `rvm-witness`
canonical and have `autogenous`'s `witness` crate depend on or converge with
it.
**Direct comparison of both crates does not support that framing** (full
detail in `04-verification-addendum.md` §3):
| | `autogenous/crates/witness` | `rvm`'s `crates/rvm-witness` (vendored in `ruvector`) |
|---|---|---|
| Size | 302 LOC, one file | 4,405 LOC, multi-file |
| Hash | SHA-256 over canonical JSON | u64 chain/record hashes |
| Auth | Ed25519, per-role `SigningAuthority` | Keyed chain MAC with derivation + ratcheting |
| Record shape | JSON artifacts (genome, mutation, antibody, incident) | 64-byte cache-line-aligned records in a fixed-capacity ring buffer |
| Runtime | std, service-side, offline+deterministic | `no_std`, hypervisor-side |
The two crates are correct for their respective layers — SHA-256-over-JSON
does not fit a `no_std` 64-byte-aligned ring buffer, and `rvm-witness`'s
keyed-MAC chain is deliberately not a signature scheme suitable for
cross-service, offline verification. **Merging them, or making one depend on
the other, would be a design error**, not a simplification.
A better anchor already exists, and this program has now verified it
directly against a clone of `ruvnet/ruflo` (HEAD `fa13ee4`, 2026-08-15; 177
ADRs in `v3/docs/adr/`), not merely inherited it. `ruflo ADR-322C` (part of
the Accepted — phases-0–2-implemented — ADR-322 flywheel-integration series)
defines a receipt/ledger/verification protocol built specifically to be a
portable, offline-verifiable, cross-layer wire format: **RFC 8785 JCS
canonical JSON, SHA-256 digests, Ed25519 signatures with domain separation**
(`Ed25519(domainPrefix || 0x00 || canonicalBytes)`) — confirmed to use
**two distinct Ed25519 signing domains** (`ruflo/flywheel-receipt/v1` and
`ruflo/flywheel-ledger-head/v1`), not one, plus a third domain-separated
prefix (`ruflo/bootstrap/v1`) that seeds the deterministic paired
bootstrap's statistics rather than signing anything — with explicit identity
derivation (`candidateId =
SHA-256(JCS(candidate policy))`, `receiptId = SHA-256(JCS(unsigned receipt
payload))`). Every authorizing term in a 322C record carries an explicit
evidence grade — **`recomputed`, `signature-verified`, or
`trusted-assertion`** — a vocabulary this ADR adopts below for grading
anchored claims. UUIDv7 run IDs, deterministic paired-bootstrap statistical
recomputation, an O_EXCL cross-process lock with directory-fsynced
compare-and-swap, and fail-closed verification (unknown fields, non-finite
numbers, and negative zero all rejected) are likewise confirmed against
source. **This same verification pass corroborates the ADR-103 ambiguity
this program flagged elsewhere (ADR-305)**: ADR-322C line 105 states its
keys "use ADR-103's provider mechanism but a distinct purpose/domain" —
confirming the witness-manifest ADR-103 is `ruflo`'s, not `ruvector`'s.
Separately, `ruflo ADR-381` is **Proposed** (not Accepted; date 2026-08-10)
and governs a narrower scope than this ADR originally attributed to it. The
anytime-valid sequential statistical evidence scheme itself — `α_k =
α_total · 6/(π²k²)` per-test allocation so `Σα_k = α_total`, and the
measured 0.6% family-wise false-promotion rate over 1,000 simulated nulls —
belongs to **ruflo PR #2956**, which ADR-381 *governs* rather than defines:
ADR-381's own decision is (1) scoping the α ledger to the ADR-322
transaction state, one stream per project root, and (2)
`resetSequentialEvidence`, an explicit, `confirm: true`-gated, human-reasoned
**evidence-epoch** reset for budget exhaustion that expires all outstanding
receipts so stale evidence cannot be replayed against a fresh budget.
**The false-promotion bound is per-epoch, not global**: after a reset, the
guarantee is family-wise false-promotion probability ≤ `α_total` for that
epoch — any PIR document citing this bound must state it the same way.
## Decision
Resolve the witness-layer question as a **shared record schema plus a
cross-layer anchoring contract**, not a crate merge or dependency edge:
1. `rvm-witness` remains the canonical implementation for its layer —
hypervisor-side, `no_std`, privileged-action recording. `autogenous`'s
`witness` crate remains the canonical implementation for its layer —
service-side, std, JSON-artifact governance records. Neither is refactored
to depend on the other.
2. Both layers adopt **ruflo ADR-322C's canonical encoding and
domain-separated Ed25519 signature scheme** as the shared, portable
record format for any witness record that needs to be verified *across*
layers — specifically, an autogenous promotion decision that needs to be
anchored into an RVM witness chain (or vice versa) is represented using
ADR-322C's canonical-JSON + domain-separated-Ed25519 encoding at the
anchoring boundary, regardless of each crate's own internal
representation.
3. Where a witness record makes a statistical claim (e.g. "this mutation's
improvement was significant"), that claim's evidence follows ruflo PR
#2956's anytime-valid e-process scheme (governed by ADR-381's stream
identity and evidence-epoch reset) rather than a single uncorrected
significance test — this is the concrete mechanism that makes "outperform
its parent" (invariant 5) auditable across an arbitrarily long sequence of
promotion attempts within an epoch. Any witness record's statistical
claim is stated as a **per-epoch** bound, not a global one, and each
authorizing term is tagged with 322C's evidence grade
(`recomputed`/`signature-verified`/`trusted-assertion`) so a reader can
tell which parts of the claim were independently recomputed versus merely
asserted.
4. ruvector ADR-134's witness schema (the 64-byte cache-line-aligned,
hash-chained record format used by `rvm-witness`) is unchanged by this
ADR; this decision governs the boundary where a non-RVM witness record
needs to be anchored into or verified against an RVM chain, not RVM's own
internal format.
## Consequences
### Positive
- Avoids a design error (merging two crates built for genuinely different
runtimes and threat models) that the original framing would have produced.
- Reuses an already-Accepted, already-implemented cross-service verification
protocol (ruflo ADR-322C) instead of this program inventing a fifth
witness-record format.
- Gives every PIR ADR that emits witness records (ADR-306, ADR-307, ADR-309,
ADR-315) one anchoring contract to target, regardless of which underlying
crate produced the record.
### Negative
- Requires cross-repo sign-off from `ruvnet/rvm`, `ruvnet/autogenous`, and
`ruvnet/ruflo` maintainers on the shared boundary format — more
coordination surface than a single-repo crate-dependency change would have
been, even though it is architecturally the correct choice.
- `autogenous` self-labels "research prototype" status; adopting ruflo
ADR-322C's format at the anchoring boundary does not itself stabilize
autogenous's own witness crate's internal API, which may still churn.
- This ADR does not eliminate the two independent witness implementations —
it deliberately keeps both. Anyone expecting "one witness crate for the
whole program" from the original framing needs to be told explicitly that
this ADR chose interoperability over consolidation.
## Security / Validation Gates
- **Witness-chain requirement**: every cross-layer anchoring event (an
autogenous promotion record anchored into an RVM chain, or the reverse)
must use ruflo ADR-322C's canonical encoding and produce a verifiable
domain-separated Ed25519 signature before either side treats the record as
committed.
- **Fail-closed verification**: unknown fields, non-finite numbers, and
negative zero are rejected at the anchoring boundary, per ADR-322C's own
verification rules — this program does not weaken that contract at the
boundary.
- **Sequential-evidence discipline**: any witness record carrying a
statistical promotion claim states its evidence per ruflo PR #2956's
anytime-valid e-process scheme (governed by ADR-381), not a single-test
p-value, expressed as a **per-epoch** bound, so the acceptance harness's
(ADR-306, WP12) day-30 comparison remains statistically sound within each
evidence epoch — a day-30-vs-day-1 comparison spanning an epoch reset must
not silently claim a global bound it does not have.
- **Standard repo gate**: `npx @claude-flow/cli@latest security scan` after
any change to signing, canonicalization, or verification code in either
witness crate or the anchoring boundary.
## Affected Repos
- `ruvnet/rvm` (`rvm-witness`, unchanged internally)
- `ruvnet/autogenous` (`witness` crate, unchanged internally)
- `ruvnet/ruflo` (ADR-322/322C canonical encoding/signature scheme — Accepted; PR #2956's sequential-evidence mechanism; ADR-381's stream-identity/epoch-reset governance — Proposed; all consumed, not modified, by this ADR)
- `ruvnet/ruvector` (anchoring-boundary implementation, RVM witness consumer)
## Dependencies
Depends on ADR-305 (adopts the cross-repo coordination posture this ADR
requires). ADR-306 (Dream Machine), ADR-307 (three-level memory), ADR-309
(LatentMesh transport), and ADR-315 (constitutional gate) all depend on this
ADR for how their respective witness records get anchored across layers.
## Alternatives Considered
- **Make `autogenous`'s witness crate depend on `rvm-witness`** (the
program's original framing): rejected — see Context; the two crates target
incompatible runtimes (`no_std` hypervisor-side ring buffer vs. std
service-side JSON), and forcing a dependency edge between them would
either break `rvm-witness`'s `no_std` constraint or strip `autogenous`'s
witness crate of the JSON/Ed25519 shape its own consumers expect.
- **Invent a new, program-specific witness schema instead of adopting ruflo
ADR-322C's**: rejected — ADR-322C is already Accepted and implemented with
a fail-closed verification suite; inventing a fifth schema would add
coordination surface without adding capability.
- **Leave the two witness crates fully independent, with no anchoring
contract at all**: rejected — this would leave invariant 3 ("every agent
communication is attributable") and invariant 5 ("every promoted mutation
must outperform its parent") unauditable across the autogenous/RVM
boundary specifically, which is exactly the boundary this program's
Governance & Constitution context needs to cross.

186
docs/adr/ADR-313-shaper-frozen-weight-skill-harness-evolution.md Normal file
View file

@ -0,0 +1,186 @@
# ADR-313: SHAPER-Pattern Skill/Harness Evolution Loop (Frozen Weights)
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-306 (PIR, depends on); ADR-308 (PIR, downstream consumer); ADR-305 (PIR, separation-of-powers invariant); ruflo ADR-150 "MetaHarness Integration Surfaces in `npx ruflo`" (Implemented, 2026-06-16 — the real source of `METAHARNESS-README.md`'s documented `optionalDependencies` invariant; see Context); ruvector ADR-259 (ruvllm mutator backend); ruvector ADR-271 (darwin_guard); ruflo ADR-322/322A/322B (proposer/promotion separation, Accepted — verified verbatim against source)
- **Tags**: pir, shaper, darwin, frozen-weights, evolution
## Context
The acceptance test's central constraint is frozen foundation-model weights:
the model never changes, only the skills, context, and execution harness
around it. Per
`docs/research/perpetual-intelligence-runtime/01-evidence-review.md`, this
is grounded in a grade-A source:
- **SHAPER** — [arXiv:2608.11350](https://arxiv.org/abs/2608.11350),
"Self-Evolving Embodied Agents via Skill-Harness Evolution," submitted
2026-08-11 (matches the program brief's date exactly). Confirms a
train-free framework that keeps model parameters frozen while evolving
reusable skills and a context/code harness through target-environment
rollouts; the same frozen model serves as both planner and optimizer.
Evaluated on VLABench and ESI-Bench. Grade A; no name collision found.
`ruvector` already has a real evolutionary loop that maps onto this pattern:
Darwin (`@metaharness/darwin`), called from `harness/src/darwin.ts` (ANN
config evolution), `examples/mragent`'s `scorePolicy` function, and
`crates/sona/src/darwin_guard.rs` (ruvector ADR-271) — profile → baseline →
mutate (seven approved surfaces via `CodeGenerator`, e.g. `OpenRouterMutator`,
`RuvllmMutator`) → sandbox → 6-term score → archive-as-tree → repeat.
`ruvllm` is a real, wired local mutator backend (ruvector ADR-259).
**One concrete, already-identified bug blocks this work package** and must
be fixed first (program plan WP0b), not discovered mid-implementation:
1. `METAHARNESS-README.md` claims `optionalDependencies` compliance,
attributing the policy to "**ADR-150**: MetaHarness Integration Surfaces
(**upstream**)." Neither `ruvector`'s own ADR-150
(`ADR-150-pi-brain-ruvltra-tailscale.md`, "π Brain + RuvLtra via
Tailscale — Semantic Embedding Upgrade") nor `metaharness`'s own ADR-150
(`ADR-150-tailscale-local-frontier-concurrent-benchmarks.md`) is the
right document — both are unrelated. **The upstream document resolves to
`ruflo`'s ADR-150**: `v3/docs/adr/ADR-150-metaharness-integration-surfaces.md`,
*"ADR-150 — MetaHarness Integration Surfaces in `npx ruflo`,"* Status
**Implemented** (2026-06-16, rev. 06-17). Its normative rule 2 is
verbatim the policy `METAHARNESS-README.md` claims compliance with:
*"Optional in `package.json`: `@metaharness/*` packages MUST appear in
`optionalDependencies` or `peerDependencies` (optional), never in
`dependencies`."* This is the fourth instance, in this ADR set, of the
same pattern the set exists to catch — assuming the wrong repo owns an
ADR number before checking (see ADR-305 Decision §6); it resolves the
same way the "ruflo ADR-322, never metaharness ADR-322" and "ADR-103"
cases did. Against that real source, the confirmed bug is: the nine
`@metaharness/*` packages in `crates/ruvector-sota-bench/harness` are
plain (hard) dependencies, contradicting ruflo ADR-150 rule 2 — the
harness currently hard-fails to install without them. ruflo ADR-150 rule
4 — *"at least one CI job must run `--ignore-optional` … the only
structural defense against accidentally promoting an optional dep to
required"* — is the stronger, CI-testable acceptance criterion this work
package should adopt instead of a plain `npm install` check (see Decision
§4 and Security Gates below).
**A second bug this ADR previously cited — an HTTP-307 redirect bug in
`ruvllm`'s model-download path — is already fixed on `main`** (commit
`946275a61`, PR #590, 2026-06-18). This ADR no longer treats it as a
blocker. Verifying that fix surfaced the actual remaining download blocker:
a **GGUF glob/alias bug in `ruvllm-cli`'s `get_files_to_download()`**
(`download.rs:193`'s glob pattern and `models.rs:65`'s alias resolution
disagree on which files a given model alias should pull), which still
blocks reliable end-to-end live-serve testing of the mutator backend. This
correction is itself an instance of the verification discipline ADR-305 now
states as a program-wide rule: an inherited "known bug" claim must be
checked against fix history (`git log` on the named path, upstream release
notes) before being repeated in a new ADR, not trusted from the asserting
document's prose alone.
## Decision
Implement the physical-intelligence evolution loop with foundation-model
weights frozen throughout, following SHAPER's pattern (arXiv:2608.11350):
1. The same frozen model serves as both planner and optimizer; only skills,
context, and the execution harness evolve — mapped onto Darwin's existing
mutation surfaces (`harness/src/darwin.ts`, `examples/mragent`
`scorePolicy`, `crates/sona/src/darwin_guard.rs`).
2. This is enforced **structurally**, not by policy: a CI check fails the
build if any mutation surface reachable from the promotion pipeline
imports a training/fine-tuning API. Policy alone ("please don't
fine-tune") is not sufficient for the acceptance test's frozen-weights
verification requirement (day-30 re-hash must be bit-identical to day 0).
3. Darwin's mutation proposals are exactly that — proposals. Per ruflo
ADR-322B's separation-of-powers invariant, adopted as a governing
invariant in ADR-305, quoted here verbatim against source (confirmed
`ADR-322B-darwin-proposer-adapter.md` line 10): *"A proposer produces
untrusted candidates only. It cannot issue promotion decisions or mutate
active policy."* ADR-322 line 15 reinforces the same point from the
Darwin-adapter side: *"Darwin adapters remain candidate generators and
never gain promotion authority."* Darwin's mutation surfaces in this
program never gain promotion authority either; every proposal routes
through ADR-306's adopted evaluation pipeline before any change to active
policy.
4. WP0b's remaining blocking bug is fixed before this work package's
live-serve testing begins: the `optionalDependencies` non-compliance
(make the nine `@metaharness/*` packages genuinely optional per ruflo
ADR-150 rule 2, or correct `METAHARNESS-README.md` to state the real
hard-dependency requirement) and the `ruvllm-cli` GGUF glob/alias bug in
`get_files_to_download()` (`download.rs:193`, `models.rs:65`). The
acceptance criterion for the dependency fix is ruflo ADR-150 rule 4's CI
job on the `--ignore-optional` install path, not merely "`npm install`
succeeds" — that is the structural defense against silently re-promoting
an optional dependency to required. The previously-cited HTTP-307
redirect bug is not part of this gate — it shipped fixed on `main` before
this ADR was written.
## Consequences
### Positive
- Grounds the frozen-weights constraint in a concrete, exact-date-matching
grade-A source rather than only the program brief's prose.
- Reuses Darwin's already-real evolutionary loop instead of building a new
mutation-proposal mechanism.
- The structural (CI-enforced) frozen-weights check, combined with
ADR-322B's separation-of-powers invariant, gives this program two
independent enforcement layers for "the model never changes and a
proposer never self-promotes" — a single-point-of-failure policy
violation in either layer alone does not compromise the other.
### Negative
- This work package cannot start live-serve testing until WP0b's remaining
bug (the GGUF glob/alias mismatch) is fixed — an explicit, tracked
blocking dependency, not a soft preference. The HTTP-307 bug this ADR
originally also gated on turned out to already be fixed on `main`,
illustrating why every inherited bug claim needs a fix-history check
before it is repeated (see ADR-305).
- Darwin currently exists as an external npm dependency
(`@metaharness/darwin`) called from three sites, not a first-class
in-repo asset; this ADR does not itself resolve that architectural
question (vendor vs. formalize-as-dependency), leaving it to the owning
work package.
- A CI check for "no training/fine-tuning API import" is a static,
import-based check; it does not catch a sufficiently obfuscated or
dynamically-loaded fine-tuning path. This is a known limitation, not
claimed to be closed by this ADR.
## Security / Validation Gates
- **Structural frozen-weights enforcement**: CI fails the build if any
mutation surface reachable from the promotion pipeline imports a
training/fine-tuning API.
- **Separation-of-powers invariant** (ruflo ADR-322B, adopted via ADR-305):
Darwin's mutation surfaces never gain promotion authority; enforced by
ADR-306's adopted evaluation/promotion pipeline, not by this ADR directly.
- **Proof-gated promotion**: every mutation still passes through
`ruvector-proof-gate`/`rvm-proof` regardless of SHAPER-pattern compliance.
- **WP0b blocking gate**: this work package's live-serve acceptance criteria
cannot be claimed complete while either the `optionalDependencies`
compliance bug or the `ruvllm-cli` GGUF glob/alias bug
(`get_files_to_download()`) remains open. The dependency fix is verified
by ruflo ADR-150 rule 4's CI job on the `--ignore-optional` install path,
not by a plain successful `npm install`.
## Affected Repos
- `ruvnet/ruvector` (`crates/sona`, `crates/ruvllm` mutator backend, `crates/ruvector-sota-bench/harness`, `agent-harness-generator`/Darwin integration sites)
- `ruvnet/ruflo` (ADR-150 and ADR-322/322A/322B — cited as source policy/invariant, not modified by this ADR)
## Dependencies
Depends on ADR-306 (Dream Machine evaluation pipeline — every mutation
proposal needs a verdict before promotion) and on ADR-305's adopted
separation-of-powers invariant. ADR-308 (WorldCycle verification) depends on
this ADR — it verifies the physical-action outputs this evolution loop
produces.
## Alternatives Considered
- **Allow a fine-tuning fallback path for cases the frozen-weights harness
can't handle**: rejected — this directly contradicts the acceptance test's
central constraint and SHAPER's own pattern; any capability gap should be
addressed via richer harness/skill mutation surfaces, not weight updates.
- **Defer fixing WP0b's remaining bug until it actually blocks a specific
task**: rejected — it is already identified, small, and cheap to fix;
deferring it guarantees it surfaces mid-implementation of this ADR's
higher-priority work instead of being resolved ahead of time.

116
docs/adr/ADR-314-kv-cache-cross-model-migration-ruvllm.md Normal file
View file

@ -0,0 +1,116 @@
# ADR-314: KV-Cache Cross-Model Migration in ruvLLM (Fast-Follow)
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: none within this program's critical path (independent parallel track)
- **Tags**: pir, kv-cache, ruvllm, fast-follow, cross-model
## Context
Fast-follow scope item 4 of the program (per `03-program-plan.md`'s scope
decision) is KV-cache cross-model migration, selected because it has the
program's strongest evidence and is the cheapest item to ship. Per
`docs/research/perpetual-intelligence-runtime/01-evidence-review.md`:
- **Cross-model KV-cache mapping** —
[arXiv:2608.03893](https://arxiv.org/abs/2608.03893), "Cross-Model KV
Cache Transfer in LLM Families: A Closed-Form Linear Mapping for Prefill
Reuse," submitted 2026-08-04 16:26 UTC (matches the brief's date exactly).
**Grade A — the strongest-evidence item in the evidence review.** Exact
figure match on every reported number: the closed-form linear mapper runs
"2.7-25x faster than re-prefill." Tested across six model pairs spanning
three model families; the linear mapper retains 73-98% of the receiver's
standalone-prefill accuracy on four pairs, while **two pairs degrade
sharply**. A nonlinear MLP variant recovers up to +37pp HellaSwag accuracy
on the failing pairs.
This is the concrete implementation target for a `ruvllm` capability:
`crates/ruvllm` already provides paged attention, KV cache management, and
SONA learning (built on `ruvector-core`/`ruvector-sona`), but cross-*provider*
or cross-*model-family* KV-cache migration is not centered here today — that
role sits closer to claude-flow's ADR-026 3-tier routing, which is a
different concern (routing between providers, not migrating cache state
between models).
## Decision
Implement arXiv:2608.03893's closed-form linear KV-cache mapper as a
`ruvllm` capability, ships independently of the Phase 1–3 PIR branch since it
depends only on `ruvllm`:
1. Implement the closed-form linear mapper for same-family model migration
in `crates/ruvllm`, targeting `kv_cache.rs`, `paged_attention.rs`, and
`serving/kv_cache_manager.rs`.
2. Implement the paper's nonlinear MLP fallback specifically for the pairs
the paper itself identifies as degrading under the linear mapper — this
is not optional; the evidence review explicitly notes this fallback is
what "directly supports the brief's implication that migration quality
must be predicted/handled before blind use."
3. Add a routing gate that predicts transfer quality **before** migrating —
never migrate blind. The gate's prediction determines whether to use the
linear mapper, the MLP fallback, or refuse migration and fall back to a
full re-prefill for a pair judged too degraded for either.
4. This work package has no dependency on the rest of this program's ADR set
(ADR-305 through ADR-313, ADR-315) and can start immediately in parallel.
## Consequences
### Positive
- Grade-A, exact-figure-match evidence gives this ADR a concrete,
independently reproducible acceptance bar (2.7-25x speedup; 73-98%
accuracy retention on four of six tested pairs).
- Fully independent of the rest of the program's critical path — delivers
value on its own schedule without blocking or being blocked by ADR-305
through ADR-313 or ADR-315.
- The "predict transfer quality before migrating" routing gate directly
addresses the paper's own finding that two of six pairs degrade sharply —
this ADR does not treat the mapper as universally safe.
### Negative
- The paper's reported figures come from its own six-pair benchmark; this
program has not yet reproduced them against its own model inventory —
the acceptance bar should be re-confirmed against `ruvllm`'s actual served
models, not assumed to transfer directly.
- The routing gate's prediction accuracy is itself an open engineering
question — a gate that mispredicts transfer quality could either block
safe migrations (losing the speedup) or allow unsafe ones (the exact
failure mode this ADR is designed to prevent).
- Two additional code paths (linear mapper, MLP fallback) plus a routing
gate add real maintenance surface to `ruvllm`'s KV-cache management code.
## Security / Validation Gates
- **Proof-gated promotion**: this capability's rollout follows the same
`ruvector-proof-gate`/`rvm-proof` promotion path as any other mutation to
`ruvllm`'s serving path — it is not exempt from standard promotion gating
merely because it ships on an independent schedule.
- **Standard repo gate**: `npx @claude-flow/cli@latest security scan` after
any change to `kv_cache.rs`, `paged_attention.rs`, or
`serving/kv_cache_manager.rs`, since KV-cache handling is a
security-sensitive serving-path component.
## Affected Repos
- `ruvnet/ruvector` (`crates/ruvllm`; new npm package `@ruvector/kv-migrate`)
## Dependencies
None — independent parallel track, can start immediately regardless of the
status of ADR-305 through ADR-313 or ADR-315.
## Alternatives Considered
- **Implement only the linear mapper, skip the MLP fallback**: rejected —
the evidence review is explicit that the two-of-six-pairs-degrade finding
is exactly why a fallback (and a routing gate) is needed; shipping the
linear mapper alone would silently produce degraded migrations on known
bad pairs.
- **Migrate blind (no routing gate) and rely on downstream task performance
to catch bad migrations**: rejected — this is the same
confounded-correlation failure mode ADR-310's causal-audit gate is
designed to prevent elsewhere in this program; predicting transfer
quality before migrating is cheaper and safer than detecting a bad
migration after the fact.

170
docs/adr/ADR-315-governance-constitution-capability-expansion.md Normal file
View file

@ -0,0 +1,170 @@
# ADR-315: Governance Constitution for Capability Expansion
- **Status**: Proposed
- **Date**: 2026-08-19
- **Deciders**: RuV Perpetual Intelligence Runtime (PIR) Program
- **Related**: ADR-312 (PIR, depends on); ADR-306 (PIR, distinct from ordinary promotion gating); ADR-305 (PIR, invariant 7 — proposer/promotion separation, binding here); autogenous ADR-393 "Product Thesis — Adaptive Agent Firewall" (autogenous repo); autogenous ADR-401 capability 5 and Update 1 §3 (governed self-improvement, `promoteAuthorized` — Done)
- **Tags**: pir, governance, constitution, capability-expansion, security
## Context
The acceptance test requires "zero unapproved capability expansion" — no
mutation may silently grant an agent a new tool, a new physical action
class, or a new communication peer without an explicit, higher-bar approval
distinct from ordinary behavioral-mutation promotion (ADR-306).
`ruvnet/autogenous` already implements a constitution/admission-gate pattern
for exactly this purpose (`constitution` crate, part of its
observe → explain → mutate → prove → canary → promote/rollback loop), and its
own ADR-401 (see ADR-305's reconciliation) frames governed self-improvement
as capability 5 of its 10-capability map: `Promote = Better ∧ Safe ∧
Authorized ∧ Reversible`.
**Correction from PR review**: an earlier draft of this ADR described that
predicate as "not yet fully closed as one checked gate," citing ADR-401's
capability-table row 5. **That row is stale relative to ADR-401's own
Decision section.** ADR-401's **Update 1 §3 is marked DONE**: `mesh-evolve.ts`
exports `promoteAuthorized(candidate, champion, { authorized, reversible })
→ PromotionDecision`, the single gate is implemented with each conjunct
independently blocking, `evolveMesh` routes every promotion through it, and
`test/promote-authorized.test.ts` proves no promotion path can skip a
conjunct. The predicate is closed upstream — this ADR does not scope work
to close it.
**Maturity caveat, corrected in this program's verification pass** (see
`04-verification-addendum.md` §2): `ruvnet/autogenous`'s README self-labels
the whole repo **"research prototype"** status, and states plainly that
"performance and economics claims in the ADRs are hypotheses until
benchmarked" — even though several of its individual ADRs (400, 401, 402,
403) carry **Accepted** status. This program treats the repo-level badge as
the governing signal for API stability: autogenous's constitution/
admission-gate API should be treated as unstable, and this program budgets
time for API churn rather than assuming production-grade stability. The
governance loop's actual implementation lives in `packages/radio-moe/src/*.ts`
(action-gate.ts, mesh-evolve.ts, disclosure.ts, reputation.ts — 6,171 LOC
total), not the Rust `constitution` crate alone.
## Decision
Adopt `autogenous`'s constitution/admission-gate pattern, **anchored on the
already-implemented `promoteAuthorized` predicate**, as the enforcement point
for zero-unapproved-capability-expansion:
1. Every mutation that would expand an agent's capability set — new tool
access, new physical action class, new communication peer — requires
explicit constitutional approval logged to the witness chain, **distinct
from** ordinary behavioral-mutation promotion (ADR-306's evaluation
pipeline). A mutation passing ADR-306's promotion gate does not
automatically pass this gate; capability expansion needs its own,
separately-authorized approval record. This gate is itself bound by
governing invariant 7 (adopted in ADR-305, from ruflo ADR-322B): whatever
proposed the capability-expanding mutation cannot also issue this gate's
approval — approval authority and proposal authority must be held by
distinct actors in the witness chain, the same separation-of-powers rule
ADR-313 enforces on Darwin's mutation surfaces.
2. This program **adopts** `mesh-evolve.ts`'s `promoteAuthorized` predicate
(`Promote = Better ∧ Safe ∧ Authorized ∧ Reversible`, all four conjuncts
already independently blocking upstream) as the mechanism whose
"Authorized" conjunct this gate's capability-expansion approval satisfies.
The residual work this program actually scopes is narrower than the
original framing: (a) the `ruvector`-side integration wiring PIR's
capability/tool/action tables into `promoteAuthorized`'s `authorized`
parameter, and (b) the distinctness rule in §1 above — ensuring a
capability-expanding mutation's "Authorized" check is evaluated against
*this program's* capability-expansion approval record specifically, not
merely against `promoteAuthorized`'s general authorization state. This
program does not build or close the predicate itself; that work is
already done upstream.
3. Approval records for capability expansion are anchored via this
program's shared witness contract (ADR-312), so the 30-day acceptance
harness (per `03-program-plan.md`) can query "zero unapproved capability
expansion" directly by diffing the capability/tool/action tables at day 0
vs. day 30 against this gate's approval log.
4. Given autogenous's self-labeled research-prototype status, this program's
integration against its constitution/admission-gate API is built with an
explicit API-stability buffer (versioned interface, integration tests
that fail loudly on upstream API changes) rather than a tight, assumed-
stable coupling.
## Consequences
### Positive
- Reuses `autogenous`'s already-designed governance concept (constitution,
admission gate) instead of inventing a parallel capability-expansion
approval mechanism.
- Directly operationalizes the acceptance test's "zero unapproved capability
expansion" requirement as a queryable log, not just a stated goal.
- Explicitly separating capability-expansion approval from ordinary mutation
promotion (ADR-306) prevents the specific failure mode where a
statistically-significant, well-tested mutation quietly also expands an
agent's capability set without anyone noticing.
- `promoteAuthorized` being DONE upstream (ADR-401 Update 1 §3) meaningfully
reduces this ADR's scope versus the original framing — this program
integrates against a finished, tested predicate instead of building or
completing one.
### Negative
- Coupling to a self-labeled research-prototype API means this integration
carries real churn risk; the API-stability buffer in Decision §4 adds
engineering overhead specifically to manage that risk.
- This program's residual scope depends on `promoteAuthorized`'s upstream
API remaining stable (see the research-prototype caveat above) — a
breaking change to its `authorized`/`reversible` parameters or return
shape would require rework on the `ruvector`-side integration, even though
the predicate's core logic is not this program's responsibility to build.
- Two separate approval paths (behavioral promotion via ADR-306, capability
expansion via this ADR) add process overhead versus a single unified
promotion gate — deliberate, per the acceptance test's own requirement
that these be distinct, but a real cost.
## Security / Validation Gates
- **Constitutional admission gate** (this ADR's core mechanism): every
capability-expanding mutation requires explicit, separately-logged
approval before it can take effect — blocking, not advisory.
- **Witness-chain requirement**: every constitutional approval or denial is
anchored via ADR-312's shared witness contract, queryable end-to-end for
the 30-day acceptance harness's capability-table diff.
- **Distinctness from behavioral promotion**: this gate is never satisfied
merely by a mutation passing ADR-306's evaluation pipeline — the two are
independently blocking.
- **Separation-of-powers invariant** (governing invariant 7, ADR-305): the
actor that proposed a capability-expanding mutation cannot also approve
it through this gate.
- **Hosted-RVM honesty discipline** (ruvector ADR-285): if any part of this
gate's enforcement runs in a hosted (non-bare-metal) mode, isolation
claims must match what has actually been tested.
- **Standard repo gate**: `npx @claude-flow/cli@latest security scan` after
any change touching capability tables or the admission-gate integration.
## Affected Repos
- `ruvnet/autogenous` (`constitution` crate, `packages/radio-moe/src/action-gate.ts` and `mesh-evolve.ts`)
- `ruvnet/ruvector` (integration point, capability/tool tables)
- `ruvnet/rvm` (witness anchoring via ADR-312)
## Dependencies
Depends on ADR-312 (the shared witness/anchoring contract this gate's
approval records use). Distinct from, but coordinates with, ADR-306's
promotion pipeline — a mutation may need to pass both gates independently.
## Alternatives Considered
- **Fold capability-expansion approval into ADR-306's ordinary promotion
gate as one more check**: rejected — the acceptance test explicitly
requires querying capability expansion independently of general
performance-based promotion; conflating the two would make that query
impossible to answer cleanly.
- **Build a `ruvector`-native constitutional gate instead of integrating
with autogenous's**: rejected — autogenous's constitution/admission-gate
concept is already designed for exactly this purpose, and building a
parallel mechanism would repeat the same anti-pattern ADR-305 already
rejected at the program level (parallel architecture instead of adopting
existing design work).
- **Treat autogenous's Accepted-status ADRs (400/401) as sufficient
evidence of API stability, ignoring the repo-level prototype badge**:
rejected — per this program's verification pass, the badge and individual
ADR statuses are not always in agreement, and the badge is the more
conservative signal for integration planning.

84
docs/research/perpetual-intelligence-runtime/01-evidence-review.md Normal file
View file

@ -0,0 +1,84 @@
# Evidence Review — RuV Perpetual Intelligence Runtime
Status: draft for ADR seeding. Compiled 2026-08-19 by parallel web-verification research agents against the primary sources (arXiv abstracts, fetched directly). Every citation below was independently located and read; nothing is fabricated. Two of the eight claims in the original brief could not be substantiated and are marked UNVERIFIED — the program plan must not depend on those two as load-bearing evidence.
## Summary table
| # | Claim (brief's shorthand) | Found | Source | Grade | Numbers verified |
|---|---|---|---|---|---|
| 1 | SHAPER — frozen-weight embodied skill/harness evolution | Yes | arXiv:2608.11350 | A | qualitative claim confirmed |
| 2 | WorldCycle — reversible-action verification signals | Yes | arXiv:2608.04964 | A | 44% drift reduction, ~4x accuracy — exact match |
| 3 | LiveMem — fixed-capacity persistent memory state | Yes | arXiv:2608.02515 | A | qualitative claim confirmed |
| 4 | TARL — 5-op executable memory ledger | Yes | arXiv:2608.03699 | A | qualitative claim confirmed |
| 5 | Causal audit of latent multi-agent comms | Yes | arXiv:2607.26773 | A | date discrepancy (see below) |
| 6 | LATTE — anomaly quarantine for latent comms | **No** | — | **UNVERIFIED** | not found under this name |
| 7 | Cross-model KV-cache mapping (2.7–25x) | Yes | arXiv:2608.03893 | A | 2.7–25x and 2/6-pairs-degrade — exact match |
| 8 | Universal WiFi CSI "RF latent vocabulary" | **No** | — | **UNVERIFIED** | no matching paper found |
Six of eight claims are grade A with primary sources directly confirming the mechanism and, where numeric, the exact figures. Two claims (LATTE, universal CSI vocabulary) are unverified after a genuine search effort and should be treated in the program plan as **internal design targets we would be first to build**, not as citations of prior work.
---
## 1. SHAPER
- **Found**: Yes — [arXiv:2608.11350](https://arxiv.org/abs/2608.11350), "Self-Evolving Embodied Agents via Skill-Harness Evolution," submitted 2026-08-11 (matches the brief's date exactly).
- **Grade**: A.
- **Claim vs. source**: Matches closely. The abstract confirms a train-free framework that keeps model parameters frozen while evolving reusable skills and a context/code harness through target-environment rollouts; the same frozen model serves as both planner and optimizer. Evaluated on VLABench and ESI-Bench (embodied agents with varied low-level action interfaces).
- **Notes**: No name collision found; "SHAPER" appears specific to this paper.
## 2. WorldCycle
- **Found**: Yes — [arXiv:2608.04964](https://arxiv.org/abs/2608.04964), "WorldCycle: Self-Verifiable Reinforcement Learning for Long-Horizon Video World Models," submitted 2026-08-05.
- **Grade**: A.
- **Claim vs. source**: Exact match on both numbers. Abstract states verbatim: "WorldCycle reduces state returning drift by up to 44% and lifts composite-action accuracy nearly 4x over the base model." A diagnostic benchmark, CycleBench, ships alongside it. Mechanism as claimed: verification signals derived from reversible/closed action cycles (an action sequence plus its inverse should return to the initial state) used for annotation-free supervision.
- **Notes**: No collision with unrelated prior work under this name.
## 3. LiveMem
- **Found**: Yes — [arXiv:2608.02515](https://arxiv.org/abs/2608.02515), "LiveMem: Maintaining Memory State Continuity in Long-Running LLM Inference," submitted 2026-08-03 (v1, matches exactly), revised 2026-08-07 (v2).
- **Grade**: A.
- **Claim vs. source**: Matches. Confirms a fixed-capacity memory state whose lifetime is independent of the active context, maintained via a parallel memory branch (Gated DeltaNet-2 backbone) alongside a bounded KV attention window — reframing long-running inference as "computational state preservation" rather than context growth. The system can answer questions from memory state after supporting evidence has left the context window.
- **Notes — name collision flagged**: "LiveMem" also names a pre-existing, unrelated consumer iOS app ("LiveMem – Live Photo Editor"). Different domain entirely, low confusion risk, but worth a footnote disambiguating "LiveMem (arXiv:2608.02515)" from the app.
## 4. TARL
- **Found**: Yes — [arXiv:2608.03699](https://arxiv.org/abs/2608.03699), "TARL: Transaction-Aware Reliable Ledgers for Executable Memory Management in Long-Term Agents," submitted 2026-08-04 (v1, matches exactly), revised 2026-08-11 (v2).
- **Grade**: A.
- **Claim vs. source**: Matches. Each incoming statement maps to one of five executable actions (add / ignore / revise-outdated-belief / reject-unreliable / defer-for-verification), maintaining accepted, pending, and rejected ledgers — explicitly framed as reducing "memory pollution" and limiting "cumulative corruption" (i.e., addressing memory poisoning).
- **Notes — name collision flagged, cite carefully**: "TARL" is heavily overloaded in prior ML/RL/robotics literature: "Taint Analysis and Reinforcement Learning" (robot software repair, arXiv:2005.03813), "Target-Aligned Reinforcement Learning" (arXiv:2603.29501), a separate "Test-time Adapted RL" concept, and an unrelated GitHub repo `xushoukai/TARL`. None relate to agent memory ledgers. **Always spell out "TARL (Transaction-Aware Reliable Ledgers)" on first use in any ADR or doc to avoid ambiguity.**
## 5. Causal audit of latent multi-agent communication
- **Found**: Yes — [arXiv:2607.26773](https://arxiv.org/abs/2607.26773), "Do Latent Channels Actually Communicate? A Causal Audit of Latent Multi-Agent LLM Communication."
- **Grade**: A.
- **Claim vs. source**: Content matches closely; **date discrepancy** — arXiv's own submission timestamp is **2026-07-29**, not Aug 5 as stated in the brief (no Aug 5 revision was found). Correct the date to late July 2026 in any citation. Substance confirmed: end-task performance gains alone don't establish that a receiver used task-relevant information passed through the latent (KV-cache) channel; the paper introduces a controlled-replacement causal audit, tested on Qwen3-4B/8B over GSM8K, ARC-C, and MATH-500.
- **Notes**: This paper is the evidentiary basis for invariant #3 in the brief ("every agent communication is attributable") — cite it as the motivating critique, dated correctly.
## 6. LATTE — anomaly quarantine (UNVERIFIED)
- **Found**: No.
- **Grade**: UNVERIFIED.
- **Search effort**: Extensive — direct phrase search, all major combinations. Found 8+ unrelated papers using "LATTE" as an acronym (latent diffusion transformer for video, atomic environment descriptors, hyperbolic Lorentz attention for EEG, robotics trajectory transformer, quantum error-correction decoding, federated test-time adaptation, bank-transaction embeddings, linear-time attention) — none relate to multi-agent latent-communication anomaly quarantine.
- **Closest genuine match on topic**: "When Latent Agents Lie: KV-Cache Integrity in Multi-Agent LLM Collaboration" ([arXiv:2606.28958](https://arxiv.org/abs/2606.28958)), fetched and confirmed to use an HMAC-SHA256 manifest-based integrity/tamper-detection scheme (774 honest payloads accepted, 295 tampered rejected) — related in spirit but a **different mechanism** (cryptographic verification, not statistical anomaly quarantine) and does **not** use the name "LATTE" anywhere.
- **Implication for the program**: Do not cite "LATTE" as prior art. Either (a) cite arXiv:2606.28958 for the integrity-checking half of the mechanism and design the statistical-anomaly-quarantine half as net-new work, or (b) treat anomaly quarantine for latent channels as an open research contribution the program can genuinely claim as novel, tied instead to LATTE's constitutional/witness-based verification concepts already present in `ruvnet/autogenous` and `ruvnet/rvm` (see 02-asset-map.md).
## 7. Cross-model KV-cache mapping
- **Found**: Yes — [arXiv:2608.03893](https://arxiv.org/abs/2608.03893), "Cross-Model KV Cache Transfer in LLM Families: A Closed-Form Linear Mapping for Prefill Reuse," submitted 2026-08-04 16:26 UTC (matches the brief's date exactly).
- **Grade**: A — the strongest-evidence item in this review.
- **Claim vs. source**: Exact match on every figure. Abstract states the mapper runs "2.7-25x faster than re-prefill" (matches). Tests six pairs across three model families; the linear mapper "retains 73-98% of the receiver's standalone-prefill accuracy on four pairs, while two degrade sharply" (matches "2 of 6 pairs degrade badly" exactly). A nonlinear MLP variant recovers up to +37pp HellaSwag accuracy on the failing pairs — directly supports the brief's implication that migration quality must be predicted/handled before blind use.
- **Notes**: This is the fast-follow item (brief's #4, KV migration in ruvLLM) — build directly against this paper's closed-form linear mapper plus the MLP fallback for degrading pairs, and implement the "predict transfer quality before migrating" routing gate the paper itself motivates.
## 8. Universal WiFi CSI "RF latent vocabulary" (UNVERIFIED)
- **Found**: No.
- **Grade**: UNVERIFIED (best adjacent work grades C — related but not matching).
- **Search effort**: Multiple phrasings tried (direct phrase, "chipset-agnostic," "shared vocabulary"/"common backbone," "tokenize" + CSI, explicit vendor-name combinations). No paper frames CSI from Realtek/Qualcomm/Nexmon/MediaTek chipsets specifically as a shared "RF latent vocabulary" feeding one common backbone.
- **Adjacent (not matching) work found**: "A Comprehensive Survey of Wireless Foundation Models for AI-Native 6G Networks" (arXiv:2608.14694, Aug 2026 — general survey of shared representations across heterogeneous wireless data, not chipset-vocabulary-specific); "WiFo-MiSAC" (arXiv:2604.18255, Apr 2026 — tokenizes heterogeneous signals via MoE backbone, but for multimodal sensing/comms, not cross-chipset CSI specifically); "UniFi" (arXiv:2512.22143 — irregular CSI sampling across packets/bands); "CSI-JEPA" (arXiv:2605.14171 — masked-prediction CSI foundation model).
- **Implication for the program**: This item (brief's #5, universal RF intelligence) is genuinely unclaimed territory — good news for novelty, bad news for evidence backing. Treat as an internal, first-party research bet with `ruvnet/RuView` as the implementation target, cite the four adjacent surveys/papers above as prior art to build on and differentiate from, and do not present it as validated by existing literature.
## Bottom line for ADR-seeding
- Build items **1 (SHAPER-style frozen-weight harness evolution)**, **2 (WorldCycle-style reversible-action verification)**, **3 (LiveMem-style persistent state)**, **4 (TARL-style transactional memory ledger)**, **5 (causal-audit-motivated attribution)**, and **7 (KV-cache cross-model migration)** all rest on grade-A, independently verifiable primary sources. These can be cited directly in ADRs.
- Item **6 (LATTE quarantine)** has no real citation — reframe the corresponding ADR as a novel contribution informed by arXiv:2606.28958's integrity-manifest approach plus `rvm`/`autogenous`'s existing witness-chain primitives, not as "implementing LATTE."
- Item **8 (universal CSI vocabulary)** has no real citation — reframe as a first-party research bet for `RuView`, citing the adjacent wireless-foundation-model literature as motivation, not as prior art being reproduced.

103
docs/research/perpetual-intelligence-runtime/02-asset-map.md Normal file
View file

@ -0,0 +1,103 @@
# Asset Map — Mechanism → ruvnet Component
Status: draft for ADR seeding. Compiled 2026-08-19 from `gh` CLI searches of the `ruvnet` GitHub org and a local search of `/Users/cohen/GitHub/ruvnet/ruvector`. **Revised** after a second, deeper local-inventory pass (asset-scout) grounded this map in specific file paths, LOC counts, and ADR numbers, and surfaced several corrections to the first pass — those corrections are folded in below, with the original claim struck through where it was simply wrong, and flagged where the two passes disagree and a live check resolved it.
**Resolved conflict**: asset-scout's pass reported `ruvnet/autogenous` as "unfindable anywhere." A direct `gh repo view ruvnet/autogenous` run during this revision confirms the repo is real, public, and was updated today (2026-08-19) — its own README badge self-labels it **"research prototype"** status. Treat the original mapping (§9 below) as correct, with that honest status caveat now attached. This is a reminder that org-wide `gh repo list`/search passes can miss repos depending on pagination and auth scope — prefer `gh repo view <exact-name>` to confirm absence before marking something UNVERIFIED.
## Headline finding — read this before anything else in this program
**The cross-mechanism architecture this brief proposes has already been designed inside the ruvnet org, one day before this research request, under the codename "Cognitum."** `ruvnet/LatentMesh`'s [`docs/adr/009-online-causal-control-loop.md`](https://github.com/ruvnet/LatentMesh/blob/main/docs/adr/009-online-causal-control-loop.md) (dated **2026-08-18**, status "Proposed") lays out an online control loop —
```
execute → transfer latent state → counterfactual audit (ADR-003) → measure causal value
→ update edge value/authority ceiling (ADR-008) → persist (ADR-005) → change topology (ADR-006, Darwin)
→ next execution
```
— and explicitly assigns a role in that loop to **every component named in this brief**: RuFlo, MetaHarness/Darwin, RuVector, MidStream, Radio, RVF/RVM, RuView, and Autogenous. Its own honesty pass (§1) is directly relevant to invariant-setting for this program: it found that "latent agent communication," "dynamic topology," and "causal communication attribution" are now *also* claimed by prior art (StateBridge, LatentMAS, MANTA, and an "E2 Explainer" paper reported 2026-08-13 — four days before this ADR), and narrows its own novelty claim honestly rather than overselling it. That self-correcting discipline should be the model for how this program's own ADRs are written.
**Implication for the program plan**: this is not a greenfield design exercise. The correct first work package is to **formally adopt or fork LatentMesh ADR-009's loop as the spine of the Perpetual Intelligence Runtime**, then fill in the parts ADR-009 itself flags as unimplemented (see below), rather than inventing a parallel architecture. Coordinate with whoever owns `ruvnet/LatentMesh` before any ADR in this program contradicts or duplicates its numbering.
ADR-009 also states plainly what's built vs. not: *"The statistical primitive (ADR-003) and admission gate (ADR-008) are implemented; the closed loop across live components is not wired."* That is the actual gap this program should close.
---
## Mechanism-by-mechanism map
### 1. MetaHarness — **confirmed external, with a compliance bug**
- **Where**: The MetaHarness *engine* is genuinely external — **nine `@metaharness/*` npm packages pinned as dependencies inside `crates/ruvector-sota-bench/harness`**, plus a bridge at `npm/packages/ruvector/src/metaharness` and 6 MCP tools exposing it. In-repo documentation: `docs/adr/ADR-256-metaharness-sdk-evaluation.md`, `ADR-260/266/271-*darwin*metaharness*`, `docs/metaharness-implementation-plan.md`, `METAHARNESS-README.md`.
- **Status**: ADR-256 concludes MetaHarness's useful ideas (cost-optimal routing, agentic tool surface, signed releases, memory/learning loop) are *already* natively covered by `npx ruvector`'s existing primitives (Tiny Dancer cost router, semantic router, MCP server, witness chain, SONA) — decision was to borrow concepts, not take a hard runtime dependency.
- **Bug to remediate**: `METAHARNESS-README.md` claims ADR-150 `optionalDependencies` compliance, but the nine `@metaharness/*` packages in `crates/ruvector-sota-bench/harness` are **plain dependencies**, not optional — meaning the harness currently hard-fails to install without them, contradicting its own documented policy. This needs a dedicated remediation work package (see WP0b below), not just a documentation fix, since it affects install-time reliability for anyone consuming `ruvector-sota-bench`.
- **Gap**: No standing orchestration *service* for the evolution loop, benchmark scoring, and SOTA validation beyond what the external `@metaharness/*` packages already provide — ADR-265/266/267 plan a more integrated version (32 mutation surfaces, genetic algorithm, Ed25519 witness signing, 3-tier validation) but it isn't shipped as a standalone in-repo crate.
### 2. Darwin (mutation/evolution engine) — **confirmed as `@metaharness/darwin`, three real call sites**
- **Where**: Darwin is the `@metaharness/darwin` package (part of the MetaHarness external dependency set above), called from three concrete, real sites in this repo: `harness/src/darwin.ts` (ANN config evolution), `examples/mragent`'s `scorePolicy` function, and `crates/sona/src/darwin_guard.rs` (ADR-271). Also `crates/sona/examples/darwin_autotuner.rs`, `darwin_ewc.rs`. Documented in `docs/adr/ADR-259/260/266/269/271`.
- **Status**: Real evolutionary loop — profile → baseline → mutate (7 approved surfaces via `CodeGenerator`, e.g. `OpenRouterMutator`, `RuvllmMutator`) → sandbox → 6-term score → archive-as-tree → repeat. `ruvllm` is a real, wired local mutator backend (ADR-259), with a known, specifically-identified live-serve blocker: **an HTTP-307 redirect bug in the ruvllm model-download path** that blocks end-to-end live-serve testing of the mutator.
- **Gap**: Realizing Darwin as a fully first-class in-repo asset (vs. an external npm dependency called from three sites) means either formalizing the dependency properly (fixing the ADR-150 optional-dependency compliance bug above) or vendoring the loop, bound to `ruvector-proof-gate`/`ruvector-verified` and ADR-265's benchmark suite. Fixing the HTTP-307 bug is the concrete near-term unblock for live e2e testing.
### 3. RuView (RF/WiFi spatial sensing) — **corrected: local checkout exists, two in-repo consumers, ADR-178 is CLOSED**
- **Where**: **Separate active repo, locally checked out at `/Users/cohen/GitHub/ruvnet/RuView`** — WiFi CSI DensePose, ESP32 firmware, Rust port, publishes the `wifi-densepose-ruvector` package; turns commodity WiFi into real-time spatial intelligence, vital-sign monitoring, presence detection; Home Assistant/HomeKit/Google Home/Alexa integration; 21 entities per node (11 raw + 10 inferred semantic states, e.g. "possible-distress," "fall-risk-elevated"). **Two** in-repo (`ruvector`) consumers, not one: `crates/ruvector-hailo-cluster/src/bin/ruview-csi-bridge.rs` (the transport bridge) **and** `crates/ruvector-perception` (3.8K LOC spatial-perception model — **synthetic-only, not yet validated against real CSI data**). Parallel modality: `crates/ruvector-mmwave` (Seeed MR60BHA2/LD2410 radar, ADR-063).
- **Status**: `ruview-csi-bridge` is explicitly **transport-only** — parses RuView's ADR-018 UDP CSI frames and posts a header-summary string into the Hailo embed RPC; the source comment explicitly disclaims doing pose embedding. `ruvector-perception` is a real, substantial (3.8K LOC) perception model, but it has only ever been trained/tested on synthetic data, never real CSI captures. **`docs/adr/ADR-178` (the ruvector↔RuView gap analysis) is CLOSED**, not open — its two still-open long-form gaps are explicitly tracked for future ADRs: **gap C** (CSI bridge I/Q → pose-semantics conversion) and **gap D** (an mcp-brain-server-side cluster consumer for RuView data).
- **Gap**: Gaps C and D from the now-closed ADR-178 are the concrete, already-scoped-by-the-org unblockers for real pose-semantic embedding — a pose-specific HEF (Hailo Model Zoo currently lacks one for the target chips), a generalized `HailoPipeline<I,O>`, host-side I/Q preprocessing, and validating `ruvector-perception` against real (not synthetic) CSI. This is the component with the largest gap between "named in the brief" and "exists validated today," and is exactly where both the pose-embedding fast-follow and the universal-CSI-vocabulary bet (evidence item #8, UNVERIFIED) should land — **pick up ADR-178's gaps C and D directly rather than re-scoping from zero.**
### 4. Dream Machine (evaluation/simulation before promotion) — **corrected: real statistical promotion machinery already exists under a different name**
- **Where**: No asset is literally named "Dream Machine." The first pass of this map pointed at SONA's dream-replay engine as the closest analogue — a deeper inventory pass found the actual functional equivalent instead: **`scripts/research-gate/`** plus **`.github/workflows/research-*.yml`** (the CI-level gate), documented in **`docs/adr/ADR-282`**, backed by real statistical promotion machinery in **`crates/ruvector-sota-bench/harness`**: `statistics.ts` (paired bootstrap significance testing), `vetoes.ts` (hard-veto conditions that block promotion regardless of the statistical result), and `flywheel.ts` (Ed25519-signed replay bundles for reproducible re-verification).
- **Status**: This is materially better news than the first pass indicated — a real, CI-wired, cryptographically-signed statistical-promotion gate already exists (paired bootstrap + vetoes + signed replay bundles), it's just not named "Dream Machine" and it isn't yet connected to Darwin's mutation loop or SONA's dream-replay engine.
- **Gap**: The program should **build on and formally adopt `research-gate` + `ruvector-sota-bench/harness` as the Dream Machine equivalent** (renaming/reframing rather than inventing a parallel system), and wire it as the evaluation stage between Darwin's mutation proposals and RVM's proof-gated promotion. SONA's dream-replay engine (`05-MEMORY-DREAMS.md`) remains a candidate *pre-filter* to feed into this gate, not a replacement for it. This significantly de-risks the program plan's biggest previously-identified gap — see the revised risk assessment in `03-program-plan.md`.
### 5. RuVector (vector memory / HNSW substrate)
- **Where**: `crates/ruvector-core` plus the full `ruvector-*` family (140+ crates — diskann, rabitq, mincut, graph, attention, etc.), `npm/packages/ruvector`.
- **Status**: Mature, in production. No gap — this is the most fully realized mechanism in the brief and should be treated as the stable foundation everything else is built on, not as work to be scoped.
### 6. RVF (cognitive containers / session recording format)
- **Where**: `crates/rvf` nested workspace (`rvf-types`, `rvf-wire`, `rvf-manifest`, `rvf-index`, `rvf-quant`, `rvf-crypto`, `rvf-runtime`, `rvf-kernel`, `rvf-wasm`, `rvf-node`, `rvf-server`, `rvf-adapters/{claude-flow,agentdb,ospipe,agentic-flow}`), `npm/packages/rvf` (`@ruvector/rvf`), `crates/ruvector-cognitive-container` ("Verifiable WASM cognitive container with canonical witness chains"). Canonical spec: `docs/adr/ADR-029-rvf-canonical-format.md`.
- **Status**: Confirmed mature per both research passes. ADR-029 makes RVF the intended single canonical binary format across all RuVector libraries (replacing fragmented REDB/bincode/JSON formats in ruvector-core, agentdb, claude-flow, agentic-flow, ospipe, rvlite, sona) — append-only crash-safe segments, progressive indexing, temperature-tiered quantization, WASM microkernel, post-quantum ML-DSA-65 signatures.
- **Gap**: Cross-library adapter adoption (agentic-flow, ospipe) is only partially built per ADR-029's own scope.
### 6b. Memory (opportunity #2 host components — added detail from second-pass inventory)
- **Where**: `crates/ruvector-agent-memory` (ADR-252), `ruvllm`'s `context/` modules (`working_memory`, `episodic_memory`, `semantic_cache`, `agentic_memory`), `reasoning_bank` (trajectory tracking / verdict judgment / distillation / consolidation), `crates/ruvector-temporal-coherence` (ADR-211). **`agentdb` itself is an external product — only an RVF adapter crate (`rvf-adapters/agentdb`) lives in-repo.**
- **Status — important correction**: the three-level memory architecture proposed in the program plan (working context → continuous latent state → transactional RuVector memory) already has concrete homes: working context maps to `ruvllm`'s `working_memory` module, continuous latent state maps to `episodic_memory`/`semantic_cache`/`agentic_memory`, and transactional RuVector memory maps to `ruvector-agent-memory` + `reasoning_bank` + `ruvector-temporal-coherence`. **Proof-gated writes for this memory already exist** — `docs/adr/ADR-194` and `ADR-047` — meaning the "sign every memory transition via RVM witness records" requirement in the original program plan is largely already built, not net-new. This meaningfully reduces the scope of program-plan work package WP3/WP4 (see `03-program-plan.md`).
### 7. RVM (signatures / governance / witness-chain / provenance)
- **Where**: **Separate repo `ruvnet/rvm`** ("coherence-native microhypervisor for edge computing and multi-agent systems"), vendored inside `ruvector` at `crates/rvm/` with sub-crates `rvm-witness`, `rvm-proof`, `rvm-cap`, `rvm-security`, `rvm-checkpoint`, `rvm-coherence`, `rvm-kernel`, `rvm-boot`, `rvm-hal`, `rvm-partition`, `rvm-sched`, `rvm-memory`, `rvm-types`, `rvm-wasm`. Key ADRs: `ADR-134-witness-schema-log-format.md`, `ADR-285-hosted-rvm-security-boundary.md`, `ADR-293-rvm-installer-appliance-formats.md`.
- **Status**: Every privileged action emits a mandatory 64-byte cache-line-aligned witness record, hash-chained (FNV-1a, optionally Ed25519/TEE-signed) for tamper evidence and deterministic replay (ADR-134). `rvm-proof` implements proof-gated state transitions (ADR-135) using `rvm-witness` + `rvm-cap` capability tables. ADR-285 explicitly forbids hosted (desktop-process) RVM from claiming bare-metal isolation strength — a governance-honesty discipline worth carrying into this program's own claims.
- **Correction to the brief**: the brief's description of "ADR-103" ("cryptographically-signed fix manifest with temporal history") does **not** match `ruvector`'s actual ADR-103 (DeepAgents review amendments, unrelated). That description matches the `ruflo-core:witness` MCP tool instead, which is claude-flow/Ruflo-side tooling with its own ADR-103 in a different repo. **Verify which repo's ADR-103 is meant before citing it in any new ADR.**
- **Gap**: RVM's hypervisor/witness core is substantially built. Net-new is wiring RVM's witness chain as the authoritative provenance layer for *program-level* governance decisions (mutation promotion, memory-ledger transitions) rather than just VM/partition-level privileged actions.
### 8. LatentMesh (P2P latent/neural communication transport) — **corrected: greenfield inside `ruvector`, design-stage externally**
- **Where — two distinct facts, not one**: (a) The **external repo `ruvnet/LatentMesh`** is real and design-stage (last updated 2026-08-19) — "training-free orthogonal alignment of hidden states as a network primitive," with crates `latentmesh-core` (wire vocabulary, `LatentFrame`, F32/F16/Int8 encoding), `latentmesh-align` (training-free orthogonal Procrustes/SVD alignment), `latentmesh-gate` (capability-governed latent execution + causal-edge verification), `latentmesh-bench`, and ADRs 001–009 (architecture/prior-art through the online causal control loop, see headline finding above). (b) **Inside the local `ruvector` repo, there is no wiring to it at all** — the only trace is an unmerged branch, `origin/docs/link-latentmesh`. It is not cloned locally and not integrated with RuVector today.
- **Status**: Externally, core packet codecs and alignment math are implemented and tested per the LatentMesh repo's own ADRs; network transport, RVF packaging, and RVM enforcement wiring are explicitly marked "not implemented" there too, and ADR-003's causal-edge verification machinery has never been run against a live multi-agent task (per LatentMesh ADR-009). Internally to `ruvector`, this is a from-scratch build, not an integration.
- **Gap / recommendation**: Plan the `ruvector`-side work as **new crates**, not as "wiring an existing integration" — asset-scout's suggestion is to house them under `crates/rvAgent/` (near the existing `rvagent-a2a`, ADR-159) or as a new `latentmesh` crate family, and treat cross-repo alignment with the actual `ruvnet/LatentMesh` design as an explicit coordination task (WP1/WP5 in the program plan), not an assumption.
### 9. Autogenous (autonomous agent communication/governance layer) — **existence confirmed live, status is self-declared "research prototype"**
- **Where**: **Separate active repo `ruvnet/autogenous`** (updated 2026-08-19) — "Governed Evolutionary Software... turns runtime failures into verified, portable, reversible software adaptations." Crates: `witness` (independently reconstructible/verifiable crypto plane, echoing RVM's design), `antibody` (Autogenous Antibody Package, unit of defense), `agl-types` (Autogenous Genome Language — typed mutations), `generator`, `evaluator`, `verifier` (admission gate), `lineage` (provenance), `ledger` (durable recovery), `promotion` (rollout controller), `deployment`, `constitution` (governance plane), `runtime`, `midstream-adapter`, `service` (Cloud Run HTTP control plane). ADRs 391/392/393/397.
- **Verification note**: a second-pass inventory reported this repo as "unfindable anywhere." A direct `gh repo view ruvnet/autogenous` re-check during this revision confirms it exists, is public, and its own README carries a **"research prototype"** status badge — meaning it's real but the org's own maintainers don't consider it production-grade yet. Nearest `ruvector`-local analogues (useful for comparison, not substitutes) are `crates/rvAgent/rvagent-subagents` (ADR-097/275) and `rvagent-a2a` (ADR-159).
- **Status**: The most governance-complete of the twelve mechanisms on paper — observe → explain → mutate → prove → canary → promote/rollback, with typed mutation genome, signed antibody packages, constitutional gating — but self-labeled research-prototype maturity, so treat its APIs as unstable.
- **Gap**: Cross-repo wiring with RuVector/ruvLLM/RVM isn't evidenced yet. **Duplication note**: `rvm` and `autogenous` both independently define a `witness` crate with near-identical framing — a real convergence point worth resolving in this program rather than maintaining two implementations.
### 10. ruvLLM (LLM gateway / cross-model routing)
- **Where**: `crates/ruvllm`, `ruvllm-cli`, `ruvllm-wasm`, `ruvllm_sparse_attention`, `ruvllm_retrieval_diffusion`; `npm/packages/ruvllm` (+ platform variants); `docs/ruvllm/`; ADRs 002, 074, 084, 165, 173, 179–181, 258–259.
- **Status**: "LLM serving runtime with Ruvector integration — paged attention, KV cache, SONA learning," built on `ruvector-core`/`ruvector-sona`. ADR-180 covers continuous-batching serving; ADR-181 BitNet quantization; ADR-173/179 Hailo/Pi edge deployment. Already Darwin Mode's local mutator backend (ADR-259).
- **Gap**: Cross-*provider* routing (Anthropic/OpenAI/local, not just local-inference serving) isn't centered here — that role sits closer to claude-flow's ADR-026 3-tier routing. Fast-follow item #4 (KV-cache cross-model migration, evidence-graded A above) is the concrete net-new work: implement arXiv:2608.03893's closed-form linear mapper plus MLP fallback for degrading pairs, as a `ruvllm` capability.
### 11. Ruflo / claude-flow (orchestration CLI/MCP)
- **Where**: `@claude-flow/cli`, deeply integrated per repo-root `CLAUDE.md` — swarm/hive-mind/hooks/memory subsystems, 26 CLI commands, 27 hooks, 12 background workers, exposed in-session as `ruflo-*` MCP tool namespaces. `rvf-adapters/claude-flow` is already scaffolded per ADR-029.
- **Status**: The most operationally mature asset in the list — swarm orchestration, agentdb-backed memory, hive-mind consensus, ADR management, security auditing, cost tracking. This is the coordination layer the whole program plan sits on top of.
- **Gap**: None to establish existence. Relevant integration gap: the RVF adapter for claude-flow is scaffolded but not confirmed fully adopted end-to-end (ADR-029).
### 12. agentdb (memory/vector database layer)
- **Where**: `crates/rvf/rvf-adapters/agentdb`, `crates/ruvector-temporal-tensor/src/agentdb.rs`, runtime state at `.swarm/agentdb-memory.db*`, `agentdb.rvf`/`.lock` at repo root and in `npm/packages/ruvllm/`, extensive `agentdb-*`/`ruflo-agentdb` MCP tool namespaces.
- **Status**: "AI agent memory with HNSW indexing" (ADR-029), invoked via `npx agentdb`, underpins claude-flow's memory subsystem.
- **Gap**: Full migration onto RVF as canonical format (ADR-029) — adapter crate exists, full fragmentation-to-unification not confirmed complete.
---
## Cross-cutting notes for the program plan
1. **LatentMesh, Autogenous, and RuView are sibling `ruvnet` repos, not subdirectories of `ruvector`.** RuView has a local checkout (`/Users/cohen/GitHub/ruvnet/RuView`) and two real in-repo consumers; LatentMesh and Autogenous have no local wiring at all — the program plan's work packages must span repos, and the `ruvector`-side LatentMesh/Autogenous work should be planned as new construction, not integration.
2. **LatentMesh ADR-009 already names the exact cross-mechanism loop this program wants to build**, including an explicit role for every component in the brief. Treat it as the architecture to extend, and open a coordination thread with the LatentMesh maintainers before this program's ADRs assign conflicting numbers or contradict its design.
3. **RVM and Autogenous both independently built a `witness` crate** with near-identical framing (cryptographic, independently-reconstructible provenance chain). This is a real duplication the program should resolve — likely by having Autogenous's `witness` crate depend on or converge with `rvm-witness` rather than maintaining two implementations, given RVM's is the more hypervisor-integrated of the two, and given Autogenous is self-labeled "research prototype."
4. **ADR-103 numbering is ambiguous across repos** — the brief's description matches claude-flow/Ruflo's ADR-103 (via the `ruflo-core:witness` tool), not `ruvector`'s own ADR-103. Any new ADR that cites "ADR-103" for witness/fix-manifest behavior must specify which repo. This is one instance of a broader problem — see point 6.
5. **Biggest real gaps, ranked by how much they block the acceptance test**: (a) RuView pose-semantic embedding validated against real (not synthetic) CSI — `ruvector-perception` is 3.8K LOC but synthetic-only; ADR-178 gaps C and D are the scoped path forward; (b) LatentMesh's actual construction inside `ruvector` — currently zero wiring, an unmerged branch stub only; (c) universal CSI vocabulary — no prior art exists anywhere, ruvnet or otherwise, so this is a first-party bet, not an integration task. **Dream Machine is no longer the top gap** — `scripts/research-gate/` + `crates/ruvector-sota-bench/harness` (paired-bootstrap statistics, hard vetoes, Ed25519-signed replay bundles) already provides real, CI-wired promotion machinery; the work is adopting/renaming/wiring it to Darwin, not building it from nothing.
6. **ADR numbering hygiene is a real, quantified problem.** `docs/adr/` contains **283 ADR files** with a **true maximum of ADR-304** (not ADR-118, which is stale — likely from an older CLAUDE.md snapshot). Numbers are **not unique**: ADR-272 appears **5 times**, ADR-264/252/194/144/040 each appear **3 times**, and roughly a dozen more numbers (268, 266, 260, 258, 256, 254, 143, 139, 138, 137, 136, 135, 134, 133, …) appear **twice**. Any new ADR from this program must claim a number **above 304**, and the collision problem itself should be a tracked hygiene work package (see program plan) rather than something new ADRs quietly work around.
7. **GCP surface is concrete, not hypothetical**: `crates/mcp-brain-server` deploys to Cloud Run as `ruvbrain`, in project **`ruv-dev`**, region **us-central1**, with real `cloudbuild` files and deploy scripts already checked in; the npm client is `@ruvector/pi-brain`. New Cloud Run services proposed in the program plan should follow this exact pattern and, where reasonable, live in the same `ruv-dev` project for shared secrets/networking rather than provisioning a new project.

297
docs/research/perpetual-intelligence-runtime/03-program-plan.md Normal file
View file

@ -0,0 +1,297 @@
# Program Plan — RuV Perpetual Intelligence Runtime
Status: draft for ADR seeding, swarm work-package assignment, and GitHub issue filing. Compiled 2026-08-19, revised same day after a second, deeper asset-inventory pass (asset-scout) grounded several sections in verified file paths, LOC counts, and ADR numbers — see `02-asset-map.md`'s corrections. Depends on `01-evidence-review.md` (evidence grades) and `02-asset-map.md` (component map). Read the asset map's headline finding first: this program extends `ruvnet/LatentMesh` ADR-009's "online causal control loop" (2026-08-18) rather than designing from scratch.
**Revision note**: the second inventory pass materially changed two things worth knowing before reading the rest of this plan. First, "Dream Machine" is *not* a from-scratch build — real, CI-wired, cryptographically-signed statistical promotion machinery already exists (`scripts/research-gate/`, `crates/ruvector-sota-bench/harness`, ADR-282) and should be adopted/renamed, not reinvented; this meaningfully de-risks what was previously flagged as the top program risk. Second, ADR numbering in this repo is not the "ADR-001 through ADR-118" stated in the root `CLAUDE.md` — the true count is 283 files with duplicated numbers up to ADR-304 (see asset map §6 of the cross-cutting notes) — every new ADR in this program must be numbered above 304.
## Governing invariants
Invariants 1–6 are carried from the brief, unchanged. Invariant 7 was added
during ADR authoring (PR #847, ADR-305), adopted from ruflo ADR-322B's
proposer/promotion separation-of-powers rule — see ADR-305 for the source
citation.
1. Every observation may change memory.
2. Every memory change is transactional.
3. Every agent communication is attributable.
4. Every behavioral mutation is tested.
5. Every promoted mutation must outperform its parent.
6. Every physical action produces new evidence.
7. A proposer produces untrusted candidates only; it cannot issue promotion
decisions or mutate active policy (adopted from ruflo ADR-322B, binding
on ADR-306, ADR-313, ADR-315).
Risk control: Darwin proposes, RVM gates what can change, Dream Machine requires statistically credible improvement before promotion.
## Scope decision
Build **1 + 2 + 3** (self-evolving physical intelligence, persistent transactional memory, verified latent communication) as the combined "Perpetual Intelligence Runtime" branch. Fast-follow with **4** (KV-cache cross-model migration in ruvLLM — grade-A evidence, cheapest to ship). Treat **5** (universal RF/CSI vocabulary) as a stretch research bet inside `RuView` with no external prior art to lean on (see evidence review item 8) — sequence it last and fund it separately if 1–4 land on schedule.
---
## Bounded contexts (DDD)
| Context | Owns | Primary repo(s) |
|---|---|---|
| **Physical Skill Evolution** | Skill/harness genome, mutation surfaces, rollout execution | `agent-harness-generator` (Darwin core), `ruvector` (`crates/sona`, `crates/ruvllm` mutator backend) |
| **World Verification** | Reversible-action verification, dream-replay pre-filter, promotion scoring | `ruvector` (`crates/ruvector-nervous-system`, SONA dream engine, `ruvector-proof-gate`) |
| **Persistent Memory Governance** | Three-level memory (working context → continuous latent state → transactional RuVector memory), TARL-style ledger, RVF/RVM provenance | `ruvector` (`crates/rvf`, `crates/rvm`, `ruvector-core`), `agentdb` |
| **Latent Communication Fabric** | Latent transport, causal-edge verification, quarantine, capability-governed execution | `ruvnet/LatentMesh` (primary), `ruvnet/rvm` (`rvm-witness`, `rvm-cap`) |
| **Cross-Model Cognition Migration** *(fast-follow)* | KV-cache mapping, transfer-quality prediction, routing gate | `ruvector` (`crates/ruvllm`) |
| **RF Sensing Substrate** *(stretch)* | Hardware-independent CSI representation, pose-semantic embedding | `ruvnet/RuView`, `ruvector` (`crates/ruvector-hailo-cluster`) |
| **Governance & Constitution** *(cross-cutting)* | Admission gates, capability ceilings, rollback, cross-repo witness convergence | `ruvnet/autogenous`, `ruvnet/rvm` |
---
## ADR list
Numbers are placeholders — assign real numbers **above ADR-304** via `ruflo-adr:adr-create` at kickoff (the repo's true max, not the stale "ADR-118" in root `CLAUDE.md` — see asset map §6), and confirm against both `ruvector`'s and `LatentMesh`'s ADR sequences before merging (see asset map note on ADR-103 ambiguity). ADR-create should also register each new ADR in `ruflo-adr:adr-index` immediately to avoid adding to the duplicate-number problem it's meant to fix.
**This list has eleven ADRs (1–11 below); the two work packages below numbered
WP0a and WP0b are process/bug-fix work with no corresponding ADR** — they
were mistakenly written as "ADR — …" entries in an earlier draft of this
plan, which claimed thirteen ADRs against the eleven PR #847 actually
shipped (ADR-305 through ADR-315). Reworded here as work-package-only items
so this plan and the shipped ADR set agree:
- **WP0a — ADR numbering hygiene remediation** (no ADR). Audit + fix pass
over `docs/adr/` to resolve the ~15+ duplicate ADR numbers found (ADR-272
×5, ADR-264/252/194/144/040 ×3 each, ~12 more ×2), by renumbering the
later-created duplicate in each collision to the next free number above
304 and updating all in-repo references to match. Process hygiene,
tracked as a separate issue, not a PIR ADR.
1. **ADR — Adopt LatentMesh ADR-009 as the Perpetual Intelligence Runtime's control-loop spine.** Decision: rather than defining a new cross-mechanism architecture, this program formally adopts the `execute → transfer → causal audit → measure → update authority → persist → evolve topology` loop from LatentMesh ADR-009, and commits to closing the specific gap that ADR names ("statistical primitive and admission gate implemented; closed loop across live components not wired"). Coordination channel opened with LatentMesh maintainers before any conflicting ADR numbers are assigned.
2. **ADR — Adopt `research-gate`/`ruvector-sota-bench` as the Dream Machine equivalent, and wire it to Darwin.** Decision: rather than building a new evaluation service, formally adopt the existing `scripts/research-gate/` + `.github/workflows/research-*.yml` + `crates/ruvector-sota-bench/harness` (paired-bootstrap `statistics.ts`, hard-veto `vetoes.ts`, Ed25519-signed `flywheel.ts` replay bundles), documented in ADR-282, as the Dream Machine role in this program. The concrete work is wiring it as the mandatory evaluation stage between Darwin's mutation proposals and RVM's proof-gated promotion — optionally with SONA's dream-replay engine (`05-MEMORY-DREAMS.md`) as a pre-filter feeding candidates into it — not writing a parallel system. This significantly reduces the risk previously flagged as the program's biggest gap.
3. **ADR — Three-level persistent memory architecture (LiveMem + TARL pattern) on RuVector's existing memory stack.** Decision: implement working-context / continuous-latent-state / transactional-RuVector-memory as three explicit tiers mapped onto components that mostly already exist: working context → `ruvllm`'s `working_memory` module; continuous latent state → `episodic_memory`/`semantic_cache`/`agentic_memory` (following LiveMem's fixed-capacity recurrent-state design, arXiv:2608.02515); transactional memory → `ruvector-agent-memory` (ADR-252) + `reasoning_bank` + `ruvector-temporal-coherence` (ADR-211), extended with TARL's five-operation ledger (add/ignore/revise/reject/defer, arXiv:2608.03699). Proof-gated writes for this tier **already exist** (ADR-194, ADR-047) — the net-new work is the TARL-style ledger states and operation semantics layered on top of the existing proof-gate, not the gate itself.
4. **ADR — WorldCycle-style verification for the physical action loop.** Decision: adopt reversible-action-sequence verification (arXiv:2608.04964) as the WorldCycle-verification stage between "observe consequences" and "Dream Machine evaluation" in the physical loop, targeting the paper's reported 44% long-horizon drift reduction and ~4x composite-action accuracy as the acceptance bar for Phase 3's world-model component.
5. **ADR — Build LatentMesh integration inside `ruvector` as new crates, coordinated with the external design.** Decision: since `ruvector` has zero existing wiring to `ruvnet/LatentMesh` today (only an unmerged `origin/docs/link-latentmesh` branch stub), build the `ruvector`-side integration as new crates under `crates/rvAgent/` (alongside the existing `rvagent-a2a`, ADR-159) or a new `latentmesh` crate family — not as "finishing an integration" that doesn't yet exist. Implement the network transport, RVF packaging (model identity, transform, permitted recipients, provenance, witness history as artifact metadata per LatentMesh ADR-008), and RVM `rvm-cap` admission enforcement that LatentMesh's own ADRs mark as "not implemented" externally too. This requires an explicit coordination channel with the `ruvnet/LatentMesh` maintainers so the two sides converge on the same wire format rather than diverging.
6. **ADR — Causal-attribution gate for latent communication.** Decision: every latent-channel deployment must pass a controlled-replacement causal audit modeled on arXiv:2607.26773 before its performance claims can be used to justify further rollout — this becomes a required CI gate on any change touching `latentmesh-align` or downstream consumers, not just a one-time paper reproduction.
7. **ADR — Anomaly quarantine for latent channels (net-new, not "LATTE").** Decision: since no verified prior art named "LATTE" exists (evidence review item 6, UNVERIFIED), build quarantine as a first-party contribution combining arXiv:2606.28958's HMAC-manifest integrity check with `rvm-witness`/`autogenous witness` provenance chains — explicitly documented as original work, not an implementation of a paper that doesn't exist under that name.
8. **ADR — Resolve the RVM/Autogenous witness-crate duplication.** Decision: `rvm-witness` becomes the canonical witness-chain implementation; `autogenous`'s `witness` crate is refactored to depend on it rather than maintaining a parallel cryptographic-provenance implementation. Both repos' maintainers must sign off before this lands.
9. **ADR — SHAPER-pattern skill/harness evolution loop (frozen weights).** Decision: implement the physical-intelligence evolution loop with foundation-model weights frozen throughout, following arXiv:2608.11350's pattern — the same frozen model serves as planner and optimizer, evolving only skills, context, and the execution harness (mapped to Darwin's mutation surfaces), never the weights themselves. This is the acceptance test's central frozen-weights constraint and must be enforced structurally (no fine-tuning code path reachable from the promotion pipeline), not just by policy.
10. **ADR — KV-cache cross-model migration in ruvLLM (fast-follow).** Decision: implement arXiv:2608.03893's closed-form linear KV-cache mapper for same-family model migration, with the nonlinear MLP fallback for the pairs it identifies as degrading, plus a routing gate that predicts transfer quality before migrating (never migrate blind). Ships independently of the Phase 1–3 branch since it depends only on `ruvllm`.
11. **ADR — Governance constitution for capability expansion.** Decision: adopt `autogenous`'s constitution/admission-gate pattern as the enforcement point for "zero unapproved capability expansion" (acceptance-test requirement); every mutation that would expand an agent's capability set (new tool access, new physical action class, new communication peer) requires explicit constitutional approval logged to the witness chain, distinct from ordinary behavioral mutation promotion. Note `autogenous`'s own README self-labels it "research prototype" status — treat its APIs as unstable and budget time for API churn, don't assume production-grade stability.
- **WP0b — MetaHarness dependency-compliance remediation** (no ADR). Fix the
confirmed bug where `crates/ruvector-sota-bench/harness`'s nine
`@metaharness/*` npm dependencies are declared as plain (hard)
dependencies while `METAHARNESS-README.md` claims `optionalDependencies`
compliance, attributed there to "**ADR-150**: MetaHarness Integration
Surfaces (**upstream**)." Neither `ruvector`'s own ADR-150
(`pi-brain-ruvltra-tailscale`) nor `metaharness`'s own ADR-150
(`tailscale-local-frontier-concurrent-benchmarks`) is the right document
— both unrelated. **The upstream document is `ruflo` ADR-150**
(`v3/docs/adr/ADR-150-metaharness-integration-surfaces.md`, "MetaHarness
Integration Surfaces in `npx ruflo`," Status **Implemented**, 2026-06-16),
whose rule 2 is verbatim the policy: *"`@metaharness/*` packages MUST
appear in `optionalDependencies` or `peerDependencies` (optional), never
in `dependencies`."* Fix the bug directly against that source — make the
nine packages genuinely optional per ruflo ADR-150 rule 2, or correct the
documentation to state the real (hard-dependency) install requirement —
and adopt rule 4 (a CI job on the `--ignore-optional` install path,
"the only structural defense against accidentally promoting an optional
dep to required") as the acceptance criterion, stronger than a plain
successful `npm install`. **The previously-tracked HTTP-307 redirect bug in
`ruvllm`'s model-download path is already fixed on `main`** (commit
`946275a61`, PR #590, 2026-06-18); it is not part of this work package.
Verifying that fix surfaced the actual remaining download blocker: a GGUF
glob/alias bug in `ruvllm-cli`'s `get_files_to_download()`
(`download.rs:193`'s glob pattern, `models.rs:65`'s alias resolution),
which this work package tracks and fixes instead.
---
## Work packages (sized for 6–8 agent swarm teams, per project anti-drift config)
| # | Package | Bounded context | Team composition | Depends on |
|---|---|---|---|---|
| WP0a | ADR numbering hygiene remediation | Governance | coordinator, adr-architect | — |
| WP0b | MetaHarness dependency-compliance + ruvllm-cli GGUF glob/alias fix | Physical Skill Evolution | coordinator, backend-dev, tester | — |
| WP1 | LatentMesh coordination & ADR alignment | Governance | coordinator, adr-architect, system-architect | WP0a |
| WP2 | Adopt research-gate/sota-bench as Dream Machine; wire to Darwin | World Verification | coordinator, system-architect, coder ×2, tester | WP1 |
| WP3 | Three-level memory tiers on RuVector (LiveMem + TARL ledger on top of existing proof-gated writes) | Persistent Memory Governance | coordinator, backend-dev, memory-specialist, tester | WP1 |
| WP4 | TARL ledger states wired into existing ADR-194/047 proof-gate | Persistent Memory Governance | coordinator, security-architect, coder | WP3 |
| WP5 | LatentMesh `ruvector`-side crates (new, under `crates/rvAgent/`) + cross-repo wire-format coordination | Latent Communication Fabric | coordinator, system-architect (cross-repo), coder ×2, tester | WP1, WP4 |
| WP6 | Causal-audit CI gate | Latent Communication Fabric | coordinator, security-auditor, tester | WP5 |
| WP7 | Anomaly quarantine (net-new — no "LATTE" prior art exists) | Latent Communication Fabric | coordinator, security-architect, coder, tester | WP5, WP6 |
| WP8 | Witness-crate convergence (rvm ↔ autogenous) | Governance & Constitution | coordinator, system-architect (cross-repo), coder | WP1 |
| WP9 | SHAPER-pattern skill/harness evolution loop (Darwin via `@metaharness/darwin`) | Physical Skill Evolution | coordinator, system-architect, coder ×2, tester, reviewer | WP0b, WP2 |
| WP10 | WorldCycle verification stage | World Verification | coordinator, coder, tester | WP9 |
| WP11 | Constitutional capability-expansion gate (autogenous, research-prototype status) | Governance & Constitution | coordinator, security-architect, coder | WP8 |
| WP12 | 30-day acceptance harness | Cross-cutting | coordinator, performance-engineer, tester, observability-engineer | WP2, WP4, WP9, WP10, WP11 |
| WP13 *(fast-follow)* | ruvLLM KV-cache cross-model migration (crates/ruvllm: kv_cache.rs, paged_attention.rs, serving/kv_cache_manager.rs) | Cross-Model Cognition Migration | coordinator, coder ×2, tester | none — parallel track |
| WP14 *(stretch)* | RuView pose-semantic embedding + universal CSI vocabulary (pick up ADR-178 gaps C & D) | RF Sensing Substrate | coordinator, ml-developer, coder, tester | independent — fund separately |
Use `hierarchical` topology, `max-agents 8`, `specialized` strategy per project config for each work package; spawn WP1–WP11 teams as concurrent swarms once WP1 clears (they gate on each other per the dependency column, not on serial scheduling).
---
## Security / validation gates
- **Structural frozen-weights enforcement (WP9)**: the promotion pipeline must have no code path that can write to foundation-model weight files — verified by a CI check that fails the build if any mutation surface imports a training/fine-tuning API.
- **Witness-chain requirement**: every state transition in Persistent Memory Governance, Latent Communication Fabric, and Governance & Constitution contexts must emit an RVM witness record (ADR-134 schema) before it's considered committed. No RVF write without a corresponding witness entry.
- **Proof-gated promotion**: `ruvector-proof-gate`/`rvm-proof` must approve every mutation promotion; Dream Machine's verdict is an input to the proof gate, not a bypass of it.
- **Causal-audit CI gate (WP6)**: any PR touching `latentmesh-align`, the quarantine module, or downstream consumers must pass a controlled-replacement causal audit before merge — modeled on arXiv:2607.26773's methodology, run against the same benchmark families (GSM8K/ARC-C/MATH-500-equivalent internal tasks).
- **Constitutional admission gate (WP11)**: capability-expanding mutations (new tools, new physical action classes, new communication peers) require a separate, higher-bar approval than ordinary behavioral mutations, logged distinctly in the witness chain so the acceptance test can query "zero unapproved capability expansion" directly.
- **Hosted-RVM honesty discipline**: per RVM's own ADR-285, any Cloud Run–hosted component of this program must not claim bare-metal isolation strength it doesn't have — carry that same claims-honesty discipline into this program's own status reporting.
- **Standard repo gates**: `npx @claude-flow/cli@latest security scan` after any change touching auth, capability tables, or witness signing, per repo-root `CLAUDE.md`.
---
## GCP deployment / publishing surface
- **Dream Machine control plane**: new Cloud Run service in project **`ruv-dev`**, region `us-central1` (mirror `mcp-brain-server`'s deployment as `ruvbrain` — same project, same region, session-affinity pattern, reuse its `cloudbuild` files as a template), fronting WP2's adopted research-gate/sota-bench evaluation service; secrets pulled from the existing Secret Manager entries (`ANTHROPIC_API_KEY`, `GOOGLE_AI_API_KEY`, etc.) rather than new ones where possible.
- **LatentMesh transport gateway**: if network transport (WP5) needs a rendezvous/relay point beyond direct P2P, host it as a second Cloud Run service, session-affinity enabled, in the same region for latency parity with the memory/brain services it talks to.
- **Cloud Scheduler jobs**: extend the existing 7-job pattern (train, drift, transfer, graph, attractor, cleanup, full) with new jobs for: nightly causal-audit re-runs (WP6), witness-chain integrity verification sweeps (WP8), and 30-day acceptance-harness daily checkpoint aggregation (WP12).
- **npm packages** (`@ruvector` scope): `@ruvector/dream-machine` (WP2), `@ruvector/latent-quarantine` (WP7), `@ruvector/kv-migrate` (WP13) — each following the existing `@ruvector/*` publish flow (see the user's own remembered npm release procedure: worktree flow, `--force --ignore-scripts` install, no-OTP publish, main-vs-registry drift check).
- **Crates**: new crates land under `crates/` in `ruvector` for anything not owned by a sibling repo (e.g., `ruvector-dream-machine`, `ruvector-worldcycle-verify`); cross-repo crates (`latentmesh-*`, `rvm-*`, `autogenous-*`) are published from their own repos per their existing release process.
- **Cross-repo coordination**: since LatentMesh, RVM, RuView, and Autogenous are sibling repos, this program needs a lightweight release-train coordination doc (owned by WP1) tracking version compatibility across the five repos involved — do not let `ruvector` pin to unreleased commits of the others without an explicit compatibility ADR.
---
## 30-day acceptance test harness design
**Precondition**: foundation model weights frozen and hash-verified at day 0; the structural enforcement from WP9's gate confirms no write path exists to weight files for the duration of the run.
**Daily cycle** (automated, via WP12):
1. Run the full physical/latent/memory loop for a fixed batch of tasks (held-out task set, not seen during any prior day's mutation testing, to prevent overfitting to the eval set itself).
2. Log per-task: latency, task success (binary + graded where applicable), sensing accuracy (RuView/mmWave ground-truth comparison where available), token/compute cost.
3. Any proposed mutation that day goes through: Darwin propose → Dream Machine evaluate (dream-replay pre-filter + sandbox score) → proof-gate check → constitutional gate (if capability-expanding) → promote or reject, each step witness-logged.
4. Nightly causal-audit and witness-integrity sweeps (Cloud Scheduler jobs above) run against that day's promoted mutations.
**Day-30 evaluation**:
- Statistical comparison of day-30 vs. day-1 metrics using a paired bootstrap or equivalent test per metric (latency, task success, sensing accuracy, cost) — "outperforms" must be a stated significance threshold (e.g., p < 0.05 with a pre-registered minimum effect size), not a raw mean comparison, to avoid the exact "gains don't prove causation" failure mode the causal-audit evidence (item 5) warns against.
- **Full mutation provenance**: every promoted mutation across the 30 days must be traceable through the witness chain from proposal → evaluation → promotion, queryable end-to-end.
- **Zero unapproved capability expansion**: diff the capability/tool/action tables at day 0 vs. day 30; any expansion must have a matching constitutional-gate approval record (WP11) or the acceptance test fails outright, independent of the performance numbers.
- **Frozen-weights verification**: re-hash the foundation model weights at day 30 and confirm bit-identical to day 0.
**Failure handling**: any day where a promoted mutation later fails its causal audit or proof-gate re-check triggers automatic rollback via `autogenous`'s existing promotion/rollback controller (asset map §9) — the acceptance test should include at least one injected failure scenario to confirm rollback actually fires during the 30-day window, not just in isolated unit tests.
---
## Top risks (revised after second-pass grounding)
1. **Cross-repo coordination overhead, not Dream Machine, is now the top risk.** Four of the seven bounded contexts depend on sibling repos (`LatentMesh`, `rvm`, `autogenous`, `RuView`) maintained outside this program's direct control — LatentMesh's own ADR-009 shows its maintainers are still actively revising scope (twice in one day, per its own text), `autogenous` self-labels "research prototype," and `ruvector` has zero existing wiring to either LatentMesh or Autogenous today. This program's timeline is exposed to their churn and to genuinely new (not integration) engineering effort on the `ruvector` side. *(Dream Machine was the top risk in the first pass of this plan — the second inventory pass found real, CI-wired promotion machinery already exists under `research-gate`/`ruvector-sota-bench`, which downgrades that specific risk substantially.)*
2. **Two of eight founding claims are unverified, and one previously-"external" component (LATTE) turns out to have zero prior art anywhere.** Treating WP7 (quarantine) and WP14 (universal CSI vocabulary) as "implement the paper" instead of "build it for the first time" will produce schedule and credibility risk if that distinction gets lost downstream (e.g., in an ADR that cites "LATTE" as if it were a real paper).
3. **ADR numbering hygiene is worse than expected and could actively cause confusion mid-program.** 283 files, true max ADR-304, with ~15+ genuine duplicate numbers (one number reused 5 times). If WP0a isn't run early, this program's own new ADRs risk colliding with existing (possibly still-duplicate) numbers, and cross-references to "ADR-X" throughout this plan and the asset map need the reader to know which of several same-numbered documents is meant.
4. **A real dependency/compliance bug is already blocking part of the pipeline this program needs.** The MetaHarness `optionalDependencies` non-compliance (hard dependency on nine `@metaharness/*` packages) and the `ruvllm-cli` GGUF glob/alias bug in `get_files_to_download()` (blocks Darwin's local-mutator live-serve e2e testing) are concrete, small, already-known issues — cheap to fix (WP0b) but currently unfixed, and WP9 (the SHAPER-pattern evolution loop, arguably the program's centerpiece) depends on both being resolved first. (A third bug this plan previously tracked here, an HTTP-307 redirect in `ruvllm`'s model-download path, is already fixed on `main` — commit `946275a61`, PR #590, 2026-06-18 — and is not part of WP0b's remaining scope.)
---
## GitHub issue breakdown
Every work package above maps to one or more fileable GitHub issues, one per repo it touches (a cross-repo WP gets a linked issue in each repo rather than one issue pretending to speak for two codebases). **These are ready-to-file specs only — do not create them; the coordinator files them with `gh issue create` once this plan is approved.** File the five epics first, then child issues referencing their epic number, then edit each epic body to link the child issue numbers back in (`gh issue create` → capture number → `gh issue edit <epic> --body-file`).
Suggested label set to create in each repo before filing (`gh label create`): `pir` (every issue in this program), `epic`, `adr` (issue produces/updates an ADR), `security` (touches witness/proof-gate/capability/quarantine), `cross-repo` (coordination-dependent), and phase labels `phase-0`, `phase-1`, `phase-2`, `phase-3`, `fast-follow`, `stretch`.
### Epics (file first, one per repo)
| Epic | Repo | Title | Labels | Links to |
|---|---|---|---|---|
| E1 | `ruvnet/ruvector` | `[PIR] Epic: Perpetual Intelligence Runtime — ruvector work packages` | `pir`, `epic` | WP0a, WP0b, WP2, WP3, WP4, WP5-ruvector, WP6, WP7, WP9, WP10, WP12, WP13, WP14-companion |
| E2 | `ruvnet/LatentMesh` | `[PIR] Epic: Perpetual Intelligence Runtime — LatentMesh coordination` | `pir`, `epic` | WP1-latentmesh, WP5-latentmesh |
| E3 | `ruvnet/rvm` | `[PIR] Epic: Perpetual Intelligence Runtime — witness-chain convergence` | `pir`, `epic` | WP8-rvm |
| E4 | `ruvnet/autogenous` | `[PIR] Epic: Perpetual Intelligence Runtime — governance integration` | `pir`, `epic` | WP8-autogenous, WP11-autogenous |
| E5 | `ruvnet/RuView` | `[PIR] Epic: Perpetual Intelligence Runtime — RF sensing substrate` | `pir`, `epic` | WP14-ruview |
Each epic body: one paragraph linking to `docs/research/perpetual-intelligence-runtime/03-program-plan.md` in `ruvnet/ruvector` (the canonical plan document — sibling repos should link to it rather than duplicating the plan), plus a checklist of its child issue numbers to be filled in after filing.
### Child issues
**WP0a — ADR numbering hygiene remediation**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `adr`, `phase-0`.
- Title: `[PIR][WP0a] Resolve duplicate ADR numbers in docs/adr/ (ADR-272 ×5, ADR-264/252/194/144/040 ×3, ~12 more ×2)`
- Body — Goal: audit `docs/adr/` and resolve every duplicate ADR number by renumbering the later-created file in each collision to the next free number above the true max (currently ADR-304), updating all in-repo references. Acceptance criteria: `ruflo-adr:adr-index` reports zero duplicate numbers; every renumbered ADR's old-number references (code comments, other ADRs, MCP tool descriptions) are updated; a CI check is added that fails on future duplicate ADR numbers. Dependencies: none — do this first, it blocks every other ADR this program creates.
**WP0b — MetaHarness dependency compliance + ruvllm-cli GGUF glob/alias fix**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `phase-0`.
- Title: `[PIR][WP0b] Fix MetaHarness optionalDependencies non-compliance and ruvllm-cli GGUF glob/alias bug`
- Body — Goal: (1) make the nine `@metaharness/*` packages in `crates/ruvector-sota-bench/harness` genuinely optional per ruflo ADR-150 rule 2 (`v3/docs/adr/ADR-150-metaharness-integration-surfaces.md`, "MetaHarness Integration Surfaces in `npx ruflo`," Implemented 2026-06-16 — the real source `METAHARNESS-README.md` attributes its policy to; neither `ruvector`'s nor `metaharness`'s own ADR-150 is the right document, both unrelated), or correct the documentation to state the real hard-dependency requirement; (2) fix the GGUF glob/alias mismatch in `ruvllm-cli`'s `get_files_to_download()` (`download.rs:193`, `models.rs:65`) blocking Darwin's local-mutator live-serve e2e tests (ADR-259). Note: the HTTP-307 redirect bug this issue previously also tracked is already fixed on `main` (commit `946275a61`, PR #590, 2026-06-18) and is out of scope here. Acceptance criteria: a CI job passes on the `--ignore-optional` install path per ruflo ADR-150 rule 4 (stronger than a plain successful `npm install`) without the `@metaharness/*` packages present (if made optional), or documentation matches reality (if not); `ruvllm`-backed Darwin mutator passes a live-serve end-to-end test. Dependencies: none. **Blocks WP9.**
**WP1 — LatentMesh coordination & ADR alignment**
- Repo: `ruvnet/ruvector` (primary) + linked issue in `ruvnet/LatentMesh`. Labels: `pir`, `adr`, `cross-repo`, `phase-0`.
- Title (ruvector): `[PIR][WP1] Adopt LatentMesh ADR-009's control loop as the runtime spine; open cross-repo coordination`
- Title (LatentMesh): `[PIR][WP1] Coordination request: ruvector is building a Perpetual Intelligence Runtime on top of ADR-009`
- Body — Goal: formally adopt LatentMesh ADR-009's `execute → transfer → causal audit → measure → update authority → persist → evolve topology` loop as this program's architecture; open a standing coordination thread with LatentMesh maintainers so `ruvector`-side work (WP5) doesn't diverge from LatentMesh's own evolving design (it revised scope twice in one day per ADR-009's own text). Acceptance criteria: a coordination doc/thread exists and is linked from both epics; this program's new ADR-hygiene-corrected ADR (WP0a) explicitly cites and doesn't contradict LatentMesh ADR-001–009. Dependencies: WP0a.
**WP2 — Adopt research-gate/sota-bench as Dream Machine; wire to Darwin**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `adr`, `phase-1`.
- Title: `[PIR][WP2] Wire scripts/research-gate + ruvector-sota-bench/harness as the mutation-promotion gate (Dream Machine role)`
- Body — Goal: connect Darwin's mutation proposals to the existing `research-gate`/`ruvector-sota-bench/harness` statistical promotion machinery (paired bootstrap `statistics.ts`, hard vetoes `vetoes.ts`, Ed25519-signed replay bundles `flywheel.ts`, ADR-282) as the mandatory evaluation stage before RVM proof-gated promotion; optionally feed SONA's dream-replay engine in as a pre-filter. Acceptance criteria: no mutation reaches RVM's proof gate without passing a `research-gate` verdict; verdict + replay bundle are witness-logged. Dependencies: WP1.
**WP3 — Three-level memory tiers on RuVector**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `adr`, `phase-1`.
- Title: `[PIR][WP3] Map LiveMem/TARL three-tier memory onto ruvllm context modules + ruvector-agent-memory`
- Body — Goal: formalize working-context (ruvllm `working_memory`) / continuous-latent-state (`episodic_memory`/`semantic_cache`/`agentic_memory`) / transactional-memory (`ruvector-agent-memory` ADR-252 + `reasoning_bank` + `ruvector-temporal-coherence` ADR-211) as an explicit three-tier architecture per LiveMem's design (arXiv:2608.02515). Acceptance criteria: each tier has a documented interface and a test proving state survives context eviction (LiveMem's core claim). Dependencies: WP1.
**WP4 — TARL ledger states on existing proof-gate**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `adr`, `security`, `phase-1`.
- Title: `[PIR][WP4] Add TARL five-operation ledger (add/ignore/revise/reject/defer) onto ADR-194/047 proof-gated memory writes`
- Body — Goal: implement TARL's (arXiv:2608.03699) five executable memory operations and accepted/pending/rejected ledger states as a layer on top of the memory writes already proof-gated by ADR-194/047 — this is a smaller scope than originally planned since the underlying gate already exists. Acceptance criteria: a poisoning-style adversarial test (per TARL's own eval) shows rejected/deferred writes never reach transactional memory. Dependencies: WP3.
**WP5 — LatentMesh `ruvector`-side crates**
- Repo: `ruvnet/ruvector` (new crates) + linked issue in `ruvnet/LatentMesh` (wire-format sign-off). Labels: `pir`, `cross-repo`, `phase-2`.
- Title (ruvector): `[PIR][WP5] Build new crates/rvAgent/latentmesh-* crates (greenfield — no existing ruvector wiring)`
- Title (LatentMesh): `[PIR][WP5] Wire-format compatibility review for ruvector's new LatentMesh client crates`
- Body — Goal: `ruvector` has zero existing LatentMesh integration (only an unmerged `origin/docs/link-latentmesh` branch) — build new crates under `crates/rvAgent/` (alongside `rvagent-a2a`, ADR-159) implementing network transport, RVF packaging, and `rvm-cap` admission enforcement against LatentMesh's `latentmesh-core`/`latentmesh-align`/`latentmesh-gate` wire format. Acceptance criteria: a live multi-agent task runs LatentMesh's causal-edge verification (ADR-003) end-to-end for the first time, from `ruvector`; LatentMesh maintainers sign off on wire-format compatibility. Dependencies: WP1, WP4.
**WP6 — Causal-audit CI gate**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `security`, `phase-2`.
- Title: `[PIR][WP6] CI gate: controlled-replacement causal audit (arXiv:2607.26773) required before latent-channel merge`
- Body — Goal: require every PR touching `latentmesh-align`-consuming code or the quarantine module (WP7) to pass a controlled-replacement causal audit before merge, modeled on the July 2026 causal-audit paper's methodology. Acceptance criteria: CI blocks merge on audit failure; audit report is witness-logged. Dependencies: WP5.
**WP7 — Anomaly quarantine (net-new)**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `security`, `adr`, `phase-2`.
- Title: `[PIR][WP7] Build latent-channel anomaly quarantine (net-new — "LATTE" has no verified prior art)`
- Body — Goal: build quarantine for anomalous latent-channel updates as an original contribution, combining arXiv:2606.28958's HMAC-manifest integrity approach with `rvm-witness` provenance — explicitly document in the ADR that this is not an implementation of a paper called "LATTE" (none was found to exist). Acceptance criteria: injected-anomaly test suite shows tampered/anomalous latent payloads are quarantined before reaching a receiving agent. Dependencies: WP5, WP6.
**WP8 — Witness-crate convergence (rvm ↔ autogenous)**
- Repo: `ruvnet/rvm` (primary, canonical implementation) + linked issue in `ruvnet/autogenous` (consumer-side migration). Labels: `pir`, `security`, `cross-repo`, `phase-2`.
- Title (rvm): `[PIR][WP8] Confirm rvm-witness as canonical; document external-consumer API for autogenous convergence`
- Title (autogenous): `[PIR][WP8] Migrate autogenous's witness crate to depend on rvm-witness instead of a parallel implementation`
- Body — Goal: resolve the duplicated cryptographic-provenance implementation — `rvm-witness` becomes canonical (more hypervisor-integrated; `autogenous` is self-labeled "research prototype"), and `autogenous`'s `witness` crate is refactored to depend on it. Acceptance criteria: `autogenous`'s witness records are verifiably interchangeable with `rvm-witness` output; both maintainer teams sign off. Dependencies: WP1.
**WP9 — SHAPER-pattern skill/harness evolution loop**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `adr`, `phase-3`.
- Title: `[PIR][WP9] Frozen-weight skill/harness evolution loop via @metaharness/darwin (SHAPER pattern, arXiv:2608.11350)`
- Body — Goal: implement the physical-intelligence evolution loop with foundation weights frozen throughout (planner and optimizer are the same frozen model; only skills/context/harness evolve via Darwin's mutation surfaces at `harness/src/darwin.ts`, `examples/mragent` `scorePolicy`, `crates/sona/src/darwin_guard.rs`). Acceptance criteria: a CI check proves no promotion-reachable code path can write to foundation-model weight files; VLABench/ESI-Bench-style eval shows skill improvement without weight changes. Dependencies: WP0b, WP2.
**WP10 — WorldCycle verification stage**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `phase-3`.
- Title: `[PIR][WP10] Reversible-action verification stage (WorldCycle pattern, arXiv:2608.04964)`
- Body — Goal: add reversible-action-sequence verification between "observe consequences" and Dream Machine evaluation in the physical loop, targeting the paper's reported 44% long-horizon drift reduction and ~4x composite-action accuracy as the internal acceptance bar. Acceptance criteria: CycleBench-equivalent internal benchmark shows the target improvement over a no-WorldCycle baseline. Dependencies: WP9.
**WP11 — Constitutional capability-expansion gate**
- Repo: `ruvnet/autogenous` (primary) + linked integration issue in `ruvnet/ruvector`. Labels: `pir`, `security`, `adr`, `cross-repo`, `phase-3`.
- Title (autogenous): `[PIR][WP11] Expose constitution/admission-gate API for external capability-expansion approval`
- Title (ruvector): `[PIR][WP11] Integrate autogenous's constitutional gate for capability-expanding mutations`
- Body — Goal: every mutation expanding an agent's capability set (new tool access, new physical action class, new communication peer) requires explicit constitutional approval logged to the witness chain, distinct from ordinary behavioral-mutation promotion (WP2). Acceptance criteria: acceptance harness (WP12) can query "zero unapproved capability expansion" directly against this gate's log. Dependencies: WP8.
**WP12 — 30-day acceptance harness**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `phase-3`.
- Title: `[PIR][WP12] Build the 30-day continuous-run acceptance test harness`
- Body — Goal: implement the daily-cycle harness described in this plan's acceptance-test section — frozen-weight hash verification, per-task metric logging, statistical day-30-vs-day-1 comparison (paired bootstrap, pre-registered significance threshold), full witness-chain mutation provenance query, capability-table diff for zero-unapproved-expansion, and an injected-failure rollback test via autogenous's promotion/rollback controller. Acceptance criteria: a full 30-day dry run completes and produces a pass/fail report against every acceptance criterion in the brief. Dependencies: WP2, WP4, WP9, WP10, WP11.
**WP13 — ruvLLM KV-cache cross-model migration (fast-follow)**
- Repo: `ruvnet/ruvector`. Labels: `pir`, `fast-follow`.
- Title: `[PIR][WP13] Implement closed-form KV-cache cross-model migration in ruvllm (arXiv:2608.03893)`
- Body — Goal: implement the paper's closed-form linear KV-cache mapper for same-family model migration in `crates/ruvllm` (`kv_cache.rs`, `paged_attention.rs`, `serving/kv_cache_manager.rs`), with the nonlinear MLP fallback for degrading pairs, plus a routing gate that predicts transfer quality before migrating. Acceptance criteria: reproduces the paper's reported 2.7-25x speedup over re-prefill on an internal same-family model pair; routing gate correctly refuses/downgrades for a known-degrading pair. Dependencies: none — independent parallel track, can start immediately.
**WP14 — RuView pose-semantic embedding + universal CSI vocabulary (stretch)**
- Repo: `ruvnet/RuView` (primary) + linked companion issue in `ruvnet/ruvector` (for `ruvector-perception` validation). Labels: `pir`, `stretch`.
- Title (RuView): `[PIR][WP14] Real-CSI validation + pose-semantic embedding pipeline (pick up ADR-178 gaps C & D)`
- Title (ruvector): `[PIR][WP14] Validate ruvector-perception (3.8K LOC) against real CSI captures, not synthetic-only`
- Body — Goal: close ADR-178's two still-open gaps — gap C (CSI bridge I/Q → pose-semantics conversion) and gap D (mcp-brain-server-side cluster consumer) — and validate `ruvector-perception` against real, not synthetic, CSI data. If time/budget allows, extend into the universal/heterogeneous-chipset CSI vocabulary research bet (evidence item #8 — no prior art exists anywhere, first-party research). Acceptance criteria: `ruvector-perception` achieves a documented accuracy baseline on real CSI captures (not just synthetic); gap C/D are closed per ADR-178's own definition of done. Dependencies: none — independent, recommend funding separately from the WP0-WP12 critical path.
---

442
docs/research/perpetual-intelligence-runtime/04-verification-addendum.md Normal file
View file

@ -0,0 +1,442 @@
# Verification Addendum — Direct Source Checks Against LatentMesh and Autogenous
Status: addendum to `02-asset-map.md` and `03-program-plan.md`, compiled
2026-08-19 by a third research pass (asset-scout) that cloned both external
repos directly rather than relying on `gh` CLI metadata or org-search
results. **This document does not edit `02-asset-map.md` or
`03-program-plan.md` in place** — it records what those two documents still
get wrong or omit as of this program's ADR-authoring pass, so the correction
is traceable rather than silently folded in. Where a claim below contradicts
`02-asset-map.md`, the section header says so explicitly.
Repos cloned: `ruvnet/LatentMesh` (HEAD `922ea196`, dated 2026-08-18) and
`ruvnet/autogenous` (HEAD `b5c6e838`, dated 2026-08-19).
## 1. LatentMesh — accurate but understated in scale
`02-asset-map.md` §8 correctly describes LatentMesh's crates, ADR sequence,
and "not implemented" markers, and its headline finding's loop diagram and
"statistical primitive and admission gate implemented; closed loop not
wired" quote both match source verbatim, including the per-stage markers on
ADR-004 through ADR-008 (004 not wired to live MidStream; 005 not wired to a
live RuVector instance; 006 no live Darwin loop; 007 no live Radio/RuView;
008's admission gate implemented in `crates/latentmesh-gate`, RVF packaging
and RVM enforcement not wired).
**What §8 does not convey: LatentMesh is a small research prototype.** The
entire workspace is 1,407 LOC across four crates:
| crate | LOC | tests |
|---|---|---|
| `latentmesh-core` | 272 | 6 |
| `latentmesh-align` | 454 | 6 |
| `latentmesh-gate` (incl. `causal.rs`) | 534 | 11 |
| `latentmesh-bench` | 147 | 0 |
That is real, tested code, but roughly 1/23rd the size of `ruvector-core`
alone (32,380 LOC / 503 tests). **There is no network transport crate
anywhere in the workspace** — no QUIC/TCP/transport module exists. This is
consistent with, and reinforces, `02-asset-map.md`'s own §8 correction that
`ruvector`-side LatentMesh work is greenfield, not integration — but it also
means "adopt LatentMesh ADR-009 as the spine" (this program's ADR-305) is
adopting a *design contract and ~1.4K LOC of primitives*, not inheriting a
mature system. Scope every ADR and work package that references LatentMesh
accordingly.
**Minor date correction**: `02-asset-map.md` §8 states LatentMesh was "last
updated 2026-08-19." The correct date, per the cloned HEAD commit, is
**2026-08-18**.
## 2. Autogenous — `02-asset-map.md` is materially incomplete
### 2a. The ADR catalog is undercounted, and the missing ADRs are the program itself
`02-asset-map.md` §9 cites autogenous's ADRs as **"391/392/393/397."** The
actual catalog, confirmed by directory listing, runs **391 through 403 — 13
ADRs, not 4**:
```
ADR-391-autogenous-governed-self-evolving-architecture.md
ADR-392-autogenous-genome-language-antibody-protocol.md
ADR-393-autogenous-product-thesis-adaptive-agent-firewall.md
ADR-394-cryptographic-closure-of-the-promotion-path.md
ADR-395-radio-realtime-streaming-peer-expert-mesh.md
ADR-396-peer-expert-protocol-security-and-governed-evolution.md
ADR-397-autogenous-streaming-mixture-of-agents.md
ADR-398-applications-and-development-loop-integration.md
ADR-399-provider-backed-mesh-run-rvm-rvf.md
ADR-400-self-evolving-mesh-perpetual-loop.md
ADR-401-perpetual-intelligence-machine.md
ADR-402-ruview-cognitum-spaces-spatial-intelligence.md
ADR-403-verifiable-execution-loop.md
```
The eight missing from the asset map's list matter directly to this program:
- **ADR-401 — "The Perpetual Intelligence Machine."** Status: **Accepted**
(framing + capability map) · **Partial** (implementation). Dated
2026-08-16. Defines a 10-capability map with an honest Built/Partial/
Gap/Narrative status legend, a stage-by-stage operating loop, and a V1 +
30-day acceptance test. Carries an explicit honesty anchor: *"'Perpetual'
does not mean conscious, immortal, or continuously improving… The system
targets operational continuity, not infallibility."* This is, on its face,
substantially the same product this program's brief describes. See
ADR-305 for the required reconciliation.
- **ADR-400 — "Self-Evolving Mesh Perpetual Loop."** Status: **Accepted —
Implemented (first flywheel turn measured).**
- ADR-394 (cryptographic closure of the promotion path), ADR-395/396 (radio
realtime streaming peer-expert mesh + its security/governed-evolution
counterpart), ADR-398 (applications/dev-loop integration), ADR-399
(provider-backed mesh runs on RVM/RVF).
- **ADR-402 — "RuView/Cognitum Spaces Spatial Intelligence."** Status:
Accepted; read-side adapters, fail-closed seam, production HTTPS API
complete; write-side sync and a 30-day acceptance test outstanding.
Directly relevant to this program's RF Sensing Substrate context (WP14).
- **ADR-403 — "Verifiable Execution Loop."** Status: Accepted;
`VerifiedPromotion` implemented, concurrent-promotion fencing and durable
replay partially implemented, enforced isolation accepted-design-pending.
ADR-401 also cross-references **"metaharness ADR-322 (flywheel receipts/
promotion)"** — a third ADR series appearing in none of this program's
research documents. Its content is unlocated as of this addendum; see
ADR-305's Decision §3 for the resulting action item.
### 2b. The governance implementation is TypeScript, not the Rust crates `02-asset-map.md` implies
`02-asset-map.md` §9 lists autogenous's crates as a Rust workspace (`witness,
antibody, agl-types, generator, evaluator, verifier, lineage, ledger,
promotion, deployment, constitution, runtime, midstream-adapter, service`).
That crate list is correct as far as it goes, but ADR-401's capability map
points almost entirely at **`packages/radio-moe/src/*.ts`**, not the Rust
workspace:
- `packages/radio-moe/src` — 6,171 LOC; `packages/radio-moe/test` — 3,161 LOC
- All 11 modules ADR-401 names exist: `mesh.ts` (252), `mesh-evolve.ts`
(277), `mixture.ts` (685), `action-gate.ts` (440), `failover.ts` (455),
`disclosure.ts` (125), `reputation.ts` (154), `rvf-trajectory.ts` (67),
`lineage-independence.ts` (243), `relevance.ts` (99), `capability.ts` (31)
- The Rust crates total 8,096 LOC / 91 test functions — real, but a
different layer (crypto/protocol primitives) than the governance loop
ADR-401 describes as Built/Partial.
Any PIR ADR describing autogenous's governance loop (ADR-315, this program)
should point readers at `radio-moe`, not only at the Rust crate names.
### 2c. Crate list omission
`02-asset-map.md` §9 lists 14 autogenous crates and gets 14 right, but
**misses `envelope`** (1,009 LOC, 7 tests) — the second-largest crate in the
workspace after `runtime` (1,471 LOC). Everything else in the asset map's
list is confirmed accurate.
### 2d. Cloud Run deployment — confirmed, not just inferred
`02-asset-map.md` documents Cloud Run deployment concretely for
`mcp-brain-server`/`ruvbrain`, but does not confirm it for autogenous
specifically. The root `Dockerfile` in `ruvnet/autogenous` is headed
*"autogenous-service — Cloud Run image (the Autogenous AGL control-plane as
a service)"*, multi-stage `rust:1-bookworm` → `debian:bookworm-slim`, `ENV
PORT=8080`, with a comment noting Cloud Run sets `$PORT`. Backed by
`crates/service` (980 LOC).
### 2e. The prototype-badge / Accepted-ADR tension
`02-asset-map.md` §9 correctly cites autogenous's README "research prototype"
status badge and its "Honest status" note that it is "not wired to live
MidStream/MetaHarness/RVF/RVM yet" and that "performance and economics claims
in the ADRs are hypotheses until benchmarked." What is worth flagging
explicitly: several of autogenous's own ADRs (400, 401, 402, 403) carry
**Accepted** status despite the repo-level prototype badge. When citing
autogenous maturity in any PIR ADR, cite the README badge for overall repo
maturity and the individual ADR's status line for that specific capability —
the two are not always in agreement, and neither alone tells the full story.
## 3. Witness-crate comparison (grounds ADR-312's reframe)
`02-asset-map.md` §9's "duplication note" (repeated in `03-program-plan.md`'s
original ADR #8 draft) described `rvm-witness` and autogenous's `witness`
crate as having "near-identical framing," recommending autogenous depend on
or converge with `rvm-witness`. A direct comparison of both crates does not
support a merge/dependency framing:
| | `autogenous/crates/witness` | `ruvector`'s `crates/rvm/crates/rvm-witness` |
|---|---|---|
| Size | 302 LOC, 4 tests, one file | 4,405 LOC, multi-file (`v2.rs` 880, `replay.rs` 253, `hash.rs` 204, `record.rs`) |
| Hash | SHA-256 over canonical JSON | u64 chain/record hashes (`compute_chain_hash`, `compute_record_hash`) |
| Auth | Ed25519 (`ed25519_dalek`), per-role `SigningAuthority` | Keyed chain MAC with derivation + ratcheting (`derive_chain_key`, `ratchet_chain_key`, `erase_key`, `CHAIN_KEY_CONTEXT`) |
| Record shape | `WitnessRecord` over JSON artifacts (genome, mutation, antibody, incident) | 64-byte cache-line-aligned privileged-action records in a fixed-capacity ring (`WitnessLog<const N>`, `WitnessLogV2<const N, const SEG>`, `DEFAULT_RING_CAPACITY = 262_144`) |
| Extras | `WitnessSeal`, `verify_seal`, `verify_chain` | `CoveragePolicy`/`CoverageError`, `verify_chain_v2_ratcheted`, `v1_head_to_genesis`, `verify_log_bytes`, queries by partition/action-kind/time-range |
| Runtime | std, service-side, offline+deterministic | `no_std`, hypervisor-side |
The shared element is the abstract idea of an append-only, hash-chained,
tamper-evident log — cryptographic primitives, data model, storage strategy,
and target runtime all differ, and each choice is correct for its own layer:
SHA-256-over-JSON does not fit in a `no_std` 64-byte-aligned ring buffer, and
`rvm-witness`'s u64 keyed-MAC chain is deliberately not a signature scheme.
**ADR-312 in this program set is written against a shared witness record
schema plus a cross-layer verification/anchoring contract, not a crate
merge or a dependency edge — merging the two crates as originally proposed
would be a design error.**
## 4. Summary of corrections to carry into this program's ADRs
| Claim in `02-asset-map.md` | Correction here | PIR ADR affected |
|---|---|---|
| LatentMesh "last updated 2026-08-19" | 2026-08-18 | ADR-305 |
| LatentMesh described without scale context | 1,407 LOC / 4 crates / no transport crate | ADR-305, ADR-309 |
| Autogenous ADRs "391/392/393/397" | 391–403 (13 ADRs); 400/401/402/403 previously uncited | ADR-305, ADR-315 |
| Autogenous governance described via Rust crate list only | Governance loop lives in `packages/radio-moe/src/*.ts` (6,171 LOC) | ADR-315 |
| Autogenous crate list (14 named) | Missing `envelope` (1,009 LOC) | ADR-312 |
| Autogenous Cloud Run presence unconfirmed for this repo specifically | Confirmed via root `Dockerfile` (`autogenous-service`, `crates/service`) | ADR-315 |
| `rvm-witness`/autogenous `witness` "near-identical framing" → merge/depend | Different primitives, data models, std/no_std, layers; reframe as shared schema + anchoring contract | ADR-312 |
## 5. `metaharness ADR-322` located — it is `ruflo` ADR-322, misattributed by autogenous
A fourth research pass located the ADR autogenous ADR-400/401 cite as
"metaharness ADR-322": it lives in **`ruvnet/ruflo`**, at
`v3/docs/adr/ADR-322-metaharness-flywheel-integration.md` — **"Adopt
`@metaharness/{flywheel,darwin}` as pluggable engines behind ruflo's ADR-176
self-improvement flywheel,"** status Accepted (phases 0–2 implemented),
dated 2026-07-28. It is ruflo's own ADR *about consuming* MetaHarness, not an
ADR published by the MetaHarness/`agent-harness-generator` project (which was
itself renamed to `ruvnet/metaharness`, 230 ADRs topping out at ADR-250 —
no ADR-322 exists there). **Cite this dependency as "ruflo ADR-322," never
"metaharness ADR-322."**
ADR-322 has three Accepted, implemented children directly relevant to this
program's promotion-gating ADRs (ADR-306, ADR-312):
- **322A** — evaluation↔promotion transaction model (`RUFLO_FLYWHEEL_TRANSACTION_V1`).
- **322B** — Darwin proposer adapter, enforcing a separation-of-powers
invariant this program's own ADR-401 reconciliation (ADR-305) is reaching
for independently: *"A proposer produces untrusted candidates only. It
cannot issue promotion decisions or mutate active policy."*
`promoteFlywheelCandidate` is the sole promotion authority.
- **322C** — receipt/ledger/verification protocol: RFC 8785 JCS canonical
JSON, SHA-256 digests, **Ed25519 with domain separation**
(`Ed25519(domainPrefix || 0x00 || canonicalBytes)`), UUIDv7 run IDs,
independent statistical recomputation via deterministic paired bootstrap.
Separately, **ruflo PR #2956** implements the sequential-promotion-evidence
mechanism (anytime-valid e-process, `α_k = α_total · 6/(π²k²)`; 0.6%
measured family-wise false-promotion rate over 1,000 simulated nulls, the
bound holding **per epoch**), and **ruflo ADR-381** (**Proposed**,
2026-08-10) governs stream identity and budget-exhaustion recovery over it.
Together they are the concrete prior art for any PIR ADR claiming
statistical promotion gating. See §8d for the full correction — an earlier
version of this paragraph attributed the mechanism to ADR-381 directly,
omitted its Proposed status, and dropped the per-epoch qualifier; that
version is superseded by this one and by §8d, not by both disagreeing.
ruflo has already suffered the exact ADR-number collision this program is
trying to avoid: a dream-cycle research PR independently proposed
`ADR-322-dream-cycle-memory-typed-provenance.md` and was closed as superseded
when it collided with the already-merged flywheel-integration ADR-322 — a
live precedent for verifying numbers against the actual filename list
immediately before committing, not against a max+1 assumption.
## 6. `ruvnet/dream-machine` is a real, Accepted, shipped repo — corrects §"Dream Machine" reasoning above and in `02-asset-map.md`/`03-program-plan.md`
An earlier pass of this research reported "Dream Machine" as a name with no
matching asset, later corrected in `02-asset-map.md`'s revision to point at
`ruvector`'s own `scripts/research-gate/` + `ruvector-sota-bench/harness`
(ADR-282) as the functional equivalent. **Both were incomplete**:
`ruvnet/dream-machine` is itself a real, public, published-to-npm repo
(pushed 2026-08-19), and its own **ADR-0001** — *"The Dream Machine engine —
a config-driven, evidence-gated nightly evolution loop composed from the
ruvnet stack"* — is **Accepted, engine v0.1.0 shipped** (compile / ledger /
witness / schedule / memory modules + CLI/TUI, 85 tests, ~2,558 LOC across
six packages), dated 2026-08-13.
ADR-0001's own thesis is the one this program's brief and ADR-306 are
circling: *"Freeze the model. Evolve the harness. Evaluation is not
promotion — the machine never merges; a human does."* It **composes**
`@metaharness/flywheel` 0.1.10, `@metaharness/darwin` 0.9.1,
`@metaharness/redblue` 0.1.4, `metaharness` CLI 0.4.5, `ruvector` 0.2.41, and
`agentdb` 3.0.0-alpha (all optional/peer dependencies), and its own text
names `ruvnet/ruflo`'s and `ruvnet/metaharness`'s nightly dream-cycle
routines as prior instances it **subsumes** — specifically metaharness
ADR-251 ("MetaHarness Nightly Dream Cycle") and the Ruflo Nightly Dream Cycle
v3 **(the "metaharness ADR-251" half of that claim does not resolve — see
§8b; reported here as dream-machine ADR-0001's own assertion, not as
independently verified)**.
**Net effect**: the "Dream Machine" mechanism now exists in **four** places
— `ruvnet/dream-machine` (the generalized, already-shipped engine),
`ruvnet/ruflo`'s nightly dream cycle, `ruvnet/metaharness`'s `docs/dream-cycle/`
(not an ADR — see §8b for why the "ADR-251" identifier is wrong), and
`ruvector`'s own `scripts/research-gate/` + ADR-282. ADR-306 in this program
is revised to cite `ruvnet/dream-machine` ADR-0001 as the consolidating
design ruvector's `research-gate` should align with, not as a name this
program invents or as work fully covered by `research-gate` alone.
**Version-drift note**: `ruvnet/dream-machine` composes `@metaharness/darwin`
0.9.1 / `@metaharness/flywheel` 0.1.10; `ruvector` currently pins `darwin`
0.8.0 / `flywheel` 0.1.7 — three of the nine `@metaharness/*` packages
`ruvector` depends on (per `02-asset-map.md` §1) are behind the versions
`dream-machine` itself composes against. Worth a line in WP0b's dependency
remediation scope, not a blocker for this ADR set.
## 7. Open items not resolved by this addendum
None remaining from the original metaharness-ADR-322 question (resolved in
§5). Still open: no repo checked so far publishes a formal reconciliation
between `ruvnet/dream-machine` ADR-0001, `ruvector`'s ADR-282
(`research-gate`), and autogenous ADR-400/401's flywheel — WP1/WP2 own
producing that reconciliation, per ADR-305 and ADR-306.
## 8. PR #847 review corrections — a fourth research pass (adr-reviewer + asset-scout, post-merge-review)
An adversarial review of the initial PIR ADR set (PR #847) verified every
cross-repo claim against direct clones of `ruvnet/LatentMesh`, `ruvnet/autogenous`,
`ruvnet/dream-machine`, and `ruvnet/metaharness`, and separately against a
clone of `ruvnet/ruflo` (HEAD `fa13ee4`, 2026-08-15; 177 ADRs in
`v3/docs/adr/`) that §1–§7 above did not have access to. Three findings were
blocking; this addendum records the corrected facts so future PIR work
doesn't regress to the earlier drafts' claims.
### 8a. Autogenous ADR-401's promotion predicate is DONE, not open
§2a above (and the earlier draft of ADR-305/ADR-315) cited ADR-401's
capability-table row 5 ("not yet one checked predicate") as the program's
residual scope. **That row is stale relative to ADR-401's own Decision
section.** ADR-401's Update 1 §3, "Converge the promotion invariant to one
predicate," is marked **DONE**: `mesh-evolve.ts` exports
`promoteAuthorized(candidate, champion, { authorized, reversible }) →
PromotionDecision`, the single gate `Promote = Better ∧ Safe ∧ Authorized ∧
Reversible` with each conjunct independently blocking, `evolveMesh` routing
every promotion through it, proven by `test/promote-authorized.test.ts`
(all-four promotes; any three-of-four does not). ADR-315 (this program) is
rescoped accordingly: it adopts `promoteAuthorized`, it does not build or
close it.
### 8b. "metaharness ADR-251" does not exist — corrected provenance
ADR-306 (and this addendum's own §6, before this correction) restated
dream-machine ADR-0001's "Prior instances" citation of "metaharness ADR-251
(MetaHarness Nightly Dream Cycle)" as fact. **The dangling citation
originates in `dream-machine` ADR-0001 line 9 itself** — *"Prior instances:
`ruvnet/metaharness` ADR-251 (MetaHarness Nightly Dream Cycle)…"* — and was
relayed verbatim from that source by the research pass that first surfaced
it, without checking that it resolved. It is not a fabrication introduced by
this program on either the research or ADR-authoring side; it is a citation
inside a real, Accepted upstream ADR that itself needed resolving before
being repeated. Direct inspection of `ruvnet/metaharness` (HEAD `5453c8c`)
finds **230 ADR files topping out at `ADR-250-sota-proof-ladder.md`** — no
ADR-251. The Nightly Dream Cycle material instead lives in
`docs/dream-cycle/` (`2026-08-13-gist.md`, `2026-08-14-gist.md`,
`LEDGER.md`), not as an ADR. ADR-306 now cites `docs/dream-cycle/` and
states this provenance rather than repeating the citation as independently
verified. **Future readers**: the correct fix is ADR-306's current text —
do not "fix" it back to "metaharness ADR-251" on the assumption that an ADR
citation inside another Accepted ADR must already be resolved.
### 8c. "ruvector ADR-150 (optionalDependencies policy)" is a misattribution — resolved to `ruflo` ADR-150
ADR-313 (and ADR-306, and `03-program-plan.md`) cited "ruvector ADR-150" as
the source of the `optionalDependencies` policy `METAHARNESS-README.md`
claims compliance with. Checked against all three clones:
- `ruvector`'s own `ADR-150` is `ADR-150-pi-brain-ruvltra-tailscale.md` — "π
Brain + RuvLtra via Tailscale — Semantic Embedding Upgrade." Unrelated.
- `metaharness`'s own `ADR-150` is
`ADR-150-tailscale-local-frontier-concurrent-benchmarks.md`. Also
unrelated.
- `METAHARNESS-README.md` itself attributes the policy to "**ADR-150**:
MetaHarness Integration Surfaces (**upstream**)."
**A first pass through this section marked that attribution unverified. It
resolves cleanly**: the upstream document is **`ruflo`'s own ADR-150**,
`v3/docs/adr/ADR-150-metaharness-integration-surfaces.md` — *"ADR-150 —
MetaHarness Integration Surfaces in `npx ruflo`,"* **Status: Implemented**
(2026-06-16, rev. 06-17). The evidence chain: (1) the title matches
`METAHARNESS-README.md`'s citation on its distinctive phrase; (2) this ADR
set already established the README's *other* "upstream" citation
(ADR-103, same README, same word "upstream") is ruflo's — corroborated
independently by ruflo ADR-322C line 105 (see §8d) — same pattern, same
repo; (3) `METAHARNESS-README.md`'s own section headings mirror ruflo
ADR-150's four rules one-for-one (e.g. its "MetaHarness Removable" heading
against ADR-150's rule 1); (4) ruflo ADR-322 line 17 shows the policy in
force upstream, at the exact package versions ADR-306's version-drift note
already flags `ruvector` as pinning (`@metaharness/darwin@^0.8.0`,
`@metaharness/flywheel@^0.1.7`, both declared `optionalDependencies`).
ADR-150's normative rule 2 is verbatim the policy in question: *"Optional in
`package.json`: `@metaharness/*` packages MUST appear in
`optionalDependencies` or `peerDependencies` (optional), never in
`dependencies`."* Rule 4 — *"at least one CI job must run `--ignore-optional`
… the only structural defense against accidentally promoting an optional dep
to required"* — is a stronger, CI-testable acceptance criterion than a
plain `npm install` check, and is now the one this program's ADRs and plan
cite.
This is the exact failure mode ADR-305 §4 requires PIR documents to avoid
(repo-qualify every cross-repo ADR reference) reproduced inside the set
meant to enforce it — and it is now the **fourth** instance of the same
"wrong repo owns this ADR number" pattern this program has caught (ADR-103,
"metaharness ADR-322" → ruflo ADR-322, "metaharness ADR-251" → does not
exist, and this one). Every reference in the ADR set and the plan now cites
`ruflo` ADR-150 directly instead of an unverified attribution.
### 8d. The ruflo ADR-322 family verified verbatim; ADR-381 needed two corrections
A full clone of `ruvnet/ruflo` confirms the ADR-322 family exactly as this
program's ADR-306/310/312/313 cite it:
| ADR | Title | Status |
|---|---|---|
| 322 | Adopt `@metaharness/{flywheel,darwin}` as pluggable engines behind ruflo's ADR-176 self-improvement flywheel | Accepted — phases 0–2 implemented (2026-07-28) |
| 322A | Evaluation and promotion transaction model | Accepted — implemented (`RUFLO_FLYWHEEL_TRANSACTION_V1`) |
| 322B | Darwin proposer adapter | Accepted — implemented for bounded retrieval-policy candidates (`RUFLO_FLYWHEEL_DARWIN_V1`) |
| 322C | Receipt, ledger, and verification protocol | Accepted — implemented (`RUFLO_FLYWHEEL_RECEIPT_V1`) |
322B's separation-of-powers sentence is verbatim (`ADR-322B-darwin-proposer-adapter.md`
line 10): *"A proposer produces untrusted candidates only. It cannot issue
promotion decisions or mutate active policy."* ADR-322 line 15 reinforces it:
*"Darwin adapters remain candidate generators and never gain promotion
authority."* 322C's stack is confirmed with more precision than this
program's earlier drafts stated: canonical JSON is RFC 8785 JCS, digest is
SHA-256, signature is `Ed25519(domainPrefix || 0x00 || canonicalBytes)`
across **two distinct Ed25519 signing domains** — `ruflo/flywheel-receipt/v1`
(L96) and `ruflo/flywheel-ledger-head/v1` (L102) — plus a third
domain-separated prefix, `ruflo/bootstrap/v1` (L82), that seeds the
deterministic paired bootstrap's statistics rather than signing anything (an
earlier draft of this addendum and of ADR-312 called this "three signing
domains," overcounting by one), with `candidateId = SHA-256(JCS(candidate
policy))` and `receiptId
= SHA-256(JCS(unsigned receipt payload))`. Every authorizing term in a 322C
record is graded `recomputed`, `signature-verified`, or `trusted-assertion`.
322C line 105 also settles the ADR-103 cross-repo ambiguity this program
flagged in ADR-305: keys "use ADR-103's provider mechanism but a distinct
purpose/domain," confirming the witness-manifest ADR-103 is `ruflo`'s.
**ADR-381 needed three corrections.** (a) **Status is Proposed, not
Accepted** (line 3, dated 2026-08-10; no supersede or later Accepted line —
earlier drafts of ADR-306/310/312 implied it was settled governance
alongside its Accepted siblings). (b) **The 0.6% figure and the `α_k =
α_total · 6/(π²k²)` allocation belong to `ruflo` PR #2956's mechanism**,
which ADR-381 *governs*, not to ADR-381's own decision. ADR-381's actual
contribution is narrower: scoping the α ledger to one stream per project
root within the ADR-322 transaction state, and `resetSequentialEvidence` — an
explicit, `confirm: true`-gated, human-reasoned evidence-epoch reset for
budget exhaustion, expiring all outstanding receipts so stale evidence
can't be replayed against a fresh budget. (c) The false-promotion bound is
**per-epoch**, not global: line 33 states the guarantee as "family-wise
false-promotion probability is ≤ α_total **per epoch**" after a reset. Any
PIR document citing this bound now states it the same way.
### 8e. The `ruvllm` HTTP-307 bug is already fixed; the systemic lesson
ADR-313 (and `03-program-plan.md`) cited an HTTP-307 redirect bug in
`ruvllm`'s model-download path as an open blocker. It was already fixed on
`main` before this ADR set was written (commit `946275a61`, PR #590,
2026-06-18). The actual remaining download blocker is a GGUF glob/alias bug
in `ruvllm-cli`'s `get_files_to_download()` (`download.rs:193`'s glob
pattern disagreeing with `models.rs:65`'s alias resolution).
All three blocking findings (8a–8c) and this one share a root cause: a claim
was carried forward from a source document — an upstream ADR's stale table
row, a citation inherited from another repo's ADR, a documented-but-unlocated
upstream attribution, or an earlier bug report — without checking that
source's own current state via fix history (`git log` on the named path,
merged PRs, release notes). ADR-305 now states this as a standing
verification rule for the remainder of this program (see its Decision §6).