User Hierarchy and Inheritance

The XAI XAPI account system is designed as a powerful tree-like hierarchical structure, making permission management and resource allocation exceptionally flexible. Understanding this structure is key to fully leveraging our platform.

Core Design Philosophy: Holographic Sub-information

Our account system design draws inspiration from the concept of "Holographic Sub-information." This concept originates from holographic photography principles: any fragment of a holographic photograph contains information about the entire image, albeit with reduced clarity.

In the XAI XAPI, each sub-account is like a fragment of a holographic photograph, inheriting and containing the core "genetic information" of its parent account. This design ensures:

Complete information transmission: Key configurations and restrictions are passed from the root node all the way to leaf nodes
Decentralized management: Each account can operate independently while maintaining consistency with the overall system
Resilience and fault tolerance: Even if intermediate levels encounter issues, sub-accounts can still function normally based on inherited information

Parent and Child Accounts

Parent Account: An account that can create and manage subordinate accounts.
Child Account: Created by a parent account, with many core attributes constrained by the parent account.

A child account can itself become a parent account, creating its own child accounts, thus forming an infinitely deep tree structure. The only exception is the system's top-level root account, which has no parent.

Genetic DNA

To effectively track and manage this tree structure, we introduced a DNA encoding generated by our proprietary genetic algorithm.

Using this DNA, the system can quickly determine the "kinship" relationships between accounts.

Permission and Attribute Inheritance

When creating a child account, many attributes are inherited from or constrained by the parent account. This embodies the "holographic sub-information" concept—the child account contains the parent's core information but may be limited or adjusted in certain aspects.

Inheritance Rules Summary:

Attribute	Inheritance/Constraint Rule	Holographic Characteristic
Rates	Child account rates cannot be lower than parent's	Preserves cost baseline information
Rate Limits (RPM/TPM)	Child limits cannot exceed parent's	Inherits resource usage boundaries
Allowed Models	Must be a subset of parent's list	Transmits capability scope
Allowed IPs	Must be a subset of parent's list	Inherits security access policies
Allowed Levels	Must be a subset of parent's list	Preserves service tier information
Model Mapper	Inherits parent's settings by default	Transmits routing strategy
Core Levels (Level, Gear, Role)	Fully inherited from parent	Maintains identity consistency

This strict inheritance and constraint mechanism ensures that parent accounts have absolute control over all their descendant accounts. For example, if a parent account disables the claude-opus-4-20250514 model, all its descendant accounts will be unable to use that model, regardless of their own settings.

Key User Field Explanations

Level: User tier, used to match the corresponding Level key pool for API calls.
Tier: User recharge tier (0-10), automatically calculated based on cumulative recharge amount.
Gear: Drift scheduling gear. Determines the system's retry and failover strategy when API calls fail.
- 0: No drift scheduling.
- 1: Prioritize retrying with the current Level keys, then attempt drifting to other Levels.
- 2: Prioritize cross-Level drift scheduling to find available services as quickly as possible.
Role: User role. Users with Role=3 have special permissions to create and manage monthly subscription users.

Design Advantages

This hierarchical design based on the "holographic sub-information" philosophy brings multiple advantages:

Ultimate flexibility: Each level can be finely configured based on inheritance
Perfect isolation: Complete isolation between different branches ensures data and configuration security
Efficient management: Through the tree structure, entire branches can be managed in bulk
Natural business model: Supports complex business scenarios like multi-level distribution and agency

Typical Application Scenarios

Scenario 1: AI Application Developers

An AI application developer can:

Create independent sub-accounts for each application, isolating API usage
Create corresponding sub-accounts for different environments (development, testing, production)
Embed API costs into application pricing through rate markups

Scenario 2: Enterprise IT Departments

Enterprise IT departments can:

Create sub-accounts for different departments, precisely controlling each department's AI usage budget
Set different model access permissions to ensure compliance
Restrict access to company networks only through IP whitelisting

Scenario 3: AI Service Resellers

Resellers can:

Create independent sub-accounts for each customer
Generate profit margins through rate markups
Create deeper account structures for large customers to support their internal management needs

Scenario 4: Educational Training Institutions

Training institutions can:

Create limited sub-accounts for each student, controlling learning costs
Restrict available models to guide students to use specific AI models
Prevent resource abuse through rate limiting

Through this sophisticated hierarchy and inheritance system, the XAI XAPI is not just a technical platform, but an infrastructure capable of supporting complex business ecosystems.