To remove an organization_id from an identity in Ory, you can use the PATCH API endpoint for identities. This allows you to update specific fields of an identity using JSON Patch format. You can use the

patchIdentity

endpoint with a "replace" operation to set the organization_id to null:

bash curl -X PATCH --location "https://{your-project-slug}.<http://projects.oryapis.com/admin/identities/{identity_id}|projects.oryapis.com/admin/identities/{identity_id}>" \      -H "Authorization: Bearer {your_api_key}" \      -H "Content-Type: application/json" \      -d '[            {              "op": "replace",              "path": "/organization_id",              "value": null            }          ]'

This PATCH operation will set the organization_id field to null, effectively removing the identity's association with any organization. The API endpoint follows the [JSON Patch](https://jsonpatch.com/) standard (RFC 6902), which allows you to perform partial updates on resources. Note that you need to authenticate your request with an API key that has the appropriate permissions to modify identities. [Ory API Reference](https://www.ory.sh/docs/reference/api) provides more details about the patchIdentity endpoint and other identity management operations.

Your approach—using a naming convention like

Feature:application1:feature1

and

Feature:application2:feature1

to sub-namespace features under applications—is consistent with Ory’s flexible data model and is considered a "clean" and valid pattern. Ory Permissions (Keto) is designed to be highly adaptable, allowing you to model your objects and namespaces in a way that fits your application's needs. The documentation explicitly states that you can use arbitrary strings as objects, and that namespaces are used to scope objects and subjects. This means you are free to encode application-specific context (like application name or ID) into the object identifier if it helps you organize and manage permissions more effectively. However, Ory recommends using unique identifiers (like UUIDs) for objects and subjects to ensure a single source of truth and to avoid encoding too much application data directly in the object string. Still, for sub-namespacing or distinguishing features across applications, your approach is valid and aligns with Ory’s intended flexibility[Namespaces](https://www.ory.sh/docs/keto/concepts/namespaces), [Subjects](https://www.ory.sh/docs/keto/concepts/subjects). Your permission model using the Ory Permission Language (OPL) is also correct. You can define relationships and permissions as you have shown, and use subject sets to express inheritance and group-based entitlements. The OPL is designed to allow such expressive and hierarchical permission models, and your use of

entitled

,

enabled

, and

edit

permissions is idiomatic[Ory Permission Language Examples](https://www.ory.sh/docs/keto/reference/ory-permission-language#examples). Summary: - Sub-namespacing objects (e.g.,

Feature:application1:feature1

) is a clean and supported approach in Ory. - Ory’s model is intentionally flexible to support such patterns. - Prefer unique, stable identifiers for objects, but encoding application context in object IDs for clarity and separation is acceptable and common. If you want to ensure maximum maintainability and avoid potential issues with string parsing or object renaming, consider using unique IDs and storing application context in your own metadata, but your current approach is fully supported by Ory’s design principles.