Chapter 13: Specification Development and Finalization

This chapter covers the practical mechanics of getting from a blank page to a published specification — the lifecycle, the key distinctions in spec drafting, compliance programs, versioning, and the path to international recognition.

13.1 The Lifecycle of a Specification

Pre-Draft and the Power of the First Proposal

Every specification starts somewhere, and where it starts matters more than most people realize.

In some working groups, the initial draft emerges organically from group discussion — everyone sits down with a clean sheet of paper and drafts together. But more often, someone shows up with an existing proposal. A company that has technology in the market, a research team with a prototype, or an engineer with a detailed vision contributes an initial document that becomes the starting point for the group's work.

As discussed in Chapter 11, this pre-draft advantage is one of the most powerful dynamics in standards. The initial architecture, the terminology, the technical approach — these all carry forward into the final spec, even after extensive iteration. A company whose technology starts as the pre-draft has a significant backwards-compatibility advantage. Their existing products are more likely to align with the final standard.

In organizations like JDF, there's a formal concept of a "pre-draft" submission. Multiple companies may bring competing proposals, and the group has to decide which one to use as the starting point. This decision is often political as much as technical. If there are three competing proposals and the group takes a majority vote, the losers may simply leave — and their implementation support leaves with them. The better approach is usually to combine proposals where possible, even if the result is an awkward starting point, because the goal is to keep everyone at the table.

Working Drafts and Iteration

Once the starting point is established, the work proceeds through iterative drafts. Engineers propose changes, the group discusses them, and the chair incorporates what has consensus. This is where most of the technical work happens — draft by draft, issue by issue.

From an IP perspective, this phase is important but often overlooked. Patent commitments typically don't lock in until the spec is finalized. Contributions during the drafting phase are provisional. This means participants can evaluate the evolving spec and decide whether to stay or withdraw before the commitment crystallizes.

One practical note: keep track of what's changing between drafts. If the scope drifts — the microwave starts becoming a toaster — that's when you need to flag the issue, not after the final draft is published.

Public Review and Comment Resolution

Most standards processes include a public review period before finalization. The draft is published, and parties outside the working group — including potential implementers, competitors, and the broader community — have an opportunity to comment. ANSI-accredited organizations are required to provide a public review period as part of their due process obligations, and many non-accredited organizations follow similar practices because it strengthens the legitimacy of the standard.

Comment resolution is one of the most process-intensive parts of standards development. Every comment must be reviewed. Every objection must be addressed — not necessarily accepted, but responded to with documented rationale. Organizations that skip this step, or that handle it pro forma, create governance risk. As discussed in Chapter 4, the right to be heard is a core element of due process, and documented comment resolution is part of the antitrust defense.

Final Approval and Publication

The final step is formal approval by the working group (and sometimes by a higher governing body) followed by publication. This is when patent commitments lock in, exclusion windows close, and the spec becomes the canonical reference that implementers build to.

The publication format matters. Some organizations sell the spec — ISO/IEC standards, for instance, are available for purchase. Others publish freely. Some use Creative Commons licenses. Some put specs on wikis. As discussed in Chapter 3, the copyright and distribution terms should support the goals of the standard: broad access for implementation, protection against unauthorized forking, and a canonical version that implementers can rely on.

13.2 Normative vs. Informative Text

Every specification contains two types of content, and the distinction has direct consequences for patent commitments.

Normative text is the part of the spec that implementations must follow. It describes requirements, interfaces, and behaviors that are necessary for compliance. Normative text is what patent commitments cover — if a claim reads on normative text, it may be a necessary claim.

Informative text — examples, explanations, appendices marked as non-normative, implementation guidance — exists to help readers understand the spec but doesn't create compliance requirements. Patent commitments generally don't extend to informative text.

This distinction matters because spec authors sometimes put substantive content in informative sections, either inadvertently or to reduce the patent commitment surface area. If a critical feature is described only in an informative appendix, implementers who rely on it may not have patent protection. When reviewing a spec, check where the technically important content lives. If it's informative, ask whether it should be normative — and understand the IP consequences of the answer.

Reference Implementations and Test Suites

Some standards bodies produce reference implementations alongside their specs — working code that demonstrates the spec can be implemented and that serves as a testable baseline.

Traditionally, reference implementations were intended solely for verification: does the spec work? Can it be implemented? If the reference implementation doesn't work, is the problem in the code or in the spec? These implementations were not intended for production use and were typically unoptimized.

Increasingly, standards bodies are producing open source implementations intended for actual deployment. This creates a convergence with the open source world discussed throughout this book — and it creates governance questions. Is the code subject to the standards body's patent policy or to its open source license? What happens when the open source implementation diverges from the spec? Who is the authoritative source — the document or the code?

Test suites serve a related function. They provide automated verification that an implementation conforms to the spec. Test suites are particularly valuable for interoperability — two implementations that both pass the test suite should interoperate, at least for the features the suite covers.

When Code Is the Spec

In some domains — encryption algorithms, compression codecs, certain protocol behaviors — the specification cannot be fully expressed in human-readable text. The algorithm itself is the standard. In these cases, the code is not a reference implementation of the spec. It is the spec.

This has IP implications. If the code is the normative specification, then patents on the algorithm — not just on the interface — may be necessary claims. The usual distinction between interface patents (covered by the commitment) and implementation patents (not covered) breaks down when the implementation is the standard.

13.3 Compliance and Certification

