AIT Official Whitepaper

Chapter 1 | AIT’s Core Philosophy: Spend to Rights

In the early stage of the digital economy, “incentives” were widely understood as immediate acquisition: spend and receive cashback, participate and receive tokens, act and receive returns. This logic may increase participation in the short term, but over time it exposes a fundamental flaw—an incentive is mistaken for a return, and participation is reduced to arbitrage. AIT believes the problem is not “insufficient incentives,” but that the object of the incentive has been defined incorrectly. What AIT emphasizes is not “what you receive after spending,” but whether that spending allows you to enter a value system in which participation can continue sustainably. This is a reconstruction at the mechanism level.

1.1 What Does “Rights” Mean in AIT?

In AIT, rights are not fixed income, a promise of returns, or an expectation of repurchase. Rights are records and participation relationships formed on the basis of real contribution and system rules. They first represent the system’s recognition of a participant’s corresponding rule-based status and may, once formal conditions are satisfied, enter release, use, or collaboration relationships.

Specifically, they include:

Recognition of rights records under system rules

Eligibility to participate in established rights-release mechanisms

Entry into subsequent use or collaboration relationships where formal rules permit

Rights do not automatically create governance rights, dividend rights, redemption rights, priority rights, or price outcomes.

The institutional significance of rights does not come from a “guaranteed outcome,” but from the combined operation of rule recognition, time conditions, participation behavior, and corresponding system states. This is also why AIT makes no price promises, no repurchase promises, and no commitment to predictable returns.

1.2 Why AIT Uses “Spending” as the Core Real-World Entry Point for Rights Formation

AIT’s choice of real spending as the core real-world entry point for Contribution Value formation and rights computation under the Consumption Confirmation path is deliberate. Spending has three characteristics that are difficult to substitute:

Real occurrence: valid spending must correspond to a real transaction and fulfillment facts and be capable of verification through applicable mechanisms.

Verifiability: spending behavior can be recorded, audited, and recognized through rules.

Social significance: consumption is a basic form of social collaboration and value exchange.

By contrast, isolated actions such as “staking,” “clicking,” or “user acquisition” can be manipulated at scale and may evolve into systematic arbitrage. Accordingly, in AIT, Contribution Value is not generated by check-ins, referrals, clicks, or user-acquisition actions; Consumption Confirmation is the core path for Contribution Value formation and rights computation. Check-ins and referrals are special participation paths. Any special rights outcomes they may create can only be carried within the predefined 2% Market Ecosystem Reserve under the applicable rules and do not change the role of real spending as the core value input.

Consumption is not designed to stimulate token circulation; it is an important entry point through which real-world value enters system computation.

1.3 How AIT Reconstructs “Spend to Rights”

“Spend to Rights” can easily be mistaken for an upgraded rebate model. AIT therefore makes a clear distinction:

A rebate generally focuses on the benefit returned after a transaction is completed.

Consumption Confirmation is the rule-based confirmation of the corresponding rights relationship after real spending has occurred and been verified.

A rebate asks “how much is distributed”; rights ask “whether the relationship has entered the rules.” In AIT, verified real spending first confirms the fact of contribution and forms Contribution Value under formal measurement rules. Contribution Value then enters Equity Value computation under the applicable rules. How Equity Value is released, how released outcomes are carried by AIT, and when they enter self-custody or subsequent circulation are separately governed by formal downstream rules rather than by a single promise.

At a broader level, Spend to Rights is a paradigm correction for the digital economy. It asks a long-overlooked question: when all behavior is digitized, recorded, and computed, does the individual remain merely “a data source to be used”?

AIT’s position is that behavior itself should become part of the institutional structure. By transforming consumption into a rights structure rather than immediate income, AIT seeks to establish a different relationship:

The individual is not merely a passive consumer.

The system is not a one-way extractor.

Value is not realized only once.

Instead, the system is built around participation, bounded by rules, and oriented toward long-term collaboration.

In one sentence:

AIT is a value system that uses verified real spending as its value entry point and forms computable contribution and continuing rights relationships under rules.

Consumption is not undertaken to obtain a short-term return, but to establish institutional rights for long-term ecosystem participation. AIT is a participatory value network built around real spending as the entry point and rights computation as the core. AIT turns consumption from something that simply disappears into something that can be confirmed: in AIT, consumption is not the end; it is the beginning of participation in the ecosystem.

Chapter 2 | AIT Values and Fundamental Principles

2.1 No Promise of Returns

AIT does not promise any form of income, return, price, or appreciation. Within AIT: rights are not income; release is not a return; and price is not a variable controlled by the system. Market price is neither promised nor guaranteed by AIT and is not treated as a project objective. Market price is formed by external supply and demand, market conditions, and other factors. At the same time, the project and related parties remain responsible for their actual controlled conduct, disclosures, and other responsibilities arising under applicable law or agreement.

AIT defines rules, not outcomes.

2.2 No Buyback & No Price Intervention

AIT does not establish repurchase mechanisms for the purpose of realizing returns or maintaining price, does not provide price support, and does not make the maintenance of any particular price range or market outcome a system objective.

AIT may, where operationally necessary, undertake liquidity deployment, functional-wallet management, or other necessary technical and operational arrangements, provided that such actions are lawful, properly disclosed, and consistent with formal rules. Such actions must not be described as repurchase, price stabilization, price support, or return guarantees.

Market price must remain clearly separated from internal value computation, rights release, and participation rules.

2.3 Real Consumption Anchoring

Within AIT, real spending is the core real-world entry point for Contribution Value formation and rights computation under the Consumption Confirmation path. Real spending has three system-level functions: helping prevent false participation and scalable manipulation, maintaining the connection between value formation and the real economy, and providing a stable input source for the long-term ecosystem.

Accordingly, AIT does not generate Contribution Value from clicks, user acquisition, check-ins, or referrals. Any special rights outcomes formed through check-ins and referrals can only be carried within the 2% Market Ecosystem Reserve specified by formal rules and do not change the role of real spending as the core value input.

2.4 Rules over Incentives

AIT explicitly rejects a design path that trades short-term incentives for behavioral scale. In AIT, behavior must first comply with the rules before it can be recognized by the system; incentives are a result of rule operation, not the reason a behavior is accepted. Once rules are established, they should not be changed arbitrarily merely to pursue participation scale, short-term attention, or market effects. Where adjustment is genuinely necessary, it must be carried out through formal governance, disclosure, and applicable rules.

The stability of rules takes priority over the attractiveness of incentives.

2.5 Participation over Hoarding

Within the AIT system, the release of unreleased rights and certain active participation behaviors are subject to continued participation, behavioral constraints, and the Action Value mechanism.

This principle governs participation and release cadence inside the system. It does not directly restrict on-chain holding or transfer after AIT has been withdrawn to a user’s self-custodied wallet. Merely holding unreleased rights passively within the system does not automatically create an additional release advantage.

2.6 Action Requires Energy

In AIT, Action Value is used to constrain participation behaviors that require active triggering within the system, such as check-ins, referrals, and other operations for which formal rules expressly require Action Value consumption.

Real spending is a real-world value input and does not, by the mere fact that spending occurs, consume Action Value. On-chain holding and transfer after withdrawal to a user’s self-custodied wallet are likewise not directly controlled by Action Value.

Action Value is an important energy constraint for active behavior inside the system. Its sources and consumption paths are defined by formal rules. The purpose of this principle is to control behavioral cadence and reduce zero-cost behavior farming and rule abuse, not to impose a uniform energy threshold on all real-world behavior or external on-chain activity.

2.7 Long-Term Stability First

All AIT mechanisms are designed with long-term system stability as the highest priority. AIT therefore accepts slower growth, meaningful participation thresholds, and limited short-term attraction, while rejecting aggressive release, high-frequency arbitrage, and arrangements that consume future participation capacity.

In one sentence:

AIT promises neither returns nor price outcomes; real spending is the core confirmation entry point; rules come first; active behavior consumes Action Value where required; and long-term stability takes priority.

AIT does not promise returns or price outcomes. Real spending is the core real-world entry point for Contribution Value formation and rights computation under the Consumption Confirmation path. Rule stability takes priority over short-term incentives. Active behavior within the system consumes Action Value where applicable. All design choices are oriented toward long-term sustainability.

Chapter 3 | AIT’s Participatory Value Network

3.1 The Achievements and Structural Limitations of Web2

Web2 built highly scalable and efficient systems for digital collaboration. Within Web2:

Platforms reduce transaction and information costs.

User behavior is continuously recorded and analyzed.

Consumption, content, and social interaction form large-scale networks.

Yet Web2’s central limitation is not primarily technological; it is structural, concerning how value is carried forward. Large amounts of behavior can be recorded and analyzed, while the long-term rights arising from those behaviors often lack institutional continuity for the individual. Platforms may use substantial amounts of user contribution without those contributions necessarily forming structural rights that individuals can continue to hold. In Web2, users often function as “behavior providers” rather than “value participants.” A meaningful share of value accumulates on the platform side, while individuals enter sustainable structural rights relationships only to a limited extent.

3.2 Web3’s Breakthrough and Its Real-World Challenges

At the conceptual level, Web3 introduced several important breakthroughs:

Value relationships can be formally recognized.

Rules can be executed openly.

Digital assets can achieve greater composability.

In practice, however, many Web3 projects have encountered a different form of imbalance:

Overreliance on financialized incentives

Treating rights as equivalent to returns

Detachment of behavior from real-world scenarios

Even where on-chain transparency, open protocols, or decentralized mechanisms are used, some implementations can still become highly speculative and dominated by short-term participation logic, crowding out long-term collaboration.

3.3 AIT’s Position: Reconstruction, Not Replacement

AIT does not seek to “reject Web2” or “replace Web3,” nor does it simply put Web2 “on-chain.” It starts from real spending and uses Web3 rule capabilities to reconstruct how value relationships are carried.

AIT’s position is clear:

Web2 provides real-world anchors.

Web3 provides rules and rights-recognition capabilities.

AIT connects the two into a sustainable participation structure.

AIT therefore follows an integrated Refactoring Path: participation begins in real spending, while rights are computed and released within a rule-based system.

3.4 Characteristics of AIT’s Participatory Value Network

3.4.1 AIT Reconstructs Consumption in the Traditional Platform Economy

The core structure of the traditional platform economy can be summarized as: platform value ← user behavior ← merchant transactions. In essence, it is a centralized platform + user behavior input + platform-side value accumulation. AIT seeks to build a different structure: rule-based system + genuine user participation + shared rights structure. In this structure: real spending → contribution record → rights computation → rule-based release and continued participation. As a participatory value network, AIT does not leave value relationships to be carried solely by a single platform. Real behaviors that satisfy the rules are continuously recorded and computed, and rights relationships become a long-term link between users and the ecosystem. In this structure:

Users are no longer merely consumers.

Merchants are no longer merely channels.

The system is no longer merely a distributor.

Instead, rules create a value structure that can be continuously participated in while reducing the space for manipulation. In AIT, spending still occurs in the Web2 world; fulfillment, services, and merchants remain real-world entities. What changes is that the value relationship created by consumption is no longer carried only by the platform or merchant on a one-way basis.

AIT’s key shift is to turn “consumption” from a one-off act into the starting point of continuing participation. Users are no longer merely payers and data providers; they become contributors of real value, participants in rights relationships, and long-term co-builders operating under rules.

3.4.2 AIT Introduces “Participation” as an Intermediate Layer

A simple “consumption → return” structure can easily become dominated by short-term return logic and may drift toward imbalance. AIT introduces a critical intermediate layer between consumption and value:

Participation. Participation means:

Behavior is constrained by rules.

Rights change over time and with behavior.

Value release is not immediate realization.

This is the underlying character of AIT’s core proposition, “Spend to Rights.”

3.4.3 AIT Is Oriented Toward Reality and Sustainability

AIT’s participatory value network has the following characteristics:

Real input: derived from real-world consumption.

Rule-based computation: executed through system rules.

Controlled cadence: constrained through Action Value and release mechanisms.

Open outcomes: no deterministic return is promised.

Together, these characteristics form a value system with controlled cadence, structural stability, and an orientation toward long-term sustainable operation.

In one sentence:

AIT combines Web2 behavior with Web3 capabilities to build a value network centered on participation.

Web2 provides real-world efficiency and anchoring; Web3 provides rules, transparency, and value composability. AIT brings the two together to reconstruct the relationship among “consumption—participation—value.” AIT is not merely a technical upgrade; it is a reconstruction of value relationships. Participation is the critical intermediate layer between consumption and value. AIT’s objective is to build a participatory value network, not an incentive-only system.

—————————————————————————————————————————————————— Action-based Intelligent Tokenization - Spend to Rights - Marketing to Assets

AIT = Action-based Intelligent Tokenization

An Intelligent Behavior-Based Value Mapping System

Spend to Rights — Marketing to Assets

Chapter 4 | AIT Tri-Value Drive Model

4.1 Why AIT Requires Three Values Rather Than a Single Value

Some traditional incentive systems attempt to use a single numerical unit for multiple functions at once: representing contribution, representing rights, and serving as the unit consumed by behavior. Such designs can be efficient at an early stage, but over the long term they are more likely to produce functional conflation, incentive imbalance, and rule abuse. AIT begins from a different judgment:

When one numerical value simultaneously performs contribution measurement, rights measurement, and behavioral-driving functions, the system is more likely to suffer from functional conflation and rule abuse. AIT therefore adopts a three-value structure in which functions are separated and mutually constrained.

4.2 AIT Tri-Value Drive Model

AIT’s core mechanism is composed of three independent but logically closed-loop numerical systems: Contribution Value (CV), Equity Value (EV), and Action Value (AV). Together they form AIT’s value-driving engine. Contribution Value records “what real contribution you formed”; Equity Value records “the rights-measurement status of that contribution under the rules”; and Action Value constrains “which applicable active behaviors you are currently able to execute within the system.”

4.2.1 Contribution Value: The Core Value Input of the Consumption Confirmation Path

Contribution Value measures real and verifiable contribution generated by users within the AIT ecosystem. Its core characteristics include:

Derived from real spending contribution facts confirmed under the rules

Formed on the basis of the Effective Confirmation Amount and formal system measurement rules

Non-transferable and non-tradable

An internal system value record that is not directly equivalent to AIT or market-circulating value

Contribution Value exists to provide the system with a verifiable and reviewable value-input foundation anchored in real spending. Contribution Value itself is not an asset and carries no return attribute.

4.2.2 Equity Value: A Dynamic Rights-Measurement Indicator, Not a Long-Term Weight

Equity Value is one of the most important—and most easily misunderstood—values in AIT. In AIT, Equity Value is neither a long-term governance weight nor a static income certificate. It is a dynamic internal rights-measurement indicator. Its calculation is:

Equity Value = Contribution Value × Equity Coefficient

The Equity Coefficient is used to determine the rights-measurement result and corresponding release ceiling within the system. It does not represent a return multiple, does not constitute a promise of financial return, and does not correspond to any price outcome. The Equity Coefficient is an institutional measurement parameter, not an investment multiple.

The Equity Coefficient is a formal system measurement parameter. Its specific value and applicable conditions are governed by formally published rules. The coefficient:

Does not constitute a promise of return

Does not correspond to any price guarantee

Does not imply any future rate of return

At its core, Equity Value transforms real contribution into a rights-measurement state that the system can continuously recognize, compute, and release. Equity Value is an internal AIT system value. It is non-transferable and non-tradable by users and is not equivalent to AIT Token. Once Equity Value produces a release result under formal rules, eligible rights outcomes may be carried by AIT carrier units under the system’s formal mapping and carrying rules. Withdrawal, self-custody, and on-chain circulation are separate subsequent states.

Accordingly, an increase in Equity Value does not equal additional issuance of AIT, and release of Equity Value does not mean that AIT has been withdrawn or entered actual circulation. EV and AIT must remain clearly distinguished.

4.2.3 Action Value: Unified Energy Constraint for Active System Behavior

Action Value is an internal AIT system energy unit used to constrain specific active participation behaviors. It does not represent an asset, does not generate returns, and does not directly correspond to AIT or market price.

The regular sources of Action Value are limited by formal rules and mainly include the staking or conversion of Equity Value under rules, together with system-defined random mechanisms. One-time Initial Action Value is a cold-start arrangement and does not constitute a regular generation path. During system operation, check-ins, referrals, and other actions that formal rules expressly require to be actively triggered may be subject to corresponding Action Value consumption conditions. Real spending itself is a real-world value input and does not consume Action Value merely because the spending occurs. On-chain holding and transfer after withdrawal to a user’s self-custodied wallet are also not directly controlled by Action Value.

The purpose of the Action Value mechanism is to establish cost and cadence constraints for applicable active behavior within the system, reducing the risks of zero-cost behavior farming and rule abuse. It is not designed to control all real-world behavior or external on-chain activity.

4.3 Closed-Loop Relationship Among AIT’s Three Values

AIT’s three-value model is not linear. It operates as a closed-loop driving system:

1. Real spending → confirmation of contribution fact → formation of Contribution Value (CV)

2. Contribution Value × formal Equity Coefficient → formation of Equity Value (EV)

3. Equity Value staked or converted under formal rules → formation of Action Value (AV)

4. Action Value consumption → triggers applicable active behavior within the system

5. Continued participation and time rules → Equity Value is released under rules; eligible release outcomes are then carried by AIT

Check-ins and referrals do not generate Contribution Value. Any special rights outcomes they may form are independently carried under the 2% Special Reserve rules and do not alter the primary Consumption Confirmation path described above.

Within this closed loop, each value performs a distinct function and constrains the others. For active system behaviors that formal rules expressly require to consume Action Value, there is no zero-cost execution path. Through functional separation and mutual constraints, the Tri-Value Drive Model helps reduce the risk of system imbalance.

Reduce value-circulation-without-substance risk: Contribution Value is anchored in verified real spending facts.

Constrain behavioral cadence: applicable active system behaviors require Action Value consumption.

Reduce short-term manipulation space: rights release is jointly constrained by time, participation, and formal rules.

This forms the technical and institutional foundation of AIT’s Long-Term Stability First principle.

4.4 Initial Action Value

AIT must allow genuine participants to complete their first institutional action. The system therefore provides a one-time Entry Action Allocation, referred to within AIT as the Initial Action Value mechanism (Bootstrapping Mechanism). This Action Value has the following characteristics:

Non-transferable

Non-stackable

Used only to complete the first institutional check-in or basic action

Does not accelerate release

Does not create any incremental rights

Initial Action Value exists solely to solve the system’s cold-start problem. It is not a reward, subsidy, or airdrop. It is simply the minimum energy allocation needed to allow participation to begin. Initial Action Value is a one-time bootstrapping allocation and a special supplement to the regular sources of Action Value; it must not be understood as a third recurring generation mechanism.

In one sentence:

AIT’s Tri-Value Drive Model separates contribution, rights, and action so that real spending can be transformed into a participatory value structure that is computable, constrained, and sustainable.

When a single value performs multiple functions at once, functional conflation and system imbalance become more likely. The three-value separation preserves functional clarity and long-term stability: Contribution Value records real contribution, Equity Value measures rights, and Action Value constrains the cadence of applicable active behavior. Together, the three form AIT’s tri-value structure.

Chapter 5 | AIT Action Value: Unified Energy for Active System Behavior

Digital collaboration systems intended to operate over the long term generally require clear resource, permission, or cost boundaries for active behavior. If active system behaviors can be executed without limit and at zero cost, behavior farming, resource abuse, and rule imbalance become more likely.

Based on this judgment, AIT introduces Action Value as the cost and cadence constraint for applicable active behavior within the system.

5.1 System Positioning of Action Value

Action Value (AV) is the unified internal energy unit used by AIT to constrain specific active participation behaviors. It does not represent an asset, does not carry returns, and has no price-anchoring meaning. Action Value primarily performs three functions:

1. One of the execution conditions for active behavior designated by formal rules

2. An important control variable for participation cadence within the system

3. A constraint mechanism for reducing zero-cost behavior farming and rule abuse

When formal rules require an active system behavior to consume Action Value, the participant can trigger that behavior only if the Action Value balance satisfies the applicable consumption condition. Action Value is therefore institutional energy for applicable active behavior, not a universal threshold for all real-world behavior. Its existence does not represent a return; its consumption represents the rule-defined cost borne by the corresponding system action.

5.2 Generation Mechanisms of Action Value

To reduce abuse, the generation paths of Action Value are strictly limited. Apart from one-time Initial Action Value as a cold-start allocation, regular Action Value comes from the following two categories:

1. Generated Through Equity Value Staking or Conversion Under Formal Rules

Users may stake Equity Value they hold, and the system converts that staking action into a defined amount of Action Value under the applicable rules. This process does not involve any promise of return. Rather, it converts the corresponding rights-measurement state into Action Value needed to execute active behavior under formal rules.

2. Generated Through a System Randomization Mechanism

The system may, under irregular and non-predictable rules, release Action Value to certain rights holders through a randomized mechanism. This mechanism is not stable, proportional, or predictable and is used only to regulate ecosystem activity.

Action Value Is Not Generated by Behavior

This is one of the most important and easily overlooked principles of the Action Value mechanism: check-ins, referrals, and other active participation behaviors do not directly generate Action Value. Where formal rules require those behaviors to consume Action Value, they only consume it. Real spending is a value input and is not automatically subject to this energy-consumption rule.

5.3 Relationship Between Action Value and Ecosystem Behavior

5.3.1 Energy Consumption by Active System Behavior

Within AIT, check-ins, referrals, and other operations that formal rules expressly require to be actively triggered may be subject to different Action Value consumption conditions. Specific consumption standards are determined by formal rules and may be adjusted through governance procedures and according to ecosystem stage.

