Summary

  • W3C’s Process says an overturned decision with existing consequences requires adequate, timely mitigation, and that upheld objection aspects are not fully addressed until that happens. It does not specify one public record showing who owns the remedy, what authority is used, what counts as adequate or who declares closure.
  • The Vibration API case does not prove failure: real follow-up occurred and an implementation report was completed. It does show that a reader must reconstruct the remedy across a Council report, specification issue, charter issue, proposed plan and wider review record.
  • W3C should create a versioned Council mitigation custody record that distinguishes a nonbinding Council suggestion from the responsible party’s accepted remedy and joins every upheld aspect to action, evidence, review state and a dated closure declaration.

A decision was reversed; its consequences did not reverse themselves

W3C’s Council can do something unusually consequential for a standards body built around consensus: it can overturn a decision after ordinary efforts to resolve a Formal Objection have failed. The public Process is careful about the binary act. The Council affirms or overturns the challenged decision. The arguments that justify overturning are the upheld aspects of the objection.

The harder problem starts one sentence later.

If the overturned decision has already produced consequences—perhaps text has entered a published document, a charter has structured work, or a standards-track action has changed an artifact—the Council should suggest how those consequences might be mitigated. The Team is then responsible for making sure adequate mitigations are enacted in a timely fashion. The upheld aspects are not considered fully addressed until then.

That is more than advisory prose. It creates an unresolved institutional state after the Council has spoken. Yet it creates no corresponding public object in which that state can be seen.

The Process does not say that the Council’s preferred remedy is binding. It expressly prevents a larger inference: the rule gives the Team no new powers, including no power to unpublish a document. The Team must ensure that responsible parties act through powers they already possess. A Working Group still develops technical consensus. A chair still acts within chair authority. A Team decision remains a Team decision. The Council does not become an editor, charter drafter or permanent supervisor.

This is a sound separation of powers. It is also a difficult handoff. The Council identifies the governance defect; another actor controls the substantive repair; the Team must ensure follow-through without taking over the repair. Unless those roles are joined by a record, accountability can disappear in the gap between them.

“Adequate”, “timely” and “fully addressed” need evidence

The Process gives the handoff three tests.

The mitigation must be adequate. Adequate against what? The natural answer is each upheld aspect identified by the Council report. But the cited section does not require a case-specific mapping between the objection, the consequence and the evidence that the remedy addresses it.

It must be enacted in a timely fashion. That need not mean one universal deadline. A line in a charter can be repaired differently from an already published technical report; a hard technical remedy may reasonably take longer than an administrative correction. But the text supplies neither a default review point nor a requirement to publish a case-specific target and reasons for delay.

Finally, the upheld aspects are not fully addressed until adequate mitigation occurs. This is a terminal state with no named declaration mechanism. The Process does not say who makes the closure determination, where it is recorded, whether the original decider and objector are notified, or how later readers distinguish full resolution from activity that merely points in the right direction.

These are not demands for mechanical governance. They are ordinary evidence questions. If an institution invokes a status, someone should be able to prove when the status changed.

Vibration shows the follow-up—and the fragmentation

The Vibration API supplies a useful test because the public trail contains both a real Council decision and visible later work.

An Advisory Committee review in late 2024 considered making the Vibration API (Second Edition) an Obsolete Recommendation. Two Formal Objections were filed. The Devices and Sensors Working Group resolved at TPAC 2024 to regress the work and publish a new Candidate Recommendation Snapshot. One objection was resolved; the other went to a Council.

On 10 August 2025, the Council upheld the remaining objection. Its report described an already complicated standards state. The document was then a Candidate Recommendation Draft, which could not be made obsolete under the cited rule. The Working Group had already regressed the specification to a Candidate Recommendation Snapshot so that it could continue work and address the concerns.

The Council did not prescribe a finished technical outcome. It recommended that the Working Group continue the publication process, document the API’s implementation experience in issue 33, and use the next recharter to set out a concrete plan and persuasive rationale—whether or not that plan involved shipping in multiple major browser engines.

