POLICY BENCH / NAC–PB1 / DEFENSIVE OPERATIONS

Write the safeguards before enforcement

A credible policy says when a signal matters, who reviews it, what disruption is acceptable, and how a player can challenge a decision. Set those boundaries here. The template is generated in this browser and sent nowhere.

LOCAL POLICY INSTRUMENT / NAC–PB1

Build a defensive policy

Four operator choices. Five visible layers. No account, upload, or remote request.

Choose the operating constraints, then generate a policy docket. The output describes safeguards and review rules; it does not judge software or players.

01 / Threat toleranceHow much unresolved risk the server accepts before a reversible response.

02 / Review staffingWho can inspect a signal before a player-facing decision.

03 / Acceptable gameplay costHow much disruption legitimate players may bear while a control is uncertain.

04 / Evidence policyWhat must exist before a signal can support an action.

Ready. The default docket is shown.

The default policy remains usable without JavaScript.Read or print the docket beside this note. The control register below defines the alternatives so you can substitute clauses manually.

Read every control definition

Threat tolerance

Low tolerance: Respond early, but keep the first response reversible.
Medium tolerance: Wait for corroboration before restricting play.
High tolerance: Observe longer and reserve intervention for reviewed patterns.

Review staffing

Solo operator: Queue cases when no reviewer is available.
Small team: Separate review from final action when coverage allows.
Covered review desk: Assign each case to a named reviewer and escalation path.

Acceptable gameplay cost

Keep cost low: Prefer silent observation and disable noisy controls quickly.
Allow limited friction: Permit brief, reversible limits with a clear notice.
Allow material friction: Permit temporary interruption after corroboration, with an impact record.

Evidence policy

Alert is context only: Signals inform staff but cannot independently justify action.
Corroborated signals: Require two independent signal families or direct staff observation.
Reviewed case file: Require a named reviewer, rationale, and retained decision record.

GENERATED LOCALLY / 2026-07-18

Defensive enforcement policy

Threat toleranceMedium toleranceReview staffingSmall teamAcceptable gameplay costKeep cost lowEvidence policyCorroborated signals

1. Scope
This policy covers player-behavior enforcement. Infrastructure protection, chat moderation, and world-visibility controls are documented separately so none are implied by the word anticheat.
2. Signals
Require corroboration before a signal changes a player's access. Require two independent signal families, or one signal plus direct staff observation, before action.
3. Action ladder
Use a reversible restriction only after corroboration; permanent action requires a completed review. Route durable actions to the shared review queue rather than relying on a single live alert.
4. Player safeguards
Controls begin in observation mode. A control that repeatedly burdens known-clean play is paused for review. Every notice names the affected policy and the review route.
5. Evidence and appeal
Record which independent observations agreed and which relevant observations did not. A second team member reviews permanent actions when available; any single-reviewer exception is recorded. Players may request review without admitting wrongdoing.

METHOD REGISTER / PUBLISHED DEFINITIONS

Evidence stays separate from policy

The builder documents operator choices. It does not claim those choices work. Measured claims require a named method, a versioned known-clean fixture, an untreated control where applicable, and an attached evidence record.

clean-play-signals / 2026-07-18

Clean-play signal observation

Count categorized detection events during a versioned known-clean fixture and compare distributions with an untreated control.

No measured result published

resource-cost / 2026-07-18

Resource-cost comparison

Compare MSPT, CPU, heap, and garbage-collection distributions under identical versioned load.

No measured result published

stack-compatibility / 2026-07-18

Stack compatibility record

Record whether a named server, proxy, translation, and client-mod stack completes a versioned fixture without an attributable conflict.

No measured result published

6 known-clean fixture definitions are published for inspection.Read the fixture register orcompare fixtures with methods.

Threat tolerance

Review staffing

Acceptable gameplay cost

Evidence policy

1. Scope

2. Signals

3. Action ladder

4. Player safeguards

5. Evidence and appeal

Clean-play signal observation

Resource-cost comparison

Stack compatibility record