Topics discussed:

• A test asserts that a decimal plus a decimal is an integer, and the reference implementation passes it happily — JavaScript hands back a number and cannot say whether it was a decimal or an integer. Pathling, which carries types all the way through, would reject the same test. So checking type stays a SHOULD rather than a MUST: the fix is to correct the test's types so strongly typed runners pass too, with a comment in the test warning whoever finds it later that this won't be relevant to every implementation.
• The test definitions used to be generated from JavaScript, which quietly broke the boundary tests. The result of lowBoundary depends on the scale of the number you feed it, so 1, 1.0 and 1.00 have to stay distinct — and JavaScript does not care. The JSON is now the first-class artefact rather than something the code emits.
• The test definitions carry no deterministic column ordering, which is fine in itself — test runners can be written to tolerate it. But the spec does define a column ordering strategy and nothing verifies it. The plan is an expectColumns assertion added to the tests' JSON schema, plus a couple of deliberately awkward ViewDefinitions whose ordering gets asserted explicitly.
• View runners should be able to tell you the shape of the result before you run it — you cannot make a home for the output if you don't know what it looks like, which matters most inside ETL pipelines and automation. It can't be a MUST: a dumb CSV runner has no schema and no types at all and is still a legitimate thing to build. Column names and FHIR types are already concrete in a shareable ViewDefinition; how those land as Parquet, Spark or Postgres types is implementation-specific and stays out of the core spec.
• Open question: must type be present on every column of a shareable ViewDefinition? The profile currently makes it a hard requirement, on the reasoning that a view only translates reliably between runners if the type is asserted. The objection came from someone who had just written 10-12 real ViewDefinitions — of over 100 columns, nearly all are strings, so tagging every one is mostly boilerplate. The counter was simply that a hard requirement is much easier to validate in the profile. Left unresolved.