Revised the Terms and definitions to comply with ISO

[seanmcilroy29]

Terms and definitions

[claude]

PR Review — Terms and definitions ISO alignment

Thanks for this! Since this is a specification repository (not code), I've framed the review around document correctness, ISO alignment, and rendering. Overall this is a solid, well-scoped change that genuinely improves ISO/IEC conformance. A few points below.

👍 What's good

• ISO Directives style applied correctly: sentence-case heading (Terms and definitions), lowercase term names, and lowercase definition text (no trailing period) all match ISO/IEC Directives Part 2 conventions.
• Clause-based numbering (4.1–4.8) replaces the ad-hoc T.1–T.8. I checked SPEC.md, FAQ.md, and README.md — there are no dangling cross-references to the old T.x labels, so the renumbering is safe.
• FLOP entry now correctly lists the full term (floating point operation) followed by the abbreviation (FLOP) on its own line — the proper ISO term/abbreviation pattern.
• Note 1 to entry on 4.1 is the correct ISO mechanism for the cross-reference to 21031:2024.

⚠️ Potential issue — Markdown line breaks (worth verifying in rendered output)

The old entries used trailing double-spaces to force hard line breaks (T.1 + two spaces, **Functional Unit** + two spaces, then the definition). The new entries have no trailing spaces:

**4.1**
**functional unit**
quantified performance characteristic...

In strict CommonMark, single newlines are soft breaks (rendered as a space), so 4.1 functional unit quantified performance… would collapse onto one line. GitHub's own renderer treats these as line breaks so it likely looks fine in the PR/repo view — but if this spec is ever exported through a standards toolchain (pandoc, cmark, etc.) the number/term/definition will run together. For portability I'd suggest keeping explicit hard breaks (trailing double-spaces after the **4.x** and **term** lines) or confirming the target renderer. Please eyeball the rendered "Files changed" view to confirm each entry still stacks on three lines.

🧹 Minor — trailing whitespace

The blank separator lines between entries now contain a single trailing space (lines 53, 55, 57, 64, 66, 70, 74, 78, 82, 86, 90). Harmless, but worth stripping to keep the diff clean and avoid lint noise.

📄 FAQ sync (per CLAUDE.md)

No action strictly required: FAQ.md refers to these concepts in explanatory prose (title-cased, e.g. "Functional Units") and does not reference the normative term numbers, so it remains accurate. Flagging only because CLAUDE.md asks us to check FAQ impact on any SPEC change.

Note (non-blocking)

The heading is now sentence case (4. Terms and definitions) while sibling headings remain Title Case (2. Scope, 5. AI Lifecycle Stages, …). This looks intentional given the companion PRs #134–#136 aligning clauses one at a time — just calling it out so the whole document lands consistently by the end of the series.

Nice incremental progress toward ISO alignment. 🚀

[claude]

🤖 Claude PR Review — Terms and Definitions (ISO alignment)

Reviewed against CLAUDE.md conventions (this is a spec repo, so feedback focuses on document correctness, Markdown rendering, and SPEC↔FAQ consistency rather than code).

👍 What looks good

• Solid ISO/IEC 21031 alignment: lowercase clause heading, sequential clause numbering (4.1–4.10) replacing the ad-hoc T.n scheme, lowercased terms/definitions with no trailing period, and the Note N to entry: convention.
• FLOP is now expressed as a full term (floating point operation) with the admitted abbreviation (FLOP) — matches ISO term/abbreviation style.
• Good internal consistency: the new terms 4.9 gross value / 4.10 effective value formalize concepts already used later in SPEC.md (the "Explanation" block around lines 242–243). Defining them up front is a real improvement. Consider adding a cross-reference from that explanation block to §4.9/§4.10 so the terms and their usage stay linked.

⚠️ Please address