Real spending does not automatically consume Action Value merely because spending occurs. On-chain holding and transfer after withdrawal to a user’s self-custodied wallet are likewise not directly constrained by the Action Value mechanism.

Accordingly, Action Value constrains the execution cadence of specific active behaviors inside the system, not every behavior in the real world or on-chain.

5.3.2 Check-In as a Special System Behavior

AIT introduces the check-in mechanism not to create a “daily reward,” but to serve as a behavioral trigger for rights release. Check-in has three system functions:

1. Verifies the user’s active intent to participate

2. Triggers the rights-release process for that day

3. Serves as the minimum threshold for Action Value consumption

Under the established rules: if the user does not check in, no release is triggered that day; without sufficient Action Value, the check-in cannot be completed; and the check-in itself consumes rather than generates Action Value. Check-in is first a system operation and release-triggering behavior, not a fixed-return mechanism. Check-in itself does not generate Contribution Value or Action Value. If it produces a special rights outcome under the 2% Special Rule within the Market Ecosystem Reserve, that outcome is independently carried under the special rule and does not change check-in’s primary role as an active system behavior and release trigger.

In one sentence:

AIT uses Action Value to establish cost and cadence constraints for applicable active behavior within the system, supporting long-term system stability.

Apart from one-time Initial Action Value, regular Action Value comes from Equity Value staking or conversion under rules and system randomization mechanisms. Applicable active behavior within the system consumes Action Value under formal rules and does not itself directly generate Action Value. Check-in is an important trigger for rights release, not a fixed-return mechanism.

Chapter 6 | AIT Energy Conservation: A Foundational Constraint for a Sustainable Ecosystem

No system intended to exist over the long term—whether physical, economic, or digital—can escape a basic fact: resource sources, behavioral costs, and usage paths require boundaries. If system behaviors can be created without limit and at very low cost, behavior proliferation, rule abuse, and value distortion become more likely over time. In early Web2 and Web3 failures, the problem was often not “insufficient incentives,” but rather that:

Behavior carried no real cost.

Rights could be generated without a substantive basis.

Value lacked boundaries and conservation conditions.

Such systems may grow rapidly in the short term, but over time they are more likely to face inflation, abuse, speculation, or erosion of trust. AIT introduces “energy conservation” not merely as a technical choice, but as a system-level constraint intended for long-term digital collaboration.

6.1 Energy Conservation Is Not “Quantity Control” but “Path Control”

A crucial clarification is required: energy conservation ≠ limiting how much a user may obtain. Energy conservation = limiting where energy comes from. In the AIT model, active participation behavior within the system does not directly generate Action Value; where formal rules require Action Value consumption, the applicable behavior consumes it. Apart from one-time Initial Action Value, the continuing sources of Action Value mainly include Equity Value staking or conversion under formal rules and system-defined random mechanisms.

This creates a fundamental constraint: sustained capacity for action must be built on rule-limited sources of Action Value and cannot be generated without limit by active behavior itself. For active system behaviors that formal rules require to consume Action Value, the system considers not only the number of behaviors but also whether the participant satisfies the applicable Action Value cost and other rule conditions.

6.2 Energy Consumption by Active Behavior Is an Important Constraint Against System Distortion

Applying Action Value costs to active system behaviors that require deliberate triggering increases the execution cost of repetitive farming, zero-cost interaction, and strategic abuse, while helping maintain behavioral cadence. Where formal rules apply:

Each active behavior must satisfy the applicable Action Value condition.

Action Value consumption creates behavioral cost and opportunity cost.

Different behaviors may apply different consumption standards according to their nature.

The Action Value mechanism is not the only means of identifying false behavior or preventing system distortion. Behavioral authenticity must still be assessed in combination with VCL recognition, rule execution, anomaly monitoring, and other system controls. The role of the energy constraint is therefore to reduce the risk of zero-cost behavior proliferation and rule abuse, not to guarantee the authenticity of every behavior on its own.

6.3 Energy Conservation as the Physical Expression of the “Long-Term Stability First” Principle

Chapter 2 introduced the Long-Term Stability First principle. “Energy conservation” is the hard constraint through which that principle is expressed in the Model Layer. It means that:

System growth must be accompanied by real input.

Applicable active system behaviors bear corresponding Action Value costs and opportunity costs.

The time and behavioral constraints governing rights release help reduce the space for short-term manipulation.

In other words, AIT does not simply seek to incentivize more behavior. It uses rules and Action Value constraints so that active behavior that satisfies the rules and bears the corresponding cost can continue to occur.

6.4 Energy Constraints as an Institutional Choice for Long-Term Digital Collaboration

Many social, economic, and technical systems that operate over the long term depend on corresponding resource, permission, or cost constraints.

Monetary systems → scarcity and credit constraints

Legal systems → authority cannot be generated arbitrarily

Energy systems → energy conversion is not fully reversible

AIT draws on this logic by using Action Value as a cost and cadence control mechanism for active behavior within the system, requiring applicable digital behavior to bear an explicit rule-defined cost. This is not a restriction on users; it is a form of protection for the system itself.

In one sentence:

AIT constrains the sources and consumption of Action Value to establish cost and cadence boundaries for active system behavior, reducing the risks of zero-cost behavior farming and rule abuse.

The source constraints and consumption mechanism of Action Value are one of AIT’s key model foundations for maintaining long-term participation cadence. Contribution Value provides real value input, Equity Value performs rights measurement, and Action Value constrains active behavior. Together they form AIT’s tri-value foundation. How value is driven, what energy is, and why energy must be conserved under strict rules are inseparable elements of AIT’s value foundation.

—————————————————————————————————————————————————— Action-based Intelligent Tokenization - Spend to Rights - Marketing to Assets

AIT = Action-based Intelligent Tokenization

An Intelligent Behavior-Based Value Mapping System

Spend to Rights — Marketing to Assets

Chapter 7 | In AIT, Value Is Computed, Not Allocated

7.1 AIT Rejects “Dividends / Rebates / Static Returns”

In some traditional incentive, rebate, and digital-asset projects, the value received by participants is often expressed directly as dividends, rebates, fixed percentages, or other return outcomes. Although these mechanisms differ in nature, participants often focus on how a predetermined or expected result will be distributed rather than on how behavior first enters a rule-based computation process. The long-term sustainability of such mechanisms is generally subject to operating, capital, institutional, and external conditions, particularly because:

Dividends generally depend on distributable profits and the applicable institutional arrangements.

Rebates generally use post-transaction benefit returns as a direct incentive.

Fixed or static-return structures can lead time itself to be treated as a source of return.

When operating conditions, funding conditions, or market conditions change, mechanisms centered on predetermined outcomes are more likely to face sustainability pressure. AIT rejects this paradigm not as a matter of regulatory avoidance, but because of a more fundamental judgment:

AIT does not treat a pre-promised return outcome as the basis on which value exists. Instead, it uses real contribution and rule-based computation as the basis for internal rights formation.

7.2 AIT’s Principle: “Value Is Not Given; It Is Computed”

From the outset, AIT’s value system adopts a different premise: the system does not pre-allocate return outcomes through discretionary promises. It computes contribution, rights, and corresponding system states under established rules. This creates three fundamental shifts:

1. The system promises no fixed return.

2. The system predefines no return ratio.

3. The system guarantees no price outcome.

Within the Computation Layer, the system’s core responsibility is to record, identify, and continuously compute qualifying real behavior under established rules. Value is not something “given to you”; it is a result formed progressively within the rules.

7.3 How Behavior, Time, and Rules Enter AIT Value Computation

Within AIT’s computation paradigm, value is not a function of a single variable, but a dynamic result under multiple constraints. At least three core variables are involved:

7.3.1 Behavior: An Input to Value, Not a Reward Trigger

In AIT, behavior does not itself directly generate returns. Behavior serves only as an input condition for value computation, for example:

Real spending → forms the input for Contribution Value computation

Applicable active system behavior → consumes Action Value under formal rules

Formally authorized governance or collaborative behavior → operates within the applicable governance rules

Whether a behavior enters a computation or execution path depends on whether it satisfies the identification, verification, and applicability conditions defined by formal system rules.

7.3.2 Time: Not a Source of Returns, but a Value Filter

AIT makes a clear distinction:

Time ≠ a return generator

Time = a value-filtering mechanism

In value computation, time matters because Equity Value release requires time, sustained behavior is treated differently from one-off bursts, and time constraints can reduce space for short-term arbitrage. Continued participation and time conditions therefore affect whether a corresponding rights state can enter subsequent release under the rules.

7.3.3 Rules: The Core Boundary of Value Computation

AIT’s rules are not tools for arbitrary human intervention. They are the boundary conditions of value computation. Rules determine which behaviors are counted, which rights may be released, and how Action Value is generated and consumed. Once rules are established, the system performs identification, computation, and state processing according to those conditions. Where anomalies, rule updates, or governance matters arise, they are handled through the corresponding governance, review, and anomaly-management mechanisms. As a result, value outcomes:

Have a basis for review

Are understandable within the scope of published rules

Use permissions, rules, and review mechanisms to reduce the space for human manipulation

7.4 Value Computation ≠ Price Appreciation

This is a boundary AIT must state explicitly. Within AIT, an increase in Equity Value, a change in capacity for action, or any other internal system-state change does not mean that market price will rise. Market price is formed externally, while internal values such as Contribution Value and Equity Value are computed under formal rules.

AIT creates only a prerequisite condition: where real demand continues to expand and value computation remains strictly constrained, the market may respond through price. This is not a promise, not an objective, and not part of the system’s design.

7.5 From “Subjective Allocation” to “System Computation”: A Paradigm Shift

AIT’s value-computation paradigm can be understood as follows:

Traditional Model

AIT Model

Project-side distribution of returns

System computation of rights

Returns precede behavior

Returns precede behavior

Behavior precedes rights

Promise-driven participation

Promise-driven participation

Rule-driven participation

Short-term incentives

Short-term incentives

Long-term formation

AIT’s value-computation paradigm is not merely a technical upgrade; it is a shift in value philosophy. The following is an example of the institutional expression of a single spending event:

Participant: User A

Scenario: Merchant B

Real spending amount: USD 100

Verification method: merchant transaction evidence + system signature

System rules:

Contribution Value: formed on the basis of the Effective Confirmation Amount and formal system measurement rules

Equity Value: Contribution Value × formal Equity Coefficient

Rights release: calculated under the formal daily release rule using the remaining unreleased Equity Value as the base

Release trigger: satisfies check-in, Action Value, and other applicable rule conditions

Relevant computation rules and system records should provide an appropriate basis for review and traceability within the scope of formal disclosure and technical capability. VCL primarily performs the functions of rule expression and computation description; actual execution is handled by the Rule Engine and related system components.

In one sentence:

In the Computation Layer, AIT identifies and computes real contribution through rules rather than pre-promising or discretionarily allocating return outcomes.

Real behavior first enters identification and computation. Contribution Value records real contribution; Equity Value forms the corresponding rights-measurement state; and time plus applicable behavior conditions affect subsequent release. Market price is not an internal value-computation result, and system computation remains clearly separated from external market outcomes.

Chapter 8 | VCL: AIT’s Value Computation Language

AIT’s Value Computation Language (VCL) is part of AIT’s computation infrastructure. It is the rule-expression framework used to express participation rules, behavioral conditions, and value-computation relationships in a consistent form. Its role is to convert value models, behavioral conditions, and computation rules into structured expressions that the system can identify and execute. VCL translates values, rules, and behavior into structured rule expressions that the system can continuously recognize, interpret, and execute.

8.1 Why a Value Ecosystem Needs a “Language”

Any system intended to operate over the long term must answer a basic question: how does the system “understand” participant behavior? Without a unified method of expressing rules, interpretation of behavior, rule execution, and value computation are more likely to depend on human understanding and case-by-case handling. This makes scale and consistent execution more difficult and increases the long-term cost of rule interpretation and implementation. In human society:

Law is a language-based constraint on behavior.

Accounting is a language-based computation of value.

Science is a formal expression of regularities.

AIT is no exception. When a system must continuously compute value under unified rules, the means by which those rules are expressed becomes an important part of the institutional structure.

8.2 Definition of VCL: Making Value Explicit

VCL is not a programming language; it is a Value Computation Language. It does not answer “how to write code.” It addresses three more fundamental questions: what kinds of behavior can be recognized by the system, under what rules those behaviors enter computation, and how the conditions used by the computation are expressed consistently.

Accordingly, VCL can be understood in two equivalent ways:

Value Computation Language (system perspective)

Participation Rule Expression Language (user and governance perspective)

Both describe the same function: translating rule conditions that might otherwise depend on human interpretation into unified and machine-recognizable expressions wherever possible.

8.3 How Rules Recognize Behavior: From Real-World Event to Computable Object

Real-world behavior is continuous, ambiguous, and unstructured, whereas computing systems operate on discrete, defined, and structured objects. VCL’s first function is to bridge this gap. From the VCL perspective, a computable behavior must at minimum be expressed through:

Behavioral subject (Who)

Behavior type (What)

Time of occurrence (When)

Rule context (Under Which Rules)

Depending on the type of behavior, additional verification fields may include amount, evidence, source, status, or other data required by formal rules. Only when a behavior has been sufficiently expressed in such a structure does it “exist in the Computation Layer.” Otherwise, it remains a real-world event rather than an object in the value system.

8.4 Rules Before Results: The Computation Philosophy of VCL

VCL’s core principle is to define the rule expression before performing the corresponding computation. The system does not reverse-engineer the computation to produce a result desired by a participant. Instead, it determines under formal rules:

1. Whether the behavior has been correctly expressed and completed the necessary verification

2. Whether the behavior satisfies the applicable rule conditions

3. Whether the relevant values, time, Action Value, and other constraints are satisfied

4. What computation result should be produced under the current rule version and applicable state

The Equity Coefficient, check-in triggers, special rights paths, and other parameters are themselves part of formal rules. Their existence does not alter the principle that rules precede results.

Where anomalous behavior, rule upgrades, or governance handling is required, the matter is processed through formal governance and anomaly-management mechanisms rather than by arbitrary manual alteration of predetermined results.

8.5 Division of Responsibilities Among VCL, the Rule Engine, and the On-Chain Carrier

Within AIT’s overall architecture, VCL, the Rule Engine, and the on-chain carrier perform different functions:

1. VCL: Expression Layer

Expresses behavior, conditions, and computation relationships

Defines what information can enter the applicable computation path

Provides structured expressions for rule execution

2. Rule Engine and System Backend: Computation and State Execution Layer

Parses the applicable rule expressions

Verifies behaviors and conditions

Computes internal system states including Contribution Value, Equity Value, and Action Value

Executes rights release, state transitions, and other system rules

3. AIT Token and Designated Functional Wallets: Carrier and On-Chain Layer

The Genesis Token contract handles standardized on-chain issuance and transfer of AIT

Eligible released rights outcomes are carried by AIT carrier units under formal mapping rules

Designated functional wallets perform corresponding on-chain delivery and operational functions under system rules

After a user completes withdrawal, AIT enters the user’s self-custodied wallet and can be held or transferred under on-chain rules

Accordingly, VCL answers “how rules are expressed,” the Rule Engine answers “how the system computes and processes states,” and AIT Token answers “how eligible outcomes are carried through a standardized on-chain unit.” The three layers connect with one another but are not interchangeable.

In one sentence:

VCL is AIT’s computation language for expressing behavior, conditions, and value-computation relationships as machine-recognizable rules.

VCL is responsible for rule expression; the Rule Engine is responsible for computation and system-state execution; and AIT Token together with designated functional wallets is responsible for the on-chain carrier representation of eligible outcomes. VCL is neither a token contract nor an independent execution system. It is an important expression layer connecting the value model with rule execution.

Chapter 9 | AIT Rights Release and Cadence-Control Mechanism

9.1 Rights Release in AIT Follows System Rules

If rights were realized in full immediately upon formation, they could easily be interpreted as immediate income and would weaken the role of time and continued participation as system constraints. AIT rejects that structure. Instead, AIT separates rights formation from rights release and embeds time and participation into the system rules. Equity Value release follows these basic principles:

No return promise: established release rules do not constitute a promise of fixed income or market return.

Participation-triggered: under the current rules, corresponding daily release requires applicable triggers such as check-in.

Cadence-controlled: release speed may be adjusted by the system under the applicable rules.

Equity Value is an internal rights-measurement state. Its release is part of a state-transition process and does not mean that AIT has entered the user’s wallet or public-market circulation.

9.2 Core Mechanisms of AIT Rights Release

9.2.1 Daily Release Rule: Exponential Release Model

AIT uses a daily diminishing-release mechanism calculated on the basis of remaining unreleased Equity Value. Under formal rules:

Equity Value is calculated for release on a daily basis.

The applicable release rate is determined by formal rules.

The daily release amount is calculated using the remaining unreleased Equity Value at that time as the base.

This structure generally produces a relatively higher release amount at the beginning and a progressively lower amount over time. Minimum measurement units, residual differences, and termination conditions are handled under formal system rules.

9.2.2 Check-In as an Important Trigger Under the Current Release Rules

Equity Value is not released automatically. Under the current formal release rules, a valid daily check-in is an important prerequisite for the corresponding daily rights release. The rules provide:

No check-in: no release occurs for that day.

Insufficient Action Value: the check-in cannot be completed.

Check-in behavior: consumes Action Value.

Check-in is not a reward. It is an institutional action by which the user actively confirms the intention to participate.

9.2.3 Check-In and the Special Rights Path

A valid check-in first serves to confirm active participation and trigger daily rights release. It does not itself generate Contribution Value or Action Value.

Under the formal Market Ecosystem Reserve rules, check-in may also form a corresponding special rights outcome. Such outcomes are carried through the 2% special path within the Market Ecosystem Reserve. The specific conditions, amounts, and execution methods are governed by formal rules.

This special path does not constitute a promise of fixed return and does not alter the role of real spending and Consumption Confirmation as the core path for Contribution Value formation and primary rights computation.

9.2.4 Referral Mechanism and Special Rights Outcomes

Referral is an active system behavior that requires deliberate triggering and consumes Action Value. It does not itself generate Contribution Value or Action Value.

Under formal rules, referrals may affect participation relationships or release cadence and may generate special rights outcomes through the 2% special path within the Market Ecosystem Reserve. Such outcomes are constrained by the special reserve, applicable conditions, and formal rules.

Referral is therefore not a Contribution Value generation mechanism and not a mechanism for unlimited creation of rights. Its function and boundaries are determined by formal system rules.

9.3 Current Genesis Fixed Supply and Supply-State Boundaries

The current AIT Genesis Token contract has a fixed total supply of 21,600,000,000 AIT, minted once at deployment. The contract has no subsequent minting function.

Fixed supply does not mean that all tokens have entered market circulation. AIT must distinguish:

Issued ≠ circulating

Allocated ≠ tradable

Pending release ≠ currently circulatable

Rights outcomes formed through system paths such as Consumption Confirmation, check-in, and referral must be carried from predefined supply reserves under formal rules and must pass through the applicable release, carrier mapping, withdrawal, or other state transitions before they can contribute to external on-chain supply.

Accordingly, the fixed supply of the current Genesis Token represents a supply ceiling and a state constraint. It does not, by itself, imply market scarcity, price appreciation, or that new participants must obtain AIT through the public market.

If a future global ecosystem phase creates requirements beyond the scope of the current Genesis allocation, those requirements must be addressed through independent governance, disclosure, compliance review, and new technical arrangements rather than through hidden minting within the current Genesis contract.

9.4 Boundary Between Rights Release and the Market

AIT must clearly distinguish internal rights release, AIT carrier representation, user withdrawal, and public-market circulation.

Release of Equity Value first creates an internal released-rights outcome. It does not mean that AIT has entered actual circulation. Eligible released outcomes are carried by AIT under formal rules. Only after the applicable withdrawal is completed and the AIT enters the user’s self-custodied wallet can it potentially participate in on-chain holding, transfer, or external market activity.

Market price is neither a result of internal value computation or rights release nor an objective promised or guaranteed by AIT. External market price is influenced by supply and demand, liquidity, market conditions, and other factors.

The system may lawfully carry out necessary liquidity deployment and functional-wallet operations, but not for the purpose of maintaining a particular market price or market outcome.

In one sentence:

Through daily diminishing release, active participation triggers, and supply-state management, AIT allows rights release to enter the AIT carrier path gradually under rule and time constraints.

Equity Value is released daily on the basis of the remaining unreleased balance. Check-in is an important trigger under the current release rules, and check-ins and referrals may also form special rights outcomes through the 2% Special Reserve. Release of Equity Value does not mean that AIT is already circulating. Only eligible outcomes that have completed AIT carrier representation and the applicable state transitions may subsequently enter on-chain holding and external circulation. The current Genesis Token has a fixed supply of 21,600,000,000 AIT, but fixed supply itself is not a promise of price or scarcity.

—————————————————————————————————————————————————— Action-based Intelligent Tokenization - Spend to Rights - Marketing to Assets

AIT = Action-based Intelligent Tokenization

An Intelligent Behavior-Based Value Mapping System

Spend to Rights — Marketing to Assets

Chapter 10 | Participation Structure and Value Motivation

10.1 User Participation Motivation

Within AIT’s Consumption Confirmation and day-to-day usage paths, users are designed not as passive beneficiaries seeking investment returns, but as basic participants in system operation. Their legal characterization in different jurisdictions and scenarios must still be determined in light of the actual mode of participation and applicable law. Verified real spending by users constitutes the core value input for Contribution Value, while continued participation forms an important foundation for institutional operation.

In traditional consumption systems, the relationship usually ends when the transaction ends. The user pays, receives goods or services, and the relationship concludes. Even where points or membership systems exist, they primarily serve marketing objectives rather than recording the long-term value of behavior itself.

