Summary

  • W3C approved the WebAssembly Working Group charter on 20 August 2026. It runs through 27 August 2028 and adds Code Metadata and Legacy Extensions work alongside revisions of the existing Core, JavaScript Interface and Web API specifications.
  • The charter names the WebAssembly Component Model only as a contingent deliverable. The WebAssembly Community Group proposal must reach Phase 4 before the Working Group aims to deliver it as a normative specification.
  • The pinned public proposal registry still lists Component Model at Phase 1. That label records an institutional state, not a judgment that the technology has no users or implementation.
  • The Component Model repository records WASI Developer Preview 0.2.0, 0.3.0 and 0.3.1, and says enabled features are kept stable for producer and consumer tools to use outside browsers in production settings while collecting feedback.
  • Phase 4 requires implementation, testing, specification, reference-interpreter and Community Group consensus evidence. It then hands the work to the Working Group, which must reach its own consensus and complete W3C standards-track steps.
  • W3C should expose a two-key promotion docket joining the exact proposal revision and phase evidence to the Community Group decision, then separately to the Working Group decision and W3C publication state.

The charter approved a route, not the destination

The approval notice is concise. W3C says it approved the WebAssembly Working Group charter on 20 August. The charter itself supplies the institutional perimeter: a start date of 20 August 2026, an end date of 27 August 2028, two named chairs, a Team contact and the Working Group's scope, deliverables and decision policy.

Some work enters that perimeter immediately. The group will produce revisions to the WebAssembly Core Specification, the JavaScript Interface and the Web API. The charter also adds a WebAssembly Code Metadata Specification and three specifications that isolate deprecated but potentially still-used extensions: one for Core, one for the JavaScript interface and one for the Web API.

The Component Model appears under a different verb. The group “aims to deliver” it, contingent on the proposal reaching Phase 4 in the WebAssembly Community Group's phase process. That clause is neither rejection nor adoption. It is a gate written into the mandate.

The distinction matters because a charter can authorize a Working Group to receive future work without declaring that the entry conditions have already been met. It defines who may act after the condition is satisfied. It does not satisfy the condition by naming it.

The same contingency appeared in the 2023 charter, when the Component Model was added as a possible deliverable. The 2026 recharter renews that design. It does not convert three years of incubation into an unstated promotion.

The public phase label is still one

The WebAssembly proposals repository acts as the public state table for feature proposals. Its latest pinned change before this article's cutoff is dated 10 August. The table puts different proposals in different buckets: two at Phase 5, several at Phase 4, several at Phase 3 and Phase 2, and a longer set at Phase 1. Component Model sits in the Phase 1 list.

This is stronger evidence than guessing from how often the technology is discussed. It is also narrower evidence. The table does not say the Component Model is unimportant, abandoned, unimplemented or unsuitable for production. It says the proposal has not been publicly registered at a later phase under this process.

Nor does the absence of a later row prove that no discussion has occurred since 10 August. A later meeting, unmerged change or unpublished decision may exist. The reproducible public state at the cutoff is the pinned table. If that state changes, the correct response is a new dated entry, not a retrospective claim that Phase 1 never mattered.

Phase numbers should therefore be read as decision states, not school grades. Phase 1 means the Community Group has accepted an in-scope, plausibly workable feature proposal and expects champions to build consensus and design evidence. It does not measure lines of specification text, installed systems, funding or market interest.

Phase 4 is a demanding handoff, not a badge

The phase process describes two institutions sharing one pipeline. After Phase 0, advancement is put on a Community Group meeting agenda and the Community Group votes on whether the entry requirements for the next phase are met.

At Phase 2, the proposal needs a precise and complete overview with a reasonably high level of consensus. Phase 3 adds a test suite and implementation work. Phase 4 raises the threshold materially. Where applicable, two or more Web virtual machines must implement the feature and pass the tests. At least one toolchain must implement it. The specification and reference interpreter must be complete, the interpreter must pass the tests, and the Community Group must have consensus both for the feature and for the completeness of its specification.

Only then is the feature fully handed to the Working Group. The Working Group still has work to do. Its members examine edge cases, confirm their own consensus and fulfil the W3C standardization process. If substantial change is required, the feature goes back to the Community Group. Phase 5 requires Working Group consensus that the feature is complete before it is merged and captured in W3C snapshots.

That sequence prevents two constitutional shortcuts. A small Working Group cannot simply label an early idea mature without the implementation and Community Group evidence the charter names. An active Community Group cannot turn its phase vote into a W3C standard without the receiving Working Group's separate judgment and W3C publication steps.

Calling it a two-key system does not mean the bodies are equal in every respect. The Community Group controls incubation and promotion evidence. The Working Group controls formal standards-track adoption inside its charter. Implementers supply evidence to both, but shipping code does not give them either key.

Phase 1 coexists with production-oriented previews

The most important counterevidence sits in the Component Model repository. It contains design material, binary and text-format work, linking and ABI documents and a growing test suite. Its milestone section identifies WASI Developer Preview 0.2.0, 0.3.0 and 0.3.1.

The repository says features enabled in those previews are kept stable by producer and consumer tools so they can be used outside browsers in production settings while collecting real-world feedback. Version 0.2.0 introduced the first Component Model-based preview. Version 0.3.0 added native concurrency support, and 0.3.1 added further types and annotations.

