3. What OASIS owes a TC

A Technical Committee asking what it gets from OASIS gets two different kinds of answer, and OASIS has never separated them in writing. Part of what OASIS does for a TC is required by written policy, and the governing clause can be named. The rest is practice: earned from real publications and held to consistently, backed by nothing except the decision to keep doing it. This chapter separates the two, then states the limits, because a limit OASIS has written down is as much a part of the contract as a promise.

The split shows in the acceptance criteria themselves. When the conditions OASIS confirms before it publishes were matched to their governing clauses in July 2026, the exercise covered the 96 conditions in the registry at that time: 38 were grounded in written policy and 58 were operational quality rules with no single written clause behind them.

Close to three in five of those 96 mapped conditions, OASIS confirms because it chose to. That ratio describes the mapped set and nothing wider. Nobody has repeated the mapping since, and the checks added on 21 July 2026 carry their governing clause inline in the registry rather than in the catalog, so the authority of every condition beyond the mapped 96 is unmapped rather than known to be earned.

#3.1 The obligations written into policy

An obligation is something OASIS is bound to do, where the governing clause can be quoted. These are not commitments OASIS chose. They are terms of the OASIS process, and they bind the TC and OASIS alike.

Four obligations govern what is published:

• All approved versions of OASIS Deliverables must be published in (1) editable source, (2) HTML or XHTML, and (3) PDF formats (TC Process 2.2.2).
• All documents and other files produced by the TC, including Work Products at any level of approval, must use the OASIS file naming scheme and must include the OASIS copyright notice (TC Process 2.2.1).
• Work Products must present three general kinds of URI as display metadata: This stage, Previous stage where applicable, and Latest stage. The latest-stage alias is the only one of the three that may be updated when a newer version is published (Naming Directives v1.7, 6.2).
• All normative computer language definitions must also be provided in separate plain text files (TC Process 2.2.5). Embedding a schema only in the document body does not satisfy the clause. Non-Standards Track Work Products are not subject to it.

One obligation governs what happens after publication, and the publishing workflow is built to satisfy it. URIs for published OASIS resources must be persistent, and resources published in the OASIS Library, the TC document repository and other venues must not be deleted or otherwise altered; resources may be revised, but all revisions are retained (Naming Directives v1.7, 6.3 and 6.4).

Two obligations constrain how names are formed:

• A stage abbreviation with its revision number must be used in lower case as a discrete path component for the document identifier, the document URI and the principal document filenames (Naming Directives v1.7, 5.2).
• A directory must not contain two or more names, filenames or directory names, that differ ONLY in case (Naming Directives v1.7, 4).

Both are blocking conditions in the acceptance criteria.

On the Standards Track, a Work Product must include a conformance clause section before it can be submitted for public review, approved as a Committee Specification, or approved as an OASIS Standard (TC Process 2.2.6). The guidelines on writing conformance clauses are recommended rather than required; the binding obligation is the Process clause, and only the Process clause is quoted when a TC is corrected.

One obligation governs visibility rather than files: all web pages, documents, ballot results and email archives of all committees and subcommittees shall be publicly visible (Committee Operations Process 1.5). Everything this handbook says about announcements, published ballot results and public review records follows from that single clause.

Alongside policy, OASIS has written down five guarantees about the publication pipeline itself, in the documentation TCs are pointed at. For every publication run:

• the source is preserved verbatim at the canonical URL alongside the renderings;
• the HTML and PDF are byte-deterministic from the same source on the same toolchain version;
• the quality checks catch known regression classes before publication rather than after;
• published artifacts are immutable at their stage-specific URL, and corrections require a new stage;
• and cache layers are refreshed on every publication so the public URL serves the new version within minutes.

Those five are stated to TCs, so OASIS is answerable for them. Two restate a policy obligation in operational terms: the immutability guarantee is the permanence clause, and source preservation is part of the three-format obligation. The other three are the pipeline's own commitments, and they change if the pipeline does.

#3.2 The practice OASIS holds itself to

The 58 earned conditions in that mapping have no clause behind them. Every one of those checks exists because a real publication went wrong in that specific way:

• a TODO: add the link. that shipped and stayed live for years;
• a lowercase citation that returned not-found on the case-sensitive host;
• a PDF rendered from an older draft than the HTML beside it;
• a self-referential symlink that a deploy materialized into 41 nested directories.

The acceptance criteria are the accumulated record of those correction rounds plus the publication pipeline's own lint registry, calibrated against a 13-package regression corpus of real submissions in their original received form.

The practice is organised in two layers:

• The first is validation. The acceptance criteria run as code against the package alone, and the TC runs them itself before it votes.
• The second is the publication audit. OASIS examines the publication event against evidence no package-level tool can see.

Both sides run identical code, so acceptance is mechanical at both ends and is not a matter of trust at either, and the TC's clean run predicts the OASIS run without substituting for it. Each layer produces a standard report, filed to the TC's request ticket and to the TC's audit record.

OASIS built the first layer to be run by the committee rather than kept in-house, and publishes the tool for TCs to use, though no clause requires either. The intent is that a formal validation failure is caught before a vote instead of after a publication. TC Administration then re-runs the same acceptance criteria identically at intake rather than accepting the TC's result.

The acceptance criteria grow over time. They stood at 165 individual checks across 55 check classes on 22 July 2026, re-derived from the tool itself rather than quoted from documentation, because the count is asserted from the code and moves as new failure modes surface. A figure written into prose without that date should be treated as out of date. The authority mapping in 3.1 covered 96 of those conditions and has not been repeated, so the split above is a measure of the mapped set and cannot be read across the full set as it now stands.

