Skip to main content
sociable systems.
Free tool · The DIY pass

The Always/Never Worksheet

Most AI policies break at their absolutes, because a hostile reader needs only one counterexample to void an always or a never. This free worksheet runs the first pass for you: list your absolutes, answer four questions on each, and see which ones survive.

Why absolutes break first

Your policy says what the system will always do, and what it will never be used for. Those are the lines a hostile reader goes for first.

An absolute is the easiest kind of promise to break. One example it cannot survive and the whole sentence is gone, along with some of the trust in everything around it. The readers who matter know this. A procurement team runs claims checks, a regulator looks for the enforcement behind the word binding, and a motivated executive reads the document the way a locksmith reads a lock.

This worksheet is the DIY version of the Always/Never Audit. It will not catch the edge cases your own team is too close to see. It will catch the absolutes you can already feel are soft, and show you how to rewrite them before someone outside the building does the finding for you.

Score your absolutes

Run the four questions on each promise.

The three examples below are the usual suspects. Replace them with the always and never lines from your own policy or pledge, answer the four questions on each, and the verdict updates as you go. Everything stays in your browser.

Your absolutes, under a hostile read
1 of 3 survive a hostile read
Can you name a real case where it would NOT hold?
Is there a named verifier who would catch a breach?
Is there a remedy when it breaks, not just a broken promise?
Is it fully in your control, not a vendor or model you do not run?
Cut or rewrite

As written, a hostile reader voids this with one example. Cut the absolute, or rebuild it around the control that enforces it and the remedy when it breaks.

Can you name a real case where it would NOT hold?
Is there a named verifier who would catch a breach?
Is there a remedy when it breaks, not just a broken promise?
Is it fully in your control, not a vendor or model you do not run?
Hedge it

Rewrite from absolute to default-plus-exception: “By default X, except in these named cases.” State who verifies it and what the remedy is when it fails.

Can you name a real case where it would NOT hold?
Is there a named verifier who would catch a breach?
Is there a remedy when it breaks, not just a broken promise?
Is it fully in your control, not a vendor or model you do not run?
Defensible

Keep it, and protect this wording through every future revision. It is a promise you can actually evidence.

Nothing you type leaves your browser. This is the DIY pass on the absolutes you can spot yourself.

Take it with you

The one-page worksheet, for paper or a workshop

Same method, as a printable form. Hand it round a room, or work it through against a document on your own. No sign-up.

Prefer not to share an email? Download it directly.

Where the DIY pass ends

The worksheet works the absolutes you can see. The audit finds the rest.

The Always/Never Audit reads your full document the way six hostile seats would, drafts the rewrites, and surfaces the nevers that are one reorganisation away from gone. The council finds; one human with 25 years in social-risk audit signs the memo. You get it in PDF and markdown within five working days.

See the Always/Never Audit →