What the .d.ts says a value is, against the entry check the generated code runs #

What the .d.ts says a value of a declared type is, and how that compares with the entry check the generated code runs.

TsSat is the reading of the text Js.tsType and Js.declareType write: a discriminated union over the type's constructors, readonly T[] for an array, ReadonlyMap<string, V> for a dictionary, and number for both Int53 and UInt32. TypeScript erases to nothing at runtime, so this is a reading of a declaration and not a check that runs — that the reading is faithful to what TypeScript means by that text is where the .d.ts is still taken on trust.

Fields are read the way a property access reads them: Js.lookupField, the first entry carrying that name. Nothing here reads the order the keys arrive in, and nothing reads a key the type does not declare.

The two sets are the same, up to one point. checkTy_tsSat says the entry check is no more permissive than the .d.ts; tsSat_checkTy says it is no less, given inRange — the numbers the value carries lie in the Int53 and UInt32 ranges the check reads, which is what number cannot express. That is the whole of what the converse assumes about a value.

The one thing a TypeScript type cannot say #

Js.checkTy reads an Int53 or UInt32 range off a number, and number carries no range. inRange is that reading on its own: Js.checkTy with every shape test passing, so the only way it comes out false is a number outside the range the descriptor names at that position. Nothing runs it — it is what tsSat_checkTy assumes, and holding it apart from TsSat is what keeps that assumption down to one.

Everything the .d.ts admits, the entry check accepts #

The direction a caller feels. TsSat reads fields by name, so the order they arrive in is not read; Js.checkFields reads only the names the descriptor carries, so a key the type does not declare is not read either. What is left is inRange.