1. Term entries will render as one run-on line (main issue). In standard/GitHub Markdown, consecutive non-blank lines collapse into a single paragraph, so:
   ```
   4.1
   functional unit
   quantified performance characteristic ...
   ```
   renders as `4.1 functional unit quantified performance characteristic ...` on one line. The previous `T.1` entries used two trailing spaces (hard line breaks) to keep number/term/definition on separate lines; that break was removed here. Recommend restoring hard breaks (two trailing spaces) or blank lines within each entry — unless the intended output target is raw ISO text rather than rendered Markdown, in which case a note saying so would help reviewers.

2. Missing blank line before **4.1**. The - IEC Electropedia ... bullet is immediately followed by **4.1** with no separating blank line, so the first term can be absorbed into the preceding list / lose spacing. Add a blank line between the list and §4.1.

3. Trailing whitespace on separator lines. The blank lines between entries were introduced as a single space rather than truly empty lines throughout the section. Harmless when rendered but trips Markdown linters and adds noise to future diffs — worth cleaning to empty lines.

📄 FAQ consistency (per CLAUDE.md)

CLAUDE.md asks that substantial SPEC additions have corresponding FAQ coverage. The new gross value / effective value terms aren't in FAQ.md. They're partly explained in the SPEC body already, so this is a judgment call — but a short FAQ entry on why both gross and effective values are defined would round it out.

Not applicable

Performance, security, and test coverage don't apply to this documentation change.

