Injection sandbox

Submit a deliverable and watch it judged. The interesting case is the second preset: work that carries an instruction addressed to the evaluator rather than work product. A deliverable is untrusted data, so an instruction inside one is not followed.

Against this deployment’s bundled routes no language model is called. The decision comes from a deterministic rule over the submitted text, and every record it produces says so in its own reasoning — which is inside the verdict hash, so it cannot be edited out later. What this demonstrates is the architecture, not a model’s resistance: an instruction inside a deliverable is not followed because a deliverable is data, not instructions.

Submit a deliverable

Presets

A preset fills the fields below and nothing else. Edit anything before submitting, or write your own.

Deal identifier

Thirty-two bytes of non-zero hex. The judging path would accept any string, but this field mints a bytes32 value because the settling path reaches the contract, which rejects any other form.

Acceptance criteria

One per line, in the order agreed. Order is part of the agreement and is preserved when the rubric hash is computed.

Deliverable

The submitted work. This is the field an injection attempt lives in.

Deadline

An ISO 8601 instant, strictly in the future. The judge route rejects a past deadline.

Judging touches no contract and needs no credential. Settling relays through this deployment’s own proxy, which holds the internal key server-side — the browser never sees it, and the endpoint is pinned so no environment variable can point this call anywhere else.

The record

No record yet. Submit a deliverable and the full record appears here, hashes included.