AIT differs by bringing consumption behavior into a continuously operating rule system, so that a single act is no longer only an immediate transaction but part of a participation structure. When a user completes real spending, the system records the corresponding Contribution Value. Contribution Value records the user’s verified real spending contribution and enters Equity Value computation under formal rules, forming the corresponding rights-measurement state. This creates three layers of participation motivation:

The first is recognition of behavior. In AIT, consumption is no longer merely expenditure; it becomes a participation fact recorded by the system. That record is not immediately realized as a benefit, but it forms the basis for continued participation.

The second comes from institutional continuity of the relationship. AIT rights release occurs progressively through time and behavior, and users must continue to perform the applicable institutional actions to trigger release. The purpose is not to provide a reward, but to extend the relationship between the user and the ecosystem beyond a single transaction.

The third comes from continued capacity to participate. Active behaviors designated by formal rules require the applicable Action Value conditions. Action Value creates cost and cadence for these behaviors and helps reduce zero-cost behavior farming. Users choose how to participate within their available capacity for action.

From the perspective of participation structure, users are effectively managing three core accounts:

First account: Consumption Confirmation. Spending is no longer merely expenditure; it becomes the basis for entering and continuing to participate in the system.

Second account: Long-term rights accumulation. Equity Value progressively enters the release process under rule and time conditions, while applicable participation behavior affects release conditions and status.

Third account: Continuing participation capacity. Action Value acts as the energy constraint for applicable active behavior, giving corresponding participation a defined cost and cadence.

In one sentence, the user’s participation motivation is:

Users participate in AIT not to obtain an immediate return, but to enter a long-term relationship structure sustained by rules, in which real behavior is recorded, carried forward, and forms the basis for continued participation.

10.2 Merchant Participation Motivation

Within AIT’s operating structure, merchants are neither providers of system capital nor the party that allocates value. Their role is to provide real consumption scenarios and connect real economic activity to the rule system through transactions.

Accordingly, the motivation for merchants to participate in AIT does not arise from token price or financial return, but from the commercial structure itself.

In traditional commerce, merchants acquire users primarily through advertising, platform traffic, or price subsidies. These methods can produce short-term growth, but the marketing cost often disappears once the campaign ends, and the user relationship ends with it. The commercial system repeatedly cycles through “acquire users — consume budget — relationship ends.”

AIT changes the structure of that relationship. Once consumption behavior is institutionally recorded, a transaction is no longer only a sale; it becomes part of the relationship between the user and the ecosystem. Merchants provide the real transaction scenario, the system records the spending behavior, and the rules form a relationship structure that can continue to be computed. This creates three layers of merchant motivation:

The first is structural extension of marketing cost. Traditional marketing expenditure is consumed when the transaction is completed, while in AIT, the consumption event becomes part of a long-term participation relationship, allowing a single transaction to continue to have effects within the rule system.

The second comes from greater continuity in the user relationship. Because rights release depends on continued participation behavior, the relationship between users and the system does not end immediately after a transaction. This shifts the relationship from one maintained by advertising to one extended by rules, lengthening merchant-user interaction over time.

The third comes from a clear separation between commercial operating responsibility and token-market responsibility. Under AIT’s institutional design, merchants do not assume responsibility for AIT price promises, repurchase promises, or fixed-return guarantees. They remain responsible for their own goods, services, transaction fulfillment, information disclosure, and other duties arising under law or contract. Under the primary Consumption Confirmation path, the merchant’s core responsibility is to provide real goods or services and complete the corresponding transaction fulfillment.

From a commercial-structure perspective, merchants effectively make three calculations:

First account: marketing-budget assetization. A transaction is no longer merely the completion of a sale; it becomes the starting point of a long-term relationship.

Second account: stabilization of the user relationship. Rules extend the user relationship rather than relying solely on advertising.

Third account: clarity of responsibility boundaries. Merchants participate in Consumption Confirmation and customer-relationship operations but do not assume AIT price, repurchase, or fixed-return guarantee obligations.

In one sentence, the merchant’s participation motivation is:

Merchants participate in AIT not for price-based returns, but to enter a long-term commercial relationship structure maintained by rules.

10.3 Structural Motivation for System Stability

Within AIT’s operating structure, the value-computation and rights mechanisms do not depend for their validity on continuous external capital injection or on artificially maintaining a particular price. They are based on verified real spending, rule-based computation, and corresponding participation constraints.

First, the system’s value source must have a real-world foundation. In AIT, value begins with real spending. Every Contribution Value record corresponds to an actual real-world transaction. The system’s value input therefore comes from real commercial activity rather than from capital inflows or price speculation, maintaining the connection between the system and the real economy.

Second, system operation requires mechanisms that constrain behavioral density. AIT uses Action Value to impose cost and cadence conditions on active system behaviors designated by formal rules. Because the sources of Action Value are rule-constrained, such active behaviors cannot be executed indefinitely and at zero cost, helping the system maintain an appropriate participation cadence.

Third, internal value changes are not produced through discretionary allocation, but through rule-based computation. Relationships among Contribution Value, Equity Value, and Action Value are computed under established rules, reducing human intervention and making system operation more rule-driven.

From a structural perspective, AIT’s stability depends on three basic conditions:

Condition 1: real spending forms the value input and keeps the system connected to the real economy.

Condition 2: Action Value constrains the execution cadence of applicable active behavior and helps keep participation at a reasonable pace.

Condition 3: rule-based computation replaces discretionary allocation, supporting more sustainable system operation.

In one sentence:

AIT’s operating structure combines genuine user participation, real merchant scenarios, and rule-based system constraints so that value computation has a durable real-world basis.

Users form contribution facts through real spending and enter long-term participation relationships; merchants provide real transaction and fulfillment scenarios and assume corresponding commercial responsibilities; and the system uses value computation, Action Value constraints, and formal rules to maintain participation cadence. Together, these three elements form the basic participation structure of AIT’s Operational Layer.

Chapter 11 | Roles of Users, Merchants, and Nodes

The previous chapter explained AIT’s participation structure from the perspectives of users, merchants, and the system. This chapter further defines the concrete roles and operating paths of these participants in the real-world ecosystem.

For value computation to continue over time, the participant structure must be clear, role boundaries must be explicit, and responsibilities must be reasonably allocated. AIT is not a one-way allocation system; it is a participatory network that depends on continuous input from real behavior. The Operational Layer must therefore first clarify:

Who participates?

What function do they perform in the system?

What responsibilities do they bear?

What responsibilities do they not bear?

11.1 Participation Path for Ordinary Users

In AIT, ordinary users are foundational ecosystem participants. Their participation path has a clear structure:

1. Stage 1: Real Spending

Users enter the system through real-world spending behavior, generate Contribution Value, and have that Contribution Value converted into Equity Value under the rules.

2. Stage 2: Continued Participation

Users complete check-ins and other applicable active behaviors, consume Action Value where formal rules require it, and satisfy the corresponding conditions for rights release or ecosystem interaction.

3. Stage 3: Collaboration and Expansion

Users may enter subsequent participation relationships through referrals, interaction, and other forms of collaboration permitted by formal rules. The role of each behavior, the rights outcome, and any Action Value consumption are governed by the applicable formal rules.

It must be clear that, within AIT’s Consumption Confirmation and day-to-day usage paths, users are designed as rule-bound participants rather than recipients of fixed returns. Their specific legal characterization must still be determined in light of the actual mode of participation and applicable law. A user’s corresponding system status is determined by continued participation, time, and formal rules rather than by a single action.

11.2 Merchant Value and Responsibilities

Merchants are not the issuer of AIT Token and do not, merely by participating in Consumption Confirmation, assume responsibility for price, repurchase, or fixed-return guarantees. Their core responsibilities in the Operational Layer include:

1. Providing real consumption scenarios

2. Assisting in confirming real transaction and fulfillment facts

3. Assuming responsibilities for goods or service fulfillment, data authenticity, necessary disclosures, and other obligations under cooperation agreements and applicable rules

The primary significance of merchant participation in AIT is to connect real commercial activity to the rule system and form sustainable customer relationships and consumption scenarios, not to obtain a particular market price or fixed financial return.

11.3 Structural Tiering of Node Roles

As the ecosystem develops, AIT may create corresponding node tiers based on real operating scope, collaborative responsibilities, service capabilities, and formal node rules. Differences among node tiers mainly concern:

1. Market-building and service responsibilities

2. The scope of merchants, users, and collaboration relationships served

3. Corresponding operating, management, and rule-execution responsibilities

4. Entry, upgrade, and exit conditions defined by formal node rules

A node tier is not automatically obtained by holding more AIT or by forming a higher expectation of market price. Its specific name, permissions, and responsibilities are governed by formal node rules.

11.4 Why Merchants Are Critical Infrastructure for AIT

Without real merchant scenarios, AIT’s primary Consumption Confirmation path would lack a verifiable real-world transaction and fulfillment foundation, and Contribution Value formation would lose its corresponding real-world anchor. AIT’s primary Consumption Confirmation path is not a virtual-behavior system; Contribution Value input must be anchored in real spending and real fulfillment facts. Merchants are therefore not an auxiliary role, but an essential real-world scenario foundation for AIT. They connect:

Real consumption

Value computation

Rights formation

Within the fixed-supply fact of the current Genesis Token contract, expansion of the merchant network can create more real consumption scenarios, participation entry points, and corresponding system-usage demand without changing the fixed-supply fact of the current Genesis Token contract.

11.5 Why Role Boundaries Are Necessary

To avoid role confusion, AIT makes clear that:

User roles and merchant roles perform different functions and bear different responsibilities.

Merchants are not the issuer of AIT Token and do not assume price or repurchase obligations merely by participating in Consumption Confirmation.

The system performs computation, state processing, and carrier representation under formal rules; it does not distribute fixed-return outcomes through discretionary promises.

Clear role boundaries are a source of operating stability. If the functions, responsibilities, and outcome commitments of different roles are conflated—for example, if merchants are expected to bear token-price obligations, or ordinary user participation is directly interpreted as a fixed-return relationship—the ecosystem may deviate from its intended design boundaries.

In one sentence:

Clear participant roles and role boundaries in AIT’s operating structure allow value computation to continue under defined divisions of responsibility.

Users enter through real spending, merchants provide the real-world anchor and scenario foundation, and the node structure creates differentiated responsibilities. Role boundaries help preserve operating stability. The first step of the Operational Layer is not growth; it is role clarity.

Chapter 12 | Consumption Scenarios and the Real-World Commercial Closed Loop

12.1 Why It Must Be “Real Spending”

From the Philosophy Layer onward, AIT makes clear that the core value input for Contribution Value and the primary Consumption Confirmation path must be anchored in real spending, not in clicks, check-ins, referrals, or similar actions. If behavior can exist independently of the real economy, a system can quickly evolve into behavior mining, arbitrage loops, and capital-driven games. Real spending has three characteristics that are difficult to replace:

1. Authenticity — consumption must correspond to real payment, transaction, and fulfillment facts.

2. Verifiability — the transaction behavior can be identified by the system.

3. Social significance — consumption is a basic unit of economic collaboration.

Accordingly, the operating foundation of AIT is not “clicks,” but real-world commercial behavior.

12.2 The Real-World Closed Loop from Consumption to Rights

Within the Operational Layer, a complete closed loop should include the following path:

1. The user completes real spending.

2. The merchant completes the corresponding fulfillment.

3. The system identifies and verifies the valid transaction.

4. Contribution Value (CV) is formed under formal rules.

5. Contribution Value enters Equity Value (EV) computation.

6. The user completes check-in or other applicable active behavior under formal rules and consumes Action Value (AV) where required.

7. Equity Value enters the release process under time and participation conditions; eligible released outcomes are carried by AIT.

8. The user continues into subsequent consumption or ecosystem participation relationships.

This means consumption is not the endpoint, rights are not the endpoint, and behavior is not the endpoint. Together, they form a continuing cycle.

12.3 How Merchants Connect Without Becoming Financialized

A critical question is how merchants can participate in AIT without being drawn into financial promises or price risk. AIT’s design makes clear that merchants do not promise token prices, are not responsible for repurchase, and do not assume responsibility for return distribution. Under the primary Consumption Confirmation path, merchants’ core responsibilities include:

1. Providing real consumption scenarios

2. Ensuring that transactions are real and verifiable

Specific participating entities must also assume responsibility, under cooperation agreements and applicable rules, for goods or service fulfillment, data authenticity, necessary disclosures, and other corresponding duties. The commercial value merchants seek is primarily continuity of customer relationships, repeat consumption, and operating efficiency—not AIT price appreciation or fixed financial returns. Merchant participation therefore remains commercial rather than financial in logic.

12.4 Diversity and Expansion of Consumption Scenarios

AIT does not restrict the type of consumption scenario. In principle, it may apply to food and beverage, retail, services, online entertainment, education, content, and other sectors. The industry is not the decisive factor; two basic conditions must be satisfied:

1. The behavior is real.

2. The transaction is verifiable.

Whether a specific scenario can connect to AIT must also satisfy transaction authenticity, verifiability, system-integration standards, and applicable requirements in the relevant jurisdiction. Only when these conditions are met can the corresponding consumption behavior enter AIT’s identification and computation paths.

12.5 How AIT Works with Existing Payment Systems and Platforms

AIT does not replace existing payment systems and does not perform statutory payment, clearing, or financial-settlement functions. It uses the result of a real transaction as an important input for Consumption Confirmation and value computation, adding rule-based rights continuity on top of existing commercial infrastructure.

Existing Payment / Commercial Systems

AIT

Complete payment, collection, and transaction settlement

Identify and verify eligible consumption facts

Record transaction amounts and transaction status

Form Contribution Value and Equity Value under formal rules

Handle existing payment and fulfillment processes

Manage corresponding rights status, participation conditions, and release rules

Provide the real-world commercial transaction foundation

Provide rule-based carrying of eligible rights results

Merchants can therefore generally continue to use their existing payment and collection systems. AIT does not require AIT Token to replace real-world payment instruments. What AIT adds is a Consumption Confirmation, value-computation, and rights-carrying layer—not a substitute payment layer.

12.6 From Closed Loop to Scale

The existence of a real commercial closed loop gives AIT three important characteristics: continuous value input, natural participation paths, and expansion grounded in commercial reality. AIT’s real-world operational expansion primarily depends on:

More real consumption scenarios connecting to the system

Deeper user participation relationships

More rule-compliant consumption and collaboration paths

Rather than token subsidies or price stimulation.

In one sentence:

AIT forms a continuing consumption—rights—action closed loop in real commercial scenarios, allowing value computation to operate over the long term in the real world.

AIT’s value input must come from real spending; merchants are the real-world anchor of the closed loop; and the system attaches to existing payment and platform structures. Consumption → rights → action → renewed consumption forms a continuing cycle. The core of the Operational Layer is not financial logic, but commercial logic.

Chapter 13 | Operating Cadence and Expansion-Control Mechanisms

AIT does not seek the fastest-growing system; it seeks the system with the longest sustainable life. This chapter asks: under the fixed supply of the current Genesis Token and the Action Value constraint mechanism, how can the ecosystem expand in an orderly manner?

13.1 Why “Cadence” Matters More Than “Speed”

When system expansion materially exceeds operating and governance capacity, imbalances are more likely to emerge among behavior, services, rights states, and market expectations. AIT’s design objective has therefore never been “maximum scale,” but stable cadence.

Cadence means:

Behavioral density can be constrained.

Energy consumption can be projected within the applicable rules.

Expansion speed can be adjusted.

13.2 Action Value as a Cadence Controller for Active Behavior

Within the Operational Layer, Action Value not only acts as an energy constraint but can also serve as an important cadence-control variable for applicable active system behavior.

For check-ins, referrals, and other operations that formal rules expressly require to consume Action Value, the sources and balance limits of Action Value create corresponding execution costs, reducing the likelihood that such behavior can be repeated without limit and at zero cost.

This mechanism cannot control all real-world behavior and cannot by itself guarantee that the system will never overheat. It can, however, work together with behavior identification, rights release, anomaly monitoring, and governance mechanisms to help maintain an appropriate cadence of active participation.

13.3 Expansion Boundaries of the Referral Mechanism

Referral is an active system behavior that requires deliberate triggering and consumes Action Value. It does not itself generate Contribution Value or Action Value.

Under formal rules, referrals may affect participation relationships or release cadence and may form special rights outcomes through the 2% special path within the Market Ecosystem Reserve.

The referral mechanism must therefore be jointly constrained by Action Value costs, the size of the special reserve, applicable conditions, and other formal rules. Its purpose is not to create an unlimited rights-generation path, but to support the expansion of real participation relationships within predefined boundaries.

13.4 Structural Control of Merchant Expansion

Merchant expansion can be an important source of ecosystem growth, but merchant expansion is not token minting. Under the fixed-supply fact of the current Genesis Token contract:

More merchants connected → more potential entry points for real consumption

More valid consumption → potentially more rule-compliant Contribution Value records

Expanded participation relationships → potentially greater rights-carrying and active-behavior demand

This creates a natural structural tension: ecosystem expansion can generate new system-use and carrier demand, but it does not change the fixed-supply fact of the current Genesis Token contract. The pace of merchant expansion must therefore remain aligned with Action Value circulation capacity, user participation density, and rights-release cadence.

13.5 Anti-Overheating and Cooling Mechanisms

Every system experiences fluctuations in activity. AIT’s operating structure includes several mechanisms that can help regulate participation cadence, including:

1. Anti-overheating mechanisms

Action Value costs constrain applicable active behavior; rights release is constrained by check-in, time, and formal rules; referrals are constrained by Action Value and the boundaries of the special rules.

2. Cooling mechanisms

If the user does not check in, release for that day does not occur. If Action Value is insufficient, the active behaviors that require Action Value cannot be triggered. Rights release diminishes over time, and when participation declines the system is not compelled to continue releasing.

13.6 Expansion Is Not Merely Growth; It Is Structural Stability

Within AIT’s operating logic, expansion is not itself a metric, user count is not an end goal, and merchant scale is not the endpoint. The real objective is:

As scale expands, to preserve as much alignment as possible among rules, rights states, participation cadence, and operating capacity.

If expansion results in uncontrolled behavior, exhausted energy, or damage to the rights structure, then expansion itself has failed.

In one sentence:

AIT’s cadence and control mechanisms are intended to help the ecosystem maintain a reasonable match among rules, participation cadence, and system capacity as scale expands.

Cadence takes priority over speed. Action Value is an important cadence-control variable for applicable active behavior. Referrals are constrained by Action Value, the 2% Special Reserve, and other formal rules. Merchant expansion does not change the fixed-supply fact of the current Genesis Token contract. Anti-overheating and cooling mechanisms jointly support orderly expansion. The core logic of the Operational Layer is that the system can expand, but expansion must remain constrained by system capacity and formal rules.

Chapter 14 | System Health and Dynamic Balance

14.1 AIT “System Health”

Within AIT, system health does not mean growth in user count, market-price appreciation, or a short-term increase in activity. It refers to structural balance among value input, energy consumption, rights release, and participation density. A healthy AIT system should exhibit:

Behavior that is not overloaded

Energy that is not overdrawn

Rights that are not structurally imbalanced

Participation that is not distorted

14.2 Balance Between Energy Input and Behavioral Density

Action Value is an important energy mechanism through which AIT constrains applicable active system behavior. Its generation and consumption relationship affects the cadence of the corresponding behavior. The following conditions are relevant:

Long-term mismatch between Action Value supply and demand for applicable active behavior → may weaken the intended cadence-control effect

Persistent insufficiency of Action Value → active behavior that requires Action Value may be restricted

The relationship between Action Value generation and consumption is therefore one important dimension of system health. This balance is not a fixed ratio and may fluctuate naturally with user scale and participation intensity.

14.3 Matching Rights Release with Participation Intensity

AIT Equity Value enters the release process under the formal daily diminishing-release rule, but Equity Value release itself does not mean that AIT has entered actual circulation. Eligible released-rights outcomes must still complete AIT carrier representation and the applicable state transitions under formal rules.

System health requires attention to the relationship between rights-release cadence and actual participation. If release conditions, participation density, and carrier cadence remain materially misaligned over time, expectation or operating pressure may arise.

AIT constrains this process through check-in triggers, Action Value conditions, time-based diminishing release, and other formal rules.

14.4 Tension Among Fixed Supply, Circulation State, and Demand Expansion

The current Genesis Token contract has a fixed supply ceiling, but fixed supply does not mean that all AIT has entered actual circulation. The quantity available for external circulation is also affected by established allocations, rights release, AIT carrier representation, withdrawal, liquidity deployment, and other state changes.

As real consumption scenarios and participation relationships expand, demand for AIT system use and for AIT as a carrier may change. Such changes do not imply that market prices will necessarily rise or that market scarcity will necessarily result.

The system should maintain clear boundaries between internal rights computation, supply-state management, and external markets, and may lawfully undertake necessary operational and liquidity arrangements without targeting a particular price outcome.

14.5 Anomalous Behavior and Correction Mechanisms

Any system intended to operate over the long term requires mechanisms for handling anomalous behavior and rule abuse. AIT may face false consumption, duplicate submissions, abnormal account behavior, rule exploitation, and other activity that departs from normal participation paths.

AIT anomaly handling may combine:

1. Behavior and data identification

2. Rule Engine verification

3. Action Value and other system constraints

4. Anomaly monitoring, review, and governance handling where necessary

Restrictions, adjustments, or other measures applied to anomalous behavior should be based on clear and reviewable formal rules and should maintain appropriate proportionality, records, and responsibility boundaries. Where applicable, corresponding notice, review, or appeal mechanisms should be available.

Where system parameters or rules genuinely require adjustment, changes should be implemented through formal governance procedures, version management, and disclosure requirements rather than through temporary or arbitrary modification of existing outcomes.

14.6 Dynamic Balance, Not Static Stability

