Appendix A. Open verification items

Every claim in this handbook has a source behind it, or it carries a [VERIFY] marker and

appears in this list. The appendix is the complete list. Nothing here is known to be wrong.

Each entry is a claim that is not yet proven, kept in view so nobody mistakes an assumption

for a record.

Twenty-six actionable [VERIFY] markers appear in this draft, and they reduce to twelve

questions. They sit in these chapters:

Chapter 1 and this appendix mention the marker to explain it; those mentions are not items.

Three of the twelve are policy conflicts rather than gaps: A.2, A.3 and A.4 each record a

place where current practice and a Required rule disagree.

#A.1 Who grants access to each system

Where: 8.2, seven cells in the inheritance table. 8.3 restates it as the section's own

open question.

Every system in the operation is known, and so is the access each one needs. Who grants

that access is recorded for exactly one of them: the request tracker, where the TC

Administrator also holds tracker administration. For these systems the granting authority is

not written down anywhere:

• the member platform;
• the internal publishing repositories;
• the four publication layers;
• the public website;
• the work tracker;
• mail.

Needed: for each system, the role that grants access and the role that owns the account.

Why it matters: this is the single largest gap in the handbook.

#A.2 Whether a Special Majority Vote must offer an abstain option

Where: 5.3.

The operating procedure sets the ballot options to Yes and No with no Abstain, following

current practice and the immediately prior ballot on the same TC. TC Process section 1.11

requires that any Work Product Ballot conducted as an electronic ballot must permit each

voter to choose yes, no, or abstain. Committee Specification Draft ballots from 2018 did

offer abstain.

Needed: a policy reading of whether a ballot submitting a Committee Specification as a

Candidate OASIS Standard is a Work Product Ballot within the meaning of section 1.11.

Why it matters: the threshold arithmetic is unaffected either way, because Yes and No

are each counted against the eligible-voter total and an abstention changes no outcome. A

voter's ability to record an abstention is not a formality, though, and if section 1.11

applies then current practice does not conform and inherited the defect from a predecessor.

Treat it as a defect to file rather than a practice to write down. Resolve it before the next

Special Majority Vote opens. Until then, record which options each ballot used.

#A.3 Whether the ballot form's single-vote setting removes the right to change a vote

Where: 5.3.

The setting used to date on the Add Ballot form is that voters may vote once. TC Process section 1.11 states, as a Required rule, that eligible voters may change their vote up until

the end of the voting period. A single-vote setting removes exactly that right. This is the

second section 1.11 conflict in the same field map, alongside A.2, and it has been in place longer.

Needed: an inspection of the live Add Ballot form to establish what the vote-once setting

actually does. If it still lets a voter re-open the ballot and change a cast vote before

close, there is no conflict and this item is closed here. If it does not, revoting is set to

allow changes until close.

Why it matters: unlike A.2, this one may not be a real breach at all, which is why it

needs an inspection rather than a policy reading. It cannot be settled by precedent: every prior ballot

used the same setting, so precedent proves only that the question was never asked. Until it

is answered, record which revoting setting each ballot used.

#A.4 Whether a wrong Committee Specification number invalidates a Statement of Use

Where: 5.4.

Current practice records a wrong Committee Specification number in the prose of a Statement

of Use as a defect and proceeds, on the ground that the prose still identifies the

specification. The Defined Terms rule that a Statement of Use must be made to a specific

version of the Specification, and must include that Specification's approval date, is

Required. Recording the defect and proceeding waives it.

Needed: a reading of what a wrong version number in the prose does to the statement when

the hyperlinks and the surrounding text otherwise identify the specification.

Why it matters: the operating posture is not what is in question. Statements of Use are

taken at face value and are not audited, and that posture is deliberate and correct. What is

in question is that one specific waiver contradicts a Required rule and has not been visible

anywhere in the record. Three Statements of Use are what a Special Majority Vote to submit a

Candidate OASIS Standard rests on, so a defect in what counts as one is a defect in the

ballot. Resolve it before the next Special Majority Vote opens.

#A.5 What the recorded 12 to 15 day Call for Consent range measures

Where: 5.6 and 7.4.

The operating procedure records that the Call for Consent itself ran 12 to 15 days across

the four specifications measured from review close to OASIS Standard. Two of the four

reproduce from the record and both conform:

