Topics discussed:

• John built an example file with a prototype rewrite of the Pathling encoders, feeding it ExplanationOfBenefit resources and letting Spark's JSON schema inference work out the schema. The point he wanted to make is that nothing in the chain needs to read a structure definition — which matches reality, since most SQL on FHIR runners don't know about structure definitions either, they just traverse data. His next test is plugging the file into Dan's FlatQuack, on the theory that since the schema mirrors the JSON, the existing queries should mostly just work.
• The annotation convention: a decimal is stored as a string so the original precision and scale survive, and a second field prefixed with two underscores holds the same value as a native decimal type. Read the original if you want to reproduce the FHIR exactly, read the annotation if you want to do arithmetic. Same idea generalises to anything where FHIR's JSON is more precise than the native type.
• Bashir asked the question the workstream had been circling: what is Parquet on FHIR for? If it's a compact binary way to move resources around, Avro or protocol buffers would do, so why Parquet at all — and if it is about queries, then schemas that shift with the data make the SQL non-transferable. John's answer was that query ergonomics isn't the goal and never was; the goal is to make the SQL on FHIR pattern work across platforms and cut down the number of runners everyone has to write. He also doesn't believe SQL over these nested formats is portable across implementations in the first place.
• Brian Kaney sketched the packaging problem as two personas: someone using SQL on FHIR while authoring an IG, which Graham's publisher work already largely covers, and someone whose product is the ViewDefinitions themselves and wants to distribute them. FHIR packages are npm under the hood — a tarball of JSON with a manifest — so the CRMI pattern transfers: a $package operation walks relatedArtifact dependsOn links and hands back a bundle, or you group things under a Library and package that instead.
• The gap John keeps hitting is that there's no way to say "these views belong together". You want to ask a server for a coherent set of views extracted at the same instant, which means referring to a collection by URL, and the only definitional resource that fits is Library — built for CQL, but co-optable. Bashir pushed further: a bag of siblings carries no semantics, so a ViewDefinition should be able to declare it depends on another, the way CQL libraries do. Arjun had hit the same wall converting to OMOP, where a patient table and an address table need execution order and generated keys to line up.