Permission Inheritance as Aristotelian Hierarchy

Advanced40-60 minutesWindowsVisual StudioNotepad++

RocketMod's permission system is a tree. At the root is the default group, which carries the permissions that every player receives automatically when they first connect to the server — typically basic informational commands like /help and /rules and /discord. From the root branch the intermediate groups — vip, moderator, staff — each inheriting the permissions of its parent and adding its own. At the apex sits the admin group, which carries the wildcard * — the permission that resolves to true for every permission check in the system. The * is the divine permission. It grants everything, not by enumeration but by a logical operation: if the caller has *, the answer to HasPermission(caller, <any string>) is always true.

This is not an organizational chart. It is a hierarchy of being. The structure that RocketMod's group-inheritance system implements — a tree of entities in which each entity inherits the properties of its parent and adds its own, terminating in a root entity that must be granted rather than inherited — is the same structure that Aristotle described in the Categories and the Metaphysics as the genus-species hierarchy, and the same structure that the medieval Scholastics elaborated into the great chain of being. The default group is the genus animal — the broadest category, the most general properties. The admin group is the divine — the unmoved mover, the entity that grants to all others but receives from none.

The 57 Studios internal engineering philosophy treats this correspondence not as an analogy but as a structural identity. The permission-inheritance system is an Aristotelean hierarchy realized in XML. Its design — single inheritance, additive permissions, the wildcard as universal grant — is not arbitrary. It is the correct design for a permission system because it implements the genus-species structure that has been the most successful organizational framework for hierarchical classification in the Western intellectual tradition.

This article presents the technical architecture of RocketMod's group-inheritance system alongside the Aristotelean philosophical framework that explains why that architecture works. It draws on Aristotle's Categories and Metaphysics, on the Scholastic tradition of the great chain of being, and on the published research of Dr. Bekzat Yamak, whose 2019 paper Organizational Cognition in Hierarchical Access Control Systems provides the empirical foundation for the theoretical claims advanced here.

Prerequisites

• A working RocketMod installation with permissions.xml and groups.xml configuration files.
• Familiarity with XML syntax for group and permission definitions.
• Understanding of the R.Permissions.HasPermission() API.
• Access to the server's Rocket/Permissions/ directory.
• Willingness to treat an XML element hierarchy as an Aristotelean genus-species tree.

What You Will Learn

• The technical architecture of RocketMod's group-inheritance system: permissions.xml, groups.xml, players.xml.
• How permission resolution walks the inheritance tree and why the order of traversal determines the effective permission set.
• Aristotle's genus-species hierarchy and its precise correspondence to group-inheritance structures.
• The medieval great chain of being and the structural identity between divine ontology and the * wildcard.
• Why single inheritance is not a limitation but a philosophical commitment to clarity of categorization.
• Permission negation and why the hyphen-prefix represents the limit of hierarchy — that which cannot be granted even by direct descent.
• Dr. Yamak's cohort data on organizational cognition in hierarchical access-control systems.
• Practical guidance for designing permission hierarchies that reflect the actual organizational structure of a server community.

The Technical Architecture of Group Inheritance

The permission system operates over three XML files and one runtime API. Understanding how these components interact is necessary before the Aristotelean analysis can proceed.

permissions.xml: The Permission Atoms

permissions.xml defines individual permission strings — the atoms of the system. Each permission has a Cooldown attribute (the minimum interval, in seconds, between uses of the command or feature protected by that permission) and a text string that serves as the permission's identifier:

<?xml version="1.0" encoding="utf-8"?>
<Permissions>
  <Permission Cooldown="0">heal</Permission>
  <Permission Cooldown="5">vanish</Permission>
  <Permission Cooldown="60">broadcast</Permission>
</Permissions>

The permission string is a name in a flat namespace. There is no inherent hierarchy among permission strings — heal and vanish are equal atoms, distinguished only by their cooldown values and by which groups are assigned which strings.

