Topics discussed:

• Nikolai's draft splits the API by what comes out: file, table, or stream — three operations with the parameters kept in line with each other. The file one deliberately copies bulk: kick it off, get a URL back, poll it, read the manifest, fetch the files. Dan's argument for staying as close to bulk as possible is that you then inherit the FHIR async operation pattern for all the polling and file-deleting and manifest handling, and don't have to maintain any of it yourself.
• Dan explained why bulk's manifest is a custom JSON blob rather than a FHIR resource: Parameters was barely sketched out back then and hardly used. Starting today he'd use Parameters — but the custom format is documented, widely implemented and extensible, and nobody stores manifests anyway, so breaking compatibility buys little beyond looking more FHIR-ish. Nikolai floated Bundle, since response.location could carry the file URL and every SDK can already parse one; Dan's view is that Bundle is tightly constrained to collections of resources and these URLs don't lead to resources — if you're stretching it that far, use Parameters.
• Nikolai's real objection was narrower: the manifest isn't described in FHIR terms at all, which makes it a semi-official structure nobody can point tooling at. His proposal — write a logical model for it, backwards-compatibly. Dan called that a fair gap, one that exists mostly because the spec predates logical models, and said nobody would object if it can be done without adding required elements. John saw no reason it couldn't.
• On tying each output file back to the view that produced it: type in the manifest is SHALL and is defined as the FHIR resource type contained in the file. Nikolai wanted the ViewDefinition URL there and noted type is already a bit of a fiction, since the file is CSV or Parquet, not a Patient. Dan preferred leaving type alone and using the manifest's per-output extension mechanism, which implementers already use in the wild to describe how files are encrypted.
• John kept pressing a level he thinks is missing: a query never depends on one view, it depends on a set of views, named certain things, that work together — so a flat list of ViewDefinition URLs is too simplistic. Dan made it concrete by asking what a FHIR-to-OMOP export request would look like, and answering himself: enormous. Nobody has a container yet; Library is the closest definitional fit, borrowed from the CQL world, and the group figured CRMI has probably already hit this problem. Dan also wanted references and canonical URLs kept as separate parameters so a server with no CRUD on ViewDefinition could still export from an IG, while Nikolai argued they're both just URLs and the distinction will confuse people — left unresolved.