That record invalidates a lazy reading of Phase 1 as “nothing exists.” People may build systems, make compatibility promises and learn from operational use before a proposal reaches formal W3C standardization. In this case, the repository explicitly describes that feedback strategy.

The same README also says that a formal specification and a reference interpreter will be added in the future. That statement helps explain why the formal phase can remain early despite substantial engineering. A production-oriented profile can stabilize a selected surface for an ecosystem without satisfying every artifact and consensus condition of Phase 4.

The inverse mistake is more consequential. Production use does not silently perform the Community Group vote, finish the reference interpreter, transfer the proposal to the Working Group or publish a W3C Recommendation. An implementation can be excellent and still occupy a pre-standardization state. A standards process can be legitimate precisely because it refuses to make popularity perform work assigned to evidence and decision.

A Community Group is not a small Working Group

W3C describes Community Groups as open, no-fee forums for early collaboration. The WebAssembly Community Group allows anyone with a W3C account to join after accepting the Community Contributor License Agreement. Its public page also warns that Community Groups are run by their communities and do not necessarily represent the views of W3C Membership or staff.

W3C's document guidance is equally explicit. Community Group reports are not standards-track documents and are not W3C standards. They can become inputs to the standards process. The legal agreements are designed to help a transition, and an existing Working Group whose charter covers the subject may adopt the work without another recharter. But transition remains an act; hosting and participation do not erase it.

This boundary protects both sides. The Community Group can iterate quickly, draw contributions from people who are not W3C Members and test ideas before the heavier Recommendation Track applies. The Working Group can inherit mature work while applying its own consensus, horizontal-review, patent-policy and publication obligations.

The boundary also constrains rhetoric. A Community Group proposal should not be sold as W3C-endorsed merely because W3C hosts the forum. A Working Group should not portray incubation consensus as its own decision before the handoff. And critics should not treat the absence of Recommendation status as evidence that the technical work is unofficial in the sense of being imaginary or unserious.

Why the join matters outside standards meetings

Status language travels. A tool vendor may say it supports “the Component Model” without identifying the preview profile or repository revision. A buyer may hear “in the W3C charter” and infer Recommendation-level review. An implementer may read Phase 1 and conclude that a feature is too volatile to deploy, even though producer and consumer tools have made a bounded preview promise. A contributor may object in a repository when the decisive phase vote belongs on a Community Group agenda, or wait for the Working Group when the design is still meant to change in the incubator.

These are not merely communications errors. Compatibility decisions become expensive to reverse. If a widely deployed preview fixes an ABI or linking expectation, later standards participants face pressure to ratify it even when new evidence suggests a better design. That pressure may be commercially rational, but it should appear as evidence and transition cost, not as an invisible transfer of authority.

The opposite risk is institutional lag. If the public phase table understates the evidence already assembled, users cannot tell which remaining criterion is genuinely open. The label becomes a waiting room with no visible queue. Champions then rely on reputation and private coordination to explain why the work is further along than the formal record shows.

A good public record must hold both realities at once: real technical adoption and incomplete institutional promotion.

The missing object is a two-key promotion docket

The needed record is not a new supreme committee. It is a compact join between public states that already exist.

The Community Group side would start with an immutable proposal revision, the current phase, the date and record of the last phase decision, and the entry criteria for the requested phase. Each criterion would point to evidence: named Web VMs, exact test-suite revision and results, toolchain implementation, formal specification, reference interpreter and unresolved exceptions. If a criterion is not applicable, the record should say who made that classification and why.

The decision entry would identify the public agenda, decision method, result and any recorded objection without converting participant attendance into universal consent. It would specify the exact feature subset promoted. Developer Preview features outside that set would remain visibly outside rather than being swept into the handoff by brand name.

The second half would begin when the Working Group receives the work. It would record the receiving revision, Working Group CfC or other decision, issues returned to incubation, horizontal reviews, patent-policy state, implementation report and W3C publication status. If substantial change sends the feature back, the return should create a new state rather than silently modifying the old handoff.

This docket would not publish private legal advice, proprietary product plans or every meeting remark. It would publish the minimum constitutional and evidentiary state necessary to explain why the keys turned.

What can be said now

As of 31 August, W3C has approved a current WebAssembly Working Group charter. The charter has authority to develop its unconditional deliverables and to receive the Component Model if the named condition is met. The public WebAssembly proposals table places Component Model at Phase 1. The Component Model repository documents meaningful developer-preview engineering and selected production use outside browsers.

The checked record does not establish that the Community Group has rejected a Phase 4 request, that W3C has delayed the work, or that any implementer has bypassed the process. It does not prove incompatibility, insecurity, vendor capture or a patent problem. It also does not establish that the Component Model is a W3C Recommendation.

The most accurate status is less dramatic and more useful. The technology is real. The formal promotion is incomplete. The new charter preserves a route between them, provided each institution leaves a receipt when it uses its key.

Sources

  1. W3C — WebAssembly Working Group charter approval notice
  2. W3C — WebAssembly Working Group Charter, effective 20 August 2026
  3. WebAssembly — proposal registry pinned at 10 August 2026
  4. WebAssembly — phase-advancement process
  5. WebAssembly — Component Model repository milestone state
  6. W3C — WebAssembly Community Group
  7. W3C — Community and Business Groups FAQ
  8. W3C — Types of documents W3C publishes
  9. Lu Heng — The Multi-Stakeholder Mirage