Topics discussed:

• Nikolai Ryzhikov demoed the reference client: a grid of ViewDefinitions you can click into, and $run on an instance with a format switch, meant for debugging. The open question was evaluate, which takes the ViewDefinition in the request body. One polymorphic operation or two? Gino argued for two, because most production servers won't let users create ViewDefinitions — that'll be an administrative or developer function — and an operation that may or may not accept an inline definition is hard to describe and leaves people posting and getting errors back. Steve Munini's implementation made the other half of the case: it runs as a stateless service with no stored views at all, which is precisely the client that has to send the view in the body. Settled on three operations — run, evaluate, validate.
• Nikolai had a second reason the two can't be one: you'd want to say that at least one of view id or view URL must be present, and there's nowhere to put a FHIRPath invariant in an OperationDefinition. Expressing that would mean reinventing profiling inside the operation, which is exactly the seam the group keeps running into.
• For output formats Nikolai had written his own extensible value set, Parquet included; Gino pointed at the MIME type value sets the capability statement already uses. The real hole is what happens when a server supports a format the value set doesn't list — there's no way in FHIR today to say so, short of overriding the whole operation and losing its identity. Gino filed a ticket to add additional bindings to OperationDefinition while they were still talking, on the grounds that there was zero chance he'd remember later.
• Bashir Sadjad assumed the API only made sense for a FHIR server, since his own thing is an ETL pipeline. Nikolai argued otherwise: a small control API on top of a pipeline can expose the same shape — the capability statement declares whether views are fixed or dynamic, you list them, then run or evaluate. Bashir realised he already has a tiny controller API and a very primitive view editor, so the open-source ViewDefinition builder could point at his pipeline and replace it.
• Gino reported on cross-version extensions: 1,800 value set comparisons covering 19,500 concept comparisons, and 1,600 structure comparisons covering 51,000 element comparisons. His view of FHIR Mapping Language, after living in it, is that he wishes it didn't exist and would rather write TypeScript that others port — an element that moved into a backbone element, taking three of its five siblings with it, is not something he knows how to say in FML. Cross-version extensions are easier only because they need to know whether something is representable, not how. He isn't aiming for 100%: Encounter status is the standing example, where R4's finished maps to either discharged or completed and only data you don't have can tell you which.