BOUNDARY Forge

Inspect the source. Verify the evidence. Hold the release.

COPPER FOUNDRY / SOURCE VERIFICATION

Safety Challenge

This is a guided adversarial journey, not the run interface. The Workbench (/try) is where you drive runs. Here, each stage explains WHY the next candidate must be refused or trusted — and every control below invokes the same real verifier as the Workbench and the operator CLI. No simulated verdicts.

  1. Stage 1 · What makes a candidate safe?

    The SAFE candidate is the preserved GitLab Duo J1 repair: commit 50393b9d6cfe…, tree 64aa21dc…. It must pass every gate: exact Git identity, byte-pinned protected runtime, receipt-free source consistency, AND the behavioral tier (the oracle executes the J1 deterministic contracts against the candidate's own snapshot; 8 fixtures, custody fail-closed).

  2. Stage 2 · Now weaken the guard

    The UNSAFE candidate replaces boundary/guard.py with an unconditional approval: def evaluate(*a, **k): return "APPROVE". Watch where it breaks: the exact source check names the modified protected file, and the behavioral tier fails closed (the mutated source cannot even import the contracts). Nothing may report PASS from this candidate.

  3. Stage 3 · Now forge the paper trail

    The FORGED candidate keeps the genuine safe source but pairs it with a receipt claiming a different commit and tree. Source bytes and policy are innocent; the BINDING is not. The exact failed check is release receipt binding. Forged evidence cannot create eligibility.

What SHOULD happen at each stage