AIT does not pursue a “constant state.” It pursues dynamic balance. User scale may fluctuate, merchant numbers may change, and market prices may rise or fall. Dynamic balance requires the system to continuously observe the relationships among real value input, applicable active behavior, rights release, supply state, and real operating capacity. When relevant conditions change, the system should determine under formal rules and governance procedures whether corresponding adjustments are required.

The objective of dynamic balance is not to guarantee that the system will never become imbalanced, but to provide the ability to identify, respond to, and recover from changes when they occur.

14.7 Feedback Loop Between the Operational Layer and the Model Layer

AIT’s Operational Layer does not exist independently. When structural changes occur:

Model Layer parameters may be adjusted under formal authority and governance procedures.

Computation Layer rules may be updated in accordance with version-management and disclosure requirements.

Operational Layer cadence may be adjusted in response to actual operating conditions.

This feedback loop helps AIT maintain the capacity for ongoing adjustment and evolution rather than becoming a rigid structure.

In one sentence:

AIT system health is the continuing maintenance of a recognizable and adjustable dynamic balance among real value input, active-behavior constraints, rights release, supply state, and real participation.

System health is not the same as user growth or price appreciation. Action Value constrains the cadence of applicable active behavior; rights release should remain reasonably aligned with participation conditions and AIT carrier representation; and anomalies are handled through formal rules, review, and governance procedures. Dynamic balance does not guarantee that the system will never become imbalanced. It gives the system the capacity to continuously identify, adjust to, and recover from change.

—————————————————————————————————————————————————— Action-based Intelligent Tokenization - Spend to Rights - Marketing to Assets

AIT = Action-based Intelligent Tokenization

An Intelligent Behavior-Based Value Mapping System

Spend to Rights — Marketing to Assets

Chapter 15 | AIT Issuance Mechanism and Supply Structure

AIT’s value does not originate from the Token itself, nor does it come into existence merely because the Token enters market circulation. Real spending and genuine participation are the starting points of value; the recording, computation, and constraint of behavior through rules form the system’s core; and the role of the Token is to provide, after those rules have been established, a digital unit through which corresponding results can be carried, recorded, transferred, and used.

Accordingly, this chapter does not begin by asking how AIT will enter the market. It first addresses a more fundamental question: how does AIT, as a digital carrier, come into existence, and under what supply structure is it issued and defined? Only after clarifying what it carries and does not carry, how it is supported by the technical environment, and how total supply and minting are structured can subsequent discussion of allocation, circulation, and stability have a sound basis. In other words, the AIT issuance mechanism is not merely a numerical arrangement; it is an institutional expression of the carrier definition and supply boundary.

15.1 Why AIT Needs a Digital Carrier

Any rule system intended to exist over the long term must answer a basic question: what ultimately carries the results computed by the system?

If behavior can only be recorded but not expressed in a stable form, rules remain conceptual. If rights can only be explained but cannot be consistently carried, the system cannot form a sustainable participation structure. If value outcomes cannot be recorded, transferred, and used through a standardized unit, the system cannot move from abstract rules to real operation.

AIT needs a carrier not to financialize the system or create an external symbol designed for trading, but to give established value relationships a unit through which they can be carried and used over the long term.

That carrier must satisfy at least four conditions:

First, it must be able to carry rule outcomes. Results produced by the system through real spending, participation behavior, time constraints, and release mechanisms need a unified unit of expression; otherwise, value relationships cannot be recorded consistently.

Second, it must function in a digital environment. AIT is not merely a paper-based institutional design; it is intended to operate over the long term across real commerce and digital networks. Its carrier unit must therefore be recordable on-chain, digitally manageable, and transferable under rules.

Third, it must support ecosystem use. The significance of a carrier is not simply that it exists, but that it can be used. A unit that can only be displayed, but cannot be carried within the ecosystem, invoked by applicable behavior, or used as part of system participation, is not an effective carrier.

Fourth, it must have boundaries. A carrier without defined boundaries can easily be consumed by external narratives. If it does not clearly state what it does not carry, it can easily be misread as a return instrument, financing instrument, or price instrument.

AIT therefore requires a carrier not because every digital system should have a Token, but because AIT has already established a sufficiently defined value structure that requires a limited, standardized, and rule-constrained digital unit to carry eligible results. AIT does not begin by creating a Token and then searching for use cases. Rather, after the value model, computation rules, and operating structure have been established, it provides a unified, verifiable, transferable, and usable on-chain carrier unit for rights outcomes that satisfy the rules.

15.2 Definition and System Positioning of AIT Token

Within the overall system, AIT is neither the origin of value nor the arbiter of rules.

It is not the source of value. Value originates from real spending, genuine participation, and continued behavioral input in real-world scenarios. Nor is it the arbiter of value: how value is confirmed, enters computation, and is released over time is determined by the Model Layer, Computation Layer, and Operational Layer—not by the Token itself.

AIT’s more precise position lies between value outcomes and digital carrying. Its responsibility is not to “generate value,” but to “carry value outcomes”; not to “determine rules,” but to comply with rules and support use.

AIT’s system position can therefore be summarized in three points: first, it is a carrier unit for value outcomes; second, it is a digital medium used in ecosystem operation; and third, it is a functional carrier within rule boundaries. It serves the system; the system is not designed to serve a Token narrative.

15.3 Relationship Between AIT and Contribution Value, Equity Value, and Action Value

AIT must be defined in clear distinction from the Tri-Value Model.

Within AIT’s overall mechanism, Contribution Value records real contribution confirmed under the rules, Equity Value represents an internal dynamic rights-measurement state, and Action Value constrains active system behavior designated by formal rules. Together, the three form AIT’s tri-value structure.

AIT Token does not replace any of these three values and must not be conflated with any of them. It is not Contribution Value, because Contribution Value records only the fact of real contribution. It is not Action Value, because Action Value is an internal energy constraint for applicable active behavior rather than a unified external carrier. Nor is AIT Token equivalent to Equity Value.

Contribution Value, Equity Value, and Action Value all belong to AIT’s internal value model. AIT Token is a standardized on-chain unit in the Carrier Layer. Equity Value itself is not an on-chain asset and does not directly enter holding, transfer, or public-market circulation. Eligible released rights outcomes that satisfy the rules are carried through the corresponding AIT carrier arrangements at the system layer. Only after withdrawal is completed and the relevant AIT enters the user’s self-custodied wallet does it enter a state in which the user may hold and transfer it under on-chain rules.

In short: Contribution Value records real contribution, Equity Value performs rights measurement, Action Value constrains applicable active behavior within the system, and AIT carries eligible rule outcomes as an on-chain unit.

15.4 What AIT Carries—and What It Does Not Carry

The definition of any carrier is ultimately completed through its boundaries.

AIT carries: digitized outcomes formed by the system from real participation; functional units that can be recorded, held, transferred, and used under rules; standardized expressions of certain rights and circulation relationships within the ecosystem; and a unified medium linking internal system-computation outcomes with the external digital environment.

AIT does not carry promises of fixed return, price guarantees, repurchase obligations by the project toward holders, shareholder rights or residual claims against a company, debt claims or principal-and-interest repayment obligations, or any result obligation created outside the rules through subjective narrative.

These boundaries must be institutionalized. Otherwise, a Token can easily become financialized, return-oriented, or treated as a result promise through external misinterpretation. For AIT, defining “what it does not carry” is not a negative disclaimer; it is a necessary measure to protect the system’s identity.

15.5 Functional Attributes and Usage Boundaries of AIT

Within the AIT system, AIT has at least three functional attributes.

First, a rights-carrier attribute. It allows certain rights outcomes that would otherwise remain only within computation relationships to be recorded uniformly and form clear, durable holding relationships.

Second, a circulation-unit attribute. As a limited digital unit, AIT may enter transfer, circulation, and exchange relationships under established rules and applicable scenarios. Circulation is not its only purpose, but it is one important condition for the carrier to function.

Third, a participation-medium attribute. AIT is not a display-only symbol. It is a medium for certain behavior, usage, and participation relationships inside the ecosystem. Its significance lies not only in being holdable, but also in being usable within the system.

These three attributes must be understood together, but they must not be conflated. AIT does not exist merely because it can circulate; it first exists as a rights carrier. It is not useful because it can be speculated on; it is useful because it can serve as a participation medium. Function precedes circulation; carrying precedes market activity; rule-based attributes precede digital-market expression.

AIT’s digital-carrier nature does not mean that it may be interpreted without limit or without regard to scenario.

Its functional boundary first comes from the boundary of the system itself. Internal functional use and rights carrying by AIT must remain consistent with AIT’s overall definition as an intelligent behavior-based value-mapping system and must not depart from core principles such as real-spending anchoring, rules first, and long-term stability first. After withdrawal to a user’s self-custodied wallet, on-chain holding and transfer are governed by the applicable on-chain rules and law.

Its usage boundary also comes from the ecosystem boundary. AIT may function within ecosystem relationships recognized by the system, but its digital form does not make it inherently suitable for every payment, settlement, financing, collateral, yield-packaging, or financial-engineering scenario.

Its expression boundary also comes from external communications. No description of AIT may go beyond its defined functions by presenting it as a project-return instrument, a short-term appreciation instrument, or a price-driving instrument.

AIT’s boundaries therefore do not arise only after circulation begins; they must exist from the moment AIT is defined. Only when usage boundaries are clear can later chapters on issuance, circulation, and market relationships avoid drifting into unlimited interpretation.

15.6 Technical Carrier and Infrastructure Structure of AIT

A digital carrier cannot become an operable object without technical support.

For a digital carrier, the carrying relationship must exist within a technical environment that can continuously record it, identify it consistently, and invoke it under rules. Otherwise, the “carrier” remains a label rather than an operational object.

Technical support is therefore not an auxiliary issue in the Carrier Layer; it is part of the carrier’s conditions of existence. A unit that cannot be recorded cannot be held. A unit that cannot be identified cannot be transferred. A unit that cannot be invoked by rules cannot become part of ecosystem use. Only after the carrier enters a technical structure do the previously defined functional boundaries, holding relationships, and circulation relationships become operationally executable.

For AIT, the significance of technical carrying is not simply “going on-chain.” It is to place AIT, as a digital unit within an intelligent behavior-based value-mapping system, into an environment that can be managed, verified, and transferred. Technology is not the objective; it is the infrastructure condition that allows the carrier to exist.

As a digital carrier, AIT must have a clear, unified, and identifiable technical form. It is not an abstract concept, but a standardized digital unit deployed within a specific technical structure, through which recording, identification, transfer, and state-update capabilities are provided. At minimum, this existence must be recordable, identifiable, and transferable. AIT’s technical form is therefore not “visualization of a concept,” but “digital carrying of rule outcomes.”

As a unified digital carrier, AIT also requires standardized carrier conventions. Unit standards, state expression, rule interfaces, and external identification should remain consistent. The more consistent the technical standards, the more stable the institutional boundaries; the more unified the technical expression, the lower the system’s trust cost.

AIT’s technical carrying requires more than deployment. It must include complete infrastructure for recording, holding, and transfer. Recording answers “does it exist?” Holding answers “to whom does it belong?” Transfer answers “how can it move?” Together, these form the minimum infrastructure requirements for AIT as a technical carrier.

As a digital carrier, AIT necessarily relies on contract structures and system interfaces to enter real operation. The role of those contracts and interfaces must remain limited to “carrying and execution” and must not be expanded into additional promises of outcome. They make the carrier operable, allow rules to be executed, and support technical continuity; they do not replace the system’s institutional boundaries.

A digital carrier intended to exist over the long term must not only be operable, but also verifiable, reviewable, and maintainable. A unit that cannot be verified is difficult to trust over time; one that cannot be reviewed cannot support institutional transparency; and one that cannot be maintained cannot be integrated into a real ecosystem.

AIT’s first ecosystem phase uses a standard BEP20 Genesis Token deployed on BNB Smart Chain. The current Genesis Token contract has a fixed supply of 21,600,000,000 AIT, issued once at deployment. It does not enable contract-level minting or additional issuance, does not use an upgradeable contract structure, and does not include a blacklist, transfer pause, buy/sell tax, or transfer tax.

Post-issuance rights-operation rules such as rights release, lock-up, entry-to-release, withdrawal, and node settlement are not embedded in the Genesis Token contract. They are handled by AIT system rules and designated functional wallets. The token contract is responsible for the existence, identification, and transfer of the on-chain carrier; it does not replace system-layer rights computation or operating rules.

15.7 Fixed Supply of the Current Genesis Token

The current AIT Genesis Token contract has a fixed supply of 21,600,000,000 AIT.

This total is not an isolated number. It is the common starting point for carrier finiteness, supply boundaries, and long-term structural expectations. If the carrier had no defined total supply, or if the supply definition could be changed arbitrarily, the carrying relationship would be difficult to sustain as a trusted long-term structure.

The fixed supply of the current Genesis Token therefore serves as the common upper limit, within the scope of this contract, for subsequent allocation, release, circulation, and supply management. The significance of the total supply is not to create a scarcity narrative, but to confirm that AIT as a carrier unit has a clear, verifiable supply boundary that cannot be arbitrarily expanded.

15.8 Initial Minting Mechanism: One-Time Minting

Once total supply is defined, AIT must also answer how that supply is initialized.

AIT Genesis Token uses a one-time initial minting mechanism to initialize its fixed supply of 21,600,000,000 AIT. The purpose is to establish the total carrier boundary in advance so that AIT’s complete supply structure exists from the outset rather than depending on continuing future minting to replenish supply.

It is important to emphasize that one-time initial minting does not mean that the entire supply enters circulation. Minting initializes the carrier units; it does not mean those units have entered holding, release, circulation, or trading states. Creation of the carrier and movement of the carrier into subsequent relationships under rules are separate stages that must be clearly distinguished.

For AIT, one-time initial minting therefore confirms the total supply boundary. Subsequent paths into allocation, release, and circulation remain strictly subject to the established rule structure.

15.9 Fixed Supply and No Additional Issuance of the Genesis Token

The current AIT Genesis Token contract has a fixed supply of 21,600,000,000 AIT. The contract does not enable minting or additional issuance, does not use an upgradeable contract, and contains no hidden technical path for additional issuance through the current contract.

When this White Paper refers to fixed supply and no additional issuance, it refers first to the on-chain supply fact of the current Genesis Token contract. Under the current contract and the applicable ecosystem phase, AIT does not respond to market sentiment, circulation pressure, or short-term expansion needs by increasing the supply of the current Genesis Token.

If AIT enters a new global ecosystem phase in the future and long-term carrying requirements arise beyond the applicable scope of the current genesis ecosystem allocation, any new ecosystem-expansion arrangement must not be implemented through hidden minting within the current Genesis Token contract. It must instead be addressed separately through independent governance, public disclosure, compliance review, holder-protection mechanisms, and a new technical implementation plan. Until such processes are formally completed, the on-chain supply of the current Genesis Token contract remains unchanged at 21,600,000,000 AIT.

15.10 Burning Mechanism

AIT has a rule-constrained burn-execution path. The current Genesis Token contract does not provide a general burn function. Where a burn is carried out under system rules, a designated functional wallet transfers the corresponding AIT to an irrecoverable address to complete the on-chain burn.

The irrecoverable address currently used under the technical standard is:

0x000000000000000000000000000000000000dEaD

Any burn should have a clearly identified source, amount, rule basis, and verifiable on-chain record. The burn mechanism serves system-rule execution and supply-state handling. It does not constitute repurchase, price support, market intervention, or a promise of market outcome.

15.11 Definitions of Issued Supply, Non-Circulating Supply, and Circulating Supply

AIT Genesis Token is issued once at deployment, but issued supply does not automatically constitute immediate circulation.

AIT allocated to ecosystem reserves, project-controlled functional wallets, locked structures, or portions that have not yet completed system release forms part of the current contract supply but does not automatically constitute actual circulating supply.

Under the current dual-layer operating structure, before a user completes withdrawal, the relevant rights, release eligibility, and withdrawal process are governed by AIT system rules. After withdrawal, when the corresponding AIT moves from the relevant project-controlled functional wallet to the user’s self-custodied external wallet, it enters a state in which the user can independently hold and transfer it under on-chain rules.

AIT’s circulating supply is therefore formed primarily through system-rule release followed by withdrawal and may also increase through liquidity deployment and other unlocked external distributions.

The following distinctions must always remain clear:

Issued supply ≠ actual circulating supply; allocated supply ≠ tradable supply; and AIT that remains unreleased or subject to lock-up does not constitute currently transferable supply.

In one sentence:

AIT’s issuance mechanism is not merely an arrangement for total supply and minting. It is an institutional structure through which AIT becomes a finite digital unit under a clearly defined carrier identity, supply boundary, and set of supply-state definitions.

AIT is first defined as a carrier and then initialized as a supply structure. Total supply boundaries come before allocation, release, and circulation. The purpose of the issuance mechanism is not to create market expectations, but to confirm the finiteness, carrying capacity, and sustainability of AIT as a value carrier.

Chapter 16 | Token Allocation Structure and Release Rules

After defining the AIT carrier and issuance mechanism, the Carrier Layer must answer an equally important question: how will these initialized carrier units be allocated, and under what rules will they enter subsequent release structures?

If Chapter 15 explains how AIT comes into existence and is issued as a carrier, this chapter explains who holds AIT, within what boundaries, what those holding relationships mean, and how different portions of the token structure enter lock-up, vesting, and release logic. The greatest risk of misinterpretation around allocation and release is not the percentages themselves, but the imagined returns, priorities, and outcome promises that may be inferred from them.

The purpose of this chapter is therefore not to expand external interpretations of the allocation structure, but to explain it institutionally: what AIT holding may provide and what it does not provide; how different holding relationships are formed; how different structural portions are locked, released, and moved into subsequent use relationships; and why all of these represent functional positions under rules rather than guarantees of any particular outcome.

16.1 Why Allocation Structure Must Be Defined Before Market Discussion

Once a digital carrier enters a supply structure, allocation must be addressed before market questions.

If allocation is not clearly defined, external observers will infer the meaning of the carrier from market outcomes. Allocation will then be interpreted through emotion, experience, and financial convention rather than through system definitions. Some may read it as a division of economic benefits, some as a pre-allocation of return rights, and others as an advance claim on future outcomes. Once these interpretations take hold, they can distort the Token’s functional position and undermine the system’s rule boundaries.

AIT must therefore define its allocation structure clearly—not to amplify “who gets how much benefit,” but to explain the scope within which holding and allocation have institutional meaning and the scope beyond which allocation does not automatically create any enforceable result obligation. AIT’s allocation structure cannot simply be treated as a division of rights under traditional finance; it must be defined by AIT’s own system logic.

16.2 AIT Holding Relationships and Functional Boundaries

Holding AIT has meaning within the AIT system, but that meaning is functional before it is outcome-based.

A functional boundary means that, to the extent expressly recognized by system rules, a holder may—by virtue of holding—enter certain holding, use, transfer, participation, or subsequent rule relationships. These relationships do not arise from external promises; they arise from the system’s institutional definition of the carrier unit.

For purposes of this section, “holding AIT” must be distinguished by state. Before a user completes withdrawal, the participant holds rights records, released outcomes, and corresponding withdrawal eligibility under system rules. Only after the relevant AIT is withdrawn to a user’s self-custodied wallet does a self-custodied holding and transfer relationship arise under on-chain rules.

More specifically, holding AIT has at least three foundational functions.

First, the holding relationship itself can be recognized by the system. AIT is not an anonymous concept, but a digital unit that can be recorded, identified, and placed into a clear holding state under the rules. The holder has a rule-recognized holding relationship and corresponding ability to dispose of the AIT held.

Second, a holding relationship can enter transfer and circulation relationships. Subject to applicable rules, scenarios, and technical conditions, a holder may transfer or circulate AIT held and may use it within the scope permitted by the system.

Third, a holding relationship may enter subsequent participation relationships. Some AIT functions do not end with “holding” itself, but may extend into use, participation, collaboration, or governance scenarios permitted by the system.

These functional relationships do not expand automatically merely because AIT is held. They remain subject to the system’s unified constraints on functional, usage, and participation boundaries. Holding AIT has institutional meaning because it can enter rules—not because holding itself inherently equals a result.

16.3 Functional Rights Associated with Holding AIT

Within the functional boundaries described above, the rights associated with holding AIT must also be clearly defined.

First, a holder has a rule-recognized right to hold the AIT in question. This is not a claim for returns against the project entity, but an institutional recognition of the carrier unit itself.

Second, subject to applicable rules, scenarios, and technical conditions, holders may enter transfer, circulation, use, and certain subsequent participation relationships. These rights arise from system rules, not from additional promises.

Holding AIT does not itself automatically create governance rights, collaboration rights, priority rights, or any other function not expressly granted by current rules. No right that has not been formally recognized may be inferred solely from the fact of holding.

In short, AIT corresponds to functional rights, not claims to an outcome. Its significance lies in entering the rules, not in escaping them.

16.4 Rights Not Granted Merely by Holding AIT

If the previous section answers “what may come with holding AIT,” this section must equally clearly answer what does not.

First, holding AIT does not automatically create a claim to income or return. A holder may not, merely by virtue of holding, require the project, a merchant, a node, or any third party to pay a fixed return, minimum return, return shortfall, or any form of price outcome.

Second, holding AIT does not automatically create membership rights, shareholder rights, or residual claims under corporate law. AIT is not a corporate equity certificate and does not by itself grant ownership, voting rights, dividend rights, or liquidation claims against any legal entity.

Third, holding AIT does not automatically create a debt claim. A holder may not, solely by holding AIT, claim principal repayment, maturity redemption, interest payment, debt settlement, or any other principal-and-interest obligation.

Nor does holding AIT automatically create special treatment outside system rules, such as additional release, governance priority, additional participation eligibility, or special arrangements. None of these may be inferred directly from the holding fact itself.

