Alternative Means Builder

An alternative means request is refused for one of two reasons: it argues that the requirement is inconvenient rather than that the intent is met another way, or it asks the official to take the applicant's word for something. Both are avoidable, and both are decided before anything is written.

Workflow

Step 1. Establish the requirement and why it fails

Ask, in one message:

1. Quote the section that cannot be met, in full, with its edition.
2. Does the code publish intent or commentary for it? Quote that too.
3. Why can it not be met? Physically impossible, an existing building condition, a conflict with another requirement, a preservation constraint, or cost?
4. What is proposed instead?
5. What analysis exists, and who performed it?
6. What is the authority's own procedure and format for these requests?
7. Has the authority been approached informally, and what was said?

Question 3 decides whether there is a case. Cost alone is rarely a basis. If that is the honest answer, say so plainly before anything is drafted, and say that the request will be read as asking for relief rather than equivalency. That is a conversation to have now.

Step 2. State the intent in the code's words, not yours

Set out what the requirement exists to achieve, quoting the published intent or commentary. If the code publishes none, say so explicitly and state the intent as the applicant's reading, labelled as such.

This is the hinge of the whole request. Everything after is measured against it, and an intent the applicant invented to be easy to meet is the objection the reviewer will raise first.

Step 3. Set out the proposal against the intent, point by point

Intent element (quoted)	How the prescriptive requirement serves it	How the proposal serves it	Evidence

One row per element of the intent. Not a general claim of equivalency; a demonstration for each thing the requirement was doing.

Where a row has no evidence column filled, that row is a gap, and gaps get counted rather than smoothed over.

Step 4. Separate compensating measures from the proposal itself

Two different things that get merged:

• The proposal. What is being done instead, which meets the intent.
• Compensating measures. Additional provisions offered because the proposal does not fully meet the intent on some element.

State them separately. A request that presents compensating measures as though they were the equivalency is a request that has conceded the argument without noticing.

For each compensating measure, say who maintains it and for how long. A measure that depends on an operational procedure needs an owner and a mechanism, or it lapses at the first change of tenant.

Step 5. Offer conditions, and test the case against its objections

Conditions. What the applicant will accept as a condition of approval: recording on the certificate of occupancy, periodic testing, a maintenance agreement, a restriction on use or occupant load, a limit on the approval's transferability. Officials approve more readily when the applicant has already named the constraints.

Objections. Then attack the case:

• Which element of the intent is least well served, and what is the answer to that?
• What does this set as a precedent in this jurisdiction, and would the official be comfortable with the next applicant citing it?
• What happens if the compensating measure fails or is removed?
• Is there a redesign that avoids the request entirely, and has it been costed? If not, the official will ask.

Report the weakest element by name. A request that does not know its own weak point will be told what it is.

Step 6. Assemble in the authority's format and report

• The request, in the order above, in the authority's format if one was given.
• The evidence list, with each item's author and reference.
• Counts: intent elements addressed, intent elements with no evidence, compensating measures, conditions offered.
• Every place the case rests on something not supplied, listed individually.

Close with the standing limits: nothing was recalled, no analysis was performed here, no precedent was cited, and approval is the authority's alone.

Step 7. Save, if asked

Ask whether to write the request to a file and where.

Rules

• Never supply code text, intent language, or a referenced standard.
• Never cite a precedent from another jurisdiction unless the user supplies it as a document with a reference.
• Never perform the analysis. Cite the engineer's report or state that none exists.
• Say plainly when cost is the only reason the requirement cannot be met.
• Address the intent element by element, never as a general claim of equivalency.
• Keep compensating measures separate from the proposal.
• Name the weakest element of the case in the output, every run.
• Never predict approval.

Anti-patterns

• Arguing that the requirement is unreasonable rather than that the intent is met.
• Stating the intent in the applicant's words when the code publishes its own.
• Presenting compensating measures as the equivalency argument.
• Citing what another jurisdiction accepted from recollection.
• Claiming a modelling result without the engineer's report behind it.
• Offering no conditions, which asks the official to take on the whole risk.
• Submitting in a format other than the one the authority prescribes.
• Hiding the weakest element rather than answering it.

Resources

None. This skill is one file. Output is written directly at the path you choose.