There are currently three different but related schema representations that capture some of the same and some different details that have to agree. This requires understanding all three of them separately and how they connect together, and creates the risk that they may not agree, resulting in an invalid configuration.

• rbac-config: captures logical "applications" and "permissions" (which sometimes differ from actual services) that users can grant through the RBAC UI
• inventory schema: captures resource types, broken up into common and service-provider-specific representations, with data fields with detailed data validation rules that can be applied to resources being reported to Kessel, but has limited ability to express relationships (a hardcoded set of id fields interpreted as references to other objects)
• KSL: captures resource types, permissions, authorization logic (as Zanzibar-based set logic), and relationships (including cardinality constraints, which could be used for validation), and cooperative templating that allows dependent services to extend the schema of other services in predefined ways, but not data fields and does not distinguish between common and service-provider-specific representations

The goal here is to have a single representation (whether one of the existing ones or something new) that captures all of the configuration in a unified way. This will give developers a single configuration surface to understand and should have a bias toward usability (including being as seamless as possible and a bias toward mature tooling and development workflows.)

See this doc for vision: https://docs.google.com/document/d/1tWxo-s7ZDGyh2eKjVUq8BMAMx_d433HaMFj-ouyDR7s/edit?tab=t.6jfobobao4rl#heading=h.4z2rizp6dsy

Prototypes should be attached to the parent epic.