Topics discussed:

• Nikolai walked through a draft MaterializedView — a resource that points at a view and says "keep this persisted over here", much the way Subscription says "notify me over here". The destination is just an opaque string: a Postgres schema, a Parquet file, a bucket. The group liked it but nobody committed to putting it in the core spec yet; a separate guide is still on the table.
• The one rule Nikolai built in: within a destination, a view can be materialised only once. That sounds arbitrary until you have views built on views — then it is what keeps working out the refresh order from turning into a puzzle.
• John's take was that the real test is building it in several codebases and seeing what breaks, and he noted it lines up with the caching Pathling already has, where the user declares what to cache and how stale it may get.
• Nikolai's FHIR-to-OMOP transformation passed all the golden tests at the connectathon, which turned the conversation to data quality: model a check as an ordinary SQLQuery that returns the bad rows, then tag it with what kind of check it is — conformance, completeness, plausibility, straight from the OMOP taxonomy — and a threshold like "fewer than 5% bad".
• Brian asked the obvious question: don't profile invariants already do this? Not quite — an invariant looks at one resource at a time, so it can say a code is wrong but not that 30% of a million rows are missing it. That is the gap, and John called native data quality tooling one of the things FHIR plainly lacks.