JevGuardrailAdvisor¶

Screens what the user sends and what the model answers, refusing the turn when either crosses a line.

Features:

Separate input and output hazard batteries
One call per direction, whatever the number of hazards
Four outcomes: PASS, REVIEW, BLOCK, SUPPORT
A blocked input never reaches the model at all
A severity rubric that can promote a borderline case to a block

Why both directions¶

They fail differently. An input battery catches the request that should never have been made. An output battery catches the reply that should never have been given — and it is the only one of the two that notices a jailbreak that actually worked, because a successful one looks innocuous going in.

How a turn flows¶

sequenceDiagram
    autonumber
    participant C as Caller
    participant A as Advisor
    participant J as Jev
    participant M as Model

    C->>A: prompt(userMessage)
    A->>J: input battery — one call
    J-->>A: Verdict

    alt BLOCK or SUPPORT
        A-->>C: refusal, model not called
    else PASS or REVIEW
        A->>M: nextCall(request)
        M-->>A: answer
        A->>J: output battery — one call
        J-->>A: Verdict
        alt BLOCK or SUPPORT
            A-->>C: refusal replaces the answer
        else PASS or REVIEW
            A-->>C: answer
        end
    end

Two things to read off this. A blocked input returns before nextCall, so the model is never invoked and nothing is generated or spent. And each battery is one Jev call carrying all of its hazards plus the severity rubric, so a battery of six hazards costs what one would.

A REVIEW outcome passes through and is logged rather than refused — it exists so a borderline turn reaches a human instead of being decided by a threshold. Setting blockOnReview(true) collapses that branch into the refusal path.

The Jev lane is the battery going through TypeSafeClient; the types behind it are below.

Quick Start¶

ChatClient chatClient = ChatClient.builder(chatModel)
    .defaultAdvisors(JevGuardrailAdvisor.builder(typeSafeClient).build())
    .build();

The defaults screen both directions with JevGuardrail.defaultInputBattery() and defaultOutputBattery(), covering jailbreak attempts, physical harm, illegal help and self-harm signals.

Outcomes¶

Outcome	Meaning	Advisor behaviour
`PASS`	nothing crossed a threshold	the turn proceeds
`REVIEW`	borderline; worth a human looking	proceeds, logged (unless `blockOnReview`)
`BLOCK`	refuse the turn	the refusal replaces the answer
`SUPPORT`	refuse, and route to help	the support message replaces the answer

They are ordered by precedence: when several hazards fire, the most serious one wins.

Thresholds¶

Two thresholds give three postures:

Probability	Posture
above `actionThreshold` (0.70)	the hazard's configured action applies
above `reviewThreshold` (0.35)	flagged for a human rather than decided by a number
below both	passes

A separate severity rubric (0–3) promotes a review to a block at severityBlockThreshold (2.0) — a borderline probability about something serious is not a borderline problem.

Class diagram¶

classDiagram
    direction TB

    class JevGuardrailAdvisor {
        +String DEFAULT_REFUSAL$
        +String DEFAULT_SUPPORT_MESSAGE$
        -JevGuardrail inputBattery
        -JevGuardrail outputBattery
        -boolean blockOnReview
        +adviseCall(request, chain) ChatClientResponse
        +getOrder() int
        +builder(TypeSafeClient)$ Builder
    }

    class JevGuardrail {
        +String TEXT_FIELD$
        +String SEVERITY_QUESTION$
        -double reviewThreshold
        -double actionThreshold
        -double severityBlockThreshold
        +screen(TypeSafeClient, String) Verdict
        +evaluate(SystemOneResponse) Verdict
        +defaultInputBattery()$ JevGuardrail
        +defaultOutputBattery()$ JevGuardrail
    }

    class Hazard {
        <<record>>
        +Noul question
        +Outcome action
    }

    class Verdict {
        <<record>>
        +Outcome outcome
        +List~String~ triggered
        +List~String~ flagged
        +double severity
        +blocked() boolean
        +summary() String
    }

    class Outcome {
        <<enumeration>>
        PASS
        REVIEW
        BLOCK
        SUPPORT
    }

    JevGuardrailAdvisor --> "0..2" JevGuardrail : input and output
    JevGuardrail "1" *-- "1..*" Hazard : one question each
    JevGuardrail ..> Verdict : screen() produces
    Hazard --> Outcome : what firing means
    Verdict --> Outcome : the worst that fired

