9. Records and accountability

Every fulfilled request leaves two records, and a publication leaves a third:

• the ticket that tracks it;
• the log and tracker row that account for the work;
• for a publication, the pair of reports that prove it was done correctly, which is why 9.3 covers publications rather than requests in general.

This chapter states what each record is, who writes it, and where it is kept. It closes with what those records cannot currently answer, which is a finding of its own and the reason several figures in this handbook had to be assembled by hand.

The same rule applies to all three records. One linking-profiles request ran for seven months with no ticket in practice, and one publication had no ticket at all.

#9.1 Every request gets a ticket

Every fulfilled TC or publication request has a ticket in the request tracker. Requests arrive by several routes, so the first task at intake is to search the tracker for an existing ticket. Those routes include:

• the public web request form;
• email;
• the member platform;
• direct message.

Where none exists, staff open one before or while the request is fulfilled, recorded on behalf of the named requester.

The requester usually has no account on the tracker, so the ticket cannot be opened under their identity. The reporter is set to the shared intake identity that every web-form request already carries, and the first line of the description records that the ticket was opened by the TC Administrator on behalf of the named requester. The body captures their request in the house form:

• the requester's name;
• the TC;
• the Work Product title, version and stage;
• the link to the minutes recording the approving vote;
• the channel and date the request arrived on.

Related tickets are cross-linked. Reports are attached to the ticket as the work completes (9.3).

This convention stands in for the requester identity the tracker does not capture. Section 9.4 gives the numbers behind that.

#9.2 Activity logs and the work tracker

Each work item has three linked places:

• The tracker row is the index.
• The activity log is the full chronological record.
• The batch directory holds the files.

A reader who has the tracker row can reach the other two from it, and a reader who has only the files can find which item they belong to.

The batch directory is one directory per TC, version and stage, with numbered phase directories running in order:

1. untouched intake files;
2. working edits;
3. renders;
4. the assembled deploy tree;
5. the drafted communications;
6. the deploy record.

The deploy tree mirrors the live path layout so that deploy is a direct copy. Companion specifications reviewed together share one batch directory.

Docs publishing and TC administration work is recorded separately from all other technology work, on its own tracker tab under its own identifier scheme. One row holds one work item, carrying:

• the TC;
• the work item;
• its type;
• the stage;
• the status;
• the TC contacts;
• who it is assigned to;
• the dates;
• the linked ticket;
• the published location;
• the hours.

Every publication, public review, ballot and defect fix is billable work, so its hours are written to the row as the work completes rather than left blank. Hours are recorded in multiples of half an hour, rounded up, and derived from the activity-log timeline, with the basis for each written into the log so the figure can be confirmed later. They reach the master billing record through a single rollup row rather than by duplicate per-item entries. Cross-cutting work that maps to no single TC goes to a standing operations row so the time is not lost.

#9.3 The two reports per publication

Every publication produces two separate reports. The first is the publication audit report, a gate-level record in which every gate reads pass or fail with its recorded evidence, or an explicit not-applicable with a reason. The publication event is audited against the fifteen mandatory gates in the canonical gate registry, and every one of them appears in the record. All fifteen:

1. byte identity between the live site and the pushed repository state;
2. any live-versus-repository difference diffed and classified;
3. render class against the TC's own precedent;
4. front matter against the live roster, the companion document and the ticket;
5. stage name under the current naming rules with no revision collision;
6. the directory index chain;
7. the archive and its manifest byte-identical with no stray members;
8. the Invitation to Comment delivered to the all-members community and confirmed at its destination;
9. the post live on the TC's own community;
10. the post live on the TC's public comment facility community;
11. the discoverability of a public review on the public feed;
12. the website news post live where the stage warrants one;
13. the ticket carrying the complete record of confirmed links;
14. an independent adversarial verifier briefed to refute the publication;
15. a human comparing the live cover page and directory listings against what was published.

A gate that does not apply to a stage is recorded not-applicable with a reason, and no gate is left unrecorded. The adversarial verifier gate is the one gate that can never be recorded not-applicable. The verdict is computed from the gate results: any gate failure, or any product finding at blocker or major severity, forces a fail, and a stated verdict that disagrees with the computed one is rejected.

