SIMALPHA OH SIMALPHA

Version: 1.0 Prepared for: BGC × iBLOOMING Founders and Core Team Prepared by: Prof. NOTA Simulator owner and principal implementer: Fabio Kalandra (“Uncle Kal”) Date: 5 August 2026 Status: Active decision-support reference

1. Purpose

This document explains:

• what SIMALPHA is;

• what it successfully does;

• what its current data and reports support;

• what they do not support;

• how founders should read the first simulation results;

• what must be corrected before future policy approval.

It replaces the Founder’s Reading Guide as the current interpretation authority.

It does not replace the original reports. The original reports remain preserved as first-version outputs.

SIMALPHA is an internal decision-support web application.

Its workflow allows a permitted user to:

1. upload or select a versioned business-data snapshot;

2. define or select a policy scenario;

3. run a deterministic simulation;

4. review money, ALPHA, distribution, and risk outputs;

SIMALPHA is not:

• a public token;

• a smart-contract deployment;

• a wallet;

• a cash-out system;

The working MVP includes:

• data-snapshot versioning;

• import and validation;

• scenario storage;

• deterministic execution;

This is a substantial technical deliverable.

The application is suitable for structured internal policy exploration.

The current compiled dataset contains:

• 236 records;

• 25 monthly periods;

• April 2024–April 2026;

• BGC and iBLOOMING records;

Examples of synthetic record keys include combinations such as:

• BGC + month + membership tier;

• iBLOOMING + month + membership tier.

These are not persistent individual member identities.

The dataset can support:

• monthly aggregate analysis;

• source-system comparison;

• tier comparison;

• issuance and cash-release sensitivity;

It cannot validly support:

• real active-user count;

• new-user count;

• retained-user count;

• churn;

Any metric derived by treating each aggregate record as a person must be removed or relabeled.

The dataset labels BGC cash-in as:

• cash in;

• recognized revenue;

• gross margin.

These labels must not be interpreted as audited revenue, gross margin, profit, or free cash.

The available data does not deduct:

• physical-product cost;

• inventory;

• shipping;

• fulfillment;

An initial policy reference using the current model assumptions.

It is not a validated reproduction of the complete historical economy.

A lower-issuance and lower-cash-release policy.

It demonstrates sensitivity to tighter parameters.

A higher-issuance and higher-cash-release policy.

It does not demonstrate real revenue or user growth because no independent future-growth evidence is included.

The name is misleading.

The scenario:

• uses the same imported historical business data;

• has no meaningful future shock;

• mainly lowers issuance;

• tightens caps;

Correct interpretation:

Treasury Preservation / Restrictive Policy Scenario

It retains the most modeled cash because the model releases the least cash.

That is a parameter consequence, not an independent finding that the policy is best.

Replace:

• Ready;

• Needs Review;

• Do Not Use.

With:

All four current scenarios should carry:

Preliminary Pass — Insufficient Evidence for Implementation Approval

Replace:

ALPHA is the practice version of iBC/iBTC.

With:

ALPHA is a neutral simulation unit used to test alternative representations of rights, rewards, access, or internal value. It does not imply that a public token will be launched.

Replace:

Actual Payout Out

With:

Modeled ALPHA Cash Release

Historical cash-out is a different data field and must be shown separately.

This statement must be removed.

PC and SP represent different rights.

Any future conversion must define:

• which original right is extinguished;

• whether conversion is reversible;

• whether product or payout rights remain;

• whether the conversion creates a new liability.

Replace:

Net Cash

With:

Incomplete Net Cash Proxy

Until the model includes:

• rewards payable;

• pools;

• fulfillment;

• COGS;

Remove or relabel:

• Active User Count;

• New Active User Count;

• Retained Active User Count;

• Affiliate Retention;

Suggested label where retained:

Aggregate Segment Concentration

The current source data contains:

• pool reward fields;

• historical cash-out fields;

• internal credit spend.

The first reports show:

• pool funding owed = zero;

• much lower modeled ALPHA cash release;

• fulfillment cost = zero.

This does not automatically prove a software bug.

It proves that field mapping, liability treatment, or policy treatment is incomplete or undocumented.

The next technical review should trace:

SIMALPHA can support decisions such as:

• whether a scenario issues more or less ALPHA;

• whether cash-release restrictions retain more modeled cash;

• whether report outputs change consistently;

It can support the conclusion:

Do not approve current tokenization.

It cannot support the conclusion:

This system is economically safe and ready for token implementation.

Required:

• versioned input;

• documented mapping;

• reproducible results;

• no unsupported member-level metrics.

Required:

• reproduce historical observed totals;

• separate actual from modeled values;

• explain every material difference.

Required:

• PC obligations;

• reward obligations;

• pool obligations;

• COGS;

Required:

• independent product buyers;

• repeat purchases;

• product usage;

• margin;

Only after Gates 0–3:

• caps;

• fees;

• internal access;

• entitlement policy;

Compare:

• conventional database;

• EventHub or evidence anchoring;

• non-transferable credential;

• internal rights;

No token implementation before written approval.

Before reading numbers, confirm whether the report says:

• actual;

• modeled;

• assumed;

• missing;

A scenario is useful only when the changed rules are clear.

Always check:

• obligations;

• costs;

• reserve;

• rights;

Every future token-related simulation must include:

No-token / conventional-system control

A simulator result should lead to one of:

• reject;

• study further;

• request evidence;

• approve limited pilot;

“Green” is not automatically approval.

1. Select a versioned dataset.

2. Confirm source and mapping notes.

3. Select a scenario.

4. review changed parameters;

• change verdict labels;

• add Insufficient Evidence;

• relabel cash release;

• relabel net cash;

• reconcile pool fields;

• reconcile partner payouts;

• reconcile fulfillment;

• trace internal credit;

• calibrate against observed totals;

• show differences;

• explain opening and closing balances.

Add support for:

• independent product demand;

• direct product sale;

• repeat purchase;

• product margin;

Apply:

• new-join decline;

• product-revenue decline;

• cash-out increase;

• PC redemption increase;

SIMALPHA is a working internal decision-support MVP with preliminary policy-sensitivity outputs. It is not yet a calibrated historical economic replay, a validated sustainability model, or a basis for final token parameters.

This is not a failure.

It is the correct status for a first serious simulation product.

The next value of SIMALPHA is to support Product-Led evidence, no-token controls, and disciplined founder decisions.

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 . 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.