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:

AttributeInheritance/Constraint RuleHolographic Characteristic
RatesChild account rates cannot be lower than parent'sPreserves cost baseline information
Rate Limits (RPM/TPM)Child limits cannot exceed parent'sInherits resource usage boundaries
Allowed ModelsMust be a subset of parent's listTransmits capability scope
Allowed IPsMust be a subset of parent's listInherits security access policies
Allowed LevelsMust be a subset of parent's listPreserves service tier information
Model MapperInherits parent's settings by defaultTransmits routing strategy
Core Levels (Level, Gear, Role)Fully inherited from parentMaintains 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:

  1. Ultimate flexibility: Each level can be finely configured based on inheritance
  2. Perfect isolation: Complete isolation between different branches ensures data and configuration security
  3. Efficient management: Through the tree structure, entire branches can be managed in bulk
  4. 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.