Follow-up is visible. Vibration issue 33 was eventually closed as completed on 1 May 2026 after implementation-report work. The 2026 Devices and Sensors charter record explicitly linked back to the Council. Charter issue 781 tracked the missing plan and implementation evidence. A later pull request proposed explicit end-of-charter plans, including a status transition if a second implementation did not emerge. That proposal closed without merge. The broader charter proceeded through more revisions, review and Advisory Committee scrutiny.

This is not a story in which nothing happened. It is a story in which the public must decide which happenings count.

Was the earlier regression already the mitigation, or an interim containment step? Did closing issue 33 fully resolve one upheld aspect, or merely supply evidence for a later decision? Did the Council’s request for a recharter plan become satisfied through other charter language, remain outstanding, or cease to matter because the Working Group chose a different consensus route? Which page states the answer with institutional authority?

No single public record does. The Council report records the decision and recommendations. The Team report records procedural history. The specification issue records one task. The charter issue records a critic’s requested conditions. Pull requests record proposed language. The strategy issue records the wider charter process. Each is useful. None is clearly the custody ledger for the Process state “fully addressed”.

An open GitHub issue is not proof of noncompliance. A closed issue is not proof of institutional closure. A merged pull request would prove that text changed, not that every upheld aspect was adequately mitigated. The missing fact is the authoritative join.

W3C’s own debate drew the boundary

Public Process issue 751 has remained open since April 2023 because experienced participants read the same handoff differently.

The issue asked whether Council recommendations and mitigations acquired binding force, whether they could disturb other consensus, and whether the Team was being given an unconstrained role. The answers established an important limit. Council suggestions are not commands. If a Council overturns a proposed decision, that decision simply does not happen. If consequences already exist, something must undo, counteract or mitigate them, but the responsible body may choose a different solution from the one the Council proposed.

The Team’s role is follow-up, not authorship. In the discussion, examples of existing levers included reminding a chair, exercising existing chair-appointment authority, blocking an advancement that failed transition requirements, and using established regression or abandonment paths. The Team cannot write a Working Group’s specification or invent a power to erase publication history.

The dispute did not disappear. One participant said the Process read as though the matter went to the Team and then “magic happens”. Others wanted the original decision maker’s responsibility stated more clearly. A central response was that the wording is already substantively correct but necessarily generic. The issue was treated as editorial and deferred.

One observation in that debate should govern the design: an objector should not have to track the resolution for months or years. That is precisely what a custody record would prevent. The objector need not control the remedy or hold a private veto. The institution that says an objection remains not fully addressed should carry the burden of showing when it is.

The strongest defence is flexibility, not opacity

W3C has a strong case against a rigid remedy form.

Formal Objections are not all directed at Working Group specifications. The original decider may be a group, chair, Team member, TAG, AB or chartering authority. A universal instruction to “send it back to the Working Group” would sometimes send it to the wrong body.

Nor should a temporary Council become a shadow standards committee. Its recommendation may be useful, but ordinary consensus can produce a better answer. Treating the recommendation as binding could bypass the participants who understand the technical and patent consequences of the change.

Public repositories also preserve more evidence than many institutions provide. The Vibration trail is reconstructable precisely because Council reports, Team reports, issues, pull requests and charter discussions are available. The absence of one dashboard does not mean the work was secret.

Finally, some information should remain restricted. Council deliberations are confidential. Member material, individual votes, personnel action and legal advice may have legitimate limits.

All four defences are persuasive. None requires the status of the remedy to be inferential. A thin record can identify roles, dates, public evidence and restricted fields without prescribing the outcome or exposing protected material.

Publish a Council mitigation custody record

W3C should create a versioned Council mitigation custody record whenever a Council overturns a decision whose consequences already exist.

The Council report should open the record because it identifies the overturned decision and upheld aspects. The Team should maintain it because the Process assigns the Team the duty to make sure adequate mitigation occurs. The responsible party should supply the substantive decision, action and evidence because only that party holds the relevant ordinary authority.