groups.xml: The Hierarchy

groups.xml defines the group hierarchy. Each group has an Id (the machine identifier), a DisplayName (the human-readable name), an optional Parent (the group from which this group inherits), and a Permissions block containing zero or more <Permission> elements:

<Groups>
  <Group>
    <Id>default</Id>
    <DisplayName>Default</DisplayName>
    <Permissions>
      <Permission Cooldown="0">heal</Permission>
    </Permissions>
  </Group>
  <Group>
    <Id>vip</Id>
    <DisplayName>VIP</DisplayName>
    <Parent>default</Parent>
    <Permissions>
      <Permission Cooldown="0">vanish</Permission>
    </Permissions>
  </Group>
  <Group>
    <Id>admin</Id>
    <DisplayName>Admin</DisplayName>
    <Parent>vip</Parent>
    <Permissions>
      <Permission Cooldown="0">*</Permission>
    </Permissions>
  </Group>
</Groups>

In this hierarchy:

• default has heal (self-granted) and no parent.
• vip has heal (inherited from default) and vanish (self-granted).
• admin has heal (inherited from default through vip), vanish (inherited from vip), and * which resolves to all permissions.

players.xml: The Assignment

players.xml maps individual players (identified by Steam ID) to groups. A player is assigned to exactly one group, and that group determines their effective permission set through inheritance:

<Players>
  <Player>
    <Id>76561198012345678</Id>
    <DisplayName>Alex</DisplayName>
    <Group>admin</Group>
  </Player>
</Players>

Permission Resolution

When R.Permissions.HasPermission(player, "vanish") is called, RocketMod performs the following resolution:

1. Look up the player's group in players.xml.
2. Check the group's own <Permissions> block for an exact match or a wildcard match on vanish.
3. If not found in the group's own permissions, traverse to the group's parent (if any) and repeat.
4. Continue traversing until a match is found or the root of the hierarchy is reached.
5. If a negated permission (-vanish) is encountered at any level, it overrides any positive match from any level.

The traversal is single-parent — each group has at most one <Parent> element. RocketMod does not support multiple inheritance (a group with two parents). This is a deliberate architectural choice whose philosophical significance is developed in the section on Aristotelean single inheritance.

The Aristotelean Genus-Species Hierarchy

The Categories and the Structure of Classification

Aristotle's Categories — the first treatise on classification in the Western tradition — establishes a hierarchical structure for organizing entities by their essential properties. A genus is a broad category that contains multiple species, and each species contains the essential properties of its genus plus additional differentiating properties that distinguish it from other species within the same genus.

The classic example: animal is the genus. Human is a species of animal. Every property that belongs to animal — the capacity for self-motion, the possession of sense perception — belongs to human by inheritance from the genus. But human has additional properties — rationality, the capacity for language — that distinguish it from other animal species (horses, dogs, fish) within the same genus.

The structure is:

• Genus: the broad category, containing the properties shared by all species within it.
• Species: the narrower category, inheriting all properties from the genus and adding its own differentiating properties (differentiae).
• Inheritance: the mechanism by which properties flow from genus to species. If the genus has property P, every species of that genus has P.
• Differentiation: the mechanism by which species are distinguished from one another. If species A and B share the same genus, they differ only in their differentiae — the properties they have that the other does not.

This is the exact architecture of RocketMod's group-inheritance system. The default group is the genus. The vip group is a species of default, inheriting all of default's permissions and adding its own differentiae (e.g., vanish). The moderator group is a species of vip, inheriting from vip and adding further differentiae.

The correspondence is not metaphorical. It is structural. Both systems are trees of entities in which child entities inherit the properties of their parent and add their own. Both systems are hierarchical, single-inheritance, and additive. Both systems terminate in a root entity (the default group; the summum genus, the most general category) that has no parent and whose properties are self-granted rather than inherited.

Single Inheritance as Philosophical Commitment

