Hi all, Thanks Adnan, that helps clarify the shape.
I think this is the point where broader community input would be useful, because options 3/4 are a materially different commitment from options 1/2. Is my understanding correct that option 1 is out of scope from your perspective, and option 2 is not sufficient for the M0 you have in mind? In other words, you are proposing option 3 as the baseline, with active planning toward option 4? Option 3 does not just put a proxy endpoint in Polaris. It makes Polaris responsible for the OL ingest path: dataset-name resolution, per-entity authZ over OL assertions, policy for non-Polaris datasets, trusted-service credentials to downstream systems, request-size and payload limits, forwarding failure semantics, audit behavior, and tenant isolation. Option 4 then adds a Polaris-local lineage storage/query subsystem. Even if the first version stores only a reduced projection, Polaris would take on many responsibilities of an OL backend: persistence semantics, query semantics, staleness/pruning, auth-filtered reads, backend compatibility, migrations, limits, and long-term compatibility with OL event shapes. At that point, even if intentionally limited, Polaris effectively operates as an OL backend for the supported subset. So before we treat option 3 plus active planning toward option 4 as the M0 baseline, I think it would be good to hear whether others agree that Polaris should take on that implementation and maintenance surface for the first milestone. Or whether we should start with a smaller integration point first. Robert
