Punisher

VECTOR archive › Governance stack › Punisher

Containment and rebalancing keep a degraded system running. Neither makes it well. Punisher is the protocol that attempts to repair what failed, and it is the point in the governance stack where the system does something genuinely difficult to predict.

Historical context

The protocols before Punisher are deterministic: thresholds, comparisons, defined responses. Repair resists that treatment, because diagnosing why a component failed and choosing among possible remedies is a judgement rather than a lookup.

That makes Punisher the first component where a learned model was admitted into the governance chain — under governance before intelligence, the surrounding structure had to exist first, and it did.

Responsibilities

Punisher owns incident diagnosis and the ranking of repair strategies by risk.

Punisher never owns the decision to restore service. A repaired component is not returned to the working set by Punisher; that is Phoenix. It also does not own its own restraint — the credit budget that governs how often it may act is a property of the protocol, not a judgement it makes.

Inputs

Incident context: what failed, the anomalies preceding it, the containment actions already taken, and the current stress state. Its own credit balance is an input to whether it acts at all.

Outputs

A diagnosis, and a set of repair strategies ranked by risk. Consumed downstream and by the audit record — the ranking is retained, not only the strategy chosen, because an incident review needs to know what the alternatives were.

Internal behaviour

A dual-head neural network. One head diagnoses the incident; the other ranks candidate repair strategies by risk. Sharing a representation between the two reflects that the appropriate remedy depends on the nature of the failure, and the heads are separate because the outputs answer different questions.

The more consequential mechanism is not the network. It is the adaptive credit system that governs it: credits regenerate at 0.02 per second to a maximum of 10, and acting consumes them.

This makes aggression a budget. A system experiencing repeated failures depletes its credits and becomes progressively more conservative — not because a rule detected a repair loop, but because the resource that repair requires has run out. Thrashing is prevented structurally rather than by a heuristic that has to recognise thrashing while it is happening.

The regeneration rate is the design decision worth noticing. At 0.02 per second, a full budget takes over eight minutes to accumulate. Repair is explicitly not something the system may do continuously.

Interactions

Atlas → Punisher → Phoenix

Punisher runs after containment and rebalancing have stabilised the system, and before recovery. The ordering means repair is attempted on a system that is no longer actively degrading — diagnosis against a moving target is diagnosis of the movement.

It is gated by stress state and by credit balance, and its behaviour is further constrained when VIHAAN is active.

Failure modes

Misdiagnosis. A wrong diagnosis produces a repair aimed at the wrong problem, consuming credits and changing system state without improving it. Risk ranking is the partial defence — preferring low-risk strategies means a wrong diagnosis is less likely to be destructive — but a confident wrong answer remains possible and is the residual risk of admitting a model here at all.

Credit exhaustion during a genuine emergency. The budget does not distinguish wasted attempts from necessary ones. A system that has legitimately needed many repairs arrives at a real incident with nothing left. This is a deliberate acceptance: the alternative is an unbounded repair loop, which is worse.

Repair that worsens conditions. Mitigated by the ranking and the budget, and not eliminated. Escalation past Punisher to shutdown exists for the case where it is not contained.

Design tradeoffs

A learned model inside the governance stack. Everything before Punisher can be reasoned about exhaustively. This cannot. The justification is that repair genuinely requires judgement — but it means the stack contains one component whose behaviour under unprecedented conditions is not fully predictable, and that should be stated plainly rather than qualified away.

A budget rather than a rule. A credit system is cruder than logic that detects repair loops directly. It is also far harder to defeat: a rule has to recognise the pathology, and a budget does not have to recognise anything.

Future evolution

The most valuable addition would be outcome feedback — closing the loop so that whether a repair actually worked informs later ranking. Whether the current design does this is not something the available sources state, and it should not be assumed.

A credit rate that varies with stress state, so that a system in genuine crisis is not rationed identically to one in routine difficulty, is the other direction. Inference, not planned work.