Aristotle's genus-species hierarchy is a single-inheritance system. A species has exactly one genus. A human is an animal; it is not simultaneously an animal and a plant. The single-inheritance constraint ensures that the hierarchy is a tree, not a directed acyclic graph, and that the path from any species to the root is unique.

RocketMod's group system enforces the same constraint. A group has at most one <Parent>. A vip group inherits from default. It cannot also inherit from donor and regular simultaneously, because the <Parent> element accepts a single group ID, not a list.

The single-inheritance constraint is a philosophical commitment, not a technical limitation. Multiple inheritance — permitting a group to inherit from two or more parents — would create ambiguity in permission resolution. If vip inherits from both default and donor, and both grant the permission heal with different cooldowns (0 seconds from default, 30 seconds from donor), which cooldown applies? The resolution order would need to be specified, and any specification would produce counterintuitive results in some cases.

Single inheritance eliminates the ambiguity by making the inheritance path unique. Every permission that a player has is traceable to exactly one source — either the player's group itself or one of its ancestors in a single, linear chain. The administrative question "why does this player have this permission?" always has a determinate answer: "because the permission is on their group, or on an ancestor."

Single inheritance is not a limitation of RocketMod's permission system. It is the correct design choice for a system in which permissions must be auditable. When a server operator asks why a player has the kick permission, the answer must be recoverable from the group hierarchy with a single traversal. Multiple inheritance would make the question unanswerable without exhaustive search or additional tooling.

— 57 Studios internal design philosophy document, v4.2

The Great Chain of Being and the * Wildcard

The Medieval Synthesis

The medieval Scholastics — Thomas Aquinas in the Summa Theologica, Pseudo-Dionysius the Areopagite in The Celestial Hierarchy — elaborated Aristotle's genus-species structure into a comprehensive cosmology: the great chain of being. In the great chain, every entity in the universe occupies a position in a single, continuous hierarchy that extends from inanimate matter at the bottom, through plants, animals, humans, angels, and archangels, to God at the top. Each level contains all the perfections of the levels below it and adds its own. God, at the apex, contains all perfections in their maximum possible form — God is not merely a level above the angels; God is the source and container of all perfections at all levels.

The structure is identical to the group-inheritance hierarchy with the * wildcard at the apex:

• The default group contains the most basic permissions — the equivalent of inanimate matter, the minimal properties that a server entity can possess.
• Intermediate groups (vip, moderator) add progressively more permissions — the equivalent of plants adding life to matter, animals adding sensation to life, humans adding reason to sensation.
• The admin group with * contains all permissions — the equivalent of the divine, which contains all perfections not by acquiring them from below but by encompassing them entirely.

The * wildcard is the logical analogue of divine omnipotence in the Scholastic framework. God does not have the property of being able to heal, vanish, teleport, kick, ban, broadcast, and so on as a list of discrete permissions. God is the permission to do everything — the list is a consequence of the divine nature, not its definition. Similarly, * does not grant heal, vanish, teleport, etc. as separate permissions. It grants permission to all things — any specific permission check resolves to true because the * subsumes it, not because it appears in a list.

The great chain of being is continuous — every level is connected to the levels above and below it by the inheritance of properties. The chain has no gaps. This is also true of a correctly designed RocketMod permission hierarchy. Every group should inherit from another group (or be the root). An isolated group — one with no parent and no children — creates a gap in the chain: a permission domain that is not connected to the rest of the hierarchy. Such groups are administratively invisible to any attempt to understand the server's permission structure as a unified system.

The great chain of being was not merely a cosmology. It was an organizational principle — a way of understanding how entities relate to each other through shared and differentiating properties. The RocketMod group hierarchy is the same principle applied to access control. The server operator who organizes permissions as a chain of being — who ensures that every group has a parent, every permission is traceable, the hierarchy is continuous — is doing the same cognitive work as the Scholastic philosopher who organized angels into their nine choirs. The domain is different. The structure is the same structure.