• PKCS#11 v3.2 opened 19 May 2026 and closed 3 June 2026, 15 days;
• OpenDocument v1.4 was announced to the membership on 22 September 2025 and was an OASIS Standard on 6 October 2025, 14 days.

The 12 at the bottom of the range matches no open-and-close pair in the record.

Needed: the ballot opening and closing timestamps for all four Calls for Consent, and

the method behind the recorded figure. Either it measures something other than the open

window, such as the interval from the announcement post to the close, or a Call for Consent

was run for less than the minimum.

Why it matters: section 2.8.3 requires the consent period to be open for at least 14

days. A 12-day open window is a breach. It currently appears in the record as a routine statistic in a forecasting note, not flagged as a defect. The figure is quoted to marketing when

a standard's date is forecast, so it is in circulation. It remains in the handbook while it is

unresolved, still marked, because if OASIS ran a short Call for Consent that

matters more than the forecast it was collected for.

#A.6 The written mandate for the standards role

Where: 10.2.

Draft 0.1 asserted, without a citation, that the standards role owns policy while the

publication and balloting mechanics move to a dedicated support position reporting into it.

Nothing in the source corpus states this.

Needed: a written source for the role definition and the reporting line.

Why it matters: 10.2 exists to tell an incoming hire what they are taking on. An

uncited organisational intent is the wrong thing to tell them.

#A.7 Owners for the improvement items

Where: 11.2, seven rows.

No owner is recorded for:

• restoring or replacing the two deploy steps that no longer function;
• making the request type machine-readable at intake;
• capturing the requester's identity at intake;
• restoring or formally retiring TC and comment mail distribution;
• restoring or retiring the public open-reviews listing;
• deciding whether OASIS commits a turnaround;
• and reducing spam reaching the public request form.

Needed: a named owning role for each.

Why it matters: the improvement backlog items have no named owners. Two of them, the non-functioning deploy steps and the non-functioning mail distribution, are also entries in 11.1.

#A.8 How a news story reaches the website

Where: 8.2.

A page is edited by opening it in the content management system's editor, changing the

content in place and republishing. How a news story gets from a draft to published is less

clear when the author and the publisher are different people.

Needed:

• whether news stories arrive through a submission form;
• who moves a draft to published when the author and the publisher differ;
• and whether the author role publishes directly or only submits for review.

#A.9 Whether a press process exists

Where: 7.4.

The rule about who is copied on a website news post is recorded, and the drafting practice

for news posts is recorded. Nothing records a press process as such.

Needed: whether a recorded press process exists at all, and if so:

• its lead time;
• its sign-off task;
• and whether press distribution is a channel distinct from ordinary member announcements.

#A.10 The wiki edit total for the measurement window

Where: 2.6.

The tools section records that the wikis have effectively stopped: five members, two TC

namespaces, the last edit anywhere on 22 May 2025, and no edits in the trailing 12 months.

Two sources in the engagement pack give different edit totals for the same window.

Needed: a single agreed wiki edit count for the window, or the reason the two

sources diverge.

Why it matters: the stable facts already carry the operational point that the wikis are

dead, so the divergence does not change the finding. The edit total is a supporting figure

and is not quoted until the two sources agree.

#A.11 The document that states the five publication guarantees

Where: 3.3.

Section 3.3 states the five things the publishing pipeline does not promise, as the limits

that sit beside the publication guarantees a TC may rely on. The specific TC-facing document

and its URL that state those guarantees and their matching limits are not yet identified.

Needed: the document and its URL.

Why it matters: the limits bind what a TC may expect as firmly as the guarantees do, so

a TC-facing statement of them should be citable rather than described.

#A.12 The Board and Board Process Committee template-approval record

Where: 3.4.

Section 3.4 records that the Board approved a master template for the OASIS Standard,

Committee Specification and Committee Specification Draft stages on 24 April 2025 and

delegated derivative templates to the Board Process Committee, which released the Committee

Note template on 3 June 2025, and that the Technical Report template does not appear in the

record. The Approvals-record URL and its two dated entries are not yet cited.

Needed:

• the Board and Board Process Committee Approvals-record URL;
• its 24 April 2025 master-template entry;
• and its 3 June 2025 Committee Note entry.

Why it matters: the two dates and the negative claim about the Technical Report template

rest on a record that is not yet linked.

---

How to close an item.

1. Confirm the answer against a real source.
2. Add it to _build/ops-facts.json with the source and the section.
3. Remove the [VERIFY] marker from the chapter.
4. Delete the entry here.