The second is the validation report. It itemizes every individual acceptance check, with the value read from the package and the value it was compared against, marked pass, warning, blocker, or not-applicable with a reason. Both reports are issued as a machine-readable record, a markdown form and a rendered document, all committed to the TC's audit directory in the internal repository, and mirrored into a single local reports directory for that TC rather than scattered across the working folders of individual publications. Both rendered documents are attached to the ticket the TC opened. The publication also produces a release manifest, machine-readable and as a staff record carrying the bibliographic block, the archive listing with checksums and the digests, and both deploy with the package.

The attachment record shows this standard as data rather than as a rule. A sweep of the tracker on 22 July 2026 found 32 attachments across 26 tickets, and every recent publication ticket carries exactly the pair, named to a fixed convention. The live instances are:

The standard holds up: a successor can confirm it directly from the tracker.

#9.4 What the record cannot currently tell you

The request tracker holds 4,381 tickets all time. Of those, 142 were raised in the 24 months to 22 July 2026, 69 in the 12 months to that date, and 41 in calendar 2026 to date. Of the 142:

• 127 are closed;
• 9 are in progress;
• 6 are resolved.

The record is complete enough to count, but not to count by category.

The request taxonomy is no longer used. The tracker defines 20 purpose-built request types, one for each kind of request a TC can make:

• public reviews at each of the three durations and an informal public review;
• Approved Errata;
• chair elections;
• charter clarification ballots;
• two separate types for closing a TC;
• creating a subcommittee;
• Committee Specification ballots;
• discussion lists;
• document uploads;
• errata reviews;
• new TC charter submissions;
• OASIS Standard submissions and their ballots;
• registration and template requests;
• open repository requests;
• version control setup.

Every one of them has real historical use:

Usage in the last 24 months is zero. All 142 recent tickets are filed as a generic task, so the request type survives only as free text in the summary line, in the form "Request a first public review for..." or "Request a Special Majority Vote to advance...". No report of the form "how many public reviews did we open last year" can be produced from the tracker without parsing prose. As of 22 July 2026 this is why usage figures for the operation have to be assembled by hand across several systems. Method: the figures come from a sweep run against the tracker's query interface on 22 July 2026, one query per request type over the window, counting tickets rather than sampling them.

Requests do not arrive under the requester's identity.

Of the same 142 tickets, 83 were filed by the shared intake account and 53 carry no reporter at all, so 136 of 142 arrive either through the shared account or anonymously. Only 5 tickets in two years carry a named requester from a TC. The web request form writes into the queue without creating or attaching a requester identity, and requesters have no accounts on the tracker to attach. So the tracker cannot answer which TCs ask for what, and the ticket record alone will not tell a successor who requested it. The house description convention in 9.1 exists to put the requester's name back into the ticket body by hand, which makes the identity readable but still not reportable.

A third limit applies to any timing figure taken from this record. Across the 24 months to 22 July 2026, 113 genuine requests were resolved with a median of 7.2 days from raise to resolution, and of those, 82 were publication, review or ballot requests, resolved at a median of 10.8 days with a range from same-day to 181 days. State the method with the figure or it misleads:

• The 20 tickets resolved invalid are spam and are excluded from the 113, which is why they are reported separately.
• The resolution date records when the ticket was closed, not when the TC received the result.
• Several requests resolve in zero days because the ticket was opened on behalf of the requester after the work was already done, which pulls the median down.

This is a record-keeping measure, not a service-level measure, and 11.1 carries the absence of a committed turnaround as its own item.

The form is open to anyone, which is why the 20 invalid tickets exist. All 20 fall inside the last 12 months, and six of them, TCADMIN-4716 to 4721, were raised consecutively in a single run and closed together. The six are a subset of the 20, not a second figure beside it.

All four findings are dated 22 July 2026 and re-derivable. Each carries the query that produced it in the fact registry, so a successor can re-run the sweep and reproduce them. Chapter 11 carries the first two as improvement items.