Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[PIR][WP33] Adaptive runtime monitoring with VoI escalation (ADR-337)

Abierto
  • ¿Algo no está bien?
#916 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
ai-infra-agents, observability-sre, security

Línea de trabajo

Comienza con crates/mcp-gate/ y lee crates/ruvector-tiny-dancer-core/src/voi.rs, especialmente decide(), observe() y el comportamiento de validación. Sigue los puntos de entrada existentes de mcp-gate antes de definir la escalera y su contabilidad. Se considera terminado cuando pasan las comprobaciones de aceptación, incluida la prueba de regresión de inspección incondicional, cargo nextest run -p mcp-gate y el análisis de seguridad.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

adr phase-w5-3 pir wave-5

Part of the PIR program epic #837. See 12-wave5-evidence-review.md and 13-wave5-program-plan.md. ADRs land via #911.

The hard part already shipped in Wave 4

crates/ruvector-tiny-dancer-core/src/voi.rs (ADR-331, WP28, merged) was written with this exact use case named in its own module docstring:

"decide is a standalone pure function so the same primitive can gate model selection..., retrieval depth, verifier invocations, agent spawning, and escalation. Only the router integration is implemented here; the others are expected to construct their own EstimatorSpec ladders over the same API."

The mapping is one-to-one: each EstimatorSpec { cost, latency_us, noise_std } is one investigator rung — cheap/noisy first, expensive/sharp last. The purchase inequality value_of_success × VoI − cost > 0 is "investigate when P(violation) × damage > verification cost". observe() does the Bayesian update between rungs.

Consume it unchanged. Reimplementing the closed form inside mcp-gate is exactly the "more independent primitives instead of strengthening the substrate" failure the Wave-5 briefing names.

Ladder

stream → cheap detector → risk score — low continues; medium buys a local verifier; high buys a strong-model investigator; critical stops execution via RVM.

Greenfield here: the detector, risk-score plumbing, ladder wiring, per-rung cost accounting. crates/mcp-gate/ is the mount point.

Four binding caveats, each documented in voi.rs and each a real failure mode

  1. Every rung must have cost > 0, or cap the rounds. EstimatorSpec::validate permits cost == 0, and a free rung is bought forever — the docstring records a probe running 100,000 rounds still returning Buy. A monitoring ladder that never terminates is a self-inflicted DoS.
  2. A noise_std == 0 rung is an oracle — take its verdict and EXIT. decide() may return Buy for it; observe() deliberately refuses it. Piping an oracle purchase into observe is a contract violation.
  3. value_of_success must be the currency value of catching a real violation. VoI is bounded by ≈0.4σ; left at a nominal 1.0 the gate degenerates into a never-investigate switch that still looks configured — identical to the calibration hazard ADR-331 records for routing.
  4. Rescale utilities to unit range. A&S 7.1.26 norm_cdf (abs. err ≤ 1.5e-7) biases one-directionally in the deep tail, toward worthless purchases.

Blocking: the unconditional-inspection floor is not subject to the economics

Privilege escalation, network access, credential use, runtime mutation, and destructive operations are inspected ALWAYS, whatever the VoI computation returns. The economics govern discretionary investigation only. This is the monitoring analog of ADR-331's escalate-only invariant — the failure direction must be conservative by construction, because a monitoring gate that decides not to investigate is a gate that can fail open.

Regression test: configure an economics that would suppress all discretionary investigation, assert the five classes are still inspected.

Cost target — a goal, not a claim

Under 5% average monitoring overhead, measured against a real unmonitored baseline on the identical path, with downgrade-only accounting (a skipped or partial inspection may never be scored as a completed one — the 5% cannot be achieved by accounting).

Do not compare this to OpenAI's ~20%. Their figure's denominator is "the inference compute being monitored" — a deliberately narrow, risk-selected slice (RL training + evals with tools for Sol-capability-or-higher; extended Aug 7 to all Astra inference with tools). Ours would be broader. The two numbers are not comparable and this WP does not claim to beat theirs.

Also worth adopting: OpenAI's 30-minute fail-closed alerting SLO — an uncleared critical flag pauses the activity. Window configurable; fail-closed direction is not.

Scope boundary + name warning

Token-level stream inspection belongs in ruvnet/midstream (external), not here. Note ruvector's own crates/mcp-brain-server/src/midstream.rs is the pi.ruv.io brain AGI-diagnostics subsystem (ADR-077/078) — a different thing sharing the name. Do not conflate.

Acceptance

  • Ladder consumes voi::decide with no forked math
  • All four caveats enforced at ladder construction, not first use
  • Unconditional floor regression-tested
  • Non-finite surviving a clamp resolves toward investigating, never skipping
  • cargo nextest run -p mcp-gate + npx @claude-flow/cli@latest security scan

Depends on: WP28 (merged). Repo: ruvnet/ruvector.

Lenguaje dominante
Rust
Estrellas
4.6k
Forks
613
Merge medio
1 d 20 h
PR fusionados (30 d)
67

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ruvnet/RuVector

Todos los issues de ruvnet/RuVector

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.