I'd say it's semi-dynamic, but to give an example:
We have 4 levels of resource types: organization, department, repository, file
Team A comes in and says they would like to add EditRepository, ViewRepository and DeleteRepository permissions -> and they want those permissions to be attachable at organization, department and repository level
Team B comes in and says they would like to add EditFile, ViewFile and DeleteFile permissions an all levels -> and also make it that if someone has a \*Repository permission attached, then they get the appropriate \*File permission automatically.
Now, in addition to above, we want Team A to be only able to directly query or set permissions they defined, and for Team B to be able to directly query or set permissions they defined (for domain separation) -> the only cross-team separation is through configuration of dependency between permissions
We can do above through directly modifying the schema of SpiceDB, but we could also create a generic "relationship" that has e.g. two caveats of "EditFile" + "Team B" -> that way we can define that during query time only relationships for given resource that have those caveats will be taken into account -> that way we have extremely simple SpiceDB schema, but we do rely heavy on Caveat evaluation.
Another thing above is the dynamism of resources -> we could have specific Org, Department, Repository & File entities in SpiceDB, or we could have a singular "Resource" one that can have child-parent relationship, but where we would not really need to worry about types and schema changes (we could implement types e.g. as composite keys, so an identifier of a resource could be Org:3245435, Repository:ABCDF etc.).