TSON 2026 Revision 36 — Change Log

This document records the changes accepted into Revision 36 of the TSON specification series, adjudicated from the implementation’s spec-feedback register (21 entries, renumbered from #1 against Revision 35: the four Revision 35 left open, and seventeen raised since). SPEC-FEEDBACK.md remains a record against Revision 35 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 revision editor at adjudication.
• [open] — a genuine design decision deliberately left open. Collected in §5.

This revision is the first to publish a third part. [TSON-JSON], the JSON encoding, was drafted against Revision 35 and edited directly as findings arose, so it is published with this revision at its first revision, written against Revision 36 of the other two. The series description in both parts changes from “two parts” to “three”, and Part 3’s own §1.6 records which type-system changes it consumes and where each landed.

This revision changes the schema grammar (§12.1) in three places — the field-definition production, the definition-mark slot, and the group-member production — and leaves the Class 1 lexer untouched: every token the new forms use is already in [TSON-DATA] §7.2.5’s closed special-token set. Nothing published against Revision 35’s frozen lexer is disturbed.

1. Baseline: the revised artifacts

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

• #23 — three slots per field, four facts per record_field. A field is spelled name?: type? ~ default or name?: type? = fixed: ? on the name answers whether the key may be omitted, ? on the type whether a written _ is admitted, and the modifier what a written value may be. The kernel’s record_field becomes { name type optional? ~ false voidable? ~ false role? ~ FREE value? } over field_role => !enum [FREE DEFAULT FIXED]; field_state is gone. What omission yields is derived and never stored: a field that is not optional is missing, an optional one with a value injects it. Four cells the six states could not spell become spellable (a: T?, a?: T, a?: T? ~ v, a: T = v), three are refused as rules (a pin on a voidable type), = _ is gone (its meaning is a?: void?, or a: void? at a restated group member), and refinement is three orders rather than a matrix. Every artifact is re-spelled. (Part 1 §2.9; Part 2 §5.2, §5.6, §5.7, §5.10, §5.11, §7.6, §8.1, §9, §12.1; all six artifacts.)
• #10 / #11 — record extension, and the discriminator as field syntax. The kernel’s record gains extension?: record_extension_type ~ OPEN over record_extension_type => !enum [ABSTRACT FINAL OPEN] and discriminators?: [field_name]. An author writes one of the words abstract or final between => and the type definition, and =? on each field the members pin; =? implies ABSTRACT. How a subtype is selected is whether discriminators is empty — the tag where it is, the marked fields where it is not — and is no member of the enum. @discriminator is retired: it stood on a choice, where the mechanism it names cannot reach. Both facts are grammar rather than annotations because erasing either changes which values conform, which §6 says no annotation may do. (Part 2 §4.1, §5.2, §5.4, §5.7, §5.8, §5.9, §6, §7.2, §8.1, §8.2, §9, §12.1, §12.2; kernel, meta, fixtures.)
• #12 — record.supertypes is [type_ref]. A supertype may be written as an application (ok => <T> result<T> & { … }), and a name cannot carry the arguments that say which instantiation is meant. On the reference channel the parent is substituted and closed with the rest of the held body, so ok<text> is IS-A result<text> and not result<int32>. type_definition.supertypes stays [type_name], computed once every parent is a type; a closed supertype writes as a bare token, so every schema with no open parent produces byte-identical output. (Part 2 §5.8, §5.9, §8.1; kernel, fixtures.)
• #13 — a record-bodied template is a family base. The kernel’s template gains extension?: record_extension_type and discriminators?: [field_name]: present, the extension is always ABSTRACT and derived — a base has no direct instances and its applications are subtypes by construction — and the selectors are whichever survive erasure of the parameters, including a field pinned to a value parameter. Such a template may be named at a type position, since no value is ever read against it; a reference, container, constructor-application or atom template may not. §1.3’s resolved-output consumer tier gains its one deliberate exception. An application at a composition operand is subsumed where it stands and mints nothing. (Part 2 §1.3, §5.8, §5.10, §8.1, §9; kernel, fixtures.)
• #20 — @rest is retired. rest => @annotation void is gone from meta.tn. A record is closed under its type with no exception, and open-ended data is a map-typed field written the same way in every encoding. The representation-directive category stays in §6 with no member. (Part 2 §6, §7.2, §9; meta, fixtures.)
• #21 — an enum has a profile. enum_set is !set_type { element_type: text } and enum carries profile?: enum_profile ~ IDENTIFIER over enum_profile => !enum [IDENTIFIER TEXT]. IDENTIFIER constrains every member to the identifier grammar and carries the name-hygiene rules that follow from it; TEXT admits any text and carries none. IDENTIFIER is inside TEXT, which is the narrowing relation a refinement follows. Every existing enum survives untouched in source and in output, the default being omitted at its own value. Numbers are never enums: the numeric tiers’ members are the spelling. (Part 1 §7.1, §7.7; Part 2 §5.4, §5.7, §7.4, §9, §11.4; kernel.)
• #22 — text_type.members. The kernel declares text_member_set => !set_type { element_type: text } and text_type gains members?: text_member_set, reached by uri_type, regex_type and email_type through the composition they already use. The pattern MUST admit every member. pattern and members are each settable once — a facet kind §5.7 lacked — set where unset, restated verbatim, never changed. (Part 2 §5.7, §7.4, §9; kernel.)
• boolean in Part 1’s vocabulary (#8). Core’s boolean => !enum [true false] is the type [TSON-DATA] §5 had no annotation for; !boolean joins the table. (Part 1 §5.5.)

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

• /2026/36/ identities on all six artifacts, with the hash chain recomputed bottom-up (§6). The register’s held-over entries were built against these identities, which is what let every built proposal above land on a published basis.
• meta.tn’s header states why it declares no directive and no extension annotation: the erasure rule holds there without exception, and both marks are §12.1 syntax.
• The kernel’s field_role sits beside product_access_type, product_size_type and element_state as an internal enum; element_state is unchanged, since an element slot cannot be omitted and has only the voidable question to answer.

2. Disposition summary

Counts: 18 accepted (2, 4, 7, 8, 10–23 — of which 2 is defined in Part 3, 5’s class sentence is taken with its annotation open, and 15’s merge key is open), 0 declined, and 3 open questions carried (1, 3, 5), plus the open remainders of 15 and of Revision 35’s #4 and #25 (§5). 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. Header, §1.3 — “Part 1 of 3”; the series is published in three parts, and [TSON-JSON] is listed as the JSON encoding, defined against the same model; the architecture diagram’s “reference encoding” line gains the JSON reader beside it.
2. §2.6 — the type-aware key-identity sentence takes #18’s qualifier: under a schema identity is over an atom key type’s value space; a compound key compares by the processor’s host representation, at least textually in a tree it builds itself.
3. §2.9 — the second sentence replaced: _ versus omission is a serialisation choice where the field’s declaration gives both the same meaning, and the declaration decides everywhere else ([TSON-SCHEMA] §5.2, §7.6) (#23).
4. §4.1 — applicability restated over what types the position (#7): base type resolution applies to a token carrying no built-in annotation at a position nothing types; a position typed by a schema, a tag, or a declared host type naming a family this series defines is read by that type’s contract. The true/false sentence and §4.4’s fall-through follow unchanged.
5. §5.5 — the !boolean row and its paragraph (#8): the two tokens, case-sensitive; the form not consulted at a typed position; the omission recorded as such.
6. §6 — the JSON reader is [TSON-JSON]; the section points at it.
7. §7.1 — the identifier-profile sentence’s list of governed positions makes “enum member” conditional on the enum’s profile (#21). The media-type paragraph names TSON-Schema as the out-of-band channel, defined in [TSON-JSON] §3.5, with its agreement rule (#2).
8. §7.7 — rule 3’s boolean mention unchanged; the identifier grammar itself is unchanged.
9. §8.1 — the fifth outcome becomes not judged, with its two members (#19); the Class 1 diagnostics unchanged.
10. §8.2 — unchanged in rule; the closing placeholder sentence stands (#1).
11. §10 — [TSON-JSON] added to the series references; identities to /2026/36/.

3.2 Part 2 — Type System and Schema

1. Header, §1, §1.1 — “Part 2 of 3”; [TSON-JSON] in the series list; the introduction’s “exactly two points” sentence updated for the field-modifier value (a bare token, ?, or nothing — never the absent sentinel).
2. §1.3 — the resolved-output consumer tier amended (#13): a consumer of closed entries never meets a held body, but MUST support a template entry named at a type position and dispatch on its extension and discriminators, never reading its body.
3. §1.6 — the example re-spelled under #23 (priority?: priority ~ 3, due?: date, tags?: [text], history?: […]); the template’s priority: priority ~ N stays unmarked (§5.7’s parametric rule); identities to /2026/36/.
4. §2.1 — the example’s !!meta/!!import identities; declaration order note unchanged.
5. §3.3.1 — template beside reference in the list of applicable kernel entries (housekeeping from Revision 35’s second pass).
6. §3.3.3 — meta.tn’s annotation list loses discriminator and rest (#10, #20).
7. §4.1 — the DATA-kind paragraph unchanged; the derived-kind paragraph unchanged.
8. §4.2 — the ~ paragraph rewritten: the three field modifiers ~, = and =? (#10, #23); the void bullet says what a: void and a?: void declare (#23).
9. §4.3 — “a template instantiation (§8.2)” dropped from the finished list (#16); the table’s Composition and Refinement rows note the FINAL refusal (#11).
10. §5.2 — rewritten. Three questions, three slots: the name’s ?, the type’s ?, the modifier; the sixteen-cell table replaced by the spelled forms and the three refusals; injection derived (an optional field with a value injects; an unmarked name with a pin is a marker the document states); the positional form over unmarked names; the FIXED check; encoder MUSTs for the two declarations a schema-less encoder cannot write (#23). Definition marks: abstract and final, the three members, the FINAL check, the subtraction exemption, inhabitance, no inheritance, identity (#11). The selector =?: the reading, the shape it is admitted on, the family check list, one level, the tuple case, the word “discriminator” (#10). Resolution: the four-fact record_field, extension and discriminators in the body.
11. §5.3 — field_state reference in the tuple paragraph replaced by field_role; the synthetic-entry paragraph gains why a use-site sugar form mints where a declared application does not (#15).
12. §5.4 — the no-class list gains the two straddling kinds (#17); the enum-class sentence reads the profile (#21); a pointer to §5.2 for member dispatch (#10).
13. §5.6 — the positional form counts unmarked names (#23); a declaration whose body is a fully-bound application resolves as the instantiation in place (#15).
14. §5.7 — the transition table replaced by three orders (#23); the identity diagonal restated (a restatement may change a default and never a pin); the facet-kind table gains settable once (#22); the finished list loses the instantiation (#16); the open-modifier paragraph restated over optional/role — a parametric = P or ~ P is written on an unmarked name and closes optional and FIXED or DEFAULT; the fix-to-absent sentence goes (#23).
15. §5.8 — Parameterized references replaced: a supertype is a type_ref, substituted and closed with the held body; the derived index records names; no second check (#12). A restated group member stays a member (#23). Composition onto a FINAL record is refused (#11). The restated-field annotation rule loses its @rest example.
16. §5.9 — rule 5 restated for a?: void? (#23); a removal drops an open application from the lineage (#12); subtraction off a FINAL record admissible (#11).
17. §5.10 — a record-bodied template is a family base; the two levels of extension; the selector condition; minting keyed on naming; the Fully-bound references paragraph replaced by the instantiation-in-place rule (#13, #15).
18. §5.10.1 — a voidable field guards recursion (#23); an abstract base with no local subtype is not a productivity error (#11).
19. §5.11 — group members take the type’s ? and no name mark or modifier; a voidable member written _ selects its alternative; restated members (#23); the two-always-present rule has nothing left to refuse and is restated as a consequence.
20. §6 — the @discriminator/@rest paragraph deleted, the checked category left with @disjoint, the representation-directive category defined with no member and its class rule stated (#5, #10, #20); the validity sentence corrected (#11); a paragraph on the two definition marks and the selector as consumed syntax whose names are reserved at one position.
21. §7.2 — closure has no exception (#20); subsumption at an ABSTRACT position and a member-dispatched one, the tag optional and required to agree (#10, #11).
22. §7.4 — enum member semantics rewritten around profile (#21); how an enum binds; the three-way split; text_type.members beside the numeric tiers with the pattern coherence rule (#22).
23. §7.5 — element order: source declaration order canonical; the comparison MUST and the fixture SHOULD deleted (#4); the compound-element qualifier (#18).
24. §7.6 — the record-field row reads permitted when the field is voidable; the field-modifier row reads never (#23).
25. §7.7 — the compound-key qualifier (#18).
26. §8.1 — record_field with its four facts; record.extension, record.discriminators, record.supertypes: [type_ref], template.extension, template.discriminators (#11, #12, #13, #23); source for a declared application (#15); the body-patterns table’s instantiation and reference rows; ingest re-checks lose the two retired annotations and gain the family checks.
27. §8.2 — a declaration owning an application is its entry; two declarations, two entries; the sugar channel keeps minting (#15); the two consumer consequences of a derived name (#14); the set-order sentence (#4).
28. §8.3 — the Fully-bound template application bullet replaced (#15).
29. §9 — the kernel row: field_role, record_extension_type, enum_profile, text_member_set, the new record/template/enum/text_type fields, no field_state; the meta row: no discriminator, no rest; the JSON paragraph points at [TSON-JSON]; the set-order convention.
30. §10.1 — an unobtainable schema is reported as unavailable, not as an error (#19); §10.2 says why a mismatch differs.
31. §11.4 — the enum-member scope is conditional on IDENTIFIER (#21).
32. §12.1 / §12.2 / §12.3 — schema-map-entry gains [ definition-mark ws ]; field-def becomes field-name ["?"] ws ":" ws … with field-modifier = ws ("~" / "=") ws token / ws "=" ws "?"; group-member gains ["?"]; absent leaves the imports; the disambiguation summary gains the mark line and the =? case; the adjacency table’s =? row (#10, #11, #23).
33. §13 — [TSON-JSON] in the series references; RFC 9651 informative; identities and pins to /2026/36/.

3.3 Companion artifacts

The revised artifacts shipped with this revision already carry the baseline of §1 and every kernel- and meta-level change in this log, at /2026/36/ identities with the hash chain recomputed bottom-up. Two doc edits remain and are listed in §6.

3.4 Part 3 — JSON Encoding

[TSON-JSON] is published with this revision, at its first revision, written against Revision 36. It was edited directly as findings arose rather than adjudicated here, and its §1.6 lists the four type-system changes it consumes and where each lives, the third of them — record extension and the discriminator field — landing with this revision. The register’s #6 (§9.4’s name-hygiene reach) and #9 (§6.5’s map-form test) were closed in Part 3 directly; the Part 3 halves of #17 (§8.2, §8.3), #20 (§6.1.1), #21 (§5.2) and #23 (§6.1.2, §7, §7.2, §7.3) are in the document as published. Part 3 §3.5 defines the TSON-Schema and TSON-Accept-Schema fields, which is #2’s answer.

4. Notable normative changes (reader’s digest)

Changes a Revision 35 implementer must act on:

1. A field is three slots. name?: type? ~ v / name?: type? = v: ? on the name says the key may be omitted, ? on the type says _ is admitted, the modifier says what a value may be. a: T? (key required, _ admitted), a?: T (key optional, _ refused), a?: T? ~ v (omission injects, _ clears) and a: T = v (a marker the document must write) are all spellable. A default needs ? on the name; a pin on a voidable type is refused; = _ is gone (a?: void?).
2. record_field stores four facts — optional, voidable, role (FREE, DEFAULT, FIXED) and value — and field_state is gone. Omission’s meaning is derived. Every T? field in the kernel, meta and core is re-spelled.
3. Refinement is three orders, not a matrix: omission absent → required → injected, voidable true → false, role FREE → DEFAULT → FIXED; a refinement may move no question backwards.
4. Records state how they may be realised: pet => abstract { … }, leaf => final { … }, or neither (OPEN). An ABSTRACT position admits exactly its subtypes and the tag is required there; nothing may compose or refine onto a FINAL record; subtraction is unaffected.
5. The discriminator is =?. pet => abstract { pet_type: text =? name: text }, dog => pet & { pet_type: = "dog" breed: text }. =? implies abstract; every subtype pins each selector; pins are distinct as values, as tuples where there are several; at such a position the tag is optional in every encoding and MUST agree where written. @discriminator is gone.
6. @rest is gone. A record is closed with no exception; open-ended data is a map.
7. record.supertypes is [type_ref]: ok => <T> result<T> & { … } makes ok<text> IS-A result<text>. Output for schemas with no open parent is unchanged.
8. A record-bodied template can be named at a type position, as a family base: ABSTRACT by derivation, discriminators whatever survives erasure. A resolved-output consumer dispatches on the entry’s extension and discriminators and never parses the held text.
9. A declaration naming an application is the instantiation entry. bx => box<text> resolves to the closed record itself, source the application, no minted box_text_… beside it and no !reference hop; two such declarations are two entries.
10. A derived name is never a consumer’s key; the applications of a template are recovered from source.
11. A record instantiation composes and refines; the “finished” list is constructor applications and their aliases.
12. Enums have a profile. !enum ["sedentary" "lightly active"] under profile: TEXT is legal; IDENTIFIER is the default and every existing enum is unchanged. Under TEXT the enum is string-class and name hygiene does not reach the members.
13. text_type.members, settable once beside pattern, which is also settable once.
14. disjoint carries class stability. A choice over an approximate atom still admitting NaN or infinities, or over a map with a compound key, is not disjoint in any encoding; ( float64 | text ) needs a tag in text too.
15. Set-typed fields are emitted in source declaration order, and resolved output is compared as written; the set comparison MUST is gone.
16. A compound set element or map key compares by the host’s equality; portable duplicate detection keys by an atom.
17. An unobtainable schema is not judged, not invalid: reported as unavailable, beside the four categories and the refusals, located at the reference. A pin mismatch stays a resolver error.
18. Base type resolution applies where nothing types the position — a host-typed target naming a §5 family reads by that family’s contract, exactly as a schema declaring it would.
19. !boolean is in the schemaless vocabulary.
20. TSON-Schema is the out-of-band schema channel, defined in Part 3, for every TSON-carrying body; it must agree with an in-band binding by canonical identity.

5. Open questions carried by this change log

Adjudicated 2026-09-23. The following remain deliberately open. They live in this change log only — the specification text carries no open questions.

Decisions taken 2026-09-23: #2 defined in Part 3; #4 option (a); #5 the class sentence without the annotation; #8 form not consulted at a typed position; #15 the rule without the merge key; #17 the two straddling kinds; #19 not judged with two members; #21 profile, and TEXT enums string-class; #23 as built, with a parametric modifier written on an unmarked name.

6. Artifact work

1. Received at Revision 36 — all six artifacts carry “2026 Revision 36 draft” and /2026/36/ identities with the hash chain recomputed bottom-up over the shipped bytes: kernel e778e463…, meta ede51d23…, core d924ef91…. Part 2 §13.2 carries them. Hash values remain non-normative; only the pin’s shape is.
2. Done: the re-spelling — every T? field, every injecting default and pin, and every = _ in the kernel, meta and core is in the three-slot form; field_state is gone and field_role, record_extension_type, enum_profile and text_member_set are declared; rest and discriminator are gone from meta; record, template, enum and text_type carry their new fields.
3. Done: two stale docs. meta.tn’s disjoint doc now places the derived fact in the !choice body, where Revision 35’s second pass moved it; and the kernel’s type_ref doc carries #15’s qualification that a declaration naming a fully-bound application is that entry. Neither changes a byte of resolved output.
4. Not verified, carried as a note: #15’s cross-schema unification is stated as given up, and no bundled schema or corpus vector exercises an import that would need it.

7. Developer Guide

tson-guide.md ships with Revision 36, realigned on the same two principles as before (it describes the design as it stands; history lives in the change logs). §1.4 and §1.5 name [TSON-JSON] as the JSON reader and record how the one apparent divergence between the two encodings moved into Part 2 as class stability; §1.6 lists three documents; §2.4 and §6.1 spell the fix-to-absent case as a?: void?; §2.6 points at the sealed family as the third shape of alternative; §2.7 records the declaration-is-the-entry rule, why sugar keeps minting, and the record-bodied template as a family base; a new §2.9 carries the rationale for the three field slots and four facts, with the census that motivated them; a new §2.10 carries record extension and the =? selector, the sealed-hierarchy reading and the OpenAPI conversion; §3.5 describes the enum profile; §5 restates refinement as three orders and composition’s FINAL refusal and type_ref parents; §6.2 adds text_type.members and settable-once; §7’s worked example is re-spelled, its resolved output shows the four facts and flagged as an abstract base; §8.1 adds the two consumer rules for minted names; §8.3 adds the not judged outcome; §9.3 adds the two encoder MUSTs; identities are bumped to /2026/36/. The Revision 33 guide candidates remain outstanding.

7.1 Part 3

tson-part3-json.md is edited for the as-published reading: “Part 3 of 3”, the anticipated binary encoding named without a part number or identity (no fourth part is published); §1.6 gains the Revision 36 changes it consumes (three slots, class stability in disjoint, the enum profile, the compound-identity qualifier) and loses REQUIRED_FIXED; §3.3 states that a declaration naming an application is that entry; §4.1 and §4.2 read base resolution’s applicability and the no-class list from Parts 1 and 2; §5.2 encodes a TEXT enum’s members as strings; §5.7 reads value over the marks; §6.2 and §6.4 take the compound-identity qualifier and source order for resolver output; §8.2’s predicate is disjoint alone and §8.3 is an informative note; §9.4 reports an unavailable $schema as not judged.