Self-Certification vs. Third-Party Testing

As discussed in Chapter 3, conformance programs come in several forms. Self-certification is lightweight and common. Third-party testing is heavier but provides more assurance. Hybrid approaches — formal testing for the first product, self-certification for subsequent ones — balance rigor with efficiency.

The choice between these models depends on the stakes. For safety-critical standards, third-party testing is often required by regulation. For software interoperability standards, self-certification is usually sufficient.

Certification Marks and Branding

The certification mark — the logo that goes on the product — is often the most commercially significant piece of IP in the standards ecosystem. As discussed in Chapter 3, retailers may refuse to stock products without the logo, and customs officers may seize products that bear the logo without proper licensing.

For practitioners, the key question is what the certification program actually tests. If it tests only normative, mandatory features, it aligns with the spec. If it tests optional features — elevating them to de facto requirements through the certification process — there's a gap between what the spec says and what the market demands. That gap creates both compliance risk and patent risk.

Interoperability Testing Events

Plugfests — organized events where multiple companies bring their implementations and test interoperability in real time — are one of the most effective tools for ensuring a spec works in practice. They surface ambiguities in the spec, implementation bugs, and interoperability issues that no amount of document review can find.

From a legal perspective, plugfests require careful handling. Competitors are sharing technical details about their implementations in a common venue. Confidentiality rules need to be clear. Patent implications need to be understood. And the results — which products interoperate and which don't — can be commercially sensitive.

13.4 Versioning and Maintenance

Minor Revisions vs. Major Versions

Standards evolve. Bug fixes, clarifications, and minor enhancements produce point releases (1.0 → 1.1 → 1.2). Significant changes in scope, architecture, or functionality produce major versions (1.0 → 2.0).

The distinction matters for patent commitments. As discussed in Chapters 7 and 8, a commitment to version 1.0 may or may not carry forward to version 1.1 or 2.0, depending on the policy. Minor revisions that correct errors without changing the normative content are usually covered by the original commitment. Major versions that add new normative content may require new commitments — and trigger new exclusion windows.

Backward Compatibility

One of the most difficult design decisions in versioning is how to handle backward compatibility. A new version that breaks compatibility with the old version fragments the ecosystem. A new version that maintains perfect backward compatibility may be constrained in what it can improve.

The approach varies by domain. Web standards tend to prioritize backward compatibility heavily — the web can't break existing websites. Protocol standards for new industries may prioritize feature advancement and accept that older implementations will need updating.

Sunsetting and Deprecation

Standards rarely die formally. They fade — implementations persist in the field long after the working group has moved on, and the spec sits on a shelf (or a website) indefinitely. As discussed in Chapter 11, the longevity problem is one of the most under-appreciated challenges in standards governance.

Explicit deprecation policies — formal declarations that a version is no longer maintained, no longer recommended for new implementations, and will eventually lose support — help manage this lifecycle. But even deprecated standards can persist in the field for decades. The VHS tape is no longer manufactured, but VHS players still exist. Standards work the same way.

13.5 International Transposition

The PAS Process

As discussed in Chapter 2, the PAS (Publicly Available Specification) process allows a consortium-developed specification to be submitted to ISO/IEC JTC-1 for an international vote. If the national bodies approve, the consortium spec becomes a formal international standard — with all the treaty-level weight, government procurement advantages, and regulatory recognition that entails.

The PAS process is a bridge between the speed of consortium development and the formality of international recognition. You develop where you want, then layer the international status on afterward. Organizations like W3C and the Joint Development Foundation have PAS submitter status, which means their specs can go through this process.

There's also a strategic use of the PAS process that's worth naming because it drives a meaningful share of the submissions that actually go through. Industry sometimes pushes a specification up to ISO/IEC not because it needs the international imprimatur for its own sake, but because international standards transpose downward into national standards systems in jurisdictions where consortium specs do not. China is the canonical example. A consortium specification developed at, say, the USB Implementers Forum or the Trusted Computing Group has limited standing in the Chinese national standards system on its own. The same specification, once accepted as an ISO/IEC international standard, can be transposed to a GB national standard and recognized in Chinese procurement and regulation. USB, UPnP, and TPM specifications all followed roughly that path. When you see industry investing in a PAS submission for a spec that already has effectively universal market adoption, the answer to "why bother?" is often a downstream national adoption strategy in a market where the international route is the only practical one.

National Body Voting and Comment Resolution

The international ballot process is its own governance challenge. National bodies vote — not individual companies. Each country's position is determined by its national body through its own process. Companies lobby their national body for the vote they want, but ultimately the vote is the nation's, not the company's.

The comment resolution process at the international level is formal and documented. National bodies submit comments with their votes, and the submitting organization must address those comments before the spec can advance. This is where the diplomatic skills discussed in Chapter 14 become relevant — building coalitions across national bodies, understanding each country's concerns, and managing the process to achieve the required voting threshold.

Regional Regulatory Adoption

Beyond formal international standardization, standards are increasingly adopted by reference in regional regulations — the EU Cyber Resilience Act, AI regulations, data protection frameworks. When a regulation references a standard, compliance with the standard becomes a pathway to regulatory compliance. This gives the standard significant commercial value and creates incentives for participation in its development.

For practitioners, the implication is that standards work doesn't end at publication. Understanding the regulatory landscape — which standards are being referenced by which regulations in which jurisdictions — is increasingly part of the advisory role.