Organizations

Data products are always owned and operated in the context of an organization (or a hierarchy of org units). The control plane uses that tree for governance that applies across the platform.

What orgs are for

• Ownership — Who may create, update, and decommission products and which namespace and naming rules apply. Ownership can be modeled so it inherits down the org chain (a parent delegates to a child, subject to your tenant’s model).
• Quotas and limits — Fair use, concurrency, and resource limits are primarily associated with the org (and sub-units) so you can plan capacity and chargeback in line with the business.
• Authorization — Roles and policies often inherit along the same hierarchy, so a policy at a parent can default to children unless you override—see Authentication and authorization.
• Observability — Aggregated logs, metrics, and alerts at org scope (or a subtree) support NOC and platform teams that need a single pane for a division or customer group (see Observability).

Data products in orgs

A data product is registered in exactly one such org (or a specific node in the tree, depending on your model). Applications (see Applications) then group products for a user-facing or internal “app” and attach CORS and other perimeter policy while still respecting org-level rules.

See also — Control plane · Data product lifecycle · Applications