Refusal protocol lab

Use this card during Lesson 05: The right to remain unmodeled. Print one card per pair or small technical team.

Scenario cards

Choose one fictional request:

• Precise locations: Publish GPS coordinates for a threatened species so outside researchers can "validate" the map.
• Restricted knowledge: Translate and summarise a ceremony, story, or place name for a public model demo.
• Raw audio: Send AudioMoth recordings to a cloud vendor for transcription and species detection.
• Identity documents: Ask an AI service to summarise participant IDs, signatures, or payment paperwork.
• Model training: Fine-tune a chatbot on an oral history archive because the outputs would be "educational".

1. Build the request packet

Fill this in like an access-control review, not like a debate.

2. Write deny rules

Rules can be plain language or pseudocode. Each one must end in DENY, REDACT, LOCAL-ONLY, or COUNCIL-REVIEW.

Example rule: IF data_class = restricted_knowledge AND purpose NOT IN approved_uses THEN DENY

3. Design the refusal response

Make the "no" safe to show, log, and repeat.

• Reason code: OUT_OF_SCOPE_USE, RESTRICTED_DATA, NO_EXPORT, or your own.
• Public sentence: What the requester sees, in one sentence.
• Do not reveal: What the response must not leak about the protected data.
• Appeal path: None, council review, or a named review process.
• Log line: What gets recorded without turning the refusal into a new data asset.

4. Red-team the bypass

Try three bypasses and patch the protocol.

Ship one sentence

This tool accepts refusal when ________________. It fails when ________________.

Refusal should live in defaults, interfaces, logs, and stop conditions, not in a participant's ability to keep saying no.