vk-org-resolution

VK org resolution — two join chains (binding)

packages/ai-gateway/internal/platform/store/virtualkey.go:vkSelectSQL resolves VirtualKey → Organization through TWO independent chains:

VK type	Chain
application	VirtualKey.projectId → Project → Organization
personal	VirtualKey.ownerId → NexusUser → Organization

The SQL JOINs both and COALESCEs the application chain first.

Required SQL pattern

LEFT JOIN "Project"      p     ON vk."projectId" = p.id
LEFT JOIN "Organization" org   ON p."organizationId" = org.id
LEFT JOIN "NexusUser"    u     ON vk."ownerId" = u.id
LEFT JOIN "Organization" u_org ON u."organizationId" = u_org.id

COALESCE(p."organizationId", u."organizationId") AS organization_id
COALESCE(org.name,           u_org.name)         AS organization_name
COALESCE(org.timezone,       u_org.timezone)     AS organization_timezone

When to apply

Touching any of:

• vkSelectSQL itself (or any sibling SELECT that joins through Project/Org/NexusUser)
• A new column on traffic_event that depends on the VK's parent (timezone, billing account, primary AccountManager, parent org id)
• A new VK type beyond application / personal
• The audit pipeline's identity JSONB stamping

Why this matters

Latent bugs in the personal-VK code path hide indefinitely when traffic is dominated by application VKs — a missing join surfaces only on the first personal-VK request. Touching personal-VK-adjacent code without testing both VK types = silent NULL columns in prod. Memory anchor: [[feedback_vk_org_dual_join_chain]].

Forbidden

• "Simplifying" the SQL by dropping the second LEFT JOIN or the COALESCE. The two Organization joins via different aliases (org, u_org) are load-bearing.
• Adding a Go-side fallback in caller code (e.g. "if meta.OrganizationID == "" then look up meta.OwnerID and read nexus_user.organizationId"). The fallback belongs in SQL — caller code reads the resolved value, not raw chains.
• Adding a new VK-derived column without verifying it has both chains' coverage.