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 clearly track and manage this tree-like relationship, we introduce the concept of DNA
. Each user's DNA
is a string that records the ID path of all ancestor nodes from the root
account to their direct parent.
For example, a user's DNA
might be .1.3.12.
, which indicates:
1
is the root account ID.3
is the user's grandparent account ID.12
is the user's parent account ID.
Through DNA
, the system can quickly determine hierarchical relationships between accounts, which is crucial for permission validation (such as whether one account has the right to manage another).
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 |
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 currentLevel
keys, then attempt drifting to otherLevels
.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.