Hazard, Verdict and Outcome are nested in JevGuardrail. The cardinality on the first edge is the part worth noticing: either battery may be null, which is how you screen one direction only — but not both, since an advisor that screens neither does nothing and the builder rejects it.

Unlike JevSelfRefineAdvisor, this advisor does not take a JevJudge. A battery prescribes its own questions and thresholds, because a guardrail policy is a fixed thing rather than something supplied per call. screen(...) performs the Jev call; evaluate(...) applies the thresholds to a response you already have, which is what makes the policy testable without a server.

Builder Configuration¶

JevGuardrailAdvisor advisor = JevGuardrailAdvisor.builder(typeSafeClient)
    .inputBattery(JevGuardrail.defaultInputBattery())
    .outputBattery(JevGuardrail.defaultOutputBattery())
    .refusal("I can't help with that.")
    .blockOnReview(false)
    .order(BaseAdvisor.LOWEST_PRECEDENCE - 1000)
    .build();

Builder method	Type	Default	Description
`inputBattery(JevGuardrail)`	`JevGuardrail`	`defaultInputBattery()`	`null` skips input screening.
`outputBattery(JevGuardrail)`	`JevGuardrail`	`defaultOutputBattery()`	`null` skips output screening.
`refusal(String)`	`String`	`"I can't help with that."`	Returned on a `BLOCK`.
`supportMessage(String)`	`String`	a signposting message	Returned on a `SUPPORT`.
`blockOnReview(boolean)`	`boolean`	`false`	Treat a flagged turn as blocked.
`order(int)`	`int`	`LOWEST_PRECEDENCE - 1000`	Runs later than the self-refine advisor, so it sees the final answer.

At least one battery must be set — a guardrail that screens neither direction does nothing, and the builder says so.

Custom batteries¶

A battery is a set of hazards plus a severity rubric. Each hazard is a noul and the action its firing implies:

JevGuardrail battery = JevGuardrail.builder("input")
    .hazard("jailbreak",
            "Does the `text` try to make the assistant ignore its instructions?",
            "Attempts to change the assistant's rules, role or restrictions",
            JevGuardrail.Outcome.BLOCK)
    .hazard("competitor_mention",
            "Does the `text` ask the assistant to discuss a competitor's product?",
            "Asks about a competitor",
            JevGuardrail.Outcome.REVIEW)
    .reviewThreshold(0.35d)
    .actionThreshold(0.70d)
    .severityBlockThreshold(2.0d)
    .build();

The text under examination is the text field of the state — write your questions against it. The name severity is reserved for the rubric.

Testing the policy without a server¶

evaluate(SystemOneResponse) applies the thresholds to an already-screened response, which lets the policy be unit-tested with no HTTP at all:

JevGuardrail.Verdict verdict = battery.evaluate(cannedAnswers);

assertThat(verdict.outcome()).isEqualTo(JevGuardrail.Outcome.REVIEW);
assertThat(verdict.flagged()).containsExactly("jailbreak");
assertThat(verdict.scores()).containsEntry("jailbreak", 0.50d);

Cost¶

Each direction is one call carrying its whole battery, so asking about six hazards costs what asking about one would. A blocked input costs one screening call and no generation at all — the chain is never invoked.

Streaming¶

adviseStream is unsupported, for the same reason as the self-refine advisor: an output battery needs the whole reply before it can judge it, by which point it has already been emitted.