The record should contain:

  • the Council report, decision date and controlling Process version;
  • the exact decision overturned and each upheld objection aspect;
  • every existing consequence that requires attention, linked to the affected artifact or process;
  • the responsible institutional role for each mitigation item;
  • the existing authority or Process power under which that actor can proceed;
  • the Council’s suggestion, clearly labelled nonbinding;
  • the remedy accepted by the responsible party, including any modified or alternative route;
  • dependencies, target date or next review point, current state and reasons for delay;
  • any publication, advancement or charter action held pending mitigation;
  • an acceptance test mapping the remedy evidence back to every upheld aspect;
  • notice or consultation state for the objector and original decider, within confidentiality limits;
  • the actor authorized to declare the mitigation adequate;
  • a dated declaration that the upheld aspects are fully addressed—or an explicit statement that no such declaration has yet been made;
  • corrections, superseding decisions, appeals and later Formal Objections; and
  • a privacy boundary explaining which evidence is restricted and why.

This would not make the Council’s technical suggestion binding. The record could say that the Working Group adopted a different consensus solution and explain how its evidence addresses the same upheld aspect. It would not create a new appeal. A new implementing decision would remain subject to the ordinary objection and review path. It would not give the Team new power. The authority field would make the opposite visible: every action must trace to a power the actor already holds.

Most importantly, the record would separate motion from closure. An issue being opened, a meeting being held or a patch being proposed is activity. A mitigation becomes adequate only when evidence is tested against the defect the Council upheld.

The record protects both the objector and the responsible group

Without a custody record, transparency arguments tend to become adversarial. The objector points to an open issue and says the remedy remains incomplete. The responsible group points to several later actions and says the matter has moved on. Neither side has a common institutional object that defines the burden of proof.

A closure record protects the objector from having to watch every repository indefinitely. It also protects the group from an objection that can never be shown to end. Once the accepted remedy, evidence and declaring authority are recorded, the institution can say what was closed and what remained outside the Council decision.

It protects the Team as well. Follow-up powers such as blocking publication or replacing a chair are serious even when they already exist. A public authority-and-status trail shows that the Team is enforcing a named Process obligation, not quietly choosing the technical outcome. If no coercive lever is used, the same record shows patient consensus work rather than neglect.

The principle is modest: a body that distributes repair authority must centralize the evidence of repair.

Evidence limits

The reviewed public record does not establish that W3C missed an internal deadline, that the Vibration mitigation remains inadequate, or that any named participant evaded the Council. Issue 33’s completion is real. Issue 781’s open state is also real. Neither alone answers the Process-level closure question.

Pull request 809’s unmerged state does not prove that its proposal was rejected on the merits or that no equivalent plan exists elsewhere. The 2026 charter attracted other changes and later controversy beyond Vibration; those disputes should not be retrofitted into evidence about the 2025 Council remedy.

The claim is therefore structural, not accusatory. W3C names a post-Council state—upheld aspects not yet fully addressed—but does not require one public artifact to carry that state to closure.

Sources

  1. W3C Process Document — 18 August 2025, Council mitigation
  2. Current W3C Process Editor’s Draft — Council mitigation
  3. W3C Process issue 751 — Council decision side effects
  4. W3C guide — Formal Objections & W3C Council
  5. W3C Council Report on the Vibration API Formal Objection, Round 2
  6. W3C Team report on the Vibration API Formal Objection
  7. Vibration issue 33 — Update implementation report
  8. Devices and Sensors charter issue 781 — Council-recommended plan
  9. W3C strategy issue 530 — Devices and Sensors Working Group 2026 Charter
  10. Charter pull request 809 — proposed per-specification plans
  11. W3C guide issue 173 — Who are the deciders?
  12. W3C Process issue 1029 — When does a Council publish its report?
  13. Heng Lu — The Multi-Stakeholder Mirage
  14. Heng Lu — On the Agency Problem at the Core of Internet Governance