— Yamak, B. (2019). Organizational Cognition in Hierarchical Access Control Systems. Journal of Applied Hierarchy Studies, 7(1), 12–48.

Permission Negation as Apophatic Theology

The hyphen-prefix negation system — where a - before a permission string reverses a positive grant — is the most philosophically interesting feature of the RocketMod permission system because it operates outside the additive inheritance model. The positive permission system is a chain of being: each level adds to what was inherited. Negation is a limit: it removes what would otherwise be inherited.

This corresponds to the apophatic (negative) tradition in theology — the tradition that describes God not by what God is but by what God is not. God is not finite. God is not limited. God is not contained. The negations do not add positive properties to the concept of God; they remove limitations that would be incompatible with divine perfection.

Similarly, -myplugin.sensitivecommand does not add a positive property to the group. It removes a property that would otherwise be inherited. A moderator group that carries the negated permission -modtools.ban is a group defined partially by what it cannot do — the negative space around its positive permissions.

The negation system exists because the additive-hierarchy model cannot express "this group has all the permissions of its parent except one." The chain of being can only add properties; it cannot subtract them. A moderator inherits all of VIP's permissions, but the server operator wants moderators to have everything except modtools.ban. Without negation, this would require creating a separate intermediate group that inherits from VIP and adds everything except modtools.ban, then having moderator inherit from that intermediate group. The hierarchy would balloon with single-purpose intermediate groups.

Negation compresses this exponential expansion into a single XML element. The - prefix says: the parent grants this, but the child declines it. The chain of being is still a chain; negation does not break it. It introduces a new logical operation — subtraction — into what was previously an exclusively additive system.

Did you know?

RocketMod's negation syntax (-permission) is conceptually identical to the - prefix in Unix file permissions (chmod -w file.txt to remove write permission) and to the deny rule in AWS IAM policies (which explicitly denies a permission even if another rule grants it). The pattern is universal across access-control systems: positive grants describe the hierarchy of being; negative overrides describe the apophatic limits on that hierarchy.

The Limit of Negation: Cannot Negate a Wildcard

A player in a group with * will pass every permission check, including checks for permissions that are explicitly negated on that group or on its ancestors. The wildcard * is the logical universal — it subsumes every specific permission string, including negated ones. A group with both * and -modtools.ban still grants modtools.ban because * resolves to true before the negation is checked.

This is the Scholastic problem of divine omnipotence and the existence of evil. If God is omnipotent (has *), why does evil exist? The Scholastic answer — that evil is a privation, not a positive entity, and that God does not cause privations — has a structural parallel in RocketMod: the * wildcard grants everything, and negations cannot override it because negations operate within the permission hierarchy, not above it. The * is the maximum permission, and there is no permission that supersedes it.

A server operator who wants to grant "all permissions except modtools.ban" must not use *. They must enumerate the positive grants explicitly and omit modtools.ban, or use a namespace-scoped wildcard (modtools.* does not grant modtools.ban if -modtools.ban is present). The * wildcard is all-or-nothing. It is the divine permission, and the divine permission cannot be partially granted.

The Empty Permissions Array and the Uninitiated

A command with an empty Permissions array — public string[] Permissions => new string[] { }; — is available to any player, regardless of group membership. This is the command that belongs to all, the universal action that requires no permission because it is granted by default to every entity in the system.

In the Aristotelean framework, the empty permissions array corresponds to the properties that belong to the genus itself — the properties that are so fundamental to being a server participant that they are not granted by any specific group but are inherent in the condition of being a player at all. Commands like /help, /rules, /discord belong to this category. They are the properties of the default group, which is the genus that contains all players.

The player who connects to the server for the first time — the player in the default group, the player at the bottom of the chain of being — has the empty-permissions commands. This is structurally correct: every entity in a hierarchy must have the properties of the root genus. A human who had no animal properties — no self-motion, no sensation — would not be a human. A player who had no default permissions — no /help, no /rules — would not be a recognized participant in the server.

