Thanks EJ, The proposal is unusually clear about the v1 scope and already identifies the important consistency cases.
I would like the guarantees in Parts 1 and 2 to become explicit backend conformance requirements before implementation settles on a physical layout. In particular: * effective reads must describe one committed state; * assign/update/delete must have the specified ordering; * `detach-all=true` must be atomic to API observers; * reverse indexes must not expose combinations that were never valid together. A backend that cannot provide one of those guarantees should capability-gate the operation rather than silently weaken it. I would also like us to review two authorization choices explicitly: Reverse lookup reveals target names and selected values without per-target read checks. The proposal also makes `TAG_DROP` sufficient to authorize `detach-all=true` for all assignments of that tag definition. Both may be intentional, but they define disclosure and change authority—especially once policy providers consume tags—and should be treated as security contract decisions rather than only implementation/performance choices. With those points made testable, I think the backend-neutral "transaction, CAS, atomic batch, or provider-native operation" framing is the right direction. I won't be able to make it to the scheduled meeting, but I'm looking forward to continuing the discussion on the mailing list! Cheers, Robert On Thu, Jul 30, 2026 at 8:38 PM EJ Wang <[email protected]> wrote: > Thanks JB for the inputs! Yufei and I were trying out the new scheduling > pattern, some delayed in between. Now I'm targeting *pacific time Aug 3, > 9-10am*. Invite has been sent and shared in the community group for > visibility. Hope you can join! > > -ej > > On Wed, Jul 29, 2026 at 9:53 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi EJ, > > > > Thanks for the update. > > > > I think 24 hours is very short notice to schedule a meeting, and I > > hope people will still be able to join to ensure a diverse audience. > > Moving forward, I would suggest giving a few days' notice to ensure > > everyone has a chance to attend. > > > > Regards, > > JB > > > > On Thu, Jul 30, 2026 at 2:16 AM EJ Wang <[email protected]> > > wrote: > > > > > > Hi folks, just FYI, the review is scheduled for Pacific time Jul 29, > > > 9-10am, it has scheduled via Polaris google calendar. Come and join! > > > > > > -ej > > > > > > On Thu, Jul 16, 2026 at 9:52 PM EJ Wang < > [email protected]> > > > wrote: > > > > > > > Hi folks, > > > > > > > > I have prepared a Google Doc > > > > < > > > https://docs.google.com/document/d/1rIJGzcsmGhfrBiRXPac51hr-jeJuuKQQBYjgBdOb9-k/edit?usp=sharing > > > > > > > for the Polaris tag spec proposal. > > > > > > > > The goal is simple: add a native tag model to Polaris so users can > > > > classify catalog objects, read those classifications back, and find > > objects > > > > by tag. > > > > > > > > The proposal covers: > > > > * tag definitions as catalog-scoped Polaris entities > > > > * tag assignments on catalogs, namespaces, table-like objects, and > > columns > > > > * allowed values on tag definitions > > > > * direct and inherited tag reads > > > > * direct by-tag lookup > > > > * the durable model behind the API > > > > * how this compares with the existing Polaris Policy API (tag design > > > > referenced policy heavily, given their pattern similarity) > > > > > > > > Please take a look and leave comments in the doc. Let me know WDYT! > > > > > > > > I would also like to discuss this in the July 23 community sync. A > > > > separate dedicated review meeting will be scheduled separately, > likely > > > > within the next two weeks. > > > > > > > > Thanks, > > > > -ej > > > > > > >