In other words, holding AIT is not a starting point from which unlimited rights can be extrapolated. It creates only a functional position recognized by the rules, not a proprietary claim to future outcomes.

16.5 Definitional Boundaries of Level 0 Investors and Level 1 Investors

Within AIT’s phased participation structure, Level 0 Investors and Level 1 Investors are distinguished not merely by time of entry, but by the maturity and validation status of the system at the time they enter.

A Level 0 Investor is an early participant who enters during the planning or early validation phase, before core carriers such as the website, system, and App are fully launched, and makes a support decision based on the project mechanism, institutional framework, team judgment, and development direction. Such a participant assumes uncertainty before product implementation and before commercial validation.

A Level 1 Investor is a phased participant who enters after the project’s core carriers have gone live, the system can demonstrate basic functionality, and certain operating or commercial results have begun to emerge. The decision is based mainly on a combined assessment of system completeness, operating status, and real-world validation, and the participant assumes uncertainty associated with expansion and development.

The distinction is therefore not simply “who came earlier,” but whether the participant entered while facing a system still in planning or a system already beginning to be validated in reality.

In one sentence: Level 0 Investors assume uncertainty before system implementation; Level 1 Investors assume uncertainty during system expansion.

These labels are used only to distinguish historically formed allocation categories within the project. They do not constitute a public offering arrangement, legal classification, confirmation of fixed returns, or promise of market outcome.

16.6 Proportion and Purpose of the Ecosystem Portion Pending Release

Within the current Genesis Token allocation structure, the Market Ecosystem portion is the principal structural component.

The current Genesis Token allocation is: Level 0 Investors 5%, Level 1 Investors 5%, Team & Technology 10%, Ecosystem Partners 5%, and Market Ecosystem 75%.

The 75% Market Ecosystem portion is the principal supply reserve for long-term system operation. Its purpose is not immediate circulation, but to serve as the supply reserve for subsequent value release, ecosystem incentives, and long-term operation. It represents structural space that the system may progressively release under established rules rather than supply that enters the market all at once.

Although the Market Ecosystem portion represents the majority of the current Genesis Token supply structure, inclusion in total supply does not automatically make it currently circulating. Its transition into subsequent states is handled separately through the Consumption Confirmation path, the 2% special path, and other formal rights rules. It serves long-term release and operating cadence rather than short-term market stimulation.

16.7 Allocation Structure for Team, Technology, Ecosystem Partners, and Investors

Apart from the Market Ecosystem portion, the remaining 25% of supply is allocated as follows: Level 0 Investors 5%, Level 1 Investors 5%, Team & Technology 10%, and Ecosystem Partners 5%.

The Level 0 and Level 1 Investor portions support early-stage funding and structural establishment; the Team & Technology portion supports system construction, technical development, ongoing maintenance, and core capabilities; and the Ecosystem Partners portion supports ecosystem coordination, external cooperation, and access to critical resources.

The existence of these categories does not change AIT’s underlying nature as a unified carrier. Their differences lie in acquisition path, purpose boundaries, and subsequent release cadence—not in a fundamental change of legal nature or result commitments. The allocation structure confirms an institutional attribution arrangement rather than a pre-allocation of market outcomes.

The purpose boundaries of each category must also remain clear: Investor portions must not be reallocated to Market Ecosystem release; Team & Technology portions must not be treated as a source of market-liquidity supplementation; and the Market Ecosystem portion must enter subsequent states under formal Consumption Confirmation rules, the 2% special rules, and the corresponding rights-carrying mechanism.

16.8 Lock-Up and Subsequent-State Rules

AIT lock-up, release, and withdrawal rules are not embedded in the Genesis Token contract. They are handled by AIT system rules and designated functional wallets.

AIT that has been allocated does not automatically enter a usable, withdrawable, or transferable state. Team & Technology, Investor allocations, Ecosystem Partners, and other restricted allocations remain subject to applicable vesting conditions, system-release rules, and withdrawal conditions before entering subsequent states.

The specific start date, vesting period, execution frequency, and proportions are governed by formally published allocation and vesting documents. Until those parameters are confirmed and disclosed, this White Paper does not make definitive statements regarding specific unlock periods, unlock percentages, or market effects.

16.9 Lock-Up Arrangements for Team, Investor Allocations, and Partners

Team & Technology, Level 0 Investors, Level 1 Investors, Ecosystem Partners, and other restricted allocations do not automatically obtain immediate circulation capability merely because they have been acquired or allocated.

Before such allocations enter usable, withdrawable, or transferable states, they must satisfy the applicable formal time-vesting arrangements and system-release rules. Acquisition paths may differ, but no holder category may bypass unified state constraints because of identity.

Specific vesting parameters and execution plans should be disclosed through formal allocation and vesting documents and remain consistent with on-chain functional-wallet records and actual distribution records.

16.10 How Rights Release Enters the AIT Carrier and Withdrawal Process

Rights release is a system-layer rule outcome within AIT. It is not equivalent to an on-chain transfer and is not equivalent to public-market circulation.

Before a user completes withdrawal, the relevant rights, release eligibility, and withdrawal process are governed by AIT system rules. Once the user satisfies the applicable rules and completes withdrawal, the corresponding AIT is transferred from a project-controlled functional wallet to the user’s self-custodied external wallet.

Rights release, AIT carrier representation, and user withdrawal are therefore three sequential but distinct states. Rights release answers whether the rule outcome has been formed; AIT carrier representation answers which digital carrier records that outcome; and withdrawal answers when the relevant AIT enters the user’s self-custodied holding state.

Release ≠ withdrawal. Withdrawal ≠ sale. Entry into a self-custodied wallet does not constitute any promise of price or market outcome.

In one sentence:

AIT’s allocation structure and release rules are institutional arrangements governing how different supply portions are attributed, locked, unlocked, and moved into subsequent use relationships; they do not automatically create promises of income, price, or any other outcome.

Allocation answers who holds and within what boundaries; release answers when those holding relationships enter subsequent states. Together they determine how carrier units move from a supply structure into a use structure, but both remain subject to rule boundaries and must not be misread as pre-allocation of outcomes.

Chapter 17 | Circulation Mechanisms and Supply–Demand Structure

After defining the carrier, issuance mechanism, allocation, and release rules, the Carrier Layer must address another practical question: how do AIT units that have been allocated, locked, released, and progressively moved into subsequent relationships form an actual circulation structure?

If the previous two chapters answer “how AIT is established and supplied” and “how that supply is attributed and enters release logic,” this chapter asks how AIT enters circulation, what quantities may enter circulation, how the circulation interfaces differ across participant types, and how supply and demand form structural relationships through this process.

This is critical because a digital carrier does not automatically become circulating simply because it has been issued or allocated. Actual circulation must rest on clear definitions, defined entry paths, rule-constrained state changes, and boundaries among different use scenarios. Otherwise, “total supply,” “allocated amount,” “existing amount,” and “transferable amount” may be conflated, leading the market to form judgments on the basis of incorrect supply assumptions.

This chapter therefore does not discuss price forecasts or investment returns. It addresses a more foundational issue: how AIT circulation is institutionally defined, and how that definition interacts with demand to form a supply–demand structure.

17.1 Definition of Transferable Supply

Circulatable supply means AIT that has completed the applicable system-state transitions and entered user self-custodied wallets, liquidity-deployment addresses, or other unlocked external distribution addresses, and is currently transferable under on-chain rules.

For AIT, transferable supply is not equal to total supply and is not automatically equal to issued or allocated supply. It refers only to the quantity that, under current rules, current state, and current technical conditions, can enter transfer, exchange, market circulation, or ecosystem-use relationships.

The purpose of defining transferable supply is therefore not to describe “how much exists,” but to identify “how much currently has circulation eligibility.” Only once this definition is clear can later discussion of circulation paths, market relationships, and supply–demand structure remain meaningful. Only AIT that satisfies all three conditions—released state, rule permission, and technical executability—constitutes currently transferable supply.

17.2 Distinguishing Non-Circulating, Locked, and Pending-Release Supply

Non-circulating supply is supply that forms part of the overall supply structure but does not, in its current state, enter market or ecosystem circulation. Locked supply is supply that has been allocated but remains subject to time, conditions, or rules and has not yet exited the locked state. Pending-release supply forms part of an established structural arrangement but has not yet entered a holding, use, or circulation state under the applicable release logic.

These distinctions are not a matter of terminology alone; they are a basic requirement of circulation transparency. For AIT, the following must remain especially clear: issued supply ≠ circulating supply; allocated supply ≠ tradable supply; pending-release supply ≠ currently transferable supply. These distinctions are prerequisites of a meaningful circulation mechanism. Without them, structural existence can be misread as immediate supply and long-term release can be misread as current sell pressure, distorting the overall understanding of the carrier’s circulation state.

Ecosystem reserves, balances in project-controlled functional wallets, locked structures, and AIT that remains unreleased or has not completed withdrawal are not automatically included in actual circulating supply merely because they have been issued or assigned a purpose.

17.3 How System Release and Withdrawal Form Circulation

AIT’s circulation structure is directly connected to the rights-release logic established earlier.

Some AIT therefore does not enter circulation automatically when it is initialized or allocated. Instead, under established rules, it progressively enters usable, transferable, or withdrawable states as the rights-release process advances. Release is one important prerequisite for circulation, but release itself does not automatically equal circulation, sale, or any price outcome.

Under established rules, rights release first forms an internal system outcome and is carried by the corresponding AIT carrier. Only after the applicable withdrawal or other external-transfer conditions are further satisfied does the related AIT enter an on-chain transferable state. Release is a prerequisite for certain subsequent states, but release itself is not equivalent to withdrawal, market sale, or a price outcome.

Rights release, AIT carrier representation, and user withdrawal are therefore three sequential but distinct states: rights release answers whether the rule outcome exists; AIT carrier representation answers how that outcome is recorded by the digital carrier; and withdrawal answers when the relevant AIT enters the user’s self-custodied holding and transfer state.

17.4 How Restricted Allocations Enter Circulation

Before Team, Investor, Partner, and other restricted allocations enter actual circulation, they must progress through the applicable vesting arrangements, system-release rules, withdrawal conditions, and external-transfer conditions.

Satisfaction of a vesting condition only means that the relevant allocation has completed the corresponding time or identity restriction. It does not automatically mean that system release, withdrawal, or external transfer has occurred. Only after all applicable conditions are satisfied may the corresponding AIT enter actual circulation.

Specific vesting methods, execution periods, proportions, and frequencies are governed by formal allocation and vesting documents. No allocation forms actual circulating supply merely because allocation has been completed or a single time condition has been reached.

Where formal parameters have not yet been disclosed, this White Paper does not predefine linear unlock percentages, completion deadlines, or the effectiveness of market-impact controls.

17.5 Circulation Differences Among Users, Merchants, and Nodes

Although AIT enters the same rule system as a unified digital carrier, the circulation interfaces associated with different types of holders are not entirely identical.

For users, AIT circulation is usually linked directly to holding, use, transfer, or subsequent participation relationships, and therefore appears mainly through individual holding and use paths.

For merchants, the significance of AIT circulation is more often expressed through usage interfaces within ecosystem-collaboration relationships. Holding AIT does not make a merchant an issuer or a controller of price, and the merchant’s circulation interface remains subject to unified rules.

For nodes or collaboration parties, the circulation interface may relate to collaborative responsibilities, degree of participation, or system-identity arrangements. These differences concern only the path and do not change AIT’s underlying nature as a unified carrier.

Differences among participant types primarily appear in system-layer acquisition, release, withdrawal, and use paths. Once AIT enters an external self-custodied wallet, its on-chain holding and transfer are governed by the same Genesis Token contract rules, without different contract-level transfer permissions based on whether the holder is a user, merchant, or node.

17.6 Distinguishing Ecosystem Circulation from Public-Market Circulation

AIT’s circulation structure must also distinguish ecosystem circulation from public-market circulation.

Ecosystem circulation refers to movement of AIT within system relationships involving holding, use, collaboration, transfer, and rules. Public-market circulation refers to transfer and exchange in a more open trading environment.

Both are forms of circulation, but their logic is different. Ecosystem circulation emphasizes usage and rule relationships; public-market circulation emphasizes exchange relationships and external supply–demand conditions. Without this distinction, ecosystem use may be misread as market trading, or market circulation may be misread as a system promise.

17.7 Demand-Side Effects of New Users, Existing Users, and Merchant Expansion

Circulation structure is not determined by supply alone; it is also affected by changes on the demand side.

For AIT, the entry of new users, continued participation by existing users, and expansion of merchant scenarios may increase ecosystem-use interfaces and potential usage demand for AIT. That does not automatically mean actual demand, market liquidity, or price outcomes will increase in parallel. Those results still depend on real-world adoption, participant willingness to use AIT, market conditions, circulation conditions, and other external factors.

If potential usage demand forms, it should arise from expansion of real participation scenarios and rule relationships rather than from system promises regarding price or outcome. Broader use and collaboration paths mean only that conditions for use may increase; they do not mean that actual demand scale, market liquidity, or price results have already formed.

17.8 Dual Paths: Public-Market Circulation and Ecosystem Use

In real operation, AIT may form a public-market circulation path and may also form an ecosystem-use path.

Ecosystem use and public-market circulation have different functions and boundaries. Public-market circulation applies only where the corresponding technical, compliance, and market conditions are available. Exchange listing, trading depth, and continued liquidity are not outcomes guaranteed by this White Paper.

AIT may establish an ecosystem-use path and may, where external conditions permit, also establish a public-market circulation path. The two do not need to exist simultaneously, and neither path is guaranteed to arise or continue.

17.9 Natural Formation of Market Supply and Demand

Only after the circulation paths described above have been defined does it become meaningful to discuss AIT’s supply–demand structure.

On the supply side, the relevant question is which quantities have circulation eligibility. On the demand side, it is which participants are forming holding, usage, collaboration, or exchange demand. This supply–demand structure should be understood as a naturally forming mechanism rather than an outcome promised by the system.

In other words, the system can define rule boundaries, supply definitions, and circulation paths, but it cannot directly define market price. If market price changes, that is an outcome of supply–demand interaction, not a result the system itself undertakes to deliver.

17.10 Boundary Between System Release and Market Price Behavior

This chapter must conclude with a clear boundary: system release and market price behavior are not the same thing.

System release changes internal rights outcomes and carrier states. Actual on-chain circulation still requires withdrawal or other applicable external-transfer conditions. Market price behavior is an external outcome of supply–demand interaction. The former belongs to the rule structure; the latter belongs to the market structure. If the two are conflated, rule changes can be misread as price promises and circulation eligibility can be misread as a return guarantee.

AIT must therefore maintain the following distinction: the system may define release and circulation paths, but it cannot define price outcomes; the system may explain supply boundaries, but it cannot replace the market’s external expression of value. Separation of the two is a foundation for the Carrier Layer to remain neutral over the long term.

In one sentence:

AIT’s circulation mechanism and supply–demand structure institutionally define which quantities may enter circulation, how they enter, and through which paths supply and demand meet; they are not a promise of any market-price outcome.

Circulation answers how states transform, how paths form, and how supply and demand meet. It may affect market structure, but it does not mean the system is responsible for market outcomes.

Chapter 18 | Risk Control and Structural Stability

AIT’s carrier structure must not only be definable, issuable, allocable, and capable of entering circulation; it must also remain structurally stable over the long term.

This chapter therefore focuses on token-level risk control and structural-stability mechanisms. It asks a deeper question: under a fixed current Genesis Token supply, a clearly defined allocation structure, and transparent circulation states, how can AIT reduce the risk of structural distortion caused by supply shocks, concentrated holdings, unlock imbalance, short-term speculation, or external misinterpretation? For AIT, “stability” does not mean maintaining a particular price range or creating superficial calm through project intervention. It means keeping the carrier unit aligned over time with its established supply boundary, release cadence, circulation definitions, and rule neutrality.

18.1 Why the Carrier Layer Must Embed Stability by Design

A digital carrier intended to exist over the long term cannot rely on market sentiment, external narratives, or temporary intervention for stability. Basic structural-stability mechanisms must be embedded in the Carrier Layer itself.

For AIT, stability does not mean maintaining a particular price range. It means reducing the risk that supply boundaries, release cadence, circulation paths, or holding structures drift materially away from the system’s design. If stability depends only on external confidence, the system becomes driven by its environment; if it depends only on temporary project actions, the carrier shifts from a rule-based structure toward subjective management.

The Carrier Layer should therefore incorporate stability into the supply structure from the beginning: Is total supply clear? Is allocation disciplined? Is lock-up defined? Is transition into subsequent states paced? Are circulation definitions transparent? Can release paths be explained? If these issues are not addressed at the Carrier Layer, later discussion of markets, circulation, and expansion lacks a reliable foundation.

18.2 Concentrated-Holding Risk and Constraint Principles

AIT’s allocation and release structure should seek to reduce the ability of a small number of parties to obtain excessive concentrated control within a short period.

Concentrated-holding risk does not only create price risk; it can also create governance, circulation, and external-perception risks. If a small number of parties acquire excessive control in a short period, outsiders may interpret them as potential sources of sell pressure, rule intervention, or pre-claimed outcomes, weakening confidence in the carrier structure.

Controls on concentrated-holding risk should combine allocation ratios, identification of functional wallets, applicable vesting conditions, system-release rules, on-chain data disclosure, and monitoring of anomalous transfers. Allocation percentages indicate the distribution of intended uses; they do not, by themselves, prove that final holdings are dispersed.

These arrangements may reduce the risk that restricted allocations enter circulation at a single point in time, but they must not be described as eliminating concentrated-holding risk, market volatility, or supply shocks.

18.3 Vesting Cadence and State-Transition Control

The vesting conditions of restricted allocations must be distinguished clearly from their circulation state. Satisfaction of a time or vesting condition means only that the allocation has completed the corresponding stage; it does not automatically mean that system release, withdrawal, or external transfer has occurred.

Team, Investor, Partner, and other restricted allocations entering subsequent states must comply with formal vesting arrangements, system-release rules, and actual execution conditions.

These arrangements are intended to reduce the risk that restricted allocations form concentrated transferable supply merely because a single condition is satisfied. Their actual effect depends on formal parameters, on-chain execution, and market conditions and does not guarantee the absence of supply shocks, market volatility, or price outcomes.

18.4 Supply-Shock Prevention Mechanisms

AIT’s structural stability also depends on whether it has basic mechanisms for reducing supply shocks.

Supply shocks can arise not only from changes in total supply, but also from misinterpretation of supply definitions, overly concentrated state transitions, or imbalanced release structures. For AIT, supply-shock prevention primarily relies on three categories of measures.

First, definition separation. Total supply, issued supply, allocated supply, pending-release supply, locked supply, and transferable supply must be clearly distinguished so that structural existence is not misread as immediate market supply.

Second, state layering. AIT supply does not enter circulation in a single step; it progresses through layers of “allocation—release—circulation.” Initialized quantity is not automatically allocated quantity; allocated quantity is not automatically released quantity; and released rights outcomes are not automatically actual circulating supply.

Third, phased entry of restricted allocations. Team, Investor, Partner, and other restricted allocations enter subsequent states subject to formal vesting arrangements, system-release rules, and applicable external-transfer conditions, reducing the risk that satisfaction of a single condition is immediately counted as actual circulation.

AIT’s supply-shock prevention is therefore fundamentally based on clear definitions, layered states, constraints on restricted allocations, and verifiable disclosure, reducing the risk that structural existence is misread as immediate market supply. These are risk-prevention principles and do not constitute a guarantee that the system can eliminate supply shocks or control market outcomes.

18.5 Effect of Action Value on Ecosystem-Usage Cadence

Although Action Value belongs to the energy structure of the Model Layer and Operational Layer, it may indirectly affect ecosystem-usage cadence in the Carrier Layer.

Certain system use, participation, and trigger behaviors are subject to Action Value as a system-energy constraint. This can affect the execution frequency of active behavior within the system and may indirectly affect the density of AIT use within the ecosystem.

Action Value does not directly restrict on-chain transfers after AIT has entered a user’s self-custodied wallet, nor does it operate as a control mechanism for public-market trading, circulating supply, or price behavior. Its effect in the Carrier Layer must therefore be understood as an indirect effect on ecosystem usage, not direct regulation of external market circulation.

18.6 Special Boundaries of the Referral and Check-In Mechanisms

AIT explicitly includes referral and check-in mechanisms, and these behaviors occupy a special position among ecosystem behaviors.

Of the fixed supply of the current Genesis Token, 75% is allocated to the Market Ecosystem, of which 73% is for the Consumption Confirmation path and 2% for the check-in and referral paths. These percentages are allocations within the established supply; they are not Equity Coefficients, release rates, or user-return ratios.

Consumption Confirmation is the core path for Contribution Value formation and rights computation. Check-ins and referrals do not generate Contribution Value and do not create new supply outside the system. Any special rights outcomes they form can only be carried under rules within the predefined 2% reserve.

Check-in simultaneously functions as an active system behavior, an Action Value consumption event, and a trigger for daily rights release. Any special rights outcome formed within the 2% reserve must be calculated separately from check-in’s triggering effect on existing rights release and must not be conflated with it.

Referral is an active system behavior, and any special rights outcome it may form is likewise subject to the overall 2% reserve boundary and specific formal rules. Check-ins and referrals may not exceed the predefined supply boundary and may not be supplemented through additional issuance.

18.7 Structural Balance Between Circulation and the Operational Layer

The circulation structure of the Carrier Layer does not exist in isolation from the Operational Layer.

Changes in real spending, participation density, merchant scenarios, or collaboration relationships in the Operational Layer may affect circulation structure. Conversely, imbalances in circulation paths, lock-up cadence, or supply definitions may feed back into Operational Layer stability. A basic structural balance should therefore be maintained between circulation and operation.

