Hi Robert,

> 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?

Yes, that's correct. Happy to hear others' opinions, but Option 4 has been
detailed in the proposal document since the very start. I'm happy to wait a
few more days for others' opinions, but as of now I don't see any active
opposition to the plans as-is and the "lazy consensus" suggested deadline
was over 2 weeks ago. I-Ting and I will start implementation in the
meantime.

Best,
Adnan Hemani

On Mon, Jun 8, 2026 at 3:19 AM Robert Stupp <[email protected]> wrote:

> 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
>

Reply via email to