Topics discussed:

• lowBoundary and highBoundary turned out not to exist in the JavaScript FHIRPath engine at all — no branch, no pull request, not even a GitHub issue discussing them. So the group decided to write them itself rather than wait. The person who has started already hit the awkward part: telling a date from a dateTime, because the two look the same in the data and type inference reports both as string.
• An implementer writing his own runner said the prose had misled him. "Sibling selects are effectively cross joined" reads as though you run each select across all resources and then cross join the lot, when in fact the cross join happens per resource. The reply was that this is exactly why the processing model page exists — it describes the algorithm rather than trying to say it in prose — but that page may not be prominent enough, and the main section probably needs the words too.
• Nikolai's functional model — ViewDefinition evaluation described as four functions you combine — is sitting on Zulip and not in the spec, and the group agreed it should be. His point was that writing the algorithm down in English is the hard part: the group has been discussing this for a year, so the current wording looks clear to them and may be clear to nobody else. Explaining it to a designer with a technical background took days, and the four-functions version was what finally landed.
• On getting to a milestone one: rather than run the full HL7 machinery — the IG publisher's qa.html checks, a ballot, formally resolving every comment raised — the group leaned to something lighter, a sheet where each member ticks off that they have actually read the spec and the tests and left comments. The reason for the checkbox was admitted openly: everyone is busy with other things, and a name against a box is what makes people sit down and read. The pull of the HL7 route is that it reaches a broader set of people than this call does.
• A C++ FHIR deserialiser built on simdjson reports around half a gigabyte per second, roughly six times faster than marshalling into Firely's object model. The suggested next step was to drop the structs entirely: simdjson only records where everything is, so FHIRPath could query that position table directly and never build an object. The bigger prize is upstream — a million patients is a terabyte of JSON, while the slice a large measure actually reads is somewhere between 150 MB and a couple of gigabytes, which is what Parquet and predicate pushdown are for.