This means the Carrier Layer should not design an “ideal circulation” structure independently of real operating scenarios, and the Operational Layer should not expand participation density without regard to carrier supply boundaries. AIT seeks to keep real consumption scenarios, behavioral constraints, release paths, and circulation eligibility reasonably aligned so that the system does not split into situations such as “high activity but structural distortion” or “clear supply but insufficient scenario capacity.”

18.8 Information Disclosure and Structural Transparency in the Carrier Layer

Structural stability arises not only from mechanisms, but also from clear information disclosure.

At a minimum, AIT’s Carrier Layer should continue to disclose clearly: total-supply definitions, allocation structure, lock-up arrangements, release paths, circulation definitions, boundaries of the burning mechanism, and scope of application. Only when these core matters are clear can external observers accurately distinguish structural existence, subsequent states, and true circulation eligibility.

These disclosures should not rely on a single document. They should be formed collectively by the White Paper, formal technical documents, contract descriptions, and subsequent governance documents, while maintaining consistent terminology and definitions. Any material change involving total-supply definitions, allocation structure, lock-up arrangements, release paths, circulation definitions, or burn boundaries should be reflected in the relevant disclosures.

Such disclosure is not merely formal transparency; it is part of structural stability. The most common misunderstanding in the Carrier Layer is often not a failure of the mechanism itself, but an external misreading of “total supply” as “immediate supply,” “allocated supply” as “tradable supply,” or a “release path” as a “price promise.”

For AIT, transparency is therefore part of risk control. By continuously presenting supply boundaries, state layers, and circulation eligibility clearly, it reduces structural misunderstanding. Disclosure should also, to the extent practicable, have a verifiable, traceable, and reviewable basis. Only when total-supply definitions, circulation states, lock-up boundaries, and key rule changes can be continuously verified externally does transparency move beyond an unverifiable narrative and become an institutional condition capable of supporting trust.

18.9 Long-Term Stability Before Short-Term Liquidity Stimulation

This chapter must conclude with one overarching principle: for AIT, long-term stability takes priority over short-term liquidity stimulation.

If an arrangement can generate greater short-term attention but damages supply boundaries, release cadence, holding structure, or system neutrality, it should not be prioritized. The Carrier Layer exists to support long-term system continuity, not short-term price performance.

This means many AIT design choices in the Carrier Layer should favor restraint over amplification and sustainability over short-term excitement. Once the carrier structure begins sacrificing total-supply boundaries, allocation discipline, circulation transparency, or rule neutrality in pursuit of localized liquidity, the likely exchange is short-term stimulation for long-term structural depletion. AIT seeks to preserve not temporary trading heat, but a stable carrier structure capable of being continuously supported by real spending, genuine participation, and long-term rules. AIT’s structural stability does not depend on the project providing price support for market price, liquidity, or trading depth.

Ultimately, Chapter 18 is not about “how to make the market hotter,” but “how to keep the carrier from becoming distorted”; not “how to manage price performance,” but “how to preserve supply boundaries, release discipline, circulation definitions, and rule neutrality.” This is why the Carrier Layer must exist and why it is a core condition for AIT to remain viable over the long term.

In one sentence:

AIT’s long-term stability relies on Genesis Token supply boundaries, state constraints, and transparency mechanisms—not market intervention.

AIT’s risk control and structural stability do not depend on active intervention in market outcomes. They depend on a long-term stability structure formed by the supply boundaries of the current Genesis Token, allocation constraints, vesting and state-transition cadence, circulation definitions, and structural transparency. Stability in the Carrier Layer is not intended to control price, but to reduce the risk that supply imbalance, structural distortion, or ambiguous boundaries cause AIT to deviate from its defined carrier role.

—————————————————————————————————————————————————— Action-based Intelligent Tokenization - Spend to Rights - Marketing to Assets

AIT = Action-based Intelligent Tokenization

An Intelligent Behavior-Based Value Mapping System

Spend to Rights — Marketing to Assets

Chapter 19 | AIT System Boundaries: What It Is—and What It Is Not

This chapter answers a foundational question: as an overall system, what is AIT by nature, what can it do, and what falls outside its defined attributes?

19.1 Why Any Long-Term System Must Define Its Boundaries First

Any system that intends to exist over the long term must first answer not “what can I do?” but “what do I not undertake?” System distortion often begins not with a defect in the mechanism, but with ambiguity in boundaries.

A system without boundary definitions may absorb more imagination at an early stage, but what it ultimately absorbs is often not capability, but ever-expanding responsibility. Users may treat participation as a claim on outcomes; markets may treat structure as a price promise; and partners may treat access as a guarantee. What is ultimately consumed is not a mechanism detail but institutional credibility.

Boundaries are therefore not a subtraction from the system; they protect system stability. Defining boundaries first does not shrink the system. It prevents the system from being amplified without limit by external narratives.

19.2 AIT Is a Behavioral Value-Computation System, Not an Outcome-Promise System

AIT’s core task is to identify, record, map, and continuously compute value inputs formed by real behavior. It creates a rule system through which behavioral value that would otherwise be consumed immediately in traditional consumption relationships can enter a computable, carryable, and sustainable institutional structure.

Value computation, however, is not an outcome promise. AIT can explain how value is identified by the system and institutionally carried forward; it cannot promise the market outcome in which that value will ultimately be expressed, and it cannot treat the rules themselves as a preset return outcome.

19.3 AIT Is a Participation Structure, Not a Return-Distribution Structure

Within AIT, users, merchants, nodes, and other collaboration parties enter a participation structure. Participation means providing real input under established rules, accepting rule constraints, forming records, and obtaining a corresponding position within the institutional structure.

If the participation structure is misread as a return-distribution structure, the nature of the system begins to drift. Participation is based on behavior, rules, and responsibility; distribution is based on outcomes, ratios, and expectations. AIT’s significance lies in bringing real behavior into a continuing rule system, not in automatically turning everyone who enters the structure into a claimant on outcomes.

19.4 AIT Is a Rule-Attachment Layer, Not a Payment-Clearing Layer

AIT does not depend for its existence on replacing existing payment systems, settlement networks, or clearing structures. It does not perform payment clearing and is not responsible for completion of payment, account settlement, or financial clearing in real commercial transactions.

AIT attaches a rule structure to the transaction and behavior facts that exist after payment and transaction completion. It does not replace the payment layer. It is a rule-attachment layer rather than a funds-clearing layer; a value-carrying structure rather than the payment channel itself.

19.5 AIT’s Design Positioning and Legal-Characterization Boundaries

AIT’s institutional design is intended to carry digital rights relationships formed through real behavior, rule-based computation, and system release. Its core purpose is not to promise investment income, fixed returns, maturity redemption, or price outcomes.

AIT and related issuance, allocation, holding, use, and circulation arrangements may be subject to different legal and regulatory requirements across jurisdictions. Their specific legal characterization must be assessed in light of the applicable jurisdiction, actual functionality, issuance and sale methods, external communications, relationships among parties, and real operating circumstances. It cannot be determined solely by project name, technical form, or self-description in this White Paper.

Accordingly, the descriptions of AIT’s functions and design objectives in this White Paper do not constitute a final determination of legal characterization in any jurisdiction. Where registration, licensing, disclosure, participation restrictions, or other compliance obligations are required by law, applicable law, regulatory requirements, and formal legal documents shall govern.

19.6 AIT Does Not Replace Merchant Operations, Platform Business, the Judiciary, or Regulators

AIT’s institutional functions have clear boundaries. It does not replace merchants’ business judgment, platform business organization, or the judicial and regulatory authority of external legal systems.

No matter how complete AIT becomes, it remains a rule system attached to real commerce and the institutional world. It may carry certain value relationships formed through real behavior, but it cannot expand into a total system that replaces real-world business operations, real governance, or the external legal order.

19.7 AIT Is Not Designed Around Investment Returns, Price Support, or Price Management

To prevent mischaracterization, AIT’s institutional design is not premised on promises to holders of fixed returns, minimum returns, repurchase, redemption, price stabilization, or exit protection, and it does not treat control of price trends, trading depth, or market volatility as a system objective. Whether AIT constitutes a regulated product or activity under a particular jurisdiction, issuance method, or trading arrangement must be determined under applicable law and actual circumstances, not merely by name or by statements in this White Paper.

These “design-boundary statements” are not supplementary disclaimers. They form part of AIT’s core definition. In real-world communication, the greatest risk of misinterpretation often comes not from mechanisms already stated clearly, but from roles that markets, users, or partners wish to impose on the system. If those roles are not proactively excluded, external expectations may progressively rewrite the system.

Explaining “what AIT is not” therefore does not diminish AIT’s value. It protects its identity from being reconstructed by external narratives.

19.8 Why Clearly Stating “What AIT Is Not” Matters More Than Expanding “What It Is”

For a long-term system, expanding the range of interpretations is generally easier than narrowing it, and absorbing more imagination is often more appealing to external expectations than drawing boundaries. But what determines whether a system can remain stable over the long term is not how many broad expectations it initially accepts, but whether it can reject responsibilities and roles that do not belong to it.

Explaining “what it is” helps outsiders understand the system; explaining “what it is not” prevents misuse. For AIT, only after it is clear about what it does not undertake can the institutional responsibilities it truly does undertake become stable, credible, and sustainable.

In one sentence:

AIT’s first boundary is not how much it can do, but what it expressly does not undertake.

AIT’s identity is therefore not defined by external expectations, but by the capability boundaries, responsibility boundaries, and non-attribute boundaries that it explicitly defines for itself.

Chapter 20 | AIT Responsibility Boundaries: Who Is Responsible for What—and Who Is Not

This chapter explains what responsibilities different parties within AIT bear and where those responsibilities end.

The Operational Layer previously identified the relevant roles. The Boundary Layer now formalizes where the responsibilities of those roles end.

20.1 Why Responsibility Boundaries Are a Prerequisite for System Stability

A system may be complex, roles may be diverse, and paths may be layered. But when responsibility boundaries are unclear, complexity eventually collapses into blame shifting or uncontrolled expansion of responsibility. A long-term system remains stable not because every party bears the same obligations, but because each party bears responsibilities that match its capabilities, authority, and role.

The purpose of responsibility boundaries is not to reduce responsibility, but to align responsibility with actual capability, scope of control, role authority, and applicable law. The project is responsible for matters it actually designs, controls, maintains, or manages, including functional wallets and disclosure, and for other duties arising under law or agreement. Users are responsible for genuine participation, compliance with rules, and independent decision-making. Merchants are responsible for real transactions, fulfillment of goods or services, and related commercial obligations. Nodes and collaboration parties are responsible for their specific collaborative duties. Relevant technical-responsibility parties are responsible, under law and contract, for system execution, security, permissions, and maintenance within their actual control.

When responsibility boundaries become blurred, the system begins to absorb outcomes it was never designed to undertake: project parties may be expected to answer for price volatility; merchant participation may be misread as price support; participation may be misread as a claim to returns; and technical execution may be exaggerated into an outcome guarantee. Distorted responsibility materially increases the risk of structural distortion.

20.2 Project Responsibilities: Rule Design, System Maintenance, and Information Disclosure

Within AIT, the project bears responsibilities for rule design, system maintenance, and institutional explanation. The project is responsible for ensuring that system rules can be defined, executed, and continuously maintained, and for clearly disclosing important changes, core boundaries, and institutional principles.

The project’s responsibilities first include establishing and maintaining AIT’s institutional framework, including parameter logic, operating principles, boundary statements, version iteration, and overall consistency. Second, the project is responsible for maintaining basic technical, organizational, and informational sustainability so that the system can preserve continuity and reviewability of its rules over time. Third, the project must explain system boundaries externally rather than allowing market, marketing, or speculative language to redefine AIT.

The project does not guarantee AIT market price, holder returns, external liquidity, or individual market outcomes. Its responsibilities, however, are not limited to abstract rule design and institutional explanation. For system design, technical maintenance, functional-wallet management, information disclosure, compliance execution, and material rule changes actually controlled or undertaken by the project, the project remains responsible under applicable law and agreement.

The absence of outcome guarantees described above does not exempt any party from liability for illegality, intentional misconduct or gross negligence, misrepresentation, material omission, technical or security responsibility, or failure to perform mandatory legal obligations.

20.3 User Responsibilities: Genuine Participation, Rule Compliance, and Independent Decision-Making

Users are foundational system participants. Their responsibility is not to support the entire system or to bear responsibility for market outcomes. It is to ensure that the behavior they submit to the system is genuine and verifiable, to comply with established rules in the course of participation, and to independently bear responsibility for their own judgment and choices.

Users are first responsible for the authenticity of their own behavior. Fabricated, falsified, circular, or manipulative participation does not constitute valid input recognized by the system. Users are also responsible for rule compliance: they must participate through rule-permitted paths rather than replacing institutional constraints with subjective expectations. Finally, users are responsible for their own decisions. Entering the system does not mean outsourcing personal judgment to the project, the market, or any other party.

The user boundary is therefore clear: users are participants, not recipients of guaranteed outcomes; they are providers of behavioral input under rules, not claimants against a system debt.

20.4 Merchant Responsibilities: Real Transactions, Valid Fulfillment, and Scenario Access

The merchant’s role in AIT is to provide real transaction scenarios and fulfill the relevant commercial obligations. Merchants are responsible for the goods or services they provide, transaction authenticity, and fulfillment capability, and—where connected to AIT—for enabling real spending behavior to enter the scope recognized by the rules.

Merchant responsibilities are real, specific, and commercial. They arise from real commercial relationships, not from system outcome obligations. Merchants are responsible for whether the transaction is genuine, whether the service occurred, and whether fulfillment was completed—not for system price, market volatility, or participant returns.

A merchant’s connection to AIT means only that its scenario is included within a rule-based carrying structure. It does not thereby become an issuer, repurchaser, price-support provider, price stabilizer, or guarantor of returns. If merchants are mischaracterized as outcome guarantors, the meaning of commercial access is distorted and the system’s responsibility structure is undermined.

20.5 Responsibility Boundaries of Nodes and Collaboration Parties: Collaborative Duties, Not Outcome Guarantees

Within AIT operations, nodes and collaboration parties may undertake technical support, scenario coordination, operational collaboration, governance support, or other organizational responsibilities. These responsibilities are functional collaboration, not outcome guarantees.

Nodes and collaboration parties are responsible for completing the specific tasks they are authorized or engaged to perform and for the quality of their execution. Participation in system collaboration does not automatically make them responsible for overall outcomes, nor does performing a supporting role in one part of the system expand their role into price maintenance, return protection, or market commitments.

This distinction is necessary because once collaboration is interpreted by the market as a guarantee relationship, nodes may be forced to bear responsibilities they neither have the capability nor institutional authority to assume. AIT must be clear: collaboration is collaboration; a guarantee is a guarantee. The two are not interchangeable.

20.6 Responsibility Boundaries of the Technical System: Execute Rules, Do Not Guarantee Market Outcomes

The technical system bears execution responsibilities rather than outcome responsibilities. It implements rules programmatically, records, identifies, processes, and computes rule-governed matters, and maintains consistency and continuity of execution logic.

The technical system does not guarantee market outcomes, does not promise price outcomes, and does not automatically convert participation paths into external results. Its responsibility is to execute rules as defined, not to satisfy external expectations as desired.

The technical system’s function is to complete recording, identification, processing, and computation under established rules—not to guarantee market price, liquidity, or external outcomes for participants. The fact that technology does not guarantee market outcomes does not exempt relevant responsible parties from duties under law or contract relating to erroneous system execution, security vulnerabilities, data processing, permission management, or ongoing maintenance.

The technical system must therefore neither be mythologized as an outcome-guarantee tool nor used as a responsibility-isolation device. Technical execution boundaries and technical responsibility boundaries must exist together.

20.7 Reverse Clarification of Responsibility Boundaries: What Each Party Does Not Undertake and Should Not Be Expected to Undertake

To prevent responsibility from expanding in reverse, the system must also state what each party does not undertake. The project does not undertake responsibility for price, returns, liquidity, or individual outcomes. Users do not acquire outcome claims beyond the rules themselves. Merchants do not undertake repurchase, price support, price stabilization, or return-guarantee obligations. Nodes and collaboration parties do not guarantee overall outcomes. The technical system does not guarantee market performance or external trading results.

This reverse clarification is not intended to evade responsibility. Its purpose is to prevent external expectations from reallocating responsibility through communication, emotion, or market language.

These exclusions apply only to market outcomes, return outcomes, and other non-promised results. They do not exclude liability arising from a party’s own unlawful conduct, breach of contract, fault, misrepresentation, or failure to perform mandatory legal obligations.

20.8 How Responsibility Overreach Causes System Distortion

Responsibility overreach often does not arise directly from institutional text, but through gradual narrative slippage. If the project hints at price outcomes, it shifts from rule designer toward outcome guarantor. If merchants are portrayed as price support, they shift from scenario providers toward support parties. If users interpret participation as a claim to returns, they shift from rule participants toward outcome creditors. If the technical system is described as capable of stabilizing every result, it shifts from execution infrastructure toward mythology.

Once such overreach occurs, the system is no longer understood through its original rules but is rewritten by external expectations. The first thing to collapse is not price, but the order of responsibility; the first thing to become distorted is not an outcome, but the definition of roles. Once responsibility crosses its boundary, the system is no longer the system originally designed.

In one sentence:

AIT’s responsibility boundaries do not evade responsibility; they prevent the system from assuming outcome obligations that do not belong to it.

Responsibility becomes meaningful only when its boundaries are clear. If responsibility expands without limit, what is ultimately damaged is not a single party but the institutional structure itself.

Chapter 21 | AIT Market Boundaries: Separation Between System Computation and Market Behavior

This chapter explains how AIT must be clearly separated from market price, liquidity, and secondary trading.

21.1 Why System Value and Market Price Must Be Distinguished

AIT defines internal value-computation rules; the market forms price outcomes through external transactions. The two may interact in reality, but they must not be institutionally conflated. Value is the system’s rule-based treatment of behavioral input; price is the market’s external pricing of the relevant unit. The former arises from rules; the latter results from supply and demand, expectations, sentiment, environment, liquidity, and other factors.

If value and price are directly equated, the system can be misread from a “rule structure” into a “price machine.” Any explanation of value computation may then be heard as a price signal; any discussion of system operation may be interpreted as market guidance; and any design of a carrying structure may be rewritten by external expectations into an investment-return narrative.

The Boundary Layer must therefore separate the two. System value may be defined; market price may not be predetermined. Value computation may continue, while price outcomes must remain for the market itself to form.

21.2 Value Computation Does Not Equal Price Appreciation

One of AIT’s core risks of misinterpretation is that outsiders may directly translate “value is computed by the system” into “price will therefore rise.” That inference may sound intuitive, but it crosses the most important boundary between the system and the market.

Value computation explains how the system identifies, records, and carries value relationships formed through real behavior. Price appreciation is a market response to the relevant unit under specific time, environmental, supply, and demand conditions. The former is an institutional process; the latter is a market outcome. The institutional process may continue steadily, while the market outcome remains uncertain.

AIT may therefore insist on the integrity of value computation, but it cannot extrapolate that integrity into certainty of price. Unless this step is explicitly separated, external communication can repeatedly drift toward the narrative that “value has been defined, so price must eventually reflect it.”

21.3 System Release, Withdrawal, and Market Circulation Do Not Constitute Price Guidance

Within AIT’s dual-layer operating structure, system release, user withdrawal, and market circulation are sequential but distinct states.

System release first forms an internal rights outcome and is carried by the corresponding AIT carrier. Only after a user further satisfies withdrawal conditions does the relevant AIT move from a project-controlled functional wallet into the user’s self-custodied wallet. Only where the applicable technical, compliance, and market conditions are available may that AIT enter external transfer or public-market circulation.

System release ≠ withdrawal. Withdrawal ≠ sale. Entry into a self-custodied wallet does not mean that a market transaction, liquidity, or price outcome has formed. No state transition constitutes a bullish signal, price guidance, price-support arrangement, or promise of a market outcome.

AIT release, withdrawal, and circulation should therefore be understood as changes in rule and carrier state, not rewritten as price expectations or realization of returns.

21.4 Project Non-Responsibility Boundaries for Price, Volatility, Depth, and Liquidity

The central exclusion within the market boundary is that the project does not guarantee or undertake result responsibility for market price levels, price volatility, trading depth, or liquidity conditions. The project may define system rules, explain structural logic, and maintain boundary language, but it must not be presumed to guarantee market outcomes.

Price is formed through independent market behavior. Volatility reflects changes in market expectations and external conditions. Depth and liquidity depend on the willingness of multiple parties, structural conditions, and actual carrying capacity. None of these can be directly converted into a project outcome obligation.

This clarification is not intended to place the project outside all responsibility. It prevents the project from being improperly drawn into market commitments it was never designed to undertake. If the market is independent, its outcomes must be allowed to be independent; and if outcomes are independent, the system cannot be required to guarantee their final performance.

The project does not guarantee market price, trading depth, or continued liquidity. However, allocation from project-controlled functional wallets, liquidity deployment, material on-chain transfers, and other conduct that may significantly affect circulation structure must still be truthfully, clearly, and adequately disclosed where required by law or agreement. “Market independence” may not be used to conceal controlled conduct, material conflicts of interest, misrepresentation, or market manipulation.

21.5 Distinguishing Market Trading, Off-Market Transfer, and Ecosystem Use

The Boundary Layer must distinguish three different scenarios: market trading, off-market transfer, and ecosystem use. They may interact in reality, but their institutional meanings differ.

