feat: trust decay acceleration on FLAGGED attestations

[mdproctor]

Context

Currently trust decay is uniform — exponential decay is applied equally over time regardless of whether the agent has recent failures. A FLAGGED attestation (missed security issue, failed obligation) should steepen the decay curve, reducing trust faster after a negative outcome. This improves the signal quality of the trust model.

Part of: #49 (Group A epic)

Current behaviour

TrustScoreComputer applies exponential decay weighting to attestations by recency. All decay is time-based. A FLAGGED attestation from yesterday has the same decay weight as a SOUND attestation from yesterday — only time distinguishes them, not the valence of the outcome.

What to implement

In TrustScoreComputer (find it: find ~/claude/quarkus-ledger -name "TrustScoreComputer.java"):

Introduce a valence multiplier on the decay weight. FLAGGED attestations decay slower (persist longer as negative evidence); SOUND attestations decay normally.

Rationale: Trust is asymmetric. A single serious failure (missed security vulnerability shipping to production) should have lasting impact. Recovering from a FLAGGED attestation requires a sustained run of SOUND attestations, not just the passage of time.

// Conceptual change to decay weight calculation:
// Current: weight = exp(-lambda * ageInDays)
// New:     weight = exp(-lambda * ageInDays * valenceMultiplier(verdict))

private double valenceMultiplier(AttestationVerdict verdict) {
    return switch (verdict) {
        case FLAGGED, CHALLENGED -> config.decay().flaggedPersistenceMultiplier(); // default: 0.5 (slower decay = more persistent)
        case SOUND, ENDORSED -> 1.0; // normal decay
    };
}

A flaggedPersistenceMultiplier of 0.5 means FLAGGED attestations take twice as long to decay as SOUND ones — they persist in the model longer.

Configuration

Add to LedgerConfig:

quarkus.ledger.decay.flagged-persistence-multiplier=0.5

Default: 0.5. Range: 0.1 (very persistent) to 1.0 (same as SOUND, no change from current behaviour).

Tests

• Agent with one FLAGGED + three SOUND attestations at equal age has lower score than agent with four SOUND (no change from current)
• At flaggedPersistenceMultiplier=1.0, behaviour is identical to current (regression test)
• At flaggedPersistenceMultiplier=0.5, FLAGGED attestation retains 50% more influence after same elapsed time
• Config key is honoured

Motivating use case

An agent approves a PR that ships a security vulnerability. A FLAGGED attestation is written. The agent continues doing good work and accumulates SOUND attestations. With normal decay, the FLAGGED attestation fades quickly. With acceleration, the failure persists in the trust calculation — the agent's security-review score recovers more slowly, reflecting that security failures warrant sustained scrutiny before full trust is restored.

Acceptance criteria

• valenceMultiplier applied in TrustScoreComputer decay weight calculation
• Config key quarkus.ledger.decay.flagged-persistence-multiplier with default 0.5
• At multiplier=1.0, all existing trust score tests still pass (pure regression)
• New tests covering asymmetric decay behaviour
• Javadoc explaining the rationale on the multiplier config key

Refs #49

[mdproctor]

Consolidation check — extract DecayFunction at the same time

Before adding the valence multiplier, read TrustScoreComputer and check whether the decay weight calculation is a single hardcoded expression or already has any abstraction. Then:

If it is hardcoded: extract the entire decay function into a DecayFunction SPI at the same time as adding the valence multiplier:

@FunctionalInterface
public interface DecayFunction {
    double weight(long ageInDays, AttestationVerdict verdict);
}

@DefaultBean
@ApplicationScoped  
public class ExponentialDecayFunction implements DecayFunction {
    @Override
    public double weight(long ageInDays, AttestationVerdict verdict) {
        double base = Math.exp(-lambda * ageInDays);
        return base * valenceMultiplier(verdict);
    }
}

TrustScoreComputer then injects DecayFunction and delegates. Future decay strategies (linear, step, no-decay for testing) become @Alternative implementations — not code changes.

Why now: you are already inside TrustScoreComputer making a change. The extraction costs almost nothing extra and produces a significantly more extensible design. Coming back later requires re-entering this file, re-understanding the algorithm, and risks breaking the valence multiplier added in this issue.

If it is already abstracted: check whether the existing abstraction is sufficient for the valence multiplier and use it.