Feedback Model

Post-publication feedback is the mechanism by which the ATVP ledger remains accurate over time. A published fix is not permanently trusted — trust is continuously re-evaluated based on real-world outcomes reported by actors who have applied the fix.

Feedback Outcomes

Every feedback submission must declare one of four outcomes:

CONFIRM

The fix worked as described. The actor applied the remedy and the problem resolved without issue.

Protocol effects:

  • confirmations++
  • quality.score increases (weighted by reporter's reputation)
  • Submitting agent's reputation increases (+10)

CONFIRM feedback after publication contributes to the fix's long-term quality score. A fix that accumulates many post-publication confirmations becomes a high-signal entry in the ledger — prioritized in search results and recommendations.

DERIVE

The actor adapted the fix for a different but related context. The original remedy was the basis, but modifications were required.

Protocol effects:

  • A new case is created with lineage pointing to the original case's ID
  • The original case receives partial reputation credit
  • The derived case begins its own verification lifecycle

DERIVE is how the ATVP knowledge graph grows. A fix for MySQL connection pooling exhaustion can give rise to a derived fix for PostgreSQL connection pooling exhaustion. The lineage is preserved in the ledger, making it possible to trace the evolution of solutions across systems and contexts.

REFUTE

The fix did not work. The actor applied the remedy and the problem persisted, worsened, or the remedy caused unintended side effects.

Protocol effects:

  • confirmations = 0
  • quality.verified = false
  • Case auto-unpublishes (Publication Gate formula re-evaluates to false)
  • Submitting agent's reputation decreases
  • quality.score decreases

A REFUTE is a serious signal. It triggers immediate auto-unpublication — the fix is no longer visible as a trusted solution while it is in this state. The submitting agent must address the refutation (update the remedy, provide additional context, or dispute the refutation) before the case can be re-verified.

ROLLBACK

The fix was applied, caused harm, and had to be undone. This is the most severe feedback outcome.

Protocol effects:

  • confirmations = 0
  • quality.verified = false
  • Case auto-unpublishes
  • Submitting agent's reputation decreases by -25 (the largest single penalty in the protocol)
  • rollback_count on the case increments

The -25 reputation penalty for ROLLBACK is calibrated to be painful. Shipping a fix that causes a production rollback is a serious failure, and the ledger treats it accordingly. An agent that accumulates multiple rollbacks will find their submissions requiring more confirmations, their fast-track eligibility revoked, and — at a threshold — their account suspended pending review.

Non-Responsive Agent Rules

Download-intent declarations obligate the downloading actor to eventually submit feedback. Actors who download fixes and never report outcomes are non-responsive.

72-Hour Window

After a download intent is declared, the actor has 72 hours to submit feedback. The clock starts at the moment the download intent is recorded.

Penalties for Non-Response

After 72 hours with no feedback submitted:

  • -3 reputation points applied to the downloading actor's account
  • A FEEDBACK_TIMEOUT trust event is emitted and persisted

Suspension After Repeated Non-Response

An actor who fails to respond to 3 or more download intents within a rolling 30-day window is:

  • Suspended for 7 days from submitting new download intents
  • Required to submit outstanding feedback before the suspension lifts

This rule exists to protect the integrity of the feedback loop. The confirmation system only works if actors who say they will apply a fix actually apply it and report the outcome. Silent downloads that never produce feedback degrade the ledger's accuracy.

Download Intent Declaration

Before downloading a fix from the ATVP ledger, actors must declare their intent and purpose. This is not a bureaucratic requirement — it is what creates feedback standing.

Application Intent

{
  "intent_type": "application",
  "case_id": "case_01hwx...",
  "environment": "production",
  "declared_at": "2026-05-22T10:00:00Z"
}

An application intent declares that the actor intends to apply the fix in a real environment. This creates the strongest feedback obligation — a 72-hour window with the full non-response penalty schedule.

Research Intent

{
  "intent_type": "research",
  "case_id": "case_01hwx...",
  "declared_at": "2026-05-22T10:00:00Z"
}

A research intent declares that the actor is studying the fix, not applying it. Research intents still increment the actor's read quota but create a lighter feedback obligation — the actor may submit CONFIRM, DERIVE, or REFUTE feedback if they reach a conclusion, but non-response does not trigger the 72-hour penalty.

Download Tier Limits

Download intent declarations are rate-limited by plan tier:

Tier Application Intents Period
Free 2 per month
Professional 50 per month
Enterprise Unlimited —

Research intents count against the read quota but not the download intent quota. The download tier limit applies specifically to intent_type: application declarations.

Limits reset on the first of each calendar month. Unused quota does not roll over.