9 Release 20 at this meeting, and what the numbers will not say

9.1 Which release the meeting was actually working on

Ask what a plenary is working on and the honest first answer is: paperwork that belongs to no release at all. 162 documents carry no release ^[1] — agendas, reports, liaison statements, project management — out of 346 ^[2].

Of the rest, one release dominates: 140 documents belong to Rel-20 ^[3]. Release 20 is the release being written, and this meeting was largely its meeting.

9.2 The Rel-20 numbers

Three separate counts point at it.

• 140 documents of every kind, from work items to liaison statements.

• 487 change requests inside packs ^[4].

• 63 documents in the meeting's own bin for Rel-20 change requests, the second largest agenda item of the four days ^[5].

Set beside Release 19's 143 change requests ^[6] and Release 18's 36 ^[7], the shape is unmistakable: Rel-20 is where the change traffic inside packs is.

9.3 Why the biggest group belongs to no release

It is worth dwelling on those 162 documents, because that is the figure people leave out of summaries and it changes the picture.

None of that 162 is release work at all. The agenda SP-260361, the previous meeting's report SP-260362, the working groups' reports, the incoming letters, the work plan SP-260606, the terms of reference SP-260470: none of them belongs to a release and all of them take time.

So a sentence like "SA#112 was a Release 20 meeting" is true about the technical work and false about the meeting. Release 20 is the largest release group and the largest group of all is the one with no release in the column.

9.4 What a release count is counting

The release field says which release a document is aimed at. It does not say when that release will be finished, how far along it is, or whether the document succeeded.

Two documents make that plain. SP-260417 and SP-260696 are one work item with two numbers, and both of them count towards their release's total — the release count is a count of paper, and the same subject can appear in it twice.

9.5 Where the Rel-20 effort went

The specification table of chapter The change requests — 689 of them, in packs is the closest this record comes to saying what the work is about. The top of it: TS 23.482 with 46, TS 23.502 with 38, TS 23.369 with 33, then TS 23.501, TS 28.312 and TS 28.552 with 29 each.

Below those: TS 23.503 with 24, TS 23.288 with 23, TS 23.228 with 22, TS 28.561 with 19, and TS 23.433 and TS 28.541 with 18 each.

That is 689 change requests ^[8] spread over 114 specifications ^[9], and the twelve above are the busiest of them.

The tail matters as much as the head. Every other specification on the list took fewer than those twelve, which is what maintaining a generation of standards looks like: a few documents under heavy construction and a long list of others taking one or two corrections each.

Note also that these are the whole meeting's counts, not Release 20's alone. The release column and the specification column are separate questions here, and the data offers no per-release breakdown by specification. The list shows where the meeting's repair effort went; attributing all of it to Rel-20 would be reading in something the counts do not say.

9.6 Four readings the numbers do support

• The management side is busy. Four of the twelve are management and orchestration documents, and the group that owns two of them sent more documents to this meeting than anybody — SA WG5, with 66 ^[10].

• AI and machine learning have their own architecture now. The single most changed document of the meeting is the AI/ML enablement service architecture TS 23.482, which belongs to SA WG6, itself the source of 41 documents ^[11] — and the long argument of the meeting was about training data for an AI model ^[12].

• Devices without batteries are real work. TS 23.369 took 33 changes, and a study on charging for the same subject was approved SP-260656.

• 6G is being planned, not written. Release 21 has a timeline SP-260595, a checkpoint in December 2026 ^[13], a name for its core network ^[14] and 11 documents ^[15]. No body of text.

9.7 Five readings they do not support

This is the part that matters more than the part above.

• Which specification changed most. The counts count change requests, not the size of a change. Nothing in this record says how much text any one of them altered. "TS 23.482 changed more than TS 23.501" is not a supported sentence; "more separate corrections were submitted against it" is.

• Which work was most important. There is no weighting anywhere. A pack of twenty-three corrections to one document SP-260379 and a single work item description that redirects a whole area SP-260663 are one row each in the document list.

• How much support anything had. The report records no vote counts, no attendance per company and no reasons. Where a decision was contested it names one objection ^[16] and nothing about anyone else's position. "Widely supported", "unanimous" and "controversial" are all outside what this record can carry.

• When any of it becomes real. The meeting approved 26 specifications and reports ^[17], and approved means approved by TSG SA. Each one still had to be produced and published afterwards, and this data does not say when that happened.

• What it means for a network. There are no deployment dates, no product impact and no market view in any of these files. The data is a meeting's paperwork.

9.8 The releases on either side

Release 19 is being finished, and there is a document that says so: SP-260604, the technical report summarising every Release 19 feature, approved at this meeting. Its numbers — 26 documents ^[18] and 143 change requests inside packs — are the signature of a release still taking corrections but no longer growing.

Release 18 and Release 17 are down to repairs: 36 change requests and 7 ^[19], under the caution the plenary noted about changing frozen releases ^[20].

Release 21 is a date and a name. Chapter Release planning — the timeline, the checkpoint and the names has the timeline, and the interesting thing about it here is how little else there is: 11 documents at a meeting that handled 346.

9.9 Doing this reading on the next meeting

The method here transfers, and it is four questions.

• N1. Which release has the most documents? That is the release being written. At SA#112 it is Release 20, with 140.

• N2. Which release has change requests but few new documents? That one is being finished. Here it is Release 19, with 143 changes inside packs and a release summary approved to mark it SP-260604.

• N3. Which release exists only as dates? That is the next one. Here, Release 21, with 11 documents.

• N4. How big is the group with no release? That is the meeting's overhead, and at SA#112 its 162 documents are the largest group of all.

Four counts, and you can describe the state of a release cycle without reading a single document. What you cannot do is say anything about the content, the importance or the consequences — which is the point of the section above.

9.10 Where this leads

Everything in this chapter rests on two things: a document database, and a meeting report that is a draft. The next chapter is about that report — what it is, what state it is in, and the two places it does not hold up: The report is a draft, and it shows.