Severity overrides

"Computer, authorize manual override, Picard four-seven-alpha-tango." Sometimes the standing orders are right for the ship but wrong for this deck, this shift. You don't rip out the safety system — you log an authorized override and move on.

A severity override retunes or silences the diagnostics a directive's own rules emit, without removing the rule. Three meta-atoms (warn=, error=, off=) plus the line-scoped disable-next-line give you a scalpel instead of "delete the rule". The target is a rule name or a diagnostic code (comma-separated for several); an unknown target is a no-op and reports unknown-override-target with a did-you-mean.

Downgrade to a warning — warn=

Keep the check, but don't block the merge on it. A warning shows in the report and leaves the exit code at 0:

<!-- mdv: block required minWords=20 warn=too-few-words -->
## Summary
<!-- mdv: endblock -->

A short Summary now prints 0 errors, 1 warning instead of failing. warn= (and error=) also enables a flag rule you name — warn=noPlaceholder turns the check on at warning severity, so you don't have to list it twice.

Upgrade to an error — error=

The mirror image: promote a normally-soft diagnostic to a hard failure. The each.falsifiable heuristic, for instance, emits vague-evidence as a warning by default — an occasional false positive should nudge, not block. Once a team trusts it, error=vague-evidence makes that quality bar non-negotiable:

<!-- mdv: evidenceList required each.falsifiable error=vague-evidence -->
## Evidence
<!-- mdv: endevidenceList -->

Now a vague bullet like - Looks good. fails the run instead of merely warning. (error=each.falsifiable — naming the rule instead of the diagnostic code — has the same effect.)

Silence it — off=

Turn one diagnostic off for this directive, leaving every other rule live:

<!-- mdv: block required minWords=20 off=too-few-words -->
## Summary
<!-- mdv: endblock -->

off= only ever silences — unlike warn=/error=, it never enables a rule you didn't ask for.

One-line escape hatch — disable-next-line

When the exception is the document's, not the contract's, suppress a diagnostic for the next directive only — and note why, after a -- reason marker (disable-next-line is sugar for off= scoped to the following line):

<!-- mdv: disable-next-line too-few-words -- stub section, filled in next sprint -->
<!-- mdv: block required minWords=20 -->
## Summary
<!-- mdv: endblock -->

Everything after -- is for human readers — it shows up in the diff and git blame, but mediva parses only the rule name and discards the reason, so it is a convention, not an enforced or stored field. Still, an override without a rationale is just a hole in the hull.

When to reach for an override

• Adopting incrementally — warn= a rule the team isn't ready to hard-gate yet, then promote it to error= once the shape settles. (See Strictness for the same dial-it-up philosophy.)
• A genuine, documented exception — disable-next-line … -- reason for the one section that legitimately breaks the rule, with the why noted inline for the next human reader.
• Reach for an override, not a deleted rule, so the policy stays intact for every other document the contract guards.