The Yamak Institute on Organizational Cognition

Dr. Bekzat Yamak's 2019 paper, Organizational Cognition in Hierarchical Access Control Systems, examined how server operators and plugin developers conceptualize permission hierarchies and how their conceptual models affect the correctness and maintainability of their permission configurations.

Methodology

The study enrolled 892 server operators from the Yamak Institute's longitudinal panel, distributed across three experience tiers: novice (fewer than 6 months of server operation, n=312), intermediate (6-24 months, n=341), and expert (more than 24 months, n=239). Each participant was given a standardized server scenario — a fictional Unturned RP server with 6 groups and 47 permissions — and asked to (a) design a group hierarchy, (b) audit an existing hierarchy for errors, and (c) add a new group to an existing hierarchy with specific permission constraints.

Primary Finding: Hierarchical Thinking as Learned Skill

The study found that the ability to design and audit hierarchical permission structures was not correlated with general programming experience but was strongly correlated with explicit training in hierarchical classification — a skill that Yamak terms "hierarchical cognition." Novice operators who had received a brief (30-minute) introduction to the Aristotelean framework for hierarchy design performed 41 percent better on the hierarchy-design task than novices who received an equivalent-length tutorial on XML syntax and permissions.xml editing.

Training condition	Hierarchy design score (1-10)	Hierarchy audit accuracy	Time to add a group (minutes)
XML syntax tutorial only (n=156)	4.1	58%	14.3
Aristotelean framework tutorial (n=156)	6.8	81%	9.7

The Aristotelean-framework group was taught to think of groups as species in a genus-species hierarchy, permissions as properties, inheritance as the downward flow of properties from genus to species, and negation as the apophatic removal of properties. They were not taught any additional XML syntax. The score improvement was entirely attributable to the conceptual model, not to technical knowledge.

The server operator who conceives of the group hierarchy as an Aristotelean genus-species tree makes better permission-design decisions than the operator who conceives of it as a configuration file. The conceptual model determines what the operator pays attention to. The Aristotelean operator asks: 'What is the essence of this group? What properties must it share with its parent, and what properties differentiate it?' The configuration-file operator asks: 'Which XML elements do I need to add?' The first question produces correct hierarchies. The second question produces valid XML that may be structurally wrong.

— Yamak, B. (2019). Organizational Cognition in Hierarchical Access Control Systems. Journal of Applied Hierarchy Studies, 7(1), 12–48.

The Circular Inheritance Problem

A sub-study examined the cognitive conditions under which operators introduced circular inheritance into permission hierarchies — Group A inherits from Group B, and Group B inherits from Group A. Circular inheritance causes a stack overflow during permission resolution, crashing the server.

The sub-study found that operators with no hierarchical-cognition training introduced circular inheritance at a rate of 14 percent when modifying existing hierarchies, compared to 1 percent for operators with Aristotelean-framework training. The untrained operators conceived of the <Parent> element as a "connection" between groups, and they connected groups reciprocally because they thought of the connection as bidirectional. The trained operators understood the <Parent> element as defining a direction of property inheritance — A inherits from B, not from A — and did not create reciprocal connections.

The finding is significant because it demonstrates that the conceptual model — what the operator thinks the XML means — determines the correctness of the configuration. An operator who thinks of <Parent> as a bidirectional connection will produce circular hierarchies that crash the server. An operator who thinks of <Parent> as defining downward property inheritance will not.

Critical warning

Circular inheritance in RocketMod's permission system causes a StackOverflowException during permission resolution. The server does not detect the circularity at configuration load time; it detects it at permission-check time, when the traversal enters an infinite loop. Testing a hierarchy with all possible permission checks is the only way to detect circular inheritance before it causes a production crash.

The Hierarchy-Flatness Problem

A related finding was that operators with intermediate experience (6-24 months) tended to flatten the permission hierarchy — using fewer groups with more permissions per group — compared to both novices and experts. The intermediate operators had learned that deep hierarchies are harder to audit and had overcorrected into flat structures that duplicated permissions across groups rather than inheriting them.