Two further things OASIS does as practice, with no clause behind either:

• It operates the rendering toolchain, the render filters, the PDF configuration and the deployment pipeline, so the TC never has to maintain any of them.
• It accepts whatever authoring format the TC works in, holding the bar at the output rather than the input.

Both layers of the practice run to the same ownership:

#3.3 What OASIS does not promise

Current practice states the limits alongside the guarantees, and the limits bind what a TC may expect just as firmly. [VERIFY]

• The pipeline does not promise editorial review of specification content; that is the TC's responsibility.
• It does not promise visual perfection of every edge case in author-supplied Markdown; the TC editor and the OASIS publication operator do the QA pass before final stage publication.
• It does not promise forward compatibility of the source with future renderer changes; major-version renderer changes are managed by the OASIS publication operator with deliberate migration.

The first of those is the one most often misread. If any check fails the run stops, that failing check is reported back to the TC, and nothing partially published reaches the public URL. That is conformance to the acceptance criteria, not a reading of the specification.

Immutability is a limit as well as a guarantee. Each stage publishes into its own stage directory under the version directory, and the stage-specific path is the citable, immutable reference for that stage; the version directory carries a latest-stage copy of the source, the HTML and the PDF that moves forward as new stages publish. OASIS cannot correct a TC's mistake at a published stage URL after the fact, and will not.

There is no committed turnaround. The stated contract commits none from request to publication. The only elapsed-time commitment in it is that cache layers are refreshed on every publication so the public URL serves the new version within minutes. A TC planning around a date should ask rather than assume. Chapter 9 records what has actually happened across the ticket history, with the method that produced it; an observed median is a record-keeping measure, not a service level.

#3.4 Where staff involvement stops

The TC owns four kinds of decision, and OASIS touches none of them:

• what the specification says;
• the companion artifacts that travel with it;
• the per-specification publication preferences;
• and the TC-wide publication defaults.

OASIS operates the publication infrastructure. The TC does not need to maintain the rendering toolchain, the render filters, the PDF configuration or the deployment pipeline; those are operated by OASIS and refined behind the contract. A TC that never wants to think about how its PDF is produced does not have to.

The delivery boundary stops at the document portal or email. TC editors deliver the final package through the TC document portal or by email. Staff move the delivered package into the internal publishing repositories.

The package may arrive in whatever form the TC produces, either fully rendered final artifacts or authoritative source for the pipeline or staff to render. TCs author in Markdown, Word, DocBook or XML, LaTeX and ODT among others. Whatever the intake form, the published result must conform to the same rules, because the bar is the output rather than the input.

OASIS supplies the templates and the TC populates them. The Board approved a master template and delegated format versions, derivative templates and maintenance to the Board Process Committee.

On quality, responsibility divides inside a single package:

Where the same boundary falls in ballots and public reviews is covered in chapter 10.

#3.5 The IPR framework and why it lets a TC collaborate safely

The publication machinery in 3.1 to 3.4 is what OASIS does with a finished specification. The OASIS IPR Policy is what makes the work leading up to it possible. It is a significant part of what OASIS provides a TC. It fixes, in advance, the licensing terms that will attach to the finished standard, so competing companies can sit on the same committee and build one standard without unexpected patent exposure after implementers have committed.

The framework is built on one defined term. An Essential Claim is a patent claim that a compliant implementation of the standard necessarily infringes. Obligations attach only to Essential Claims, never to a member's wider patent portfolio, which is what keeps the commitment limited and knowable.

The IPR Mode is chosen once, at charter, and fixed. Every TC operates under exactly one of four modes, named in its charter, and a TC cannot change mode without closing and re-chartering. The mode decides how Essential Claims must be made available:

Because the mode is set at formation and cannot drift, a successor never renegotiates it and never guesses it: it is read from the charter, and it is the mode named in the IPR reference every public-review Invitation to Comment carries.

Two obligations bind members, and one attaches by membership alone.

• The Contribution Obligation is incurred by submitting material: the contributor must license, or covenant over, any of its patents that become Essential Claims when that contribution is folded into the standard.
• The Participation Obligation is incurred by membership, with no contribution required, once a party has been a member for at least 60 days, is still a member at least 7 days after a draft is approved for publication, and that draft goes on to become a final standard. It then covers every Essential Claim in that standard.

Both survive the work. A party that withdraws sheds future Participation Obligations but keeps every obligation already incurred, so a commitment made cannot be walked back by leaving.

Disclosure is a good-faith duty. A participating member must disclose patents it actually knows may contain Essential Claims. It is not required to conduct a patent search, and OASIS does not compile or guarantee a complete patent landscape. The operational hook is in the review: a call for disclosure goes out with the public-review copies of a Standards-Track deliverable, which is one more reason the public review in chapter 6 is required and not a formality.

The Feedback License is why non-member comments route where they do. A non-member who comments does so under the OASIS Feedback License, which binds any Essential Claims in that feedback to the same mode the TC operates under. That is the reason the comment routing in chapters 6 and 7 is not optional: a comment submitted through the TC's public comment facility arrives under the Feedback License, while one sent by some other channel does not carry that commitment and cannot be accepted.

The distinction this chapter draws still holds: the IPR framework is policy, binding and clause-backed, not earned practice. The operator's part in it is small and specific: confirming the chartered mode, ensuring the disclosure call accompanies a public review, and routing comments through the facility that carries the Feedback License. The framework itself is administered by OASIS legal and governance, not by the publication operation.