Market trading refers to buying and selling in a price-formation context. Off-market transfer more often refers to non-public transfers or arrangements between parties. Ecosystem use refers to functional invocation and carrying of the relevant unit within rule-permitted scenarios. Without this distinction, every unit in a transferable state can be reduced to “something intended for trading,” allowing market logic to consume the institutional significance of ecosystem use.

AIT must maintain the following distinctions: market trading is not the purpose of the system; off-market transfer does not automatically constitute ecosystem carrying; and ecosystem use should not be equated directly with price realization. Separating these paths prevents the system from being compressed into a single trading structure in external narratives.

21.6 Why Market Independence Must Be Institutionalized

“Market independence” is not merely a principle statement; it is a boundary condition that must be institutionalized. Without explicit market-independence language, outsiders may assume that because the system issues, computes, releases, and organizes certain carrying relationships, it should also bear extended responsibility for market results.

That default expectation is especially dangerous. It can pull the project into an obligation to explain price, cause every fluctuation to trigger questions about “why the promised result was not delivered,” and turn every change in liquidity into an alleged system failure. The market, originally an independent environment for behavior, can then be drawn backward into the system’s responsibility structure.

AIT must therefore state market independence as a clear institutional boundary: the existence of a market does not mean the system is responsible for it; the occurrence of a trade does not mean the project made a promise; and price formation does not mean value has been guaranteed to appear in a particular form.

21.7 Communication Boundaries in Market Contexts: Value Computation Must Not Be Rewritten as a Price Promise

In market contexts, the most common form of overreach is often not the mechanism crossing a boundary, but communication crossing it first. All market-related communications must remain at the level of rule explanation and boundary explanation. Value computation must not be rewritten as a price promise, and structural soundness must not be rewritten as certainty of return.

21.8 Why AIT Must Reject the Narrative Slippage “Value Computation = Investment Return”

Once “value computation” is treated as equivalent to “investment return,” AIT’s institutional positioning changes entirely. A rule system built to carry value from real behavior is rewritten into an outcome-return system; a structure centered on participation, responsibility, and rules is reduced to a market narrative centered on expected returns.

This slippage may appear to accelerate communication in the short term, but it destroys long-term order by converting short-term expectations into a substitute for system boundaries. System boundaries become consumed by the market, responsibility boundaries are rewritten by return expectations, information boundaries are overridden by promotional pressure, and governance boundaries become captive to short-term price objectives.

AIT must actively reject such narratives—not because it seeks to avoid the market, but because it must preserve the system first. Only if the system is not consumed by return logic can the market boundary remain intact.

In one sentence:

AIT can define value-computation rules, but it cannot define market-price outcomes.

A clear discontinuity must remain between the system and the market. Only when that discontinuity is institutionalized can AIT avoid being rewritten by external narratives into a price instrument.

Chapter 22 | AIT Compliance Boundaries: Scope, Restricted Parties, and External Jurisdictional Relationships

This chapter explains how AIT should respond to external legal order and compliance requirements across different jurisdictions, participant types, and participation circumstances.

22.1 Why the Boundary Layer Must Include Compliance Boundaries

A system that seeks to exist over the long term cannot define only its internal rules; it must also explain how it relates to external rules. The purpose of compliance boundaries is not to turn the White Paper into a legal opinion, but to state AIT’s institutional posture toward jurisdictional differences, regulatory environments, and participant restrictions.

Compliance therefore belongs in the Boundary Layer. The objective is not to freeze legal questions into permanent answers, but to make AIT’s stance clear: AIT is not a system designed to oppose regulation. It recognizes external jurisdictions, accepts differentiated constraints, and permits applicable adjustments.

22.2 Relationship Between AIT’s Rule System and External Legal Order

AIT’s rule system is an internal institutional structure. External legal order is the superior constraint within the real-world environment in which that system operates. The two are not competitors; they exist in a hierarchy. AIT may define participation logic, carrying rules, and governance boundaries within its own scope, but it cannot declare its internal rules inherently superior to external law, judicial decisions, or regulatory requirements.

AIT must therefore be clear that its rule structure is internal, not a substitute for external legal order. Its interpretive authority exists only within its own boundary and cannot expand into final authority over external legal relationships.

22.3 Why AIT Is Not Designed to “Avoid Regulation”

If a system is designed from the outset to “circumvent regulation, evade constraints, or escape jurisdictional limitations,” its long-term stability generally faces greater uncertainty because its institutional design is built on external conflict rather than clear boundaries, real-world compatibility, and sustainable existence.

AIT is not designed to avoid regulation. By expressly including compliance issues in the Boundary Layer, AIT states that long-term continuity comes not from confrontation but from restraint, and not from evasion but from recognition of real-world constraints.

22.4 Jurisdictional Differences and Restrictive Interpretation

AIT cannot be understood, applied, or accepted identically in every jurisdiction. Different countries, regions, and regulatory environments may apply materially different standards to digital rights, market circulation, participant qualifications, information disclosure, and participation behavior.

AIT must therefore recognize that differences in application exist and allow restrictive interpretation in different jurisdictions. Recognizing difference does not weaken the system; it prevents the system from being packaged incorrectly as a structure that applies identically and without qualification everywhere.

22.5 Restricted Regions, Restricted Parties, and Restricted Participation Circumstances

Compliance boundaries must also apply to specific objects: which regions, which participants, and which participation circumstances may be restricted. A restricted region means that, because of local law, regulatory requirements, or uncertainty, the system may choose not to make certain participation paths available. Restricted parties are natural persons, legal entities, or other organizations that may not be suitable for particular scenarios because of identity, qualification limits, legal requirements, or risk-control considerations.

Restrictions do not represent system failure; they demonstrate recognition of boundaries. A system with no restrictions at all may appear open but can often be less credible.

Specific restricted regions, restricted parties, restricted functions, and restrictive participation conditions should be defined in formal availability rules, terms of service, compliance policies, or subsequent notices and updated over time in light of applicable law and risk status. Principle-level statements in the White Paper do not replace actual availability scope or restricted-party lists.

22.6 Applicability of KYC / AML / Sanctions Requirements Across Participation Scenarios

KYC, AML, and sanctions requirements do not rewrite the identity of the system. They are compliance boundaries imposed by external legal order on particular participation scenarios. AIT should not assume that all participation scenarios require the same level of verification, nor should it assume that any participation path can operate entirely outside such requirements.

Where applicable, AIT and relevant operators should implement identity verification, anti-money-laundering monitoring, sanctions screening, recordkeeping, suspicious-activity reporting, and restriction handling according to applicable law, business nature, participant role, and risk level. Different participation paths may apply different levels of measures, but scenario differences, technical form, or internal system rules may not be used to avoid compliance obligations that are legally required.

22.7 Compliance Differences Among Merchant Access, User Participation, and Market Circulation

A point that requires particular emphasis is that merchant access, user participation, and market circulation are not the same compliance issue. Merchant access concerns operating entities, fulfillment relationships, and scenario authenticity. User participation concerns behavioral authenticity, participant eligibility, and rule applicability. Market circulation concerns the trading environment, jurisdictional requirements, and identification of restricted parties.

AIT must recognize that the three may differ in compliance intensity, method of application, and restriction conditions. This does not make the system inconsistent; it is a necessary response to real-world complexity.

22.8 Adjustment Principles When Compliance Requirements Change

External legal order is not static. Regulatory environments, jurisdictional interpretations, enforcement intensity, and applicable requirements may change. AIT must therefore preserve the ability to adjust internally when external conditions change.

When laws, regulatory requirements, or enforcement environments change, AIT may adjust availability scope, access conditions, participant eligibility, participation paths, verification intensity, and relevant system functions as required, and may restrict, suspend, or terminate particular regions, parties, or business paths where necessary.

If external legal requirements conflict with current internal rules, applicable law and regulatory requirements take priority. AIT may not refuse legally required adjustments on the grounds of preserving the “system identity” or “core principles.” At the same time, to the extent permitted by law, relevant changes should preserve necessary disclosure, traceability, and participant protection.

22.9 Compliance Boundaries Exist So the System Can Exist Over the Long Term

Compliance boundaries are not intended to make the system appear conservative. They exist so the system can qualify for long-term existence. A structure that ignores jurisdictional differences, denies participant restrictions, or discounts external rules may appear freer and more expandable in the short term, but it is more likely to face sustainability and compliance-stability pressure over the long term.

A truly sustainable system does not treat compliance as an auxiliary burden; it treats compliance as part of the system boundary. Only by recognizing the existence of real-world order can the system exist within reality over the long term; only by recognizing the priority of external boundaries can internal rules avoid becoming a self-declared empty structure.

In one sentence:

AIT’s compliance boundaries help the system remain restrained, transparent, and adjustable across different jurisdictions and regulatory environments.

AIT does not seek long-term existence by avoiding reality. It seeks long-term foundations by recognizing reality, adapting to reality, and continuing to operate within real-world boundaries.

Chapter 23 | AIT Governance Boundaries: What Can Be Adjusted—and What Cannot Be Changed

This chapter explains how AIT governance maintains restraint between what can be adjusted and what must remain protected, without evolving into arbitrary power to redesign the system.

23.1 Why a System Must Distinguish “Adjustable Parameters” from “Non-Negotiable Principles”

If everything in a system can be changed at any time, then the system has no principles—only temporary choices. But if nothing can ever be adjusted, the system loses the ability to respond to reality.

A long-term system therefore needs two capabilities at once: the ability to optimize and adjust without damaging its identity, and the discipline to identify core principles that ordinary adjustments may not override. AIT’s governance boundaries are built on this distinction.

23.2 Adjustable Matters: Operating Parameters, Cadence Parameters, Technical Implementation, and Execution Details

AIT is not a static structure incapable of evolution. Over the course of long-term operation, certain operating parameters, cadence arrangements, technical implementation methods, and execution details may be adjusted in light of actual conditions, efficiency requirements, and governance judgment.

Operating cadence may be optimized for different stages; technical implementation may change for maintenance or upgrade needs; and certain identification rules, processing thresholds, and execution details may be refined without changing the system’s identity. The purpose of such adjustments is not to change what the system is, but to make it operate more steadily, accurately, and sustainably while preserving its principles.

Adjustability is therefore not arbitrariness. It is limited optimization protected by boundaries. Parameters can be adjusted precisely because they are not the final layer that defines AIT’s identity.

23.3 Core Principles and Non-Breachable Boundaries of the Current Contract

AIT governance must distinguish among system core principles, current-contract facts, and adjustable execution parameters.

AIT’s core principles include: real spending is the core real-world entry point for Contribution Value formation and rights computation; the system does not promise fixed returns, price outcomes, or repurchase-based support; and rules take priority over short-term incentives and market sentiment. Check-ins and referrals do not generate Contribution Value, and any special rights outcomes they may form can be carried only within the predefined 2% of the Market Ecosystem Reserve under the applicable rules, without changing the role of real spending as the core value input.

In the Carrier Layer, the current Genesis Token contract has a fixed supply of 21,600,000,000 AIT, does not enable contract-level minting or additional issuance, and is not upgradeable. These current-contract facts may not be altered through ordinary parameter adjustment, administrative permissions, or hidden technical paths.

If AIT enters a new global ecosystem phase in the future and new ecosystem-carrying arrangements need to be considered, they must be treated as an independent governance matter and addressed separately through public disclosure, compliance review, holder-protection mechanisms, and a new technical implementation plan. Any future arrangement does not change the on-chain fixed-supply fact of the current Genesis Token contract.

Governance may therefore optimize execution methods and operating parameters, but it may not rewrite the real-spending anchor into false or circular input, rewrite the absence of return promises into outcome guarantees, or use the existing contract or ordinary governance procedures to bypass the current fixed-supply fact.

23.4 Boundaries of Adjustable Matters Across the Model, Computation, Operational, and Carrier Layers

AIT governance operates concretely across layers. Certain structural parameters in the Model Layer may be adjusted, but the value stance may not be changed. Identification and execution details in the Computation Layer may be optimized, but rule-based computation may not be rewritten into result distribution. Cadence, access, and collaboration methods in the Operational Layer may be reset, but the participation structure may not be rewritten into a return structure. Carrying methods and execution arrangements in the Carrier Layer may be optimized, but the fixed-supply fact of the existing Genesis Token contract may not be overridden, nor may the no-outcome-promise principle be breached. Any future ecosystem-generation arrangement must be handled separately under independent governance and compliance procedures.

Governance is therefore not a single-layer operation but a limited cross-layer capacity for adjustment. The key question is not whether adjustment is possible, but whether each layer knows what belongs to the space for optimization and what, if changed, would rewrite the system’s identity.

23.5 Parameter Updates Must Not Cross the System’s Core Definition

One of the most dangerous governance problems is not an open declaration that principles are changing, but the gradual rewriting of the system’s identity under the label of “parameter updates.” Open redesign is often easy to identify; gradual drift can be more difficult to detect.

Parameter updates may serve execution efficiency, recognition accuracy, operating stability, and system sustainability. They may not, under the label of technical, operational, or stage-specific needs, materially change the source of value input, responsibility boundaries, outcome-promise structure, or market-relationship definition. Once an update crosses the boundary of system identity, it is no longer an optimization; it is a redesign.

23.6 What Counts as an Upgrade, What Counts as Drift, and What Counts as Overreach

Governance requires a clear judgment framework. An upgrade improves implementation, operating efficiency, or collaboration structure without changing core principles. Drift occurs when the system gradually moves away from its original boundaries without openly rewriting the principles. Overreach occurs when a core principle is directly breached and AIT’s underlying nature changes.

These must not be conflated. Without a clear distinction, drift can be described as an upgrade and overreach can be packaged as optimization.

23.7 Authority Boundaries of Governance Adjustments: What May Be Decided—and What May Not

Governance requires authority boundaries because not every matter should be decided through ordinary governance. Matters involving parameters, cadence, technical implementation, and procedures may enter governance judgment within the defined boundaries. Matters involving foundational principles such as real-spending anchoring, no return promises, current contract supply facts, responsibility boundaries, and market independence should not be repeatedly re-decided as ordinary governance matters.

Governance may determine operating parameters, cadence, technical implementation, and procedural arrangements within the boundaries, but ordinary parameter adjustment may not change the fixed supply, absence of minting, or non-upgradeability of the current Genesis Token contract, and governance may not be used to create hidden issuance, fixed returns, price support, or outcome-guarantee mechanisms.

If a new ecosystem generation or new supply-carrying arrangement needs to be considered in the future, it must be evaluated, disclosed, and executed as a separate matter rather than packaged as an ordinary parameter update of the existing system.

The purpose of authority boundaries is not to weaken governance, but to prevent governance from shifting from system maintenance into reconstruction of the system’s identity.

23.8 What Governance Must Not Do: Change the Value Stance, Chase Short-Term Markets, or Rewrite Responsibility Boundaries

If governance shifts from maintaining long-term structure toward pursuing short-term market effects, temporary communication gains, or stage-specific sentiment, the system can quickly move from rules first to results first. The behavior governance must avoid is not “doing nothing,” but doing what should not be done in response to short-term incentives.

Governance may not change AIT’s value stance, rewrite the behavioral-value carrying structure into a return-promise structure, rewrite responsibility boundaries to satisfy the market, or breach the fixed-supply fact of the current Genesis Token contract or other core principles because of short-term volatility. Such actions may appear to demonstrate governance capacity, but in reality they consume institutional credibility.

A mature system is defined not by how much its governance can do, but by whether governance knows what it must not do even when external expectations are strong.

23.9 Why Governance Restraint Matters More Than Governance Power

In many systems, governance is imagined as a powerful capacity to redesign: the presence of governance is taken to mean that paths can be continuously rewritten, directions corrected, and expectations satisfied. For long-term systems, however, the more important characteristic is not power but restraint.

Power creates short-term flexibility; restraint creates long-term credibility. Only when outsiders can trust that certain principles will not be casually rewritten because of market sentiment, stage pressure, or localized interests can governance function as a stabilizer rather than a source of uncertainty.

AIT does not need a governance structure that “can change everything.” It needs a governance structure that “knows what cannot be changed.” Only then does governance serve the system rather than consume it.

In one sentence:

AIT governance exists not to rewrite the system at will, but to preserve long-term stability without crossing core principles.

A system that can be adjusted is not the same as a system that can be rewritten arbitrarily. AIT’s governance boundaries exist to preserve that distinction.

Chapter 24 | AIT Participation Boundaries: Which Behaviors Are Included—and Which Are Excluded

This chapter explains what forms of participation the system recognizes, what forms it excludes, and why “recorded” does not mean “recognized.”

24.1 Why Participation Boundaries Must Be Explicit

Not every behavior that occurs should be recognized by the system, and not every action that technology can record automatically constitutes valid participation. For a system such as AIT, which carries value from real behavior, participation boundaries are critical because the system does not carry the surface appearance of behavior; it carries the authenticity, rule compliance, and value significance behind it.

If participation boundaries are unclear, any action can be packaged as participation and any record can be demanded as recognized input. The system then shifts from “rules carrying real behavior” toward “technology collecting all actions.” Value inputs become overwhelmed by noise, institutional fairness is eroded by strategic behavior, and what the system ultimately carries is performance rather than value.

Participation boundaries therefore do not exist to exclude participation. They exist to protect genuine participation.

24.2 Preconditions for Valid Participation: Genuine, Verifiable, and Rule-Compliant

AIT recognizes valid participation only where at least three conditions are satisfied together: the behavior is genuine, verifiable, and compliant with the rules. Genuine means the behavior is not fabricated, fictional, or circular. Verifiable means the system can determine, under established conditions, whether the behavior actually occurred. Rule-compliant means the behavior falls within the scope the system is institutionally permitted to carry.

All three conditions are required. If behavior is genuine but cannot be verified, the system cannot determine whether it should be recognized. If it is verifiable but not genuine, the system becomes a mechanical recorder of false participation. If it is both genuine and verifiable but does not satisfy the rules, the system cannot include it in computation merely because “it really happened.”

Valid participation is therefore not created by subjective declaration; it is an institutional judgment formed by the applicable rule conditions.

24.3 Distinguishing Consumption, Check-In, Referral, and Governance Behaviors

Different types of behavior in AIT have different characteristics and cannot simply be treated as equivalent. Consumption usually relates directly to real transactions and is the core source of value input. Check-in more directly expresses continued participation and behavioral recording; its meaning is to maintain the relationship rather than to be equivalent to consumption. Referral may support collaborative expansion and ecosystem growth. Governance behavior belongs to institutional participation and should not be misread as a substitute for the value input itself.

Without these boundaries, all behaviors may be measured as though they were the same, leaving the system unable to distinguish “core input” from “collaborative behavior,” or “value source” from “supporting path.” The Boundary Layer separates these behaviors not to reduce the importance of any category, but to return each to its proper role.

In value-input terms, consumption is the core path for Contribution Value formation. Check-ins and referrals do not generate Contribution Value; any special rights outcomes they may form can only be carried within the predefined 2% Market Ecosystem Reserve under the applicable rules. Governance behavior and other ecosystem interactions do not automatically constitute a source of Contribution Value or rights outcomes. Different behaviors must not be treated as equal value inputs merely because they are all recorded by the system.

24.4 Participation Does Not Equal Arbitrage; Use Does Not Equal a Claim to Outcomes

Entering the system does not mean entering a structure that may be freely arbitraged. Likewise, using a relevant unit in a rule-permitted scenario does not automatically create a claim to a particular outcome.

Participation begins with rule recognition, whereas arbitrage often begins by searching for gaps at the boundary. Use begins with functional invocation, whereas claims to outcomes arise when functional relationships are misread as return relationships. If the two are conflated, the system will be driven toward “how to profit from the structure” rather than “how to participate continuously within the rules.”

AIT does not make abstract judgments about the subjective motives behind lawful holding, use, or market behavior. It does, however, refuse to recognize false transactions, circular behavior, manipulative interaction, rule circumvention, or records created by exploiting system vulnerabilities as valid value input. Participation and use do not automatically create a claim to income, redemption, price, or other market outcomes.

24.5 Exclusion of False Transactions, Circular Behavior, and Manipulative Interaction

The Boundary Layer must make clear that some behaviors do not constitute valid participation even if they appear to complete an interaction. False transactions contain no real value input. Circular behavior is only a formal loop. Manipulative interaction attempts to substitute strategic actions for genuine participation. If such behaviors are recognized by the system, fairness is directly damaged.

AIT therefore applies a clear exclusion principle to such behavior. The system does not exist to record every action; it exists to carry real value. If a behavior depends on fabrication, circularity, strategic packaging, or malicious manipulation, it loses the basis for entering value computation and rights carrying.

24.6 Why “Recordable” Does Not Mean “Recognized”

Technical recording capability is not the same as institutional recognition capability. The fact that an action can be recorded means only that it leaves a technical trace. Whether it is recognized depends on whether it satisfies the system’s authenticity, verifiability, and rule-eligibility requirements.

This distinction is one of the most easily overlooked—and most important—points in AIT’s participation boundaries. In technology-centered narratives, people often treat “recordable” as “computable” and then “computable” as “claimable.” If that logic were accepted, the system would cease to be a rule system and would become merely a recording machine.

AIT must repeatedly emphasize that recording is a prerequisite, not a conclusion. What determines whether behavior enters the system is not whether it was recorded, but whether it satisfies the formal conditions for institutional recognition.

24.7 Boundaries for Identifying, Excluding, and Correcting Anomalous Behavior

The Boundary Layer must explain not only what the system recognizes, but also how the system responds to anomalous behavior. An anomaly does not necessarily imply malicious intent. It does, however, mean that authenticity, frequency, method, structure, or outcome departs from normal boundaries and requires further identification and handling.

For anomalous behavior, the system may identify it, temporarily withhold recognition, exclude it, or apply corrective measures. Such handling also requires boundaries: it must not expand arbitrarily into excessive suppression of normal participation, nor may technical imperfection justify abandoning basic identification responsibilities. AIT requires limited and clearly defined anomaly-handling capacity, not unlimited discretion.