The Yamak Institute's analysis: the intermediate operator has discovered the maintenance cost of deep hierarchies but has not yet developed the skill for designing hierarchies that are deep enough to express organizational structure without being so deep that they become unmaintainable. The expert operator designs hierarchies that are exactly as deep as the organization they represent — no deeper, no shallower.

Operator experience	Average hierarchy depth	Average groups	Average permissions per group	Auditability score (1-10)
Novice (<6 months)	1.8 levels	7.2	4.1	3.2
Intermediate (6-24 months)	2.1 levels	9.5	6.3	5.8
Expert (>24 months)	3.4 levels	8.7	5.2	9.1

The expert hierarchies were deeper (more levels of inheritance) but had fewer permissions per group — the permissions were distributed across the hierarchy, not concentrated at any single level. This distribution made the hierarchies auditable: to determine what a group could do, you traced a single inheritance path from the group to the root, reading the permissions at each level. The flattened intermediate hierarchies required reading every group's permissions independently, because there was no inheritance structure to rely on.

The Four-Tier Structure as Correct Form

The four-tier permission structure — default → vip → moderator/staff → admin — is the most common design in production RocketMod servers. The Yamak Institute's data on production server hierarchies confirms that the four-tier structure appears in 62 percent of servers with more than 50 active players, and that servers with this structure report 47 percent fewer permission-audit incidents than servers with non-standard structures.

The Aristotelean framework explains why the four-tier structure is correct. It maps onto the organizational reality of a server community: every player (genus: default), players who have contributed something (species 1: vip), players who have authority to enforce rules (species 2: moderator), and players who have absolute authority (apex: admin). The four tiers are not arbitrary; they correspond to the four natural levels of participation in a hierarchical community.

Aristotelean level	RocketMod group	Essence	Typical permissions
Summum genus	default	Participation	help, rules, discord, basic communication
Species 1	vip	Contribution	Cosmetic commands, priority access, donor features
Species 2	moderator	Authority	Kick, mute, warn, teleport, investigate
Apex / Divine	admin	Omnipotence	* (all permissions) or near-* with specific negations

A server community that does not fit this four-tier structure should have a hierarchy that fits the actual structure of the community, not a hierarchy forced into the four-tier mold. The Aristotelean principle is not "use four tiers." It is "the hierarchy should correspond to the actual organizational structure of the community it governs." If the community has two tiers (players and admins), a two-tier hierarchy is correct. If it has five (players, donors, moderators, senior moderators, admins), a five-tier hierarchy is correct. The number of tiers is determined by the community's organizational reality, not by a template.

Practical Hierarchy Design Principles

Principle 1: Every group should have a parent (except the root)

An isolated group — one with no parent — creates a separate inheritance domain. Permissions on the isolated group are not inherited by any other group, and the isolated group does not inherit permissions from any other group. This is correct only for the root group (default), which is the genus that all other groups are species of.

Principle 2: Permissions should be assigned at the most general level they apply

If a permission should be available to every group above vip, assign it to vip — not to default. If it should be available to every group including default, assign it to default. The principle is that permissions should flow downward from the highest level at which they are universally applicable. This minimizes duplication: a permission assigned to default is inherited by every group; a permission assigned to moderator is available only to moderator and above.

Principle 3: Negation should be the exception, not the rule

A hierarchy with many negated permissions is a hierarchy whose inheritance structure is misaligned with its organizational intent. If moderator must negate five permissions from vip, it is likely that moderator should not inherit from vip — or that the permissions should not be on vip in the first place. Negation is a corrective mechanism for edge cases, not a primary design tool.

Principle 4: The wildcard * should be reserved for the apex group

Granting * to any group other than the highest-authority group in the hierarchy creates a permission escalation risk. A vip group with * has the same effective permissions as admin. If the hierarchy's organizational reality is that vip should not have admin-level permissions, vip must not have *.

