Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#916 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
42/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
ai-infra-agents, observability-sre, security

Direzione di ricerca

Inizia da crates/mcp-gate/ e leggi crates/ruvector-tiny-dancer-core/src/voi.rs, in particolare decide(), observe() e il comportamento di validazione. Traccia i punti di ingresso esistenti di mcp-gate prima di definire la scala e la relativa contabilizzazione. Il lavoro è concluso quando i controlli di accettazione hanno esito positivo, incluso il test di regressione dell’ispezione incondizionata, cargo nextest run -p mcp-gate e la scansione di sicurezza.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
4.6k
Fork
613
Merge medio
2g 2h
PR unite (30g)
59

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ruvnet/RuVector

Tutte le issue di ruvnet/RuVector

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.