> For the complete documentation index, see [llms.txt](https://baca.endhonesa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://baca.endhonesa.com/all-notas-markdowns/archived-oioi/2026/08/20260802-01-bgc-iblooming-master-document-v1.0.md).

# BGC X IBLOOMING MASTER DOCUMENT

## Project Review, Findings, Strategic Transition, and Founder Decisions

**Prepared for:** BGC × iBLOOMING Founders\
**Founder meeting:** On August 2026\
**Prepared by:** Prof. NOTA\
**Technical and simulation contribution:** Fabio Kalandra (“Uncle Kal”)\
**Business and operational input:** The BGC × iBLOOMING Founders\
**Review period:** December 2024 – August 2026\
**Version:** 1.11 — Pre-Meeting\
**Confidentiality:** Internal — Founders and Core Team

***

## 1. Executive Decision Brief

### 1.1 Why This Document Exists

The BGC × iBLOOMING Web3 initiative began as an exploration of blockchain identity, loyalty, internal utility, and a possible future public token.

During the following year, the project uncovered a more important reality:

* BGC and iBLOOMING already operate internal value, reward, and entitlement systems;
* the largest recorded cash inflow is concentrated in BGC affiliate-entry transactions;
* iBLOOMING’s direct product economy is much smaller;
* the existing reward system cannot be safely converted into tokens without complete rights, liability, accounting, legal, and tax treatment;
* SIMALPHA is useful as an internal evidence and policy-testing tool, but its first reports do not prove sustainability or token readiness;
* Web3 Login remains independently valuable and ready for engineering implementation;
* the strongest next strategic opportunity is not to create a new speculative financial mechanism, but to build measurable demand for real physical and digital products.

This document closes the original Phase-1 exploration and presents a more disciplined strategic direction.

### 1.2 Central Conclusion

> **BGC × iBLOOMING should not tokenize its existing affiliate membership, Purchase Credit, Sales Point, LTS, reward, pool, payout, or deferred obligations.**

The present evidence is sufficient to conclude that approving such tokenization now would be premature.

The present evidence is not sufficient to conclude that:

* the existing economic system is financially sustainable;
* current cash-in equals profit;
* reserves are adequate;
* all reward and product obligations are covered;
* a public token can be safely backed or redeemed;
* member-level reward distribution is fair;
* tokenization will reduce tax or operating cost;
* a restrictive cash-out policy creates productive value.

### 1.3 Primary Strategic Recommendation

BGC × iBLOOMING should transition from a **reward-led acquisition focus** toward a **product-led commercial and technology program**.

The next program should prioritize:

1. implementation of the approved Web3 Login architecture;
2. independent validation of demand for physical products, digital products, content, education, profiling, and AI-enabled services;
3. product, commerce, retailer, distribution, supply-chain, access, ownership, and trust infrastructure;
4. small, non-tradable Web3 product pilots;
5. selective use of blockchain only where ownership, verifiability, portability, provenance, or multi-party trust creates measurable value;
6. selective use of AI where it improves product discovery, customer support, operations, content, or decision quality;
7. separation of any future public-token research from the BGC affiliate and reward engine.

### 1.4 What Founders Are Asked to Decide

The founders are not being asked to approve final token parameters.

They are asked to decide:

1. whether to approve a Product-Led strategic transition;
2. whether to authorize Web3 Login implementation under Yuku and the engineering team;
3. whether to close the old PC/SP-to-ALPHA tokenization track as an automatic roadmap;
4. whether to retain public-token exploration only as an optional, separate research track;
5. whether to approve one physical-product and one digital-product demand pilot;
6. whether to separate product-marketing metrics from affiliate-acquisition metrics;
7. whether to appoint the resources required for any further financial, accounting, legal, tax, data, or token validation;
8. whether to prohibit the use of the affiliate network as a distribution mechanism for a new deposit, yield, DeFi, DEX, CEX, or fundraising product.

***

## 2. Document Authority and Evidence Classification

### 2.1 Evidence Classes

| Classification                | Meaning                                                                     |
| ----------------------------- | --------------------------------------------------------------------------- |
| Confirmed AS-IS Rule          | Rule documented in the final UNDERSTANDING Doc                              |
| Approved Specification        | Completed design accepted for implementation                                |
| Founder Working Alignment     | Direction recorded from discussions but not necessarily a formal resolution |
| Historical Artifact           | Dated evidence of work, discussion, or software output                      |
| Consultant Finding            | Interpretation based on available rules, data, and documents                |
| Draft Hypothesis              | Proposed future state not approved for implementation                       |
| Preliminary Simulation Output | Model output under incomplete evidence                                      |
| Management-Reported Context   | Information reported by management but not independently validated          |
| Decision Required             | Matter requiring explicit founder authority                                 |

### 2.2 What This Document Is Not

This document is not:

* an audited financial statement;
* a forensic accounting report;
* a legal opinion;
* a tax opinion;
* an investment memorandum;
* a token offering document;
* a smart-contract deployment authorization;
* proof that BGC operates legally in every country where a participant may exist;
* proof that any token would be accepted for listing or public trading.

***

## 3. Ecosystem and AS-IS Economic Model

### 3.1 BGC

BGC operates an affiliate-membership and physical-product-credit system.

A new Affiliate User:

1. pays an entry fee in fiat;
2. receives Purchase Credit;
3. causes LTS to be generated;
4. can trigger reward allocations through the documented network rules.

The final UNDERSTANDING Doc identifies five affiliate levels:

* Pathfinder;
* Voyager;
* Explorer;
* Pioneer;
* Special.

### 3.2 iBLOOMING

iBLOOMING is positioned as a digital education, personal-development, content, profiling, and AI-enabled platform.

Its products and programs include concepts such as:

* GiM;
* iLearn;
* iMATRIX;
* Channel Provider content;
* digital courses and content;
* AI-assisted product and learning experiences.

### 3.3 Purchase Credit

Purchase Credit is documented as:

* an internal credit associated with affiliate membership;
* a value used for BGC physical products;
* fixed at a reference of 100 PC = USD 1.

PC must not be casually treated as free cash, profit, a public token, or a right that can be duplicated.

### 3.4 Sales Point and LTS

The final UNDERSTANDING Doc records:

* 1 SP as a USD 1 calculation reference;
* LTS equal to 70% of a new affiliate’s entry fee;
* several BGC rewards and pools as percentages of new-join LTS.

### 3.5 Two Different Economic Engines

| Dimension                   | BGC                                                     | iBLOOMING                                           |
| --------------------------- | ------------------------------------------------------- | --------------------------------------------------- |
| Primary recorded cash event | Affiliate membership entry                              | Product or service transaction                      |
| Main reward trigger         | New join and network position                           | Product or service purchase                         |
| Internal value units        | PC, SP, LTS                                             | Transaction revenue and reward allocation           |
| Main current strength       | Affiliate-entry scale                                   | Product and digital-service potential               |
| Main current weakness       | Entry-linked reward logic and unmeasured obligations    | Very small direct-product revenue compared with BGC |
| Strategic need              | Transparency, liability control, and product separation | Independent product demand and repeat usage         |

### 3.6 What Can Be Said About Member Motivation

The current rules and aggregate data support the conclusion that affiliate-entry cash dominates the recorded economy.

They do **not** directly measure why each member joined.

The responsible statement is:

> **The transaction pattern and reward design are consistent with an ecosystem in which the income opportunity is likely a stronger acquisition driver than independent product demand. Member motivation has not yet been directly measured.**

The correct test is whether customers buy the same products, at the same prices, without affiliate membership or income opportunity.

***

## 4. Complete Project Chronology

### 4.1 December 2024 — Initial Discovery Through Voyage

Voyage met Mr. Onggy, who introduced iBLOOMING and its AI-enabled education and profiling direction.

Voyage shared experience in Web3 and AI.

The relationship led to a Kuala Lumpur discussion with the five founders.

### 4.2 Kuala Lumpur — Web3 and AI Exploration

Voyage:

* explained blockchain, crypto assets, internal utility, ownership, and community mechanisms;
* used iBLOOMING as a case study;
* identified brand, communication, interface, and product-positioning opportunities.

No company-to-company Voyage project was finalized.

### 4.3 June–July 2025 — Individual Engagement

* Janet became Creative Lead.
* Prof. NOTA was engaged as blockchain and technology consultant.

The engagement required Prof. NOTA to discover the problem, translate founder expectations, and build the architecture and documentation.

### 4.4 July 2025 — Initial Web3 Pitch

The first proposal focused on:

* Web3 Login;
* unified wallet identity;
* ALPHA as a controlled loyalty simulation;
* user earn, save, and spend behaviour;
* utility before public-market exposure.

The proposal was primarily iBLOOMING-centered and did not yet include a complete BGC economic reconstruction.

### 4.5 10 July 2025 — Founder Meeting Day 1

The founders responded positively to Web3 Login.

ALPHA was described as a temporary simulation placeholder.

The discussion quickly expanded to:

* a public iBLOOMING token;
* BTC-linked value;
* liquidity;
* staking;
* governance;
* public-market utility.

This scope expanded before the full BGC model was understood.

### 4.6 11 July 2025 — Founder Meeting Day 2

KK explained:

* affiliate membership;
* Purchase Credit;
* Sales Points;
* network rewards;
* pools;
* BGC and iBLOOMING interaction.

Prof. NOTA recognized that part of the proposed ALPHA behaviour already existed off-chain.

Yuku raised fundamental questions about:

* token value;
* BTC linkage;
* legal implications;
* product use;
* sustainability.

The response at the time was too optimistic. Internal tokenization and future public-token paths were discussed before full rights, reserve, accounting, legal, and tax analysis.

This is now recognized as assumption debt.

### 4.7 August–October 2025 — System Reconstruction

Two important specifications were produced.

#### UNDERSTANDING Doc

A final AS-IS reference for:

* user types;
* affiliate levels;
* PC;
* SP;
* LTS;
* RR;
* GR;
* Miracle Cash;
* GPSP;
* WEC Pool;
* iBLOOMING transaction and reward distributions.

#### WEB3LOGIN Doc

A detailed architecture for:

* existing credential login;
* Passkey;
* post-login Wallet Setup;
* embedded EOA or connected wallet;
* deterministic Smart Account;
* identity mapping;
* API;
* security;
* DevOps;
* testing;
* rollout.

### 4.8 October–November 2025 — Whitepaper and Tokenflow Drafts

The drafts proposed:

* EventHub;
* AlphaController;
* PC/SP-to-ALPHA conversion;
* non-transferable ALPHA;
* spend/access/stake;
* cash-out windows;
* public iBC/iBTC;
* reserve and redemption concepts.

These documents made assumptions visible but did not resolve:

* PC product-right substitution;
* SP payout-right substitution;
* double entitlement;
* reserve backing;
* tax treatment;
* token-holder rights;
* public-market regulation.

### 4.9 November 2025 — Alignment Preparation

An Alignment Call document proposed:

* data mapping;
* simulation;
* Pilot v1;
* owners;
* governance;
* legal and risk discussion.

It is an agenda and expected-outcome document, not a complete decision record.

### 4.10 10 December 2025 — Founder Zoom

Project records indicate working alignment that:

* simulation should precede final token parameters;
* ALPHA should remain internal and non-public;
* public iBC/iBTC should remain a separate later track;
* legal review should be a gate;
* Web3 Login could proceed independently.

These are working alignments, not proof that the economics or legal structure were validated.

### 4.11 January 2026 — SIMULATION Doc v0.1

The document proposed:

* historical-data ingestion;
* PC/SP-to-ALPHA conversion parameters;
* reward intensity;
* sinks;
* cash-out policy;
* four scenarios;
* treasury, fairness, and user metrics.

Its weakness is that it began with token-policy simulation before complete historical accounting reconstruction.

### 4.12 March–June 2026 — SIMALPHA

Uncle Kal developed SIMALPHA as a real internal decision console with:

* versioned data snapshots;
* validation;
* scenarios;
* deterministic runs;
* comparison;
* result references;
* reporting and PDF export;
* actual-versus-forecast separation.

Prof. NOTA provided the business architecture and source documents.

Uncle Kal owned the simulator product and implementation decisions.

AI supported implementation but did not own business meaning.

### 4.13 May 2026 — Founder Feedback

The founders stated that they did not want to spend significant time learning technical reports.

They wanted:

* concrete findings;
* recommendations;
* options;
* decisions.

This changed the required output from “simulator demonstration” to “founder decision interface.”

### 4.14 June 2026 — Data Pipeline and First Scenario Reports

The available data for the current SIMALPHA scope was cleaned, restructured, and prepared for import.

This phase confirmed the completion of:

* collection of the available data;
* data cleaning;
* restructuring and formatting;
* import preparation;
* scenario execution;
* report generation.

Reports were produced for:

* Baseline;
* Conservative;
* Growth;
* Stress;
* cross-scenario comparison;
* founder reading support.

The precise interpretation of this completion is:

> **The current SIMALPHA data pipeline is complete for preliminary aggregate policy comparison. It is not final economic, accounting, legal, tax, or token evidence.**

***

## 5. Work Completed and Responsibility Boundaries

### 5.1 Prof. NOTA

* founder Web3 education;
* project discovery;
* meeting documentation;
* AS-IS rule reconstruction;
* UNDERSTANDING Doc;
* WEB3LOGIN architecture;
* LIVING coordination;
* Whitepaper and Tokenflow hypotheses;
* SIMULATION Doc;
* system-integration thinking;
* founder findings and recommendations;
* Product-Led strategic transition.

### 5.2 Uncle Kal

* SIMALPHA product definition;
* application architecture;
* data ingestion;
* validation;
* scenario engine;
* deterministic execution;
* reports;
* comparison;
* reproducibility;
* data restructuring;
* founder-readable output improvements.

### 5.3 Responsibility Boundary

Prof. NOTA is not the sole owner of:

* finance;
* accounting;
* forensic reconciliation;
* legal;
* tax;
* product cost;
* reserve certification;
* engineering implementation;
* multi-country compliance.

If founders want to proceed into those areas, accountable and qualified owners must be assigned.

***

## 6. SIMALPHA Findings

### 6.1 What SIMALPHA Was Designed to Test

SIMALPHA was designed as an internal economic and policy simulator for the BGC × iBLOOMING ecosystem.

Its primary purpose is to take an operating profile derived from available historical or forecast business data and test how different policy configurations affect the circulation, issuance, use, retention, and release of value inside the ecosystem.

The simulation process is:

```
Business data
→ simulation-ready operating profile
→ policy parameters
→ scenario execution
→ economic and treasury metrics
→ Ready / review / risk result
→ founder decision
```

The parameters tested may include, depending on the scenario:

* ALPHA issuance multipliers;
* reward intensity;
* user and group caps;
* internal-use or sink assumptions;
* cash-release thresholds;
* cash-release frequency;
* fees;
* treasury guardrails;
* other operational controls represented in the model.

SIMALPHA therefore does more than demonstrate that data can be imported or that reports can be generated.

It demonstrates how alternative policy configurations behave when applied to a defined BGC × iBLOOMING operating profile.

***

### 6.2 Historical Data, Forecast Data, and Simulation Meaning

SIMALPHA can conceptually operate with two different data modes.

#### Historical Operating Profile

Historical data answers:

> **If these policy and ALPHA rules had been applied to an economic pattern that actually occurred, how would the modeled system have behaved?**

This is a historical policy backtest.

A scenario that receives a `Ready` result means that the tested parameter configuration remains within the simulator's defined thresholds when applied to that historical operating profile.

#### Forecast Operating Profile

Forecast data would answer:

> **If the business achieves this future operating profile, how would the proposed policy configuration behave?**

In this mode, the forecast assumptions become operating targets or control assumptions that must later be compared with actual business performance.

The current four selected SIMALPHA reports use imported data rather than an activated Growth Forecast.

***

### 6.3 Meaning of a `Ready` Result

A SIMALPHA `Ready` result should be interpreted as:

> **The tested policy configuration is compatible with the tested operating profile under the thresholds and rules represented in the current simulation model.**

It does not mean that future business conditions are guaranteed to remain identical.

If an approved configuration is later implemented, the operating profile used in the simulation should become a reference benchmark or operating envelope.

Actual performance should then be monitored against material variables such as:

* cash inflow;
* reward generation;
* PC and SP activity;
* internal value usage;
* cash-release behaviour;
* reward concentration;
* other model inputs and guardrails.

Material deviation from the tested operating envelope should trigger review and, where appropriate, a new SIMALPHA run.

In this way, SIMALPHA can function not only as a pre-implementation simulator but also as an ongoing policy-control and decision-support tool.

***

### 6.4 Scope of the Current Compiled Dataset

The current SIMALPHA compiled dataset contains:

* 236 simulation-ready records;
* 25 monthly periods;
* April 2024–April 2026;
* BGC and iBLOOMING monthly-tier records.

The `member_key` values in this compiled dataset are synthetic monthly-tier identifiers rather than persistent individual-member identities.

This describes the structure of the **compiled SIMALPHA input**.

It should not be interpreted as meaning that more granular raw business or member-level source data does not exist.

The raw source material available during the project included multiple datasets and more granular records. The current SIMALPHA dataset represents the portion that was interpreted, transformed, structured, and prepared into a consistent format for the present simulation scope.

Further use of additional raw source tables for institutional accounting, member-level reconstruction, or other purposes would require confirmed data semantics, table relationships, source ownership, and cross-functional validation.

***

### 6.5 Aggregate Data Used in the Current Simulation Scope

| Metric                        |           BGC |  iBLOOMING |      Combined |
| ----------------------------- | ------------: | ---------: | ------------: |
| Cash in                       | $4,034,038.00 | $21,117.00 | $4,055,155.00 |
| Recognized-revenue field      | $4,034,038.00 |  $6,335.10 | $4,040,373.10 |
| Gross-margin field            | $4,034,038.00 |  $6,335.10 | $4,040,373.10 |
| Internal credit or sink spend |   $567,234.00 |      $0.00 |   $567,234.00 |
| PC volume                     |   403,403,617 |          0 |   403,403,617 |
| SP reward basis               |     2,823,835 |          0 |     2,823,835 |
| Global/direct reward          |   $411,385.60 |  $1,429.46 |   $412,815.06 |
| Pool reward                   |   $508,288.57 |    $950.52 |   $509,239.09 |
| Historical cash-out           |   $546,506.11 | $25,715.08 |   $572,221.19 |

These fields form part of the operating profile used by the current simulation model.

They should be read according to their SIMALPHA data definitions and should not automatically be treated as audited accounting classifications.

***

### 6.6 What the Current Data and Simulation Show

The current SIMALPHA work shows that:

* the available business data can be transformed into a consistent simulation-ready operating profile;
* historical BGC and iBLOOMING economic activity can be used as the basis for policy testing;
* policy parameters materially change ALPHA issuance, use, held balances, and modeled cash release;
* different scenario configurations can be evaluated against defined treasury and policy thresholds;
* the current Baseline, Conservative, Growth, and Stress-labelled configurations all return `Ready` within the present model thresholds;
* recorded BGC cash-in is approximately 191 times recorded iBLOOMING cash-in;
* the tested historical operating profile is economically dominated by BGC affiliate-entry transactions;
* iBLOOMING direct product cash-in is very small by comparison;
* existing BGC reward formulas are materially connected to new-join LTS.

These are valid outputs of the current simulation scope.

***

### 6.7 What the Current Results Should Not Be Interpreted As

A `Ready` simulation result is not the same as an automatic company-wide implementation approval.

The current results should not, by themselves, be interpreted as:

* an audited financial statement;
* a certification of company-wide profitability;
* a legal opinion;
* a tax opinion;
* a guarantee that future operating conditions will match historical conditions;
* approval of a freely tradable or publicly listed token;
* proof of a public token's future market price;
* approval of economic behaviours that were not represented in the tested data and model.

SIMALPHA can evaluate model-level sustainability and policy compatibility under the tested conditions.

It should not be described as a standalone certification of every accounting, legal, operational, product, or market dimension of BGC × iBLOOMING.

Where a final implementation decision depends on those additional dimensions, the relevant internal owners and professional functions must validate them.

***

### 6.8 On-Chain Interpretation

The current simulation is most directly relevant to an on-chain system that represents substantially the same value flows and economic rights that were included in the simulation.

If ALPHA or another on-chain mechanism is implemented as an internal representation of existing economic activity, its rules should remain within the tested policy boundaries unless a new simulation is performed.

The simulation should not be interpreted as having tested economic behaviours that were not included in the source operating profile.

For example, if the tested business data does not contain:

* open-market trading;
* speculative price discovery;
* public liquidity;
* governance markets;
* unrestricted token transfer;

then the current SIMALPHA results should not be treated as validation of those behaviours.

Any materially different economic function requires a separate model, dataset, scenario, and decision process.

***

### 6.9 Current Scenario Interpretation

#### Baseline

The Baseline scenario is intended to stay close to the existing operating behaviour and provide a reference configuration.

#### Conservative

The Conservative scenario applies tighter policy controls and lower value-release intensity.

#### Growth

The Growth scenario applies more permissive or expansion-oriented policy parameters.

The current report should not be interpreted as a forecast of actual future business growth because the selected results use imported data with Growth Forecast disabled.

#### Stress

The original SIMULATION Doc defined Stress testing around external shocks such as:

* revenue decline;
* rapid membership growth;
* cash-out spikes;
* changes in internal-use behaviour.

The current selected `Stress` report does not apply that full external-shock design.

It primarily applies a more restrictive policy configuration to the same imported operating data.

For the current report set, it is therefore more accurately interpreted as:

> **Treasury Preservation / Restrictive Policy Scenario**

This does not invalidate the result.

It clarifies what the current result actually tests.

A future true stress run may separately apply external shocks to the operating data.

***

### 6.10 Report and Decision Status

The current reports return `Ready` for all four selected scenarios within the present simulation thresholds.

This simulator verdict should remain visible.

The correct distinction is:

#### Simulation Verdict

> **Ready**

Meaning:

> The tested configuration passes the thresholds represented in the current model when applied to the tested operating profile.

#### Implementation Decision

> **Pending Founder Decision**

Meaning:

> A `Ready` simulator result does not automatically authorize implementation.

Founders must still decide:

* whether the existing economic system should be represented on-chain at all;
* which rights or value flows, if any, should be represented;
* which tested parameter configuration should be considered;
* what operational conditions must be maintained;
* what additional accounting, legal, tax, technical, or business validation is required for the selected implementation.

***

### 6.11 SIMALPHA Phase-1 Conclusion

SIMALPHA has successfully completed its current Phase-1 purpose as an internal policy and economic simulation tool.

It has:

* transformed available business data into a simulation-ready operating profile;
* enabled repeatable scenario execution;
* tested alternative policy configurations;
* produced measurable differences between configurations;
* identified configurations that pass the current model thresholds;
* exposed the economic characteristics of the operating data;
* created a structured basis for founder decisions.

The responsible conclusion is therefore not:

> “SIMALPHA failed to prove sustainability.”

The more accurate conclusion is:

> **SIMALPHA demonstrates model-level policy compatibility and sustainability under the tested operating profile and defined thresholds. Any decision to implement an on-chain representation of those economic flows remains conditional on founder approval, institutional validation of the selected rights and operating conditions, and the scope of the implementation being materially consistent with what was actually simulated.**

***

## 7. Core Findings

### 7.1 Existing-System Tokenization Is Not Approved

The existing system must not be tokenized at this stage.

Reasons:

* PC and SP represent different rights;
* conversion may create duplicate entitlements;
* obligations are not fully reconciled;
* public-token backing is unresolved;
* legal and tax treatment is unresolved;
* the current data is aggregate;
* tokenization could make an entry-driven model more programmable without making it more productive.

### 7.2 Internal Circulation Is Not New Economic Value

Keeping value inside the ecosystem may delay cash outflow.

It does not automatically create external demand, margin, profit, productivity, or reserve.

### 7.3 Tokenization Does Not Create Product Demand

A token can support ownership, access, auditability, interoperability, and provenance.

It cannot substitute for product quality, pricing, distribution, customer demand, retention, supply chain, or customer support.

### 7.4 Web3 Login Remains Valid

Web3 Login has independent value.

It can support:

* unified identity;
* wallet ownership;
* digital receipts;
* product passports;
* credentials;
* token-gated access;
* retailer verification;
* creator entitlements.

Its continuation is justified by its product and infrastructure value, not merely because time has already been spent.

### 7.5 Product Demand Must Become Measurable

BGC × iBLOOMING should measure:

* non-affiliate product buyers;
* affiliate buyers paying new fiat;
* PC redemptions;
* repeat product purchases;
* subscription retention;
* content completion;
* product margin;
* customer-acquisition cost;
* willingness to purchase without financial reward.

***

## 8. Product-Led Strategic Transition

### 8.1 New Strategic Thesis

> **BGC × iBLOOMING should progressively reduce dependence on reward-led acquisition and build a measurable product-led commercial engine. Blockchain and AI should support real products and operations, not become a substitute for product value.**

### 8.2 Product-Led Workstreams

#### Workstream 1 — Web3 Identity

* implement approved Web3 Login;
* create wallet readiness;
* support cross-application identity.

#### Workstream 2 — Product Demand

* separate customers from affiliates;
* run product-first campaigns;
* measure conversion, usage, and repeat purchases.

#### Workstream 3 — Commerce and Distribution

* product catalogue;
* SKU and batch structure;
* inventory;
* wholesale and retail flows;
* distributor and retailer management;
* fulfillment;
* digital commerce.

#### Workstream 4 — Product Trust and Ownership

* authenticity;
* product passports;
* warranty;
* ownership records;
* proof of purchase;
* traceability.

#### Workstream 5 — Digital Access

* course and content entitlements;
* subscriptions;
* access passes;
* credentials;
* product-content bundles.

#### Workstream 6 — AI Enablement

* product recommendation;
* support;
* creator tools;
* product-content matching;
* operational analytics;
* demand insights.

#### Workstream 7 — Evidence and Governance

* KPIs;
* decision logs;
* privacy;
* legal gates;
* pilot review;
* resource ownership.

### 8.3 Technology Principle

> **Use conventional technology where it is sufficient. Use blockchain where verifiability, ownership, portability, provenance, interoperability, or multi-party trust creates measurable value. Use AI where it measurably improves decisions, operations, content, or user experience.**

Blockchain and AI do not automatically reduce cost or increase security.

Every proposed use must compare:

* conventional database option;
* blockchain option;
* AI-assisted option;
* total cost;
* operational risk;
* user value.

***

## 9. Recommended Product Pilots

### 9.1 Physical Product Passport

A customer buys a physical product with fiat.

The wallet receives a non-tradable or controlled digital credential containing:

* SKU;
* serial or batch;
* authenticity;
* warranty;
* instructions;
* after-sales access.

### 9.2 Digital Access Pass

A customer buys GiM, iLearn, a course, or a content package with fiat.

The wallet receives an access credential.

The pilot measures activation, content usage, completion, retention, and support burden.

### 9.3 Product and Content Bundle

One purchase may combine:

* physical product;
* digital content;
* onboarding;
* warranty;
* education;
* access credential.

This links BGC and iBLOOMING through product utility, not income promises.

### 9.4 Retailer or Distributor Credential

Verified retailers or distributors receive credentials showing authorization, product range, territory, validity, and status.

### 9.5 Pilot Rules

Each pilot must:

* be limited in scope;
* use fiat settlement;
* not promise yield;
* not depend on recruitment;
* not create a tradable speculative asset;
* have measurable KPIs;
* have a stop condition;
* have a named business owner.

***

## 10. Public Token and Financial-Product Boundaries

### 10.1 Public Token

Any future public token must be separate from the BGC affiliate engine.

It must not:

* be funded through affiliate entry;
* be distributed as recruitment compensation;
* convert PC or SP by default;
* settle existing obligations without explicit treatment;
* promise yield;
* promise buyback;
* promise price support;
* promise appreciation;
* use new-token buyers to fund existing rewards.

### 10.2 Financial-Return Appetite

The apparent interest of members in financial rewards must not be treated as proof that a new financial product is needed.

It does not validate deposits, yield products, lending, staking return, DeFi, DEX, CEX, or fundraising.

Any such business would require separate governance, qualified regulatory advice, licensing analysis, risk management, capital, custody, security, and an independent economic source of yield.

### 10.3 Current Recommendation

> **Do not propose a BGC × iBLOOMING DeFi, DEX, CEX, deposit, yield, or fundraising product as the next phase.**

***

## 11. Strategic Options

### Option A — Product-Led Transformation With Conventional Technology

Focus on product, commerce, demand, distribution, data, and operations.

Use blockchain only when later justified.

**Recommendation:** Core strategy.

### Option B — Product-Led Transformation With Web3 Identity and Credentials

Implement:

* Web3 Login;
* product passports;
* access credentials;
* retailer credentials;
* receipts.

No public token.

**Recommendation:** Preferred first implementation path.

### Option C — Event Anchoring or Shared Audit Layer

Use blockchain for tamper-evident proofs, selected shared events, and multi-party verification.

No token unless separately justified.

**Recommendation:** Research after data architecture is stable.

### Option D — Non-Transferable Internal Rights

Consider only when the right is precisely defined, liability treatment is complete, and conventional credentials are insufficient.

**Recommendation:** Hold.

### Option E — Public Utility Token

Consider only after independent product demand, legal and tax review, market need, rights and reserve design, and separate governance.

**Recommendation:** Optional research only.

***

## 12. Founder Decisions Required

1. Approve or reject Product-Led strategic transition.
2. Authorize Web3 Login implementation.
3. Close the old existing-system tokenization roadmap.
4. Decide public-token status.
5. Select one physical and one digital product pilot.
6. Separate product and affiliate metrics.
7. Appoint resources and owners.
8. Approve the financial-product boundary.
9. Confirm Prof. NOTA’s role as Product and Web3 Transformation Consultant.
10. Authorize preparation of the Product-Led Systems Program 2026–2027.

Detailed decision wording is provided in the Founder Decision Brief.

***

## 13. Post-Meeting Roadmap

### First 30 Days

* publish meeting resolutions;
* close old LIVING Doc;
* appoint owners;
* begin Web3 Login implementation planning;
* select product pilots;
* define product-demand baseline;
* correct SIMALPHA report labels.

### Days 31–60

* run product-first campaign experiments;
* implement the first identity and access integration;
* create product and commerce data models;
* measure conversion and usage;
* decide whether product passports or access credentials add value.

### Days 61–90

* evaluate pilots;
* publish evidence;
* decide whether to scale;
* create new Product Paper, System Design, or Product Flow only for approved use cases.

No public-token timeline should be established during this period.

***

## 14. Recommended Founder Resolution

> BGC × iBLOOMING acknowledges that Phase 1 produced a final AS-IS rules reference, a founder-approved Web3 Login architecture, a working SIMALPHA decision-support application, a prepared aggregate dataset, and preliminary simulation reports.
>
> The founders acknowledge that the current evidence does not support final tokenization of the existing membership, PC, SP, reward, pool, or payout system.
>
> BGC × iBLOOMING therefore resolves to:
>
> 1. close the old existing-system tokenization track as an automatic implementation roadmap;
> 2. proceed with Web3 Login as a separate infrastructure project;
> 3. shift the next program toward Product-Led Systems Transformation;
> 4. validate independent demand for physical and digital products;
> 5. begin with limited, non-tradable product, access, ownership, or credential pilots;
> 6. keep public-token research separate from the affiliate engine;
> 7. prohibit using the affiliate network as a channel for a new deposit, yield, DeFi, DEX, CEX, or fundraising product under this program;
> 8. assign qualified owners for finance, accounting, legal, tax, data, product, operations, and engineering work;
> 9. create new documents for new approved use cases rather than rewriting archived tokenization drafts.

***

## Appendix A — Artifact Status Summary

| Artifact             | Final Status                                    |
| -------------------- | ----------------------------------------------- |
| UNDERSTANDING Doc    | Final AS-IS reference                           |
| WEB3LOGIN Doc        | Final and approved; implementation pending      |
| Old LIVING Doc       | Close after final transition update             |
| Whitepaper Drafts    | Archive as hypotheses                           |
| Tokenflow Drafts     | Archive as hypotheses                           |
| SIMULATION Doc v0.1  | Archive as first token-policy simulation design |
| SIMALPHA             | Working MVP                                     |
| Compiled Dataset     | Complete for current aggregate scope            |
| Scenario Reports     | Technically complete; analytically preliminary  |
| Master Document v1.0 | Active founder decision source                  |
| Product-Led Program  | Pending founder approval                        |

***

## Appendix B — Evidence Required Only If Tokenization Continues

* PC issued, redeemed, outstanding, expired, and fulfillment cost;
* rewards credited, paid, retained, and reinvested;
* pools accrued, funded, distributed, and outstanding;
* opening and current reserve;
* product COGS;
* operating expenses;
* intercompany transfers;
* stable member identity;
* legal and tax opinions;
* token-holder rights;
* reserve and redemption design.

This work must be institutionally owned. It is not a solo responsibility of Prof. NOTA.

***

## Appendix C — Closing Statement

> The most important result of this year is not a token.
>
> The result is a clearer understanding of where technology creates value and where it could amplify risk.
>
> BGC × iBLOOMING does not need a new way to make people more interested in putting money into a system. It needs stronger reasons for people to buy, use, trust, and return to its products.
>
> Web3 Login, product ownership, access, authenticity, distribution, and AI-enabled product experiences can support that direction. A public token should remain optional and separate until product demand and institutional readiness are proven.

***

P.S. Read this document freely for information and guidance. Do not redistribute or restate—no quotes, summaries, paraphrases, or derivatives—without prior written permission from [**Prof. NOTA**](https://nota.endhonesa.com/). Sharing the link is allowed. So, share the link, not the text. Do not discuss or re-tell the contents in any form—written, spoken, or recorded—without prior written permission.

***