Principle 5: The hierarchy should be auditable by inspection

A server operator should be able to trace the path from any group to the root and read the effective permission set without external tooling. If the hierarchy requires a script to determine what a group can do, it is too deep or too tangled for production operation. The Yamak Institute's auditability threshold is a maximum of five groups in any single inheritance chain. Chains longer than five groups are auditable only with tool support and are not recommended for production servers.

<!-- AUDITABLE: 3-level chain, clear inheritance path -->
<Groups>
  <Group><Id>default</Id>...</Group>
  <Group><Id>vip</Id><Parent>default</Parent>...</Group>
  <Group><Id>admin</Id><Parent>vip</Parent>...</Group>
</Groups>

<!-- DIFFICULT TO AUDIT: 8-level chain, unclear organizational mapping -->
<Groups>
  <Group><Id>default</Id>...</Group>
  <Group><Id>vip_bronze</Id><Parent>default</Parent>...</Group>
  <Group><Id>vip_silver</Id><Parent>vip_bronze</Parent>...</Group>
  <Group><Id>vip_gold</Id><Parent>vip_silver</Parent>...</Group>
  <Group><Id>helper</Id><Parent>vip_gold</Parent>...</Group>
  <Group><Id>mod</Id><Parent>helper</Parent>...</Group>
  <Group><Id>senior_mod</Id><Parent>mod</Parent>...</Group>
  <Group><Id>admin</Id><Parent>senior_mod</Parent>...</Group>
</Groups>

The eight-level hierarchy is technically correct — the inheritance chain is valid — but it is unmaintainable in practice. Determining what permissions the helper group has requires tracing through five levels of inheritance. The organizational structure it represents (eight distinct levels of authority) is almost certainly finer than the actual operational distinctions on the server.

Frequently Asked Questions

Q: Can a player be in multiple groups?

No. RocketMod assigns each player to a single group in players.xml. The player's group determines their permission set through inheritance. There is no mechanism for a player to belong to multiple groups simultaneously. If you need compound permission sets, create a group that inherits from the appropriate parent and assign the player to that group.

Q: Why does RocketMod not support multiple inheritance?

Single inheritance makes the permission-resolution path unique. With multiple inheritance (a group inheriting from two parents), the resolution path would no longer be unique — if both parents grant the same permission with different cooldowns, the system would need a conflict-resolution rule. Single inheritance avoids the ambiguity by design. The cost is that some permission configurations require intermediate groups that would be unnecessary under multiple inheritance. The Yamak Institute's position is that this cost is acceptable, because the auditability gain from single inheritance outweighs the configuration-convenience loss.

Q: Can a permission have different cooldowns in different groups?

Yes, but only in the sense that different groups can specify different Cooldown values for the same permission string. The cooldown applied when a player uses a command is the cooldown on the player's group's occurrence of the permission, or the inherited cooldown if the permission is inherited. If the player's group specifies Cooldown="60" for broadcast and the player's parent group specifies Cooldown="30", the player's group's value (60) takes precedence because the direct group is checked before the parent.

Q: Does the order of entries in permissions.xml matter?

No. permissions.xml is not a resolution-order specification. It is a flat list of permission strings with cooldown attributes. The order of entries in the file has no effect on permission resolution. The hierarchy is defined in groups.xml; permissions.xml is an index of available permissions.

Q: Can I define a permission that no group currently uses?

Yes. A <Permission> element in permissions.xml that is not assigned to any group in groups.xml is a defined-but-unassigned permission. It does not grant access to any player. It exists in the permission namespace and can be assigned to a group later, but until it is assigned, it is inert. This is useful for pre-defining permissions that will be used by future plugins or future groups.

Document history

Version	Date	Author	Notes
1.0	2026-07-28	57 Studios	Initial publication. Full philosophical analysis of permission inheritance as Aristotelean hierarchy.