Topics discussed:

• Inter-query dependencies landed in both the spec and the reference implementation. John split them into two profiles — SQL Query and SQL View, the same shape except a View can't take parameters — and grouped them under a single "SQL" menu item because the navigation was getting crowded. The open question he left was whether you can actually run a SQL View. Nikolai's answer: yes, and you can export it as CSV too, it's just a bad idea on a large dataset.
• Steve Munini implemented the operations one at a time and came back with six inconsistencies (#358–#363) — the kind of drift you only notice when you build all four operations rather than one. Good ideas had been sprinkled into the newer operations and never backported to the older ones. His fix is a single operations-common.md page holding everything the four operations share, so there's one place to change instead of four. Nikolai wanted the refactor done first with no semantic changes at all, then the changes layered on top of it.
• The chunked-encoding question (#361) resolved itself once Nikolai drew the line: streaming only means anything for the run operations, because export never hands back data — it hands back a manifest of file locations. And those locations are deliberately unspecified; the spec says URI, which might be an internal bucket or a local path, and might not be HTTP at all. How the client fetches the file is out of scope.
• Issue #363 — whether an async operation completes with 303 or 200 — turned out to be unanswerable, because FHIR now has three competing async patterns: the original ad hoc bulk data JSON manifest, the R5 bundle-based one, and Josh Mandel's newer incubator version. Nikolai prefers Josh's, because it drops the forced Bundle response and separates the status code for "are you finished?" from the status code for the result. John's objection was practical: he implements async once in Pathling and uses it for every operation, and won't maintain different semantics per operation. Nobody in the room could say where the incubator IG had actually landed.
• Nikolai wants to seed a community FHIR-to-OMOP project, and his argument is that the valuable part isn't the transformation code — it's the corner cases. A single Condition can land in three different OMOP tables depending on the code; one ICD-10 code can fan out into several SNOMED codes and several rows. His unit for that is a test case: some FHIR resources in, the expected OMOP rows out, and a note explaining why. Arjun liked the framing of a shared evaluation framework rather than yet another implementation. John's worry was engagement — that it quietly becomes two people working alone unless the wider community is brought in properly.