In other words, anomaly identification exists to protect fairness, not to create new uncertainty.

Restrictions, exclusions, adjustments, or other measures applied to anomalous behavior should be based on clear and reviewable formal rules, follow a principle of proportionality corresponding to the severity of the anomaly, and preserve necessary records. Where applicable, notice, review, or appeal paths should be provided. Anomaly handling must not become a basis for arbitrary expansion of system discretion.

24.8 Relationship Between Participation Boundaries and Fairness

A system is not fair merely because it treats every behavior identically. Fairness depends on whether different types of behavior are distinguished appropriately. Treating genuine participation and strategic behavior as the same may look equal, but is unfair. Recognizing long-term sustained input and short-term manipulative interaction together may look open, but it damages fairness.

Participation boundaries are therefore part of the fairness structure itself. The clearer they are, the less likely genuine participants are to be displaced by anomalous behavior. The more ambiguous they are, the more likely the system is to be captured by parties skilled at performing the rules rather than contributing real value. Protecting boundaries is, in substance, protecting fairness.

24.9 What Does Not Constitute AIT Value Input

Not every behavior related to the system constitutes value input. Noise-based interaction, transactions lacking an authentic basis, operations without rule-recognition grounds, and surface-level actions performed only to generate records cannot constitute a source of value that AIT should carry.

Value input must remain limited because if the concept of input expands without limit, the system loses the ability to distinguish value. A system that carries every action ultimately becomes incapable of carrying real value. AIT therefore maintains that only inputs that genuinely satisfy rule conditions and constitute real behavioral value contribution fall within the scope it recognizes.

In one sentence:

AIT does not recognize every recorded behavior; it recognizes only participation that is genuine, verifiable, and within rule boundaries.

The openness of the system does not lie in accepting everything, but in carrying only behavior that is genuine, verifiable, and compliant with formal rules.

Chapter 25 | AIT Information and Communication Boundaries: Disclosure and External-Communication Boundaries

This chapter explains how AIT should maintain restrained and consistent positioning across the White Paper, website, market communications, community communications, and other external materials.

25.1 Why Information and Communication Boundaries Are Part of the System Itself

Many systems lose control in communication before they lose control in mechanism. The mechanism may remain within bounds while the language has already crossed them; the rules may remain unchanged while the narrative pushes the system into a position it was never meant to occupy. For AIT, information boundaries are therefore not auxiliary—they are part of the institutional structure.

The purpose of information and communication boundaries is to prevent external communication from becoming an entry point through which the system’s identity is rewritten.

25.2 Functional Boundary of the White Paper: Rule Explanation, Not Outcome Promise

The function of the White Paper is to provide an institutional explanation of the system’s philosophy, structure, rules, boundaries, and evolution path—not to promise any market, return, or individual outcome. It explains; it does not guarantee delivery of results.

The White Paper may explain AIT’s institutional logic, define system boundaries, and describe carrying relationships and governance rules. It must not drift into price prediction, return implication, repurchase promises, or result guarantees. AIT’s White Paper must be understood as a rule-and-boundary document, not an outcome-guarantee document.

The White Paper also does not replace specific terms of service, participation rules, risk disclosures, compliance policies, allocation and vesting documents, or any other formal documents required by law. Specific eligibility, function availability, rights and obligations, and restrictions are governed by the formal rules in effect at the relevant time and by applicable law.

25.3 External Communications Must Not Cross Return, Price, or Outcome Boundaries

What must be most strictly prohibited in external communication is any form of implication regarding returns, price, or guaranteed outcomes. Whether stated directly or communicated through analogy, metaphor, or suggestion, if the effect is sufficient to cause outsiders to understand the system as a structure promising return outcomes, the boundary has already been crossed.

All external statements must remain at the level of rules, boundaries, mechanisms, and scenarios, and must not enter the territory of guarantees regarding price, returns, or other outcomes.

25.4 Consistency Requirements Across the White Paper, Website, Community, and Sales Materials

Whether a system truly respects its boundaries cannot be judged only by how restrained the White Paper is. All other external materials must remain consistent with it. If the formal document maintains clear boundaries while the website, community, or sales materials continuously create return expectations, the system will ultimately be defined by the louder communication layer.

The White Paper, website, community communications, sales materials, and other formal or semi-formal external information must therefore remain consistent in their core positioning. Expression may be simplified for different contexts, but the boundaries may not be expanded.

25.5 Distinguishing Risk Disclosure, Functional Description, and Commercial Promotion

Risk disclosure, functional description, and commercial promotion are three different forms of communication and cannot substitute for one another. Risk disclosure explains limitations, boundaries, and uncertainty. Functional description explains what the system can do and how it operates. Commercial promotion typically seeks to attract attention and facilitate understanding.

In none of these communication contexts may the system’s core boundaries be exceeded. AIT may be expressed clearly, but not exaggerated; it may be communicated effectively, but not distorted.

25.6 What Must Be Disclosed—and What Must Not Be Exaggerated

For a rule-based system, information that must be disclosed primarily includes matters relevant to the system’s identity, boundary assessment, participation conditions, applicability restrictions, material changes, and rule principles. Key information concerning how the system is established, how it operates, how responsibilities are defined, how boundaries are handled, and how changes are managed should not be deliberately withheld.

What must not be exaggerated is any content that could create misunderstanding about outcomes. The purpose of disclosure is to help outsiders understand the boundaries—not to encourage additional imagination beyond them.

25.7 Information Updates, Versioning, and Material Change Disclosure

A long-term system cannot remain on one static version forever, so information updates and version iteration are normal. What matters is that updates serve clarity rather than ambiguity, and that version iteration explains what changed rather than leaving outsiders to believe that foundational principles were rewritten silently.

AIT should maintain clear explanation mechanisms for important updates, material changes, and adjustments to key boundaries. An update is not merely the release of new content; it is also a renewed confirmation of system continuity and principle stability. Changes involving important rules, core parameters, participation conditions, responsibility boundaries, or other material matters should at minimum record the applicable version number, effective date, and principal scope of change. Where necessary, the manner in which the change applies to existing participation relationships should also be explained. Version records should remain traceably consistent with formal disclosure documents.

25.8 How AIT Avoids Being Misread as an Investment Narrative

AIT avoids being misread as an investment narrative not through a single disclaimer, but through a complete and consistently applied set of boundary-expression principles. The White Paper must state the absence of outcome promises; the website must maintain rule-based positioning; communities must reject return-oriented language; sales materials must avoid price implications; and all external communications must preserve the same boundary: AIT carries behavioral value relationships and does not promise market-return outcomes.

Only when this position is maintained consistently across all contexts can AIT avoid being recharacterized as a different structure for the convenience of local communication. Boundaries must be repeated not because the system is unclear, but because external narratives continually attempt to rewrite it into a form that is easier to consume.

In one sentence:

AIT’s information and communication boundaries require all disclosure and communication to remain within rule explanation and not slide into outcome promises.

If communication is broader than the rules, the system will ultimately be defined by the communication rather than by the rules. AIT establishes information boundaries precisely to prevent that outcome.

Chapter 26 | The Meaning of Boundaries: Why Restraint Matters More Than Expansion

This chapter explains why AIT deliberately limits itself and why boundaries do not restrict growth but protect long-term existence.

26.1 Why Long-Term Systems Depend on Self-Restraint—and Why Boundaries Do Not Prevent Growth

Boundaries are often misunderstood as restrictions, as though emphasizing limits means abandoning expansion, imagination, or growth. Long-term systems work in the opposite way: they do not grow because they have no boundaries; they grow because clear boundaries prevent growth from tearing the system apart.

Self-restraint is not self-weakening. It keeps system expansion within a range that does not distort the system’s identity. Growth without boundaries may appear faster but is more fragile; growth within boundaries may appear slower but is more sustainable. AIT sets limits not because it lacks imagination, but because it refuses to exchange unlimited external expectations for short-term appearance of expansion.

26.2 Why Systems Without Boundaries Drift Toward Expanding Responsibility and Collapse of Trust

A system without boundaries initially gains freedom but ultimately inherits unlimited responsibility. If the system does not state what it does not undertake, outsiders will continuously attach new responsibilities to it; if it does not state what it is not, outsiders will continuously reinterpret it as the form that is easiest to market.

Eventually, the system is no longer defined by its rules but by market sentiment, communication narratives, and outcome expectations. Responsibilities increase while boundaries disappear, until the system appears able to explain everything but can actually deliver nothing. Trust may collapse not because the system committed fraud, but simply because it failed early enough to reject responsibilities that never belonged to it.

26.3 Why AIT Would Rather Explain More Narrowly Than Promise More Broadly

For a system that seeks long-term institutional credibility, explaining itself more narrowly is often harder than making broader promises. Narrow explanation means giving up some communication convenience, rejecting statements that would attract attention more easily, and acknowledging at critical moments that “this does not belong to us.”

That restraint is precisely a source of long-term trust. The broader the promise, the greater the pressure to deliver; the narrower the explanation, the more stable the institutional boundary. AIT would rather explain itself clearly and conservatively than create greater expectations in the wrong direction for short-term effect. Once a system trades incorrect promises for attention, the eventual cost can greatly exceed the initial convenience.

26.4 From Rule Stability to Institutional Trust: How Boundaries Become a Source of Credibility

Rule stability is not merely a technical issue; it is a trust issue. Whether outsiders trust a system depends less on how much vision it articulates than on whether it can preserve the boundaries it originally wrote down in the face of pressure, volatility, temptation, and market sentiment.

Boundaries become a source of credibility because they tell outsiders that the system does not exist to satisfy every short-term expectation, but to preserve its identity over time. A system that can change its language, boundaries, or structural interpretation whenever convenient may be flexible in the short term but is difficult to trust over the long term. By contrast, a system willing to remain restrained at critical moments can gradually build institutional trust.

AIT seeks institutional trust rather than emotional trust. Institutional trust is not built by amplifying promises; it accumulates through stable boundaries.

26.5 Relationship of the Boundary Layer to the First Five Layers and the Evolution Layer: Boundaries Are Guardrails, Not an Endpoint

The Boundary Layer does not reject the first five layers and does not block future evolution. Instead, after the first five layers have developed the system’s capabilities, the Boundary Layer adds guardrails necessary for long-term existence. Before the Evolution Layer discusses future expansion, the Boundary Layer first states which forms of expansion should not be pursued at the cost of crossing boundaries.

The Philosophy Layer defines the value stance, the Model Layer defines the structure, the Computation Layer defines the rules, the Operational Layer defines the real-world paths, and the Carrier Layer defines the carrying unit. The Boundary Layer then brings the capabilities created by those layers back within clear responsibility boundaries. The Evolution Layer may continue only within the scope permitted by applicable law, system core principles, and formal governance procedures, and must not advance “evolution” through unprocedural, undisclosed, or responsibility-boundary-breaching conduct.

Boundaries are therefore guardrails, not an endpoint; they do not close the system, but prevent evolution from drifting; they do not compress the future, but protect the future so that it remains consistent with the system’s original intent.

In one sentence:

AIT’s Boundary Layer does not shrink the system; it enables the system to exist over the long term without losing its identity.

Long-term systems are not sustained by unlimited expansion. They survive because, at critical points, they know how to exercise restraint, preserve boundaries, and reject narrative slippage.

Chapter 27 | AIT’s Direction of Evolution

AIT’s evolution is oriented toward greater stability, stronger sustainability, and broader reusability. It is not intended to become a project that continually manufactures new discussion, but to gradually enter the stable order of everyday consumption, long-term participation, and real-world collaboration. For AIT, what is genuinely worth pursuing is not a one-time surge, but long-term validity.

27.1 AIT’s Evolution Is Not Driven by Hype, but by Stability

AIT does not measure its progress by short-term hype, nor does it allow market sentiment to determine structural direction. Hype can bring attention, but it cannot replace order; expansion can bring scale, but it cannot replace stability. A system that deserves long-term use must first demonstrate that, as participation density changes, scenario types increase, and cyclical fluctuations emerge, it can still maintain clear rules, defined boundaries, and sustainable operation. AIT’s direction of evolution is therefore not to pursue faster external growth, but to maintain greater internal stability over a longer horizon.

27.2 AIT’s Long-Term Direction: From Consumption Confirmation Mechanism to Participatory Infrastructure

AIT begins by enabling real consumption to be identified, computed, and confirmed within rules. Its next step is to move beyond the single act of “confirmation” and further form an infrastructure structure centered on participation. In other words, consumption confirmation is not merely a one-time institutional recognition; it can gradually become the starting point for continued participation, long-term collaboration, and the maintenance of order. AIT’s long-term direction is not to expand one incentive tool into more incentive methods, but to evolve from a consumption-confirmation mechanism into participatory infrastructure capable of supporting participation relationships, collaborative relationships, and long-term order.

27.3 From an Operable System to a Sustainable System

The preceding six parts have explained AIT’s basic structure and operating model, as well as how consumption, rights, and action form sustained relationships under rules. Part VII goes further by asking whether this system can endure over the long term. Being operable means only that the system can function under current conditions; being sustainable means that it does not depend on a single stage, a single wave of attention, or a single explanatory framework, but can continue to preserve rule effectiveness and structural stability in more complex environments. AIT’s real evolution is not from “nonexistent” to “existent,” but from “able to run” to “able to keep running over time.”

27.4 From Local Viability to Replicable Viability

A system that works only in a single pilot, a single scenario, or under special conditions remains a stage-specific mechanism rather than a long-term structure. AIT’s direction of evolution must therefore include a move from local validity to replicable validity. Replicability does not mean simply copying form. It means enabling the system’s structural logic to be reused across scenarios, regions, and collaborative relationships within the limits permitted by applicable law, formal governance rules, and AIT’s core system constraints. Only when AIT no longer depends on a particular window of opportunity, but can remain valid under more real-world conditions, can it genuinely begin to resemble infrastructure.

In one sentence:

AIT’s evolution is the transition from an operable consumption-confirmation mechanism to participatory infrastructure designed for long-term use.

Chapter 28 | AIT’s Ecosystem Evolution

AIT’s long-term viability depends not only on whether its rules are clear, but also on whether it can enter a broader range of real-world collaboration. Ecosystem evolution does not simply mean adding more labels, more industries, or more connected parties. It means enabling an increasing number of participants to form sustainable participation, coordination, and order relationships under the same rule constraints. AIT’s ecosystem evolution is therefore not expansion of scope for its own sake, but structural expansion.

28.1 From Consumption Relationships to a Participatory Ecosystem

In traditional commercial relationships, consumption usually ends when the transaction is completed. In AIT’s structure, consumption is not the end of the relationship but the beginning of a participation relationship. A real consumption event is not merely a payment event; it is a value input recognized by rules. What follows is therefore not a one-time reward, but the qualification, pathway, and possibility for further ecosystem participation. AIT’s ecosystem evolution is first reflected in this shift: consumption relationships extend into participation relationships, participation relationships further settle into ecosystem relationships, and the system gradually moves from a one-time transaction structure toward a long-term participation structure.

28.2 Users May Evolve from Participants into Long-Term Collaborators

In AIT’s early stage, users first enter the system as consumption participants. Over the long term, however, users need not remain in a one-way position of being incentivized, recognized, and released. As rules are used continuously, participation paths are repeatedly validated, and Action Value circulation gradually takes shape, users may evolve from one-time participants into long-term participants who understand the rules, follow them, and continue to collaborate within them. AIT does not require every user to become a governance participant; rather, it aims for long-term participation to evolve from occasional or passive involvement into more sustained rule-based collaboration. This is the distinction between a long-term collaborator and a short-term participant.

28.3 Merchants May Evolve from Access Points into Ecosystem Coordination Hubs

Merchants in AIT do not assume financial commitments or price responsibility. Their fundamental role is to provide real consumption scenarios and verifiable transactions. As the system evolves, where rules, capabilities, and actual collaboration conditions permit, some merchants may evolve from simple scenario access points into ecosystem coordination hubs. An ecosystem coordination hub means that a merchant is not only where transactions occur, but can also become an important connection point for extending consumption relationships, deepening user participation, and forming local ecosystem relationships. The evolution of the merchant role is not a transformation from a commercial entity into a financial entity, but from a single-point participant into a long-term collaborator.

28.4 Nodes May Further Assume Responsibilities for Maintaining Order

Nodes in AIT are not decorative identities. They are roles that may bear greater collaborative, connective, and order-related responsibilities within the structure. As the ecosystem expands, the significance of nodes should not stop at structural hierarchy, but may further extend to rule maintenance, collaboration support, and local order stability.

Whether a node may further assume responsibilities for rule maintenance, collaboration support, or local order maintenance must be based on formal role rules, governance authorization, and demonstrated capacity to perform those duties. It cannot be inferred solely from the number of connections, participation scale, or market influence.

The long-term value of a node lies not in the title itself, but in whether it can continuously perform the corresponding collaborative responsibilities within formal rules.

28.5 Social Collaboration Partners May Gradually Enter AIT’s Collaborative Structure

Where the rules are compatible, real scenarios are established, and applicable compliance conditions are met, AIT’s ecosystem collaboration does not need to be limited to traditional merchant settings. Real-world entities that are not traditional merchants but can support real participation and rule-based collaboration may also gradually enter AIT’s collaborative structure when rule, governance, and compliance conditions are in place—for example, education, technology services, content services, and digital collaboration providers. They do not need to take the form of traditional merchants. If they can form stable interfaces with consumption confirmation, participation pathways, and collaborative relationships, they may be incorporated into AIT’s collaborative structure. Over time, AIT may therefore explore a broader social collaboration structure built on top of its commercial access network.

28.6 AIT’s Applicable Scenarios May Extend from Commercial Consumption to Broader Social Collaboration

AIT begins with commercial reality because real consumption, verifiable transactions, and merchant access provide its most stable real-world foundation. Its long-term scope of application, however, need not be limited to commercial consumption itself. As rules become more stable, participation relationships extend over time, and social collaboration partners are gradually incorporated, AIT’s applicable scenarios may expand from commercial consumption into broader forms of social collaboration. Here, “extension” does not mean leaving commerce behind. It means starting from commerce and moving into education, services, content, computing power, digital collaboration, and other real-world scenarios that can be supported by rules. The sign of ecosystem evolution is not simply broader coverage, but the ability of the same rule structure to remain valid across more forms of social collaboration.

In one sentence:

AIT’s ecosystem evolution is the formation of a broader, more stable, and more sustainable participatory ecosystem among users, merchants, nodes, and social collaboration partners under common rules.

Chapter 29 | AIT’s Ultimate Destination

AIT’s long-term objective should not be understood as becoming a more widely discussed project, nor should it remain merely a mechanism innovation belonging to a particular cycle. The real question is: after consumption confirmation, long-term participation, and rule-based collaboration are repeatedly validated in reality, in what form can AIT ultimately be used over the long term? The answer is not a larger slogan, but a more restrained judgment: AIT’s ultimate value lies not in continuously manufacturing novelty, but in gradually becoming civilizational infrastructure that can be used repeatedly over time.

29.1 AIT Is Built for Long-Term Infrastructure, Not Short-Term Hype

A system that depends on hype for survival will ultimately fade when the hype fades. A system worthy of long-term use, by contrast, must avoid losing control when attention rises and avoid becoming ineffective when attention falls. AIT’s long-term direction, therefore, is not to become a “hot project,” but to continuously improve its usability, stability, and reusability as long-term infrastructure. Infrastructure here does not mean that it must be directly visible like a payment system. It means that, through repeated long-term use, it can become a structure that no longer requires constant explanation yet can be relied upon consistently. The value of civilizational infrastructure lies not in the grandeur of its concept, but in its long-term usability.

29.2 AIT Truly Evolves When Consumption Confirmation Becomes as Natural as Payment

Whether AIT has completed its evolution does not depend on how many people discuss it, but on whether it reaches a state of “natural presence.” Mature structures are often no longer explained repeatedly as new things; through repeated use at scale, they become part of the default order. For AIT, this mature state would mean that consumption confirmation is no longer an institutional innovation understood by only a minority, but exists in real-world relationships as naturally as payment; users can enter without additional learning, merchants can connect without repeated explanation, and the system can continue operating without repeatedly declaring its own value. When consumption confirmation reaches this natural state, AIT will have completed its transition from an innovative mechanism to infrastructure.

29.3 AIT Does Not Claim to Define Civilization; It Serves Civilization

AIT does not present itself as defining civilization, nor does it use abstract grand narratives as a substitute for real structural development. Its more restrained position is to serve civilization. To serve civilization means using rules as an intermediary, consumption confirmation as a starting point, and long-term participation as a pathway to provide the real world with more stable ways to carry behavior, confirm relationships, and organize collaboration. Civilization is not created by proclamation; it gradually settles through the sustained use of many forms of infrastructure. AIT’s significance lies not in asserting a civilizational slogan, but in providing a long-term usable structure for a more stable order of digital collaboration.

29.4 From a Project Mechanism to Civilizational Infrastructure

AIT’s ultimate ascent is not the transformation of a small project into a larger project, but the gradual transition from a project mechanism into civilizational infrastructure. The former depends on team-driven execution, stage-based narratives, and external attention; the latter depends on stable rules, scenario adoption, and long-term reuse. Projects have cycles; infrastructure has time. Projects must be explained repeatedly; infrastructure proves itself through use. AIT’s real completion will not be stronger narrative capability, but structural capability that can be used over time. When it can continuously and stably support consumption confirmation, participation relationships, and collaborative order across broader scenarios, AIT may gradually exhibit the real characteristics of infrastructure and continue toward its long-term vision.

In one sentence:

AIT’s long-term goal is not to remain a stage-specific project, but to become civilizational infrastructure that can be used by real society over the long term.