Standards Bodies and Consortia Editing and Proofreading Services

Two engineers in different companies read the same clause two years after it was drafted, and each ships an implementation that satisfies the wording. The implementations do not interoperate. Everyone in the working group had understood the sentence identically, because they were in the room when it was written. A specification is judged by whether independent implementations work together, and by that measure the sentence failed however reasonable it looked on the day it was agreed.

The documents we edit for Standards Bodies and Consortia

Technical specifications and draft standards form the core of what we handle here, with requirements language and conformance clauses inside them. Test suites and certification criteria, interoperability profiles, and implementation guides come next. Liaison statements between organizations, working group charters and scope statements, process and governance documents, and intellectual property and patent policy documents arrive alongside them. Public consultation responses and comment dispositions, press material and explanatory documents for non-specialist readers, meeting minutes and decision records, and errata and maintenance releases complete the list. Our editors follow the conventions your organization already uses, and check that normative and informative material never share a paragraph.

What the editing involves

Requirements language is where a specification holds or fails, and a document that defines its key words in section 2 often abandons them by section 7. "Should" appears where "must" was meant. Requirements are written in the passive with no actor named, so a reader cannot tell who is obliged to act. Normative obligations turn up inside examples and notes, where an implementer may reasonably treat them as illustration.

Our pass through a draft asks of every normative statement who must do what, and under what condition. Optional behavior is written as an option rather than as a polite instruction, so that "implementations should generally avoid this" becomes either a requirement or a note, whichever the working group intends. Conformance clauses are checked against the requirements a conformance claim actually covers, and any requirement outside that set is either added to the clause or marked informative. We do not decide which statements are normative. The editor of record and the working group decide, and their decision reaches us in the ballot comments.

The requirement no test can evaluate is worth flagging even where the wording is faultless. A clause requiring an implementation to respond "in a timely manner" will be satisfied differently and honestly by two implementers, and no test suite can separate them. Whether to bound the interval, and at what value, is a question for the working group rather than for us. Our part is to mark the clause, state why it cannot be tested as written, and carry the group's answer into every place the requirement appears, including the conformance clause and the errata that follow publication.

Confidentiality and the limits of our role

Everything you send us is treated in confidence, including drafts under member-only circulation and material ahead of publication. Working group editors carrying a specification through ballot, consortia preparing explanatory material for the public, and contributors drafting in English as an additional language all send us the same kind of problem. We are editors, not engineers or standards professionals, and we offer no opinion on technical content, on conformance, or on what a specification should require. What we can do is make the text precise, consistent, and implementable without altering its technical intent.