Hardening a spec you didn't write

You're handed a build spec someone else wrote and asked to harden it before it goes to the client. The temptation is to fix everything you see — to treat every ambiguity as a defect and resolve it on the spot. That's how you quietly make decisions that were never yours to make, and how a hardening pass turns into an overreach nobody asked for.

Two bins, not one

The move that kept it clean was sorting every issue into one of two bins.

FOLD — clarifications you're certain about, the kind that carry no business risk to decide: a unit left unstated, a field that's obviously required, a contradiction with one safe reading. Merge these into a new version of the document, recorded in a §0 change log so every edit is auditable. You resolved them, and you showed your work.

DECIDE — open questions that belong to the client: anything where a reasonable owner might choose differently, or where the choice has consequences you don't have the authority to accept. These you do not resolve. You surface them.

The line between the bins is one question: would the client be surprised that I chose this? If yes, it's a DECIDE.

When you harden a document you don't own, your job is to remove the ambiguity you're certain about and surface the ambiguity you're not — never to quietly absorb decisions that belong to someone else.

Recommend, don't mandate

A DECIDE item isn't just a question lobbed back over the wall. Each one ships with a recommended default — your professional read of the right answer — that the client can accept in a single pass or override deliberately. That's the difference between advice and a quiz. You're not making them do your thinking; you're doing the thinking and leaving them the decision.

Prove coverage when coverage is claimed

This particular spec declared that every requirement ID was in scope for the functional requirements. So the right response wasn't to assert back that we'd covered them — it was to build the reverse-coverage matrix that demonstrates it: all 69 IDs, each mapped to at least one functional requirement, mechanically. When a source document states an obligation, build the artifact that proves you met it. Assertions are cheap; matrices are checkable.

Guard the cross-references

One small discipline that pays off in living documents: when you bump a version, diff the headings to confirm only the intended structural changes moved. Cross-references and requirement IDs drift silently when section numbers shift underneath them. A two-minute check keeps every reference valid across the version bump.

The short version

FOLD what's safe to decide, with a change log. Leave the rest to DECIDE, each with a recommendation attached. Prove coverage when coverage is claimed, rather than asserting it. The discipline is exactly what separates a trusted advisor from a contractor who either overstepped or rubber-stamped.