Overall a clean, well-motivated ISO-alignment change. Fixing the Markdown line-break behavior (#1/#2) is the key item before merge.

[claude]

Review — #137 Terms and definitions (ISO alignment)

Two earlier automated reviews already covered the rendering and whitespace nits, so I verified those claims and focused on what they missed. Net: the clause renumbering is safe and the style shift is right, but there are a few substantive definitional issues worth resolving before merge.

Corrections to the earlier reviews

• The run-on rendering issue is real, not "likely fine". One review suggested the GitHub renderer treats these soft breaks as line breaks. That is true for issue/PR comments, but not for .md files rendered from a repository — there, consecutive non-blank lines collapse into a single paragraph. So SPEC.md:62-64 will render as 4.1 functional unit quantified performance characteristic of an AI system that serves as… on one line, for all ten entries, and 4.8 will additionally run the term and its abbreviation together. This is a genuine regression from the T.1 form, which used trailing double-spaces deliberately.
• There is no missing blank line before **4.1**. SPEC.md:61 is a genuinely empty line. That item can be disregarded.
• Confirmed independently: no T.1–T.8 references survive anywhere in SPEC.md, FAQ.md, ANCILLARY.md or README.md, and all ten terms are actually used in the document body — no orphan entries. The renumbering is clean.

1. 4.2 / 4.3 define the two central personas by payment

Current: 4.2 consumer = "entity that uses AI services and pays for functional units of AI"; 4.3 provider = "entity that develops and delivers AI services, selling functional units of AI".

The commercial framing (pays for, selling) is carried over from the old text, but it conflicts with the rest of the spec and with the stated scope:

• 6.1 and 6.2 define the Consumer and Provider boundaries purely by lifecycle stage. No payment anywhere.
• It excludes an organisation that trains and self-hosts its own model — that entity performs both roles and pays no one. Clause 1 says the spec applies to "a broad range of AI system types", with no market-transaction precondition.
• It excludes free-tier and internal-platform consumers, which are exactly the cases where an SCI score is useful.

Since #137 is the PR that ISO-aligns this clause, it is the right place to make the definitions role-based rather than transactional. Suggestion: 4.2 consumer = "entity that uses an AI service delivered by a provider"; 4.3 provider = "entity that develops, hosts or delivers an AI service to consumers", plus a note to entry along the lines of: "A single entity MAY act as both consumer and provider, for example when it trains and self-hosts a model for its own use; in that case both boundaries (see 6.1, 6.2) apply." That note also pre-empts a question Clause 6 currently leaves open.

2. gross value / effective value are now defined twice, in different words

The new 4.9/4.10 duplicate the "Explanation" block at SPEC.md:243-247, and the wordings have already drifted — 4.9 says "without adjustment for actual usage or contribution", the block says "without adjustment". Two normative statements of the same concept will diverge further on the next edit, and ISO/IEC Directives Part 2 keeps definitions in the terms clause only.

Concrete fix within this PR:

• SPEC.md:240 becomes: "Whether emissions are normalized using gross values (4.9) or effective values (4.10)"
• Delete the two definitional bullets at :244-245, keeping only the rationale sentence at :247 ("Reporting effective values gives a more realistic picture…"), which is guidance rather than definition and belongs in the body.

This is also the cross-reference the second review asked for, but resolved by removing the duplicate instead of linking to it.

3. The note on 4.1 cites the referenced clause by title rather than number

It reads "…described in the Functional Unit clause of ISO/IEC 21031:2024". ISO citation style is numeric — ISO/IEC 21031:2024, <clause number>. A title-based citation silently breaks if 21031 is revised and the clause is renamed, and a reader cannot jump straight to it on the OBP. Worth also double-checking that R is the symbol 21031 actually uses for the functional unit, since the note asserts it normatively.

4. Rendering — one fix that solves two problems

Rather than restoring trailing double-spaces (invisible, easily stripped by editors, and re-broken by the next contributor), consider promoting each entry to an H3 heading — a line reading ### 4.9 gross value, then the definition as its own paragraph, then the note to entry. This fixes the run-on rendering, matches how every other numbered subclause in SPEC.md is written (### 2.1, ### 5.1, ### 8.2.1), and makes terms deep-linkable and TOC-visible — which matters for a document whose whole point is being cited by clause number. Today 4.9 has no anchor, so 8.2.2 cannot actually link to it. The trade-off is divergence from the ISO plain-text entry layout; if that plain layout is required for an eventual submission format, restore the hard breaks instead and say so in the PR description so future editors do not "clean up" the trailing spaces.

Either way, please also convert the whitespace-only separator lines (SPEC.md:54,56,58,65,67,71,75,79,83,87,91,96,100,102,106 — each contains a single space) to genuinely empty lines.

5. Missing term: material

Outside this diff, but it is a gap in the clause this PR is finalising: material gates two SHALL statements (SPEC.md:171, SPEC.md:195 — "SHALL be included … when material; they MAY be included when not material") and appears again at :218 and :241. It is defined nowhere, and a normative requirement whose trigger condition is undefined is not testable — two implementers will draw the boundary differently and both can claim conformance. If 21031 defines materiality, add a note to entry pointing at it; if not, this clause needs a 4.11 material entry with either a stated threshold or an explicit "determined and disclosed by the reporting entity". Reasonable as a follow-up issue rather than scope creep here.

FAQ (per CLAUDE.md)

FAQ.md does not reference term numbers, so nothing breaks. But CLAUDE.md rule 3 asks for FAQ coverage of substantial additions, and gross value/effective value are new normative terms — a short FAQ entry on why the spec distinguishes them (crediting pruning, deduplication and sparsity optimisations) would satisfy that, and it is useful rationale to capture while it is fresh.

Process suggestion

.github/workflows/ has only the two Claude workflows — no markdown linting. The trailing-whitespace and hard-break classes of issue in this PR are exactly what markdownlint (MD009, MD047) catches for free, and a link checker would guard the OBP and Electropedia URLs at :59-60. Given that the tests of a spec repo are its lint and consistency checks, that seems worth an issue.

Not applicable: performance, security, test coverage (documentation-only change).

Summary: items 1 and 2 are worth resolving in this PR — the payment-based persona definitions and the duplicated gross/effective definitions are both things a standards reviewer would send back. Item 4 needs a decision on the target output format. Items 3 and 5 are quick, and 5 could reasonably be deferred. The core change — clause numbering plus ISO term and definition style — is the right direction and cleanly executed.

[claude]

Review — Clause 4 ISO alignment

Reviewed per CLAUDE.md: this is a specification repo, so the axes below are document conformance, cross-reference integrity, and rendering rather than code/perf/security/tests (none of which apply to this diff).

Two earlier automated reviews are already on this PR. Rather than restate them, I verified their claims and focused on what is still open. Two corrections first:

• ❌ "Missing blank line before **4.1**" — not accurate. SPEC.md:61 is a genuinely empty line between the - IEC Electropedia bullet and **4.1**. No action needed.
• ❌ "GitHub own renderer treats these as line breaks so it likely looks fine" — not accurate. GitHub renders repository .md files with soft line breaks collapsed; the hardbreaks behaviour applies to comment fields (like this one), not to files in the tree. The run-on-line concern is real. Corroborating evidence: the T.1 entries this PR replaces used trailing double-spaces precisely to force those breaks.

Confirmed accurate from the earlier reviews: no dangling T.n cross-references remain anywhere (SPEC.md, FAQ.md, README.md, ANCILLARY.md all clean), and 15 separator lines in the new block are single-space rather than empty.

---

🔴 Main issue: 4.1 redefines a term owned by the normative reference

Clause 4 opens with "the terms and definitions given in ISO/IEC 21031:2024 and the following apply" — which asserts that 4.1–4.10 are additional terms. But the Note in 4.1 says the concept is already "described in the Functional Unit clause of ISO/IEC 21031:2024." If 21031 defines functional unit in its terms clause, then this document both inherits and overrides that definition, and a conformance reader has no rule for which one wins. ISO/IEC Directives Part 2 treats redefining a term from a normatively-referenced document as a defect.

Worth confirming against the 21031 text, then picking one:

• Preferred — rename to a distinct term, e.g. 4.1 AI functional unit, defined as a specialization of the R in 21031. No collision, and it reads correctly at the call sites in clauses 8.1/8.2.
• Or drop 4.1 entirely and rely on the 21031 definition, keeping only the AI-specific guidance already in 8.2.1.
• Or keep the override but say so explicitly ("This document specializes the definition given in ISO/IEC 21031:2024, 3.x, for AI systems").

The same question applies more weakly to 4.2/4.3 (consumer, provider) if 21031 defines those.

🟠 Note/example tagging is inconsistent across the three entries with trailing prose

Entry	Trailing text	Tagged?
4.1	This definition adapts the functional unit concept (denoted R)...	❌ untagged prose
4.9	Note 1 to entry: Examples include total parameters...	✅ Note
4.10	Examples include active parameters used per inference...	❌ untagged prose

Under ISO/IEC Directives Part 2, everything following a definition in a term entry must be an explicitly labelled Note n to entry: or EXAMPLE. Untagged paragraphs are ambiguous — a reader cannot tell whether they are normative. Suggest tagging 4.1 as Note 1 to entry:, and making 4.9/4.10 symmetric (EXAMPLE fits both, since both are purely example lists — 4.9 currently wraps its examples inside a Note).

🟠 Vague citation in the 4.1 note

the Functional Unit clause of ISO/IEC 21031:2024 — cite the clause number (ISO/IEC 21031:2024, 3.x or , Clause N). Prose-named clause references break silently when the referenced standard is revised, and cannot be resolved by a reader who does not already own the document.

🟠 4.9/4.10 now duplicate the 8.2.2 Explanation block

SPEC.md:243–247 already carries near-verbatim text for both concepts:

• Gross values refer to total quantities without adjustment — e.g., total parameters in the model, total tokens in a raw dataset, or total theoretical FLOPs.
• Effective values account for actual usage or meaningful contributions — e.g., active parameters used per inference (for sparse models), deduplicated or curated tokens, or utilized FLOPs during computation.

Defining these in Clause 4 is the right call, but leaving both copies means two sources of truth that will drift at the next revision. Suggest reducing the 8.2.2 block to its genuinely additive final sentence plus a cross-reference:

> **Explanation**: See 4.9 (gross value) and 4.10 (effective value).
>
> Reporting *effective* values gives a more realistic picture of efficiency by recognizing
> carbon savings from optimizations like pruning, deduplication, or sparse activations.

While in that area: SPEC.md:240 reads "using gross or *effective* values" — italicising only one of the two now-defined terms. Worth making consistent.

🟡 Rendering — hard breaks

As above, each entry collapses to 4.1 functional unit quantified performance characteristic... on one line. Restore the trailing double-spaces the T.n entries used:

**4.1**··
**functional unit**··
quantified performance characteristic of an AI system that serves as the reference unit for carbon intensity calculation

(·· = two spaces.) Please confirm in the rendered Files changed view — three lines per entry, ten entries. The same pass can convert the 15 single-space separator lines to genuinely empty ones.

🟡 Cross-PR consistency (PRs 137–142)

Not blocking this PR, but flagging since it is a six-PR series all branched from 5a52cab:

• Rebase order — 137–142 each rewrite a different clause of the same file. Different line ranges, so textual conflicts are unlikely, but whichever lands first will require the rest to rebase, and clause numbering should be re-verified after each merge.
• Heading case — this PR moves 4. to sentence case (Terms and definitions) while 2. Scope, 5. AI Lifecycle Stages, 7. AI Life Cycle Coverage remain Title Case. PR 139 does the same for clause 6. Fine as an incremental series, provided a final pass catches the stragglers.
• Requirement verbs — PR 139 lowercases SHALL to shall in clause 6 (correct per ISO Directives, which uses lowercase). Clause 4 has no requirement verbs so nothing to do here, but the document will be left mixed: uppercase SHALL/SHOULD/MAY survive throughout clauses 6–8 (SPEC.md:133–251). Worth a dedicated PR in this series.
• Defined-term capitalization — 4.2/4.3 define lowercase consumer/provider, but the body consistently writes Consumer/Provider. ISO does not use capitalization to mark defined terms, so the body usage is what eventually needs adjusting, not these definitions.

📄 FAQ sync

Per CLAUDE.md, FAQ.md has no coverage of the new gross value / effective value terms. The rationale for defining both (rather than mandating effective values) is a genuine design decision and a natural FAQ entry — something like "Why does the spec allow reporting gross values at all?" Judgment call, but it is exactly the kind of "why is it structured this way" content FAQ.md exists to hold.

---

Summary: the direction is right and the mechanical ISO conversion is well executed. Before merge I would fix the hard-break rendering (🟡, quick) and resolve the 4.1 term collision with 21031 (🔴, needs a decision). Note tagging and the 8.2.2 de-duplication are worth folding into the same pass.

[claude]

Review: Revised the Terms and definitions to comply with ISO (#137)

Thanks for this — moving clause 4 to ISO drafting conventions (sentence-case heading, lowercase term entries, no terminating full stop, 4.1-style entry numbers, floating point operation / FLOP as preferred term + abbreviation) is the right direction, and the two new entries for gross value / effective value fill a real gap. A few things I'd fix before merge.

1. Rendering: the hard line breaks were dropped, so each entry collapses onto one line 🔴

The previous version used two trailing spaces after the entry number and the term to force line breaks (T.1··, **Functional Unit**··). The new version removes them, so in CommonMark/GitHub the three lines of each entry are a single paragraph and render as:

4.1 functional unit quantified performance characteristic of an AI system that serves as the reference unit for carbon intensity calculation

That defeats the ISO layout the PR is trying to achieve, and it affects all ten entries (SPEC.md:63-108). Either restore the trailing double-space:

**4.1**  
**functional unit**  
quantified performance characteristic of an AI system ...

or use <br> if trailing whitespace is undesirable. Worth previewing the rendered file before merge — there is no markdown lint/render check in CI (.github/workflows/ only holds the two Claude workflows), so this class of issue will not be caught automatically.

2. gross value / effective value are now defined twice, with drifting wording 🟠

SPEC.md:244-248 already carries an explanatory blockquote in 8.2.2 with near-identical but not identical text ("meaningful contributions" vs. the new "meaningful contribution"; "total quantities without adjustment" vs. "without adjustment for actual usage or contribution"). Two copies of a normative definition will diverge over time. Suggest trimming 8.2.2 to a cross-reference — e.g. "Whether emissions are normalized using gross values (4.9) or effective values (4.10)" — and keeping only the guidance sentence about why effective values are preferable, since that part is guidance rather than definition.

3. ISO drafting details still outstanding

• Notes and examples need their ISO labels. The paragraph at SPEC.md:67 is a note to entry, and SPEC.md:102 / SPEC.md:108 are examples. ISO/IEC Directives Part 2 style is Note 1 to entry: This definition adapts ... and EXAMPLE Total parameters in a model, total tokens in a raw training dataset, total theoretical FLOPs. As plain paragraphs they read as body text of the clause rather than as part of the term entry.
• Cite the referenced clause by number. SPEC.md:67 says "the Functional Unit clause of ISO/IEC 21031:2024"; ISO practice is a numeric reference, e.g. "ISO/IEC 21031:2024, 5.x".
• Possible redefinition conflict. Clause 4 states that the terms in ISO/IEC 21031:2024 apply, and then 4.1 defines functional unit — a term that standard defines itself (it is the R in the SCI equation). Redefining a term taken from a normatively referenced document is something ISO reviewers usually push back on. Either name the AI-specific concept distinctly (functional unit for AI) or make the note explicit that this narrows, rather than replaces, the 21031 definition.

4. FAQ.md is not updated

Per the CLAUDE.md change-management rules, substantial SPEC changes need matching FAQ coverage. gross value and effective value are now normative definitions, and FAQ.md has no entry explaining the distinction or why the spec asks providers to disclose which they used (the only "effective" hit in FAQ.md is unrelated, at line 44). The T.x → 4.x renumbering is worth a line too, since issues and meeting notes may reference the old identifiers. I checked the repo and nothing cross-references T.1-T.8, so the renumbering is internally safe.

5. Whitespace and cross-PR consistency 🟡

• The inserted blank lines contain a single space rather than being empty (about a dozen of them). Harmless for rendering — CommonMark treats whitespace-only lines as blank — but it is trailing whitespace that will show up as noise in every future diff of this region. It matches the already-merged clause 3, so if that is deliberate house style, ignore; otherwise clean both.
• Heading case is now mixed: clauses 3 and 4 are sentence case, clauses 5-9 are still title case. Fine as an intermediate state given Revised the AI lifecycle stages to comply with ISO #138-Revised the Implementation examples to comply with iso #142 are in flight, but the set should land together (or in quick succession) so the document is not left half-converted.
• Related divergence across the sibling PRs: Revised the Terms and definitions to comply with ISO #139 lowercases SHALL → shall, while this PR leaves requirement keywords untouched. Worth an explicit project-wide decision on whether requirement verbs are uppercase (RFC 2119 style, as used throughout SPEC.md today) or lowercase (ISO style) before merging any of them, otherwise the document ends up with both.

Nits

• Entry numbers are bolded (**4.1**) along with the term. ISO renders the entry number as plain text and only the preferred term in bold — not consequential in Markdown, but easy to align.
• 4.6 token: "typically representing parts of words, or characters" has a stray comma before "or".
• 4.4 model training: the change from "a specific task(s)" to "specific tasks" is a good cleanup, thanks.
• Making the two terminology-database URLs proper Markdown links would be friendlier, though the current bare-URL form does mirror ISO's own front matter.

Nothing here is structural — items 1 and 2 are the ones I would want fixed before merge, with 3 and 4 addressed either here or as a fast follow-up.

[Henry-WattTime]

I think the definition in 4.9 and 4.10 need to be corrected to make sense.

[claude]

Review: Revised Terms and definitions to comply with ISO (#137)

Thanks for this — moving Clause 4 to ISO/IEC Directives Part 2 term-entry style (numbered 4.x entries, lowercase terms, definitions with no leading article and no terminating period) is the right direction, and the two new entries (4.9 gross value, 4.10 effective value) fill a real gap: those concepts were already being used in §8.2.2 without being defined. I checked for dangling references to the old T.1–T.8 identifiers across SPEC.md, FAQ.md, ANCILLARY.md and README.md — there are none, so the renumbering is safe.

A few things worth fixing before merge. Since this is a spec repo, I have framed "bugs" as rendering/consistency defects and "tests" as CI checks.

1. Rendering regression: term entries collapse onto one line (blocking)

The previous version ended T.1 and **Functional Unit** with two trailing spaces — Markdown hard line breaks. Those were dropped, so each entry is now three consecutive lines in a single paragraph:

**4.1**
**functional unit**
quantified performance characteristic of an AI system that serves as the reference unit for carbon intensity calculation

GitHub renders .md files without breaks: true (unlike issue/PR comments), so single newlines become spaces. Every entry will render as a run-together line: 4.1 functional unit quantified performance characteristic of an AI system…, which loses exactly the number/term/definition structure the PR is trying to introduce.

My suggestion is to make the entries real subclause headings rather than bold text:

#### 4.1 functional unit

quantified performance characteristic of an AI system that serves as the reference unit for carbon intensity calculation

That fixes the line-break problem, and as a bonus gives each term a stable anchor (#41-functional-unit) so later clauses can link to definitions, and puts the terms in the GitHub document outline. ISO permits term entries as subclauses, so this stays compliant. If you would rather keep bold text, restore the two trailing spaces on the number and term lines instead.

2. Whitespace-only "blank" lines

The 14 blank lines added in this clause each contain a single space (" ") rather than being empty. CommonMark treats them as blank so paragraph breaks still work, but they trip markdownlint MD009, show up as trailing-whitespace noise in diffs, and are inconsistent with the rest of SPEC.md. Worth normalising to genuinely empty lines. The same pattern appears in the sibling ISO-compliance PRs #139–#142, so it may be worth agreeing on once.

3. 4.1 redefines a term from a normative reference

Clause 4 opens with "the terms and definitions given in ISO/IEC 21031:2024 and the following apply", then 4.1 supplies a different wording for functional unit, which ISO/IEC 21031:2024 already defines. That leaves two competing definitions of the same term in scope, and ISO drafting rules discourage redefining a term inherited from a normatively referenced document. Two clean options:

• Drop 4.1 and rely on the inherited definition, adding any AI-specific guidance as a note in Clause 8 where functional units are actually specified; or
• Define a distinct term (e.g. AI functional unit) whose definition explicitly says "functional unit (ISO/IEC 21031:2024) expressed as an AI-specific reference unit".

4. The note on 4.1 needs ISO note formatting and a numbered cross-reference

This definition adapts the functional unit concept (denoted R) described in the Functional Unit clause of ISO/IEC 21031:2024 for AI-specific reference units.

Two ISO-compliance points: notes attached to a term entry are labelled Note 1 to entry:, and cross-references cite the clause number, not the clause title ("Clause X of ISO/IEC 21031:2024" or ISO/IEC 21031:2024, X.Y). As unlabelled prose sitting between term entries, it currently reads as normative text modifying the referenced definition. Suggested:

Note 1 to entry: This term adapts the functional unit (denoted R) of ISO/IEC 21031:2024, Clause X, to AI-specific reference units.

(Substituting the real clause number.)

5. 4.8 abbreviated-term formatting

**4.8**
**floating point operation**
**(FLOP)**

ISO puts the abbreviated term on its own line, unparenthesised, immediately after the full term:

4.8
floating point operation
FLOP
basic computational operation used as a measure of computational work in AI systems

Also consider hyphenating to floating-point operation, which is the more common form in the literature.

6. 4.9/4.10 now duplicate the §8.2.2 explanation block

SPEC.md:240-244 still carries its own prose definitions of gross and effective values, with wording that differs from the new entries. Two independent definitions of the same normative terms will drift. I would trim the §8.2.2 block to the examples only (total parameters vs. active parameters, raw vs. deduplicated tokens, theoretical vs. utilised FLOPs) and let it reference 4.9/4.10 for the definitions — the examples are genuinely useful there and do not belong in Clause 4.

7. Minor / optional

• SPEC.md:61 — http://www.electropedia.org/: current ISO boilerplate uses https://. Worth switching, since the point of the clause is to match ISO text verbatim.
• SPEC.md:58 — recent ISO boilerplate reads "maintain terminology databases"; "terminological" is the older phrasing. Low confidence on which edition you are targeting, so treat as a nit.
• Heading case: ## 4. Terms and definitions is now sentence case while §5 ## 5. AI Lifecycle Stages and §8 ## 8. Functional Units are title case. Revised the Terms and definitions to comply with ISO #139–Revised the Implementation examples to comply with iso #142 appear to be converting headings to sentence case too, so this resolves itself once they land — just flagging that SPEC.md will be mixed-case in the interim.
• Term case vs. body usage: the entries are lowercase (correct for ISO) while the body uses capitalised "Consumer"/"Provider" as role names. That is acceptable ISO practice, but worth a conscious decision so it is applied consistently across the sibling PRs.
• 4.4 — "specific tasks" instead of "a specific task(s)" is a genuine improvement; thanks.

CI / checks

There is no linting in .github/workflows/ (only the two Claude workflows), which is why issue 1 above can reach main unnoticed. For a document-as-deliverable repo, a small CI job would pay for itself:

• markdownlint-cli2 on *.md (MD009 trailing whitespace, MD012 multiple blanks, heading-level consistency) — would have caught issues 1 and 2
• a link checker (e.g. lychee) for the ISO/IEC URLs and any future external references
• optionally, a grep-based guard that RFC 2119 keywords stay in the agreed case, since Revised the Terms and definitions to comply with ISO #139 lowercases SHALL to shall while other clauses still use uppercase

Process notes

• Per CLAUDE.md, changes to SPEC.md should be checked against FAQ.md. I read through FAQ.md — it has no term list, so nothing here contradicts it. 4.9/4.10 introduce no new concepts (both were already described in §8.2.2), so I do not think a new FAQ entry is strictly required. If the gross-vs-effective distinction is expected to attract questions, a short FAQ entry under "Functional Units" explaining why effective values are encouraged would be a natural addition.
• This branch's merge base predates the current dev (the Normative references clause has since gained the "For dated references…" sentence). The merge is still clean, but a rebase would make the diff reflect what actually lands.
• Revised the Terms and definitions to comply with ISO #137 and Revised the Terms and definitions to comply with ISO #139 share the title "Revised the Terms and definitions to comply with ISO", but Revised the Terms and definitions to comply with ISO #139 actually revises Clause 6 (Persona-based software boundary definition). Worth retitling Revised the Terms and definitions to comply with ISO #139 to avoid confusion in the weekly-call review. Revised the Terms and definitions to comply with ISO #137's last context line is the ## 5. AI Lifecycle Stages heading, which Revised the AI lifecycle stages to comply with ISO #138 also touches — merging Revised the Terms and definitions to comply with ISO #137 first should avoid a conflict.

Not applicable

No executable code, dependencies, or user-input handling is involved, so there are no performance or security considerations in this change.

Overall: the ISO restructuring is sound and the new terms are a real improvement. Item 1 needs fixing before merge; items 3–5 are what an ISO editor would flag; the rest is polish.

🤖 Generated with Claude Code