TSON 2026 Revision 38 — Change Log

This document records the changes accepted into Revision 38 of the TSON specification series, adjudicated from the implementation’s spec-feedback register (25 entries, renumbered from #1 against Revision 37, all raised since Revision 37 closed every entry open against Revision 36). SPEC-FEEDBACK.md remains a record against Revision 37 and is not modified by this revision; each of its entries receives a disposition here.

Provenance markers used in the disposition table:

[settled] — the resolution was settled by the spec author inside the feedback register itself, is already implemented in the revised companion artifacts shipped with this revision, or was decided by the spec author at adjudication.
[open] — a genuine design decision deliberately left open. Collected in §5.
[editorial] — a sentence the revision editor had to write that no register entry dictates, or a reading the editor took where the register admits more than one. Each is the spec author’s to confirm; collected in §5 beside the open questions.

This revision does not change the lexer. [TSON-DATA] §1.3’s lexer-freeze paragraph stands as Revision 37 left it: a qualified name (#13) is a parse of a token the lexer already emits, performed by the slot’s type, and the . the identifier profile reserved is now spoken for without entering the identifier grammar.

It does change the data grammar at one position: a field name is matched against the identifier grammar only in a document that names no schema, and the match moves from the parser to the resolver, so a schemaless { "first name": 1 } is a resolver error where it was a parse error (#10). It changes the schema grammar at the same position — a declared field name is any single-line token, judged at link by its record’s name type — and otherwise leaves §12.1 alone.

What this revision changes most is the kernel, and with it the shape of resolved output: type_definition is gone and an entry is its value (#14); type, namespace, kind_type and ref_type join the kernel and data and text_enum leave it (#9, #22, #23, #24, #10); a record’s fields are a map keyed by name (#12) and its names have a type (#10); a record template is a record with parameters (#17); and the five network families leave core for a new library, net.tn, beside three atoms new to the series (#2, #5, #6, #8). Every bundled pin changes.

1. Baseline: the revised artifacts

Thirteen of the register’s proposals arrived already implemented in the companion artifacts, and Revision 38 adopts them as its baseline. Summarising the normative effect:

#2 — the network types are a library of their own. net.tn (https://tson.io/2026/38/m/net.tn), governed by meta and importing nothing, holds ipv4, ipv6, cidr4, cidr6 and mac, moved from core unchanged, and the three atoms below. Core no longer declares the five, so a schema importing core alone may declare mac or hostname for itself. Meta’s network constructors say “Instance is ipv4 in net”. (Part 1 §5.5, §5.6, §10; Part 2 §1.5, §9, §13.2; core, meta, net.)
#5 — hostname_type. Meta declares hostname_type => atom & atom_specification & { spec?: = "…rfc5890" allow_idn?: boolean ~ true } and net instances hostname: a domain name in LDH, A-label or U-label form, in any mix, A–Z read as a–z and nothing else mapped, each label at most 63 octets and the name at most 253 in A-label form, no trailing dot, the last label not beginning with a digit; the value is the name, so Example.COM, example.com, xn--bcher-kva.example and bücher.example are two values, and the canonical text is the lowercase U-label form. (Part 1 §5.5, §10; Part 2 §5.5, §9, §13; meta, net.)
#6 — host_type. Meta declares host_type => atom & atom_specification & { spec?: = "…rfc3987" } and net instances host: RFC 3987’s ihost profiled to DNS — a hostname, an IPv4 address, or an IPv6 address with or without brackets, no zone identifier — one string-class atom whose value is the member’s with the member’s own equality, an IPv4 address never equal to an IPv6 one. (Part 1 §2.2.1, §5.5; Part 2 §5.5, §9; meta, net.)
#8 — media_type_type. Meta declares media_type_type => atom & atom_specification & { spec?: = "…rfc6838" allow_parameters?: boolean ~ false types?: [text] suffixes?: [text] } and net instances media_type: an RFC 6838 media type with RFC 9110 §8.3.1 parameters where an instance admits them, the type, subtype and parameter names and a charset value compared without ASCII case, parameters a map, the canonical text lowercase with parameters sorted by name. (Part 1 §5.5, §10; Part 2 §5.5, §5.7, §9; meta, net.)
#9 — the type kind. The kernel declares type => abstract top & { chain?: type_chain }, and atom, product and sum compose it; reference, template and namespace compose top directly, and data is gone. An entry is a type exactly when it IS-A type; IS-A top is still the constructor predicate. Every constructor under a base kind gains type in its chain. (Part 2 §4.1, §4.2, §8.1, §9; kernel, fixtures.)
#10 — a record’s field names have a type. record gains name_type?: identifier_kind, and enum_type.type is renamed name_type and retyped identifier_kind: an enum’s members and a record’s field names are names drawn from an identifier family, held to it by the same three rules. text_enum is removed, a closed set of text being text_type’s members facet; identifier_base gains ASCII, and scheme_name is restated over it (start: ASCII continue: ASCII continue_add: "+-." exclude: "_" normalization: ASCII_CASEFOLD, the same set). record.discriminators and field_group’s member slots are text, each judged by the record’s name type. (Part 1 §1.5, §2.5, §2.8, §7.1, §7.4, §7.7, §8.1, §8.2; Part 2 §5.2, §5.4, §5.8, §5.11, §7.4, §7.7, §8.1, §9, §11.4, §12.1; Part 3 §1.3, §3.2, §6.1.1, §8.3.1, §9.4; kernel, fixtures.)
#12 — a record’s fields are a map keyed by name. record_field loses name; field_map => namespace & { key_type?: ~ field_name value_type: = record_field ordered?: = true } joins the kernel and record.fields is field_map. The explicit form is !record { fields: { x => { type: int32 } … } }; the brace form an author writes is unchanged. (Part 2 §5.2, §5.6, §8.1; kernel, fixtures.)
#14 — type_definition goes; a type carries its own chain. type_chain => { parents?: [type_ref] supertypes?: [type_name] subtypes?: [type_name] } is type’s one field; record.supertypes is removed; application => @annotation type_ref is a resolver-attached key annotation, read as stated on ingest; schema => namespace & { key_type: = type_name value_type: = top }. An entry resolves to its value, and output is source with sugar expanded, bodies flattened and chains computed. (Part 2 §1.3, §1.6, §4.1, §5.5, §5.7–§5.9, §6, §7.2, §8.1–§8.3, §9, §10.1; kernel, every fixture.)
#15 — top, type, the base kinds and namespace are abstract. Each states extension: ABSTRACT in resolved output, and a direct application of one is refused as any abstract record’s is, naming the subtypes that would satisfy it. §3.3.1’s “base kind’s own reader” sentence is retired. (Part 2 §3.3.1, §4.1, §12.1; kernel, fixture.)
#17 — a record template is a record with parameters. record gains parameters?: [template_param]; template holds every other open body and loses extension and discriminators. A record template is a family base, ABSTRACT by construction, its own extension each application’s, and its chain.parents the parents as written, one of which may be an application. (Part 2 §4.1, §5.10, §8.1, §9; kernel, fixture.)
#22 — kinds. kind_type => atom & { of: type_name members?: [type_name] } is the atom whose values are the names of the types in the closure built with of, with kind => <T> !kind_type { of: T } as its inline spelling and members a resolver-derived index. The kernel declares identifier_kind, atom_kind and type_kind, types both name_type slots by identifier_kind, and retypes every slot that names the type of a value — record_field.type, tuple_element.element_type, array.element_type, map.key_type and value_type, choice.variants, template_param.type and bound — as type_kind; type_ref stands only where an application may. Core declares a kind sibling. (Part 2 §4.2, §5.3, §5.10, §7.4, §8.1, §9, §13; Part 3 §5, §5.6; kernel, core, fixtures.)
#23 — namespace. namespace => abstract top & { key_type: identifier_kind value_type: type_kind ordered?: boolean ~ false } is the constructor whose instances are maps keyed by names; schema and field_map are the kernel’s two. A value of a namespace type is read as the map it describes, never as a record of its facets; a meta-schema declares one and a schema it governs holds a value of it as an entry (orders => !interface { … }), which is a value and never a type. (Part 2 §2.2.2, §2.2.3, §4.1, §5.2, §8.1, §9; kernel, fixture.)
#24 — ref_type. ref_type => atom & { of: type_name } with ref => <T> !ref_type { of: T } is the atom whose values are qualified names of values; of names a type of the writer’s own namespace, never a constructor. Kernel vocabulary only: core declares no ref, a reference naming an entry that holds a value, which only a kernel-governed schema has. (Part 2 §4.2, §5.12, §9; kernel.)

The artifacts also carry housekeeping the register did not raise, adopted here on the same footing:

identifier_kind’s members are listed. The kernel’s resolved fixture writes members: [field_name identifier param_name scheme_name type_name] — the three roles are aliases of a member and listed beside it — and atom_kind and type_kind list theirs, type_kind’s including top, namespace, field_map, schema and the synthetic arrays.
record_extension_type’s doc no longer cites §5.9’s emptied supertypes: “a subtracted record’s chain is empty, so it mints no IS-A edge”.
core.tn’s reference list drops RFC 4291, RFC 4632 and RFC 9542 with the families that left; net.tn’s carries them with RFC 1123, RFC 3492, RFC 5890–5893, RFC 5952, RFC 6838, RFC 6839 and RFC 9110 §8.3.1.
The resolved fixtures’ conventions note is rewritten for the new output shape: an entry is its value, a type body carries chain, a composition’s fields are flattened with chain first, and a slot that names a type is type_kind and holds a bare name.

2. Disposition summary

#	Entry (abridged)	Disposition
1	A refusal is a rejection by this processor, not “not judged”	Accept. [TSON-DATA] §8.1’s fifth outcome becomes two: refused — this processor declined the document under its own configuration (its §8.2 policy and data version, its §9.1 limits, or a schema it does not hold and will not fetch or one past its size limit) — a rejection here and never a finding about validity, MUST be distinguishable from the four categories and MUST name the rule or limit; and undetermined — this processor could not obtain what it would judge against (nothing at the reference, no answer), and nothing was judged. The closing sentence reads “two conforming processors may legitimately disagree on whether they accept a document, while never disagreeing on validity”. §8.2 and §9.1 cite “refused”; [TSON-SCHEMA] §10.1 and §11.2 split “its policy or its network did not supply” along the same line. One sentence added at adjudication: a refusal under a fetch policy SHOULD NOT disclose the allowlist. [editorial] [TSON-JSON] §9.4 and §10.1 already carry the outcome. [settled]
2	The network types are a library of their own, `net.tn`	Accept — the baseline above. Part 2 §1.5 counts nine companion artifacts and §13.2 carries the five normative pins, the four fixtures listed in §13.3; §9 states the principle: a family most schemas never use belongs in a library outside core. [TSON-DATA] §5.5’s table gains a column naming the library each row’s name comes from, and §5.6’s rule is restated: a schemaless name denotes the type its library declares under that name, so a document moving under a schema that imports the library keeps its meaning. A language change: a schema importing core and using `ipv4`, `ipv6`, `cidr4`, `cidr6` or `mac` imports `net.tn` as well. [settled — implemented]
3	A type annotation outside the built-in vocabulary is a resolver error	Accept, on the register’s four grounds: the vocabulary does not grow, gradual adoption runs through the built-ins, the verdict is portable, and the removed sign bounds protect no deployed document. [TSON-DATA] §1.5, §3.2, §5.1, §5.6 and §8.1 and [TSON-SCHEMA] §7.1 read as the register proposes; §3.1 and [TSON-SCHEMA] §6 are untouched, the preserved-uninterpreted treatment belonging to `@` annotations alone. A host-typed read is no exception, and host types as a schema is a caller’s explicit choice outside the series’ verdict. A language change: `!nonesuch` in a schemaless document is refused. [settled]
4	An identity is an IRI whose host is a `host` value	Accept. [TSON-DATA] §2.2.1: an identity’s host is a `host` value as §5.5’s row defines it (an `ireg-name` a `hostname`, an `IPv4address` an `ipv4`, an `IP-literal` an `ipv6`; IPvFuture and zone identifiers refused); canonical identity is the host’s canonical text plus the path, the path NFC; `!!id` is written in canonical form only, and a reference may use any spelling of the same identity — A-labels, ASCII case, an uncompressed or bracketed IPv6 address, the URI spelling with percent-encoded UTF-8 read back and hex case ignored — and is read to canonical form before comparison; what has no IRI form stays an error. The Unicode-version consequence is stated beside §7.1’s. The identity atom the HTTP layer asked for is recorded as considered and not taken (§5), for the register’s reasons. [TSON-JSON] §3.5 already carries a reference beyond US-ASCII in its URI spelling. [settled]
5	`hostname` is a domain name in either label form	Accept — the baseline above. [TSON-DATA] §5.5 gains the row; the four boundaries an operator will meet (uppercase beyond ASCII, a trailing dot, a digit-initial last label, percent-encoding) are stated beside it. [settled — implemented]
6	`host`: a host name or an IP address, one string-class atom	Accept — the baseline above. [TSON-DATA] §5.5 gains the row; `[::1]` and `::1` are one value, the canonical text unbracketed, and `ipv6` itself still refuses the brackets. `allow_zone` is recorded as the likely first facet and not taken (§5). [settled — implemented]
7	§7.7 says identifier validity is the same at every Unicode version; §7.1 says it grows	Accept — §7.7 claims the weaker property §7.1 states: a text valid at one Unicode version is valid at every later one, a content-addressed schema’s validity can be lost to no UCD refresh, and a processor on an earlier version may refuse a name a later one accepts, its report naming the version. [settled]
8	`media_type`: a media type and its parameters	Accept — the baseline above. [TSON-DATA] §5.5 gains the row. `types` and `suffixes` are member sets under §5.7 and `allow_parameters` a permission; the `charset` fold is the one value fold, the list closed. `uri_template` is not proposed and not taken. [settled — implemented]
9	The `type` kind	Accept — the baseline above. §4.1 is rewritten around `top`, `type`, the three base kinds and `namespace`; kind determination reads a base kind off the chain excluding `top` and `type`, with `namespace` read the same way. [settled — implemented]
10	A record’s field names have a type: `record.name_type`	Accept — the baseline above, and every reading the register settles as built: one field for one mechanism on both constructors; a name type is an identifier family whose `normalization` implies NFC (`NONE` refused, `ASCII_CASEFOLD` admitted only over an all-ASCII profile); a document’s name is matched in the type’s form and an undeclared name is a closure error whether or not it is a value of the type; inheritance keeps one name type, as the constructor’s rule, and supertypes with different ones do not compose; the brace form states a type by composition onto a fieldless abstract base and has no syntax of its own; a profile may not add a Default_Ignorable_Code_Point, a control or a space other than U+0020; a schema’s own references to its fields match exactly; a lookahead does not judge a name; a document that names a schema has its field names judged by that schema alone, and a Class 1 processor reading it holds field names to no name rule. Language changes: `enum_type.type` is `name_type`; `!text_enum [...]` is `!text ^ { members: [...] }` or an enum over the author’s own identifier type; a field-name position admits any single-line token. [settled — implemented]
11	The guide and the schema skill should say what `name_type` makes possible	Accept for the guide — a new section on the register’s seven-point outline (§7.2). The `tson-schema` skill is published with the series but is not among this revision’s inputs; its edits are recorded as outstanding (§5). [settled]
12	A record’s fields are a map keyed by name	Accept — the baseline above, with the map ordered, the key family the record’s `name_type`, and a duplicate refused by the layer that can see it: a spelling written twice is the map’s duplicate key, two spellings that are one value of the name type are the linker’s resolver error. [settled — implemented]
13	A value written by name: a qualified name	Accept, as #24 refines it. A new [TSON-SCHEMA] §5.12 states the qualified name — segments joined by `.`, the first a type name resolved as a `type_ref` is, each further one selecting a key of a namespace value or a field of a record value, every hop written, no index and no quoted segment — and its judgement: found first, judged after, never a choice among candidates, each refusal naming its own step. Under #24 a name stands at a slot typed `ref<T>` and nowhere else, so #13’s bare-name-at-a-product-position rule is subsumed: §5.6’s positional form keeps a bare token where the positional field is atom-typed, and in a schema document a product- or sum-typed positional fill is written as the explicit record (the register’s decision 1); a data document reads every bare token as before (decision 3). Decisions 2, 4–11 are taken as built. [TSON-DATA] §7.1’s `.` is the separator of [TSON-SCHEMA] §5.12. One consequence is flagged for confirmation (§5): `record_field.type` is now `type_kind`, an atom, so by the rule as stated `fields: { p => x }` is a positional fill and not the withdrawn spelling the register’s vector pins. [editorial] [settled]
14	`type_definition` goes	Accept — the baseline above. §8.1 is retitled and rewritten around `type_ref` and `type_argument`; an entry resolves to its value; an entry’s kind is its value’s type’s kind, judged by origin; `source` is gone and the sentences naming it in §5.5, §5.7, §5.8 and §5.10 read the tag; §5.9’s lineage sentences and rule 10 go, a subtracted record’s chain being empty; §7.2’s “never the body’s lineage” goes; `@application` is a key annotation beside `@synthetic`, derived, never author-written, read as stated on ingest; `chain` is never written by a declaration and never declared by a constructor. The in-memory fact the implementation keeps for a tightened constructor’s one parent is noted and asks nothing of the text. [settled — implemented]
15	`top`, `type` and the base kinds are `abstract`	Accept — the baseline above. An annotation typed by a base kind is a schema error in either §6 position. [settled — implemented]
16	A record template’s parameters stand in three places; a parameter is never an operand	Accept. §5.10 “Held bodies”: in a `!record` body a parameter stands only at a field’s type, a field’s default or fixed value, or an argument of an application, anywhere else a resolver error naming the slot; §5.8: an operand may carry arguments naming the parameters, and an operand that is itself a parameter is a resolver error, under the shadowing rule. Templates over other constructors are unchanged. [settled]
17	A record template is a `record` with `parameters`	Accept — the baseline above. A record template is not held; the base’s ABSTRACT is by construction and the record’s own `extension` is each application’s; `template` is not a type and an application of it is its expansion; a record template named bare at an operand of `&` or `^` is a resolver error. [settled — implemented]
18	An application nothing declares is its expansion	Accept. §8.2: a fully-bound application of a template materialises its expansion, a synthetic entry keyed on its content, and mints no instantiation entry unless the expansion names the application itself, where the knot is tied on the application; a minted record is a member of nothing, and one whose chain would name a declared type is a resolver error at the declaration that wrote the application; a declaration names only itself; a diagnostic names what the author wrote. The `vector_pixel_af3` example is rewritten. A verdict change, stated in §4: a minted record composing an application only a use site mints now loads. [settled]
19	A selector’s type may contain no parameter, value parameters included	Accept — §5.10: a selector’s declared type mentions none of the template’s parameters, at any depth; a parameter-free application satisfies it. [settled]
20	A routed `= P` is FIXED where it is written	Accept — §5.7 “Open modifiers”: the role is the modifier’s, as beside a literal, and materialisation substitutes the argument into `value` without changing a fact; a FREE field never carries a value, open or closed. The kernel’s `record_field` doc already states it. [settled — implemented]
21	A template’s parameter pin is a selector whatever its name’s mark	Accept — §5.7 and §5.10 drop “on an unmarked name”; the base reads the selector required with the pin dropped, and each member is FIXED to its argument, optional as the name was marked. [settled]
22	The types built with a constructor are a kind: `kind_type`	Accept — the baseline above, with `of` resolving in the structure namespace and naming `type` or `namespace` or a constructor below either (#23), membership one walk over resolved entries, a kind no bound, members computed at link over the governing closure, and the inline `kind<T>` sugar. Open — two remainders (§5): whether a kind admits an abstract type (running: membership by construction, which the text states), and the higher kind `kind_type.of` would want, which the series has none of. [settled — implemented / open]
23	A namespace is a constructor whose instances are maps	Accept — the baseline above, with the reading rule, membership (a namespace constructor is a type and a member of `type_kind` and the namespace kinds and of no other), only a namespace entered by a qualified name, a namespace type declared only by a meta-schema, and `data` removed. Open — one remainder (§5): whether a namespace entry (`myapi => !api { … }`) is listed by `kind<api>` and `kind<namespace>` as running, or only where its value is a type; the text states the running behaviour, marked for confirmation. [editorial] A namespace keyed by text and `&` over namespace values are not proposed and not taken. [settled — implemented / open]
24	A reference to a value: `ref_type`	Accept — the baseline above. The slot declares the spelling: a slot typed `ref<T>` holds the name and nothing else, one typed `T` the value inline; a kind-typed slot of a value body holds one bare name and refuses a braced application; a reference is kernel vocabulary and core declares none. [settled — implemented]
25	An import stands at the importer’s governing level	Accept — §2.2.3: an imported schema MUST stand at the importer’s governing level, both named the meta-kernel as their `!!meta` or neither, judged per import edge; a meta-schema declares the vocabulary its constructors use, and an ordinary schema reaches a meta-schema’s constructors only through its `!!meta`. The bundled chain already imports at one level throughout. A language change: a schema governed by `meta.tn` importing `meta-kernel.tn` or a meta layer, and a kernel-governed schema importing `core.tn`, are refused. [settled]

Counts: 25 accepted (1–25 — of which #22 and #23 carry open remainders), 0 declined, and 3 open questions carried (#22’s two, #23’s one), plus the open remainder of Revision 35’s #25 and Revision 37’s Part 3 ordered-map confirmation (§5). Revision 37’s open #2 — a namespace as a value — is closed by #13, #22, #23 and #24 together, and its open #3 — a JSON member name that is not an identifier — by #10. Open questions are recorded here and are NOT reflected as open text in the specification.

3. Accepted changes by target document

3.1 Part 1 — Text Data Format

§1.5 — the name MUST reads “every type-annotation and annotation name, and every field name of a document that names no schema” (#10); a type annotation outside the vocabulary MUST be reported as a resolver error (#3); the reporting bullets speak of a refusal as a rejection by this processor (#1).
§2.2.1 — an identity’s host is a host value (§5.5) and its path NFC; canonical identity is the host’s canonical text plus the path; !!id is written in canonical form only; a reference may use any spelling of one identity and is read to canonical form — host spellings, URI spelling with percent-encoded UTF-8 read back and hex case ignored — before comparison; what has no IRI form stays an error; an identity’s validity grows with the Unicode version as §7.1’s does (#4).
§2.5 — a field name is a value of its record’s name type ([TSON-SCHEMA] §5.2), an identifier where no schema says otherwise and always in a schemaless document; the duplicate rule compares in the name type’s form; the remedy “a key that is not a name belongs in a map” stays (#10).
§2.8 — a record’s first field name is a bare unquoted or single-line token; the identifier match moves to §2.5’s schemaless rule (#10).
§3.2 — a type annotation whose name is not in the built-in vocabulary, in a document with no schema in scope, is a resolver error (#3).
§5.1, §5.6 — the marker sentences become resolver errors (#3); §5.6’s rule is restated by library: a schemaless name denotes the type its library declares under that name (#2).
§5.5 — the table gains a column naming the library each row comes from, and three rows: !hostname, !host and !media_type, each with its value space, equality and canonical text; the paragraph on the string-class atoms counts them (#2, #5, #6, #8).
§7.1 — _id is a resolver error in a schemaless document and a parse error unquoted (#10); . is the identifier separator of [TSON-SCHEMA] §5.12, no longer “future”, and the identifier profile is unchanged by it: a qualified name is a token the slot’s type parses (#13).
§7.4 — the field-name note: an identifier position in a schemaless document, judged by the record’s name type under a schema (#10).
§7.7 — the Unicode-version sentence (#7); a token at a naming position whose decoded text fails the grammar is a parse error at annotation and type-annotation names, and a resolver error at a schemaless field name (#10).
§8.1 — the resolver errors gain a type annotation outside the vocabulary (#3) and a schemaless field name that is no identifier (#10); “not judged is a fifth outcome” becomes “refused and undetermined are two outcomes beside the four categories”, each defined (#1).
§8.2 — “the fifth outcome” reads “refused” (#1); a record’s field names and an enum’s members are names under their type’s profile, and a profile may not add a Default_Ignorable_Code_Point, a control or a space other than U+0020 (#10).
§9.1 — a limit refusal is the refused outcome (#1).
§10 — RFC 3492, RFC 5890–5893, RFC 5952, RFC 6838, RFC 6839 and RFC 9110 join the normative references (#5, #6, #8), and RFC 5322, cited by §5.5 since Revision 36 and never listed, gets its row [editorial].

3.2 Part 2 — Type System and Schema

§1.3 — a Class 2 processor produces a schema value of the kernel’s schema, a namespace from name to value; a resolved-output consumer dispatches on a record template’s parameters, extension and discriminators and never reads held text (#14, #17); a refusal and an unavailable schema are the two outcomes of #1.
§1.4 — a schema value is a value of schema, a namespace (#14, #23).
§1.5 — nine companion artifacts, net.tn among the normative five (#2).
§1.6 — the resolved-output sentence and the companion-fixture pointer follow the new shape (#14).
§2.2.2 — a namespace type is a constructor, declared only by a meta-schema, which then owns the vocabulary its constructors use (#23).
§2.2.3 — an imported schema stands at the importer’s governing level (#25).
§3.3.1 — the base-kind reader sentence goes (#15); reference.target and kind_type.of are the two slots beside a ! head that may name a constructor (#22); the namespace types (field_map and schema among them) join what is applicable and type_chain and template_param what is not, the kernel’s !schema { … } being the application resolver output writes (#23).
§4.1 — rewritten: top => abstract {}, type, the three base kinds composing type, namespace composing top with its reading rule, reference and template; no data; the IS-A order and type_chain; a kind derived by origin (#9, #14, #15, #23).
§4.2 — kind_type, kind, identifier_kind, atom_kind and type_kind; ref_type and ref, kernel vocabulary; a type slot is type_kind (#22, #24).
§4.3 — the operations table: subtraction empties the chain and keeps no lineage (#14).
§5.2 — name_type and its rules — the default, inheritance, the brace form by composition, the form implying NFC, the profile floor, matching in the type’s form, a document’s name judged by the record that reads it; fields as a map and the duplicate layers; discriminators [text; 1..]; “a family member is declared” rewritten for #18, a minted record being a member of nothing (#10, #12, #18).
§5.3 — a type slot is type_kind and holds a bare name; an argument is read as its parameter’s type (#22).
§5.4 — an enum’s class is read off its members under its name_type, an identifier family; the text_enum sentence goes; a kind and a reference are string-class (#10, #22, #24).
§5.5 — three clauses for hostname, host and media_type’s value spaces (#5, #6, #8).
§5.6 — the positional form keeps a bare token where the positional field is atom-typed; in a schema document a product- or sum-typed positional fill is the explicit record; the end state has no source (#13, #14).
§5.7 — the role is the modifier’s where it is written; a parameter pin is a selector whatever its mark (#20, #21); types and suffixes among the member sets and allow_parameters among the permissions (#8).
§5.8 — a parameter is never an operand (#16); supertypes with different name types do not compose (#10); the resolution paragraph reads chain (#14).
§5.9 — the lineage sentences and rule 10 go; the resolution paragraph: the chain is empty (#14).
§5.10 — rewritten in its template-forms, held-bodies and family-base paragraphs: a record template is a record with parameters and only a template over another constructor is held; a parameter stands in three places in a record body; a selector mentions no parameter; the base’s ABSTRACT is by construction; a record template named bare at an operand is refused; an application nothing declares is its expansion; type_kind marks a type parameter (#16, #17, #18, #19, #22).
§5.11 — member slots are text, judged by the record’s name type (#10, #12).
New §5.12 — Values by name — the qualified name, ref<T>, the judgement, the refusal table, and what the rule does not decide (#13, #24).
§6 — application joins synthetic among the resolver-attached annotations (#14).
§7.2 — subsumption reads chain.supertypes; the lineage sentence goes; !schema marks a namespace value (#14, #23).
§7.4 — enum_type.name_type: identifier_kind; text_enum removed and a closed text set pointed at text_type.members; identifier_base with ASCII and scheme_name restated; a name type’s form implies NFC; the profile floor (#10).
§7.7 — a document’s field names are matched in the record’s name type’s form, stated as a paragraph of its own since §7.2 and Part 1 §2.5 cite §7.7 for it (#10).
§8.1 — retitled “Output Records: type_ref and type_argument” and rewritten: an entry is its value; type_chain and where parents holds an application; kind derived by origin; where type_ref stands and where type_kind does; record_field without name; field_map; @application; the ingest rules — chain read as stated, members and subtypes recomputed, @application kept; the body-patterns table (#9, #10, #12, #14, #17, #22, #23).
§8.2 — two identities restated without source; an application nothing declares is its expansion; the self-reaching case; a minted record is a member of nothing; the vector<pixel, 1920> example (#14, #18).
§8.3 — the source sentences go; an alias’s target may name a constructor (#14, #22).
§9 — the kernel and meta rows rewritten; a net.tn row; core’s contents and the library principle; the extension guidance reads “a slot that names a type is typed by a kind, a slot that names a value by a reference, and type_ref is for a slot that holds an application” (#2, #9, #10, #12, #14, #17, #22, #23, #24).
§10.1, §11.2, §11.5 — the two outcomes of #1; a fetch refusal does not disclose the allowlist [editorial]; an allowlist matches a host as a host value (#4, #5).
§7.8 — scoped.schemas is written keyed by schema_identity, as meta.tn declares it and as the same paragraph already said; Revision 37’s {uri => …} was a slip [editorial].
§5.9 — rule 8: a subtracted construction whose head is a constructor is no longer one, its chain being empty and IS-A top the constructor predicate; Revision 37 kept it a “constructor with lineage and no contract”, and with lineage gone (#14) the text follows the predicate [editorial] — for the spec author to confirm.
§11.4 — a record’s field names and an enum’s members are scopes under their name type’s profile (#10).
§12.1 — the type-name note’s field-name clause: any single-line token, judged at link by the record’s name type (#10); the abstract note gains the six kernel entries (#15).
§13 — RFC 3492, RFC 5890–5893, RFC 5952, RFC 6838, RFC 6839 and RFC 9110 added; §13.2 carries the five normative artifacts with the pins as received, and §13.3 the four fixtures.

3.3 Companion artifacts

The revised artifacts shipped with this revision carry the baseline of §1 and every kernel-, meta-, core- and net-level change in this log. Their entries are not edited by this adjudication; §6 lists three doc lines that disagree with the text and are left as received, with the pins they would move.

3.4 Part 3 — JSON Encoding

[TSON-JSON] is edited directly as findings arise, and arrived with the Part 3 halves of five entries already in place: #1 (§1.6 item 19, §9.4, §10.1), #4 (§1.6 item 18, §3.5), #10 (§1.3 principle 3, §1.6 item 15, §3.2, §3.3, §6.1.1, §8.3.1, §9.4), #17’s library (§1.6 item 17, §5, §5.6) and #22 (§1.6 item 16, §5, §5.6). The second pass completed it for the rest, and §7.1 lists the edits. Part 3 defines no type-system rule, so each is a spelling of a rule §3.1 or §3.2 owns.

4. Notable normative changes (reader’s digest)

Changes a Revision 37 implementer must act on:

Resolved output has a new shape. type_definition is gone: an entry is its value (person => !record { … }, age => !integer_type { chain: { supertypes: [integer] } min: 0 }), a type carries chain: { parents? supertypes? subtypes? }, a record’s fields is a map from name to record_field with no name inside, and a record template is !record { fields: { … } parameters: [ … ] }. Every fixture changes.
A record’s field names have a type. record.name_type names an identifier family, field_name by default; enum_type.type is name_type; text_enum is gone. A schema translated from JSON-LD or OpenAPI declares json_name => !identifier_type { start_add: "@$" } on a fieldless abstract base and composes it.
A field-name position admits any single-line token. Schemaless, a name that is no identifier is a resolver error; under a schema the record’s name type judges it, and an undeclared name is a closure error.
A document that names a schema is judged by that schema alone. A Class 1 processor reading it holds its field names to no name rule.
type is a kernel kind. atom, product and sum compose it; data is gone; top, type, the base kinds and namespace are abstract.
namespace is a constructor whose instances are maps. schema and field_map are compositions over it; a meta-schema declares its own, and a governed schema holds a value of it as an entry.
Kinds. kind<C> is an atom whose values are the names of the types built with C; every slot that names the type of a value is type_kind and holds a bare name; type_ref stands only where an application may. Core declares kind, so a schema importing core may no longer declare one.
References. ref<T> is an atom whose values are qualified names, orders.place_order, kernel vocabulary only; a slot typed ref<T> holds a name and a slot typed T a value inline.
An import stands at the importer’s level. A meta.tn-governed schema may not import the kernel or a meta layer; a kernel-governed schema may not import core.
The network types are in net.tn. ipv4, ipv6, cidr4, cidr6 and mac leave core; hostname, host and media_type join beside them, in the library and in the schemaless vocabulary.
An identity’s host is a host value. !!id is written in canonical form; a reference may use any spelling and is read to canonical form before comparison.
An unknown schemaless type annotation is a resolver error. !nonesuch is refused where it was a preserved marker.
Refused and undetermined. A refusal is a rejection by this processor and never a finding about validity; a schema that could not be obtained leaves the document undetermined; a schema this processor will not fetch is a refusal.
A record template’s parameters stand in three places, and never as an operand of & or ^; a selector’s type mentions no parameter; a routed = P is FIXED where written; a parameter pin is a selector whatever the name’s mark.
An application nothing declares is its expansion, and mints no instantiation entry; a minted record is a member of nothing. One verdict changes: u: vip<text> over vip => <T> box<T> & { … } beside w: box<text> now loads.
identifier_base gains ASCII, and scheme_name is written over it.
@application is a derived key annotation on an entry that closes an application, read as stated on ingest; a declaration never writes it, nor chain.
Every bundled pin changes (§6).

5. Open questions carried by this change log

Adjudicated 2026-10-26. The following remain deliberately open, or are the revision editor’s readings awaiting the spec author’s confirmation. They live in this change log only — the specification text carries no open questions.

Ref	Question	Status
Rev 35 #25 (→ —)	Annotation cardinality as the means of per-name replacement.	Open — recorded as considered.
Rev 37 #10 (Part 3)	The two MUSTs [TSON-JSON] §6.4 states for an ordered map.	Open — still the spec author’s to confirm; not raised in the register.
#22 (remainder)	Whether a kind admits an abstract type: membership by construction, as running (`kind<record>` holds `pet => abstract { … }` and a family base; `kind<namespace>` holds `namespace` itself), or a concrete-only kind.	Confirmed (§9): membership by construction, as the text states; a record template is listed, and naming it at a kind-typed slot is refused as open (§4.2, §5.12).
#22 (remainder)	`kind_type.of` is typed `type_name` and not by a kind: its values are names of constructors, which no kind covers, so it would want a classifier of constructors the series has none of.	Open — the store is stated in prose, as every constructor role’s is.
#23 (remainder)	Whether a namespace entry (`myapi => !api { … }`) is listed by `kind<api>` and `kind<namespace>`, as running, or a kind’s members are entries IS-A `type` or namespace constructors only.	Confirmed (§9): a namespace entry is listed by the kinds of its constructor and by no kind of types; the sentence was missing and §4.2 now carries it.
#13 (reading)	`record_field.type` is `type_kind` under #22, an atom; by §5.6’s rule as #13 states it, `!record { fields: { p => x } }` is then an atom-typed positional fill of `type`, not the withdrawn product-typed spelling the register’s vector pins. The text states the rule; the vector may be stale.	Confirmed (§9): the text is right and the implementation admits the fill; the register’s vector was stale.
#1 (addition)	A refusal under a fetch policy SHOULD NOT disclose the allowlist ([TSON-SCHEMA] §11.2).	Confirmed (§9). The reference implementation discloses the list at adjudication and is to change.
§5.9 rule 8 (reading)	A subtracted construction headed by a constructor is not itself a constructor: its chain is empty, and IS-A `top` is the predicate (§4.2). Revision 37 said “a constructor with lineage and no contract”.	Confirmed (§9): the chain is empty and the application is refused as not applicable.
§8.1 (consequence of #22)	`record_field.type` is `type_kind`, an atom, so `record_field` has a positional form and a data document may write `fields: { x => text }`; canonical output writes the explicit record.	Confirmed (§9), in a schema document as in a data document (§5.6).
#4 (considered)	An identity atom whose equality is canonical identity.	Not taken — every atom pins an external standard, `identity` is a name core should not take, and canonical text in `text` meets the need.
#6 (considered)	`allow_zone` on `host_type`, for a listener binding a link-local address.	Not taken — recorded as the likely first facet.
#8 (considered)	`uri_template`.	Not taken — a pattern over values is not a value.
#11 (outstanding)	The `tson-schema` skill’s “Records and fields”, “Enums”, conversion and pitfall sections.	Outstanding — not among this revision’s inputs; the guide’s new section is the model.

Decisions taken 2026-10-26: #1 the two outcomes, and a fetch refusal naming no allowlist; #3 the resolver error, with host-typed reads no exception; #4 the host as a host value and the identity atom not taken; #13 subsumed by #24 and the positional rule as stated; #16, #19, #20 and #21 as the register proposes; #18 the self-reaching exception and the one verdict change; #22 and #23 with their remainders open and the running behaviour stated; #25 the level rule per import edge.

6. Artifact work

Received at Revision 38 — all nine artifacts carry “2026 Revision 38 draft” and /2026/38/ identities, and each normative pin was checked against sha256 over the bytes past the !!id line of the copy received and matched: kernel 44c9268c…, meta 1c1d87b4…, core 11e69386…, net 765628e6…, policy bd594937…. The chain is consistent — meta pins the kernel, core, net and policy pin meta, policy pins core. Hash values remain non-normative; only the pin’s shape is.
Re-stamped before publication (§9). The doc lines below disagreed with the text and are corrected, so every pin moves: kernel 9cc191d3…, meta 62dde2f3…, core 95f66505…, net 06a939fa…, policy fc9208c7…; Part 2 §13.2 carries the five rows.
The doc lines corrected:
- The kernel’s application doc wrote its application of a namespace entry as “a DATA entry”, a kind #23 removes; it now says “a namespace entry”.
- The kernel’s kind_type doc said of “is type or at or below it”, where #23 admits namespace or a constructor below either, and said a kind is “not IS-A top” with no exception for a namespace constructor; it now states §4.2’s rule, membership by construction included.
- The kernel’s type doc said type_kind holds “the one constructor”; its top doc omitted the namespace types; its type_chain doc said a template’s parents are “kept after it closes” — each now says what §4.1 and §4.2 say.
- core.tn’s header listed uri among core’s same-named siblings of kernel and meta entries; the sibling is iri.
- meta-kernel-resolved.tn’s conventions note said a parametric = P or ~ P “fixes nothing until materialisation”, counted “the four base kinds”, and described every open entry as held; it now states #20’s rule, three base kinds and namespace, and a record template as a record with parameters. core-resolved.tn’s note cited §8.1 for the shadowing rule, which is §5.10’s.
Not verified, carried as a note: ingest of resolved output is unimplemented, so #14’s “read chain as stated” and “keep @application” and #22’s recomputed members are stated in §8.1 and not running; a later schema’s application is not yet unified with an imported library’s declared one for the same reason.

7. Second pass: Part 3 and the Developer Guide

Both ship with Revision 38. Neither carries a decision that §2 does not record; where a sentence had to be written that no register entry dictates, it is marked [editorial] and is the spec author’s to confirm.

7.1 Part 3

tson-part3-json.md is the copy received, completed for the entries it had not yet consumed. Header and status read Revision 38 and drop “proposed and not yet published”; series references move to /2026/38/.

§1.2 — “a field name is an identifier at every layer” reads “a field name is a value of its record’s name type, an identifier by default” (#10).
§1.6 — items 15 to 19 are Revision 38’s, published; item 16 says ref_type stands in schema documents only, which have no JSON form, and is listed for the record.
§3.2 — the $type row reads “string (a type name)”, a type name being what the kind-typed slot holds (#22); the sentence after the table that a schema SHOULD NOT declare the three stands (#10).
§6.4, §10.4 — “never reserved”, “no $-reservation” and “the reserved namespace itself is not spoofable … and not extensible” are restated over the three annotation members, used and not reserved (#10). [editorial] No change of meaning.
§9.4 — the outcome paragraph reads refused and undetermined as #1 states them, already in place; the series references in §11.2 follow.
Cross-references. [TSON-SCHEMA] §8.1’s title changes, and the three places Part 3 cites it for record_field’s facts are checked against the renumbered section; no section number moves.

7.2 Developer Guide

tson-guide.md is realigned on the same two principles as before: it describes the design as it stands, and history lives in the change logs.

§1.3, §1.6, §4.3 — schemas as data under the new output shape (person => !record { fields: { … } }), nine artifacts, and type among the kernel entries meta’s declarations use (#9, #12, #14).
§2.7 — a record template as a record with parameters, an application nothing declares as its expansion, and the three places a parameter stands (#16, #17, #18).
§2.9 — a routed = P FIXED where written (#20) and a parameter pin a selector whatever the mark (#21).
§2.10 — a minted record is a member of nothing (#18).
New §2.11 — “A name has a type” — the register’s seven-point outline for #10 and #11: what a name is; what breaking out makes possible (JSON vocabularies, words as names, names compared without case, a house style); when it is the right tool and when it is not; what it costs; the safety that stays on; a worked JSON-LD conversion.
§3.3, §3.5 — an identity’s host as a host value and the spellings a reference may use (#4); the unknown-annotation rule (#3); the Unicode-version property stated as §7.1 states it (#7).
§3.5 — where the policy lives: policy.tn (Revision 37’s answer, which the guide still described as undefined), and refused against undetermined (#1).
§4.5 — the network library beside “why core is small” (#2).
§6.1 — retitled “value, void, identifier and the kinds” (#22); §6.4 — namespace beside scoped as the kernel’s other open construct (#23).
New §6.8 — “Kinds, namespaces and references” — the proto-schema reading of kind<C> (a universe’s code type, a subuniverse carved by construction), why a kind is not a sum, namespace as the constructor whose instances are maps, ref<T> and the qualified name, and the meta-service example end to end (#13, #22, #23, #24).
New §6.9 — “Host names, hosts and media types” (#5, #6, #8).
§7’s worked example is rewritten in the new output shape: entries as values, a chain on priority, title_text and the instantiation, flagged as a !record with parameters and extension unstated (the base’s ABSTRACT being by construction), fields as maps, and history’s array naming the synthetic the expansion lands on. [editorial] — no shipped fixture holds a record template or an instantiation; the shape follows §8.1 and §8.2 as revised.
§8.1 — two identities restated without source; @application on a declared entry that closes an application (#14, #18).
§8.3, §9.2 — refused against undetermined in diagnostics and at the boundary (#1); an import at the importer’s level (#25).
References gain RFC 3492, 5890–5893, 5952, 6838, 6839 and 9110; identities are /2026/38/.

The Revision 33 guide candidates remain outstanding.

8. Third pass: verification

Run after the parts and the guide were revised, by a reader who had not produced them, against the register and the nine artifacts. Each of the 25 entries’ suggested-resolution items was found in the sections it names in Parts 1, 2 and 3; the five pins were recomputed over the shipped bytes and match §13.2; the kernel’s declarations (record, record_field, template_param, kind_type, ref_type, namespace, field_map, schema, type_chain, enum_type, identifier_base, scheme_name), core’s kind and absent ref, net’s eight entries and the fixture’s type_kind membership (top, namespace, field_map, schema and the synthetic arrays in; type, atom, record out) agree with §4.2 and §9; no Revision 37 vocabulary remains outside sentences that name an earlier revision; §5.12’s nine citations resolve and §6–§8 keep their numbers. What the pass found, and what was done:

Part 2 §7.7 was cited by §7.2 and by Part 1 §2.5 for the name-type matching rule and did not state it — stated now (§3.2 item 25).
Part 2 §7.8’s scoped was written {uri => …} where meta.tn keys it by schema_identity, as the same paragraph said; corrected in Part 2 and the guide (§3.2 item 34).
Part 2 §5.2 and §9 counted type among record_field’s “four facts”; the kernel counts four beside type, and the text now does.
Part 2 §4.1 said a record template’s parents are kept “after the template closes”, which read as the instantiation’s; it now says the template entry keeps them and a closed instantiation keeps none, as §5.8 says.
Part 2 §1.6’s example still shipped “revision 37”; Part 3 §3.2’s $type row still read “string (identifier)”; both corrected.
This log claimed RFC 1123 among the added references and nine rows in §13.2; neither was so, and the log now says what the parts do. Part 1 §10.1 gains the RFC 5322 row §5.5 has cited since Revision 36, and the guide the RFC 5891 row its range implied.
The kernel fixture’s conventions note disagrees with #20 and with the kernel’s own record_field doc; recorded in §6.3 beside the three doc lines already there.
The guide’s §2.11 lacked one of the register’s four stated costs (a host binding names a relaxed name through the name the record states); added.

9. Fourth pass: the implementation’s verification

Run by the implementer against the adjudicated text, entry by entry, before publication, with each of the five editorial readings of §5 checked against running code and confirmed as the table now records. The text carried every entry’s substance; what it did not carry, or carried against itself, was raised as eleven findings and folded into Parts 1 and 2 in this pass, so the register opens against Revision 38 empty:

Part 2 §5.5 carried no value-space clause for hostname, host or media_type, though §3.2 item 14 above claimed them and six citations pointed there; the three clauses are written, types and suffixes compared without ASCII case.
“Refused” being a term, Part 1 §8.1’s validity-at-every-processor claim is qualified by the Unicode version the text needs, an earlier-version processor’s report is a lexer or resolver error, and twenty-four loose uses of “refuse” for a validity error now name the error.
Part 1 §7.7 named the joining-control contexts’ properties as stabilised; they are not, and the monotone guarantee now states its one exception, for identifiers and for host names alike (§2.2.1, §5.5, §7.1, §8.1, §8.3).
Part 2 §5.2 and §11.4 put an undeclared name at closure before hygiene, against [TSON-JSON] §9.4 and the readers; a value of the name type now meets §8.2 first.
Part 2 §4.2 states that a namespace entry is listed by its constructor’s kinds, the namespace-type carve-out in the membership walk, where kind<namespace> holds namespace itself, top as a constructor and a type_kind member, and why ref_type.of is type_name; §9’s “the one slot typed type_name” is corrected.
§5.12 refused a record template a kind lists; both facts are now stated together.
§5.6 and §5.12 overstated which bare tokens are refused; §4.2’s placement paragraph said a subtraction off a constructor IS-A top, against §5.9 rule 8.
Seven sentences from the held-template reading survived for record templates: the base’s extension “stated”, “ABSTRACT does travel”, the type_ref slot lists, §12.1’s instance comment, §5.2’s “same checks”, a deferred-diagnostic example and §5.8’s alias-to-instantiation sentence.
§8.2’s vector<pixel, 1920> use site beside hd_row, its identity bullet, §8.3’s “the one !reference”, §5.10’s c3 and §5.10.1 disagreed on instantiation identity and @application; and #18’s verdict change is now stated in §8.2.
“Empty chain” where the fixture has subtypes, “four facts” counting type, extension unmarked in §9, and the canonical !record_field tag.
A dozen wrong examples and cross-references, the §5.10 selector example, { _id: 1 } in Part 1 §2.5 and a literal U+00AD in §8.2 among them.

What remains open is §5’s, and the tson-schema skill’s edits.