Product: Product Experience

6.1 Introduction

Product is MICROBA's product capability.

It manages the product experience from discovery through selection and into the member's continuing Product journey.

Product does not own payment processing, member identity, HIVE sponsorship, or SA circulation. Those responsibilities belong to their respective MICROBA capabilities.

The core principle is:

**Product owns the product and its experience. Commerce owns the

commercial transaction.**

A person may discover a MICROBA Product as a Visitor, become a member where required, purchase directly with or without a sponsor, and continue the Product experience through their Living Identity.

6.2 Product Is Independent of HIVE

A MICROBA Product does not require HIVE participation.

A member may purchase a Product without:

• becoming an affiliate;
• sponsoring another person;
• building a network; or
• having a Direct Sponsor.

Conceptually:

Member
  |
Product
  |
Purchase
  |
Commerce

HIVE is evaluated separately only when a valid Direct Sponsor relationship and an eligible sale exist.

6.3 Product Discovery

Products may be discovered through approved public and member experiences, including:

• the MICROBA website;
• Product pages;
• Articles;
• Launch events;
• the MICROBA chatbot;
• direct links;
• member invitations;
• HIVE referrals; and
• other approved channels.

Product discovery does not itself create a sale, HIVE commission, or SA entitlement.

6.4 Visitor Product Experience

A Visitor may be allowed to view public Product information before joining.

Public information may include:

• Product name;
• Product purpose;
• description;
• images;
• standard price;
• available set or quantity options;
• general usage information;
• educational context;
• FAQs; and
• applicable public terms.

Protected member-specific information remains private.

6.5 Product Identity

Every Product should have a stable system identity.

A Product record may conceptually include:

• Product ID;
• Product Name;
• SKU or equivalent commercial identifier;
• Product Type;
• status;
• standard price;
• currency;
• eligibility rules;
• images/assets;
• Product metadata; and
• versioned commercial configuration where applicable.

The exact technical schema belongs to the Product architecture specification.

6.6 Standard Price

The Product capability provides the authoritative Product pricing configuration used to construct a commercial request.

For the current model under discussion, a Product may have a standard price such as:

1 Set       = Rp10,000
10 Sets     = Rp100,000
100 Sets    = Rp1,000,000
1,000 Sets  = Rp10,000,000

The unit price remains consistent unless an approved pricing or discount rule applies.

The Product page should clearly distinguish:

• standard price;
• quantity;
• applicable discount;
• SA usage; and
• final commercial amount.

6.7 Quantity

A purchaser may select an available quantity or set count according to Product rules.

Conceptually:

Unit Price x Quantity
        |
Gross Product Value
        |
Applicable Adjustments
        |
Commercial Request

Product determines which quantities are available.

Commerce receives the committed commercial snapshot and must not trust a browser-supplied amount as authoritative.

6.8 Product Selection

The Product experience may allow the member to configure an eligible selection.

Depending on the Product, this may include:

• quantity;
• variation;
• package;
• delivery option;
• Product-specific choices; and
• other approved configuration.

The final selection becomes a Product snapshot before Commerce creates the order.

6.9 Living Snapshot

Where a Product journey requires a committed configuration, Product produces a validated Living Snapshot.

The Living Snapshot represents the Product state that the purchaser has committed to for the commercial transaction.

Conceptually:

Product Journey
      |
Member Selection
      |
Validation
      |
Living Snapshot
      |
Commerce

The snapshot protects the commercial transaction from later changes to the Product page or configuration.

6.10 Product Does Not Create the Order

Product initiates commercial intent but does not own the order.

Canonical flow:

Product
   |
Validated Product / Living Snapshot
   |
Commercial Request
   |
Commerce::createOrder()
   |
Commerce Order

Once Commerce creates the order, Commerce becomes the source of truth for the commercial transaction.

Product should reference the Commerce order rather than creating a competing order record.

6.11 Commerce Owns Checkout

Checkout belongs to Commerce.

Product should not independently implement:

• payment-provider selection;
• payment tokens;
• payment confirmation;
• payment webhook processing;
• transaction settlement;
• receipt generation; or
• commercial payment status.

The Product experience hands the validated commercial request to Commerce.

6.12 Combined Cart and Checkout

The current MICROBA Commerce direction supports a combined Living Cart + Checkout experience for the expected low-item-volume Product journey.

Conceptually:

Product
  |
Committed Snapshot
  |
Commerce
  |
Living Cart + Checkout
  |
Payment

This keeps the purchase journey simple without changing Product ownership.

6.13 Secure Commercial Snapshot

The browser must not be trusted to determine authoritative commercial values.

Commerce should receive or resolve trusted server-side information such as:

• Product identity;
• quantity;
• unit price;
• gross value;
• eligible discount;
• SA usage;
• currency;
• Product snapshot; and
• applicable commercial metadata.

A user changing browser parameters must not be able to change the authoritative order amount.

6.14 Purchase Without a Sponsor

A Product may be purchased without a sponsor.

Example:

Member
  |
Select Product
  |
No Direct Sponsor
  |
Commerce
  |
Payment
  |
Order Complete

The purchase remains valid.

HIVE commission is zero where no valid Direct Sponsor exists.

Applicable SA rules continue independently.

6.15 Purchase With a Direct Sponsor

Where the purchaser has a valid Direct Sponsor relationship:

Member B
  |
Direct Sponsor = A
  |
Product Purchase
  |
Commerce
  |
Eligible Sale
  |
HIVE
  |
Applicable 9% Direct Sponsorship

Product does not calculate the sponsorship commission.

HIVE owns sponsorship rules.

6.16 Personal Purchase

A member may purchase Product for personal use.

Personal purchase is a valid Product and Commerce activity.

However:

Personal Purchase
      |
Self-Sponsorship Commission
      |
      NO

Applicable SA provision may still arise from eligible personal sales according to SA rules.

6.17 Product and SA

Product and SA are separate capabilities.

A Product purchase may interact with SA in two directions:

1. eligible sales may contribute to SA provision; and
2. existing SA may be used as an eligible purchasing benefit.

The Product capability should not mint, recycle, transfer, or redeem SA itself.

Those actions belong to the SA system, coordinated with Commerce where commercial activity is involved.

6.18 Current SA Provision Reference

The current system model uses a 3% SA provision/allocation reference on eligible sales.

At the current programme reference:

1 SA = Rp30,000

Example:

Eligible Sales: Rp1,000,000
3% Provision:   Rp30,000
Whole SA:       1

A smaller purchase may create backend provision.

Example:

Purchase:       Rp10,000
3% Provision:   Rp300

Rp300 is provision value, not 0.01 SA held by the member.

SA is issued as whole uniquely numbered units when the applicable entitlement threshold is reached.

6.19 SA as a Product Purchasing Benefit

Eligible SA may be used toward Product purchases according to programme rules.

The current architecture allows SA to function as a purchasing benefit or discount mechanism.

Example:

Product Value: Rp300,000
SA Used:       2 SA
Reference:     Rp30,000 per SA

SA Benefit:    Rp60,000
Remaining:     Rp240,000

The exact checkout presentation may use simpler public wording later.

At system level, Commerce must record the SA-funded and other payment portions accurately.

6.20 100% SA-Funded Purchase

The architecture permits an eligible purchase to be funded entirely with SA where programme rules allow it.

Example:

Product Value: Rp300,000
SA Used:       10 SA
Reference:     Rp30,000 per SA

Remaining Cash Payment: Rp0

This is still a real Commerce transaction.

The system must record:

• Product value;
• SA used;
• serial numbers involved;
• applicable sales treatment;
• resulting SA movement; and
• downstream eligibility according to approved rules.

A zero cash balance does not mean that no transaction occurred.

6.21 No Arbitrary SA Limit Required by Product

Product should not impose an artificial SA limit merely because a high-SA purchase could reduce the cash amount substantially.

If the approved programme permits full SA usage, Product and Commerce should support it.

Any future SA usage restriction must be an explicit programme rule rather than an accidental interface limitation.

6.22 SA Serial Movement

When SA is used in an eligible Product transaction, the system must preserve the identity of the SA involved.

Example:

Member
  |
SA-000125
SA-000402
  |
Used in Product Purchase
  |
Treasury

The serial numbers do not disappear.

They move according to SA/Treasury rules and may later be recycled.

6.23 Recycle Before Mint

Product sales may create new SA entitlement, but Product does not decide whether a new SA should be minted.

The SA system follows:

Recycle First. Mint Only the Shortage.

Example:

Entitlement Requires: 5 SA

Treasury Available:   3 SA
Recycle:              3 SA
Mint New:             2 SA

Only the shortage receives newly created serial numbers.

6.24 Product Discounts

Product may support approved discount rules.

A discount should be explicit and traceable.

The system should distinguish between:

• standard Product price;
• quantity-based pricing where approved;
• promotional discount;
• SA purchasing benefit;
• other approved discount; and
• final amount.

These concepts should not be mixed into one unexplained number.

6.25 Product Pricing and HIVE Eligibility

The displayed Product price and HIVE eligible-sales amount are related but not necessarily identical concepts.

Commerce must determine the authoritative eligible commercial basis after applicable adjustments.

HIVE then applies its rule to the eligible amount.

Product should not independently calculate the 9% commission.

6.26 Product Pricing and SA Eligibility

Likewise, Product should not independently decide the final SA entitlement.

Commerce provides the authoritative eligible sales event.

The SA system evaluates provision and entitlement according to approved SA rules.

Conceptually:

Product
  |
Commercial Snapshot
  |
Commerce
  |
Eligible Sales Event
  |
  +---- HIVE
  |
  +---- SA

6.27 Product Order Status

Product may display the commercial status of a related order, but Commerce owns that status.

Examples may include:

Pending Payment
Paid
Processing
Completed
Cancelled
Refunded

Product should consume the Commerce state rather than maintaining a contradictory local payment status.

6.28 Product Fulfilment

After Commerce confirms the required transaction state, Product or another designated fulfilment capability may continue the Product journey.

Conceptually:

Commerce Payment Confirmed
          |
Commerce Event
          |
Product / Fulfilment
          |
Next Product State

The exact fulfilment responsibility depends on the Product type.

6.29 Product Journey

A MICROBA Product may represent more than a simple SKU.

Where applicable, Product may support a continuing journey around the member's purchase.

A conceptual journey may include:

Discover
   |
Select
   |
Purchase
   |
Activate
   |
Use / Participate
   |
Progress
   |
Complete / Continue

The Product engine owns the Product-specific states.

Commerce owns only the commercial agreement and payment lifecycle.

6.30 Product and Profile

My MICROBA may display Product information related to the member.

For example:

MY MICROBA

My Products
Active Journey
Previous Products
Product Status

Profile does not become the owner of Product records.

Product remains the source of truth for Product-specific activity.

6.31 Product and Knowledge

Product may link to relevant educational Articles or Knowledge activities.

For example:

Product
  |
Learn More
  |
Knowledge / Article

However, Product usage does not automatically mean that a member has completed a Knowledge activity.

Knowledge progress follows Knowledge rules.

6.32 Product and Launch

Launch events may introduce or explain MICROBA Products.

An event may link to a Product page.

However:

Launch owns Event
Product owns Product
Commerce owns Transaction

An event should not duplicate Product pricing logic.

6.33 Product and Visitor

Visitors may discover public Product information.

If a Product requires a member identity before purchase:

Visitor
  |
Product
  |
Purchase Intent
  |
JOIN / SIGN IN
  |
Living Identity
  |
Return to Product / Commerce

The system should preserve the safe purchase intent where possible.

6.34 Product and Membership

Product should use the canonical MICROBA Living Identity.

It must not create a separate Product-only member identity.

The MID provides the stable connection between the member and their Product activity.

6.35 Product Ownership

Product owns Product-domain information.

Examples include:

• Product definition;
• Product configuration;
• Product availability;
• Product-specific rules;
• Product journey state;
• Product assets; and
• Product-specific member progress where applicable.

Product does not own:

• member identity;
• sponsor relationship;
• payment transaction;
• SA serial registry;
• Knowledge progress; or
• Launch events.

6.36 Product Availability

A Product may have an availability state.

Examples may include:

Draft
Active
Unavailable
Paused
Retired

An unavailable or retired Product should not silently disappear from historical orders.

Commerce history must continue to reference the Product snapshot that existed when the order was created.

6.37 Product Versioning

Product information may change over time.

For example:

• description;
• image;
• package;
• price;
• formula;
• availability; or
• Product-specific rules.

Historical Commerce transactions must preserve the commercial snapshot applicable at the time of purchase.

A future Product update must not rewrite the historical order.

6.38 Price Changes

If the standard price changes after an order is created, the existing Commerce order should retain its committed commercial snapshot according to Commerce rules.

Example:

Day 1
Product Price = Rp10,000
Order Created = Rp10,000

Day 5
Product Price Changes = Rp12,000

Existing Day 1 Order
Remains based on committed Rp10,000 snapshot

A new order uses the current approved price.

6.39 Product Images and Assets

Product may own approved Product media such as:

• Product images;
• packaging images;
• educational diagrams;
• Product banners;
• instructions; and
• related assets.

Assets should be versioned or managed appropriately so historical and current experiences remain understandable.

6.40 Product Information Integrity

Product information should be accurate and governed.

The system should avoid:

• misleading prices;
• unsupported claims;
• inconsistent descriptions;
• stale availability;
• conflicting package information; and
• duplicated Product identities.

Material changes should follow appropriate administrative controls.

6.41 Product Administration

Authorized administrators may manage Product configuration according to capabilities.

Administrative actions may include:

• create Product;
• edit Product;
• activate Product;
• pause Product;
• retire Product;
• manage price;
• manage Product assets;
• manage eligibility; and
• manage Product-specific configuration.

Important changes should be auditable.

6.42 No Silent Historical Rewriting

Product configuration changes must not silently rewrite historical commercial facts.

For example, changing today's Product price must not change yesterday's paid order.

The platform should distinguish:

Current Product Definition
        vs.
Historical Order Snapshot

This is essential for reconciliation.

6.43 Product Purchase Example

Assume:

Product:       MICROBA Set
Unit Price:    Rp10,000
Quantity:      100
Gross Value:   Rp1,000,000

The Product system validates the selection and sends the commercial request to Commerce.

Commerce then manages:

Order
Payment / SA Usage
Eligible Sales
Transaction Status

Downstream systems evaluate their own rules.

For example:

Eligible Sales
   |
   +---- HIVE: applicable direct sponsorship
   |
   +---- SA: applicable 3% provision

6.44 Example — Direct Purchase Without Sponsor

Member selects 100 sets
        |
Gross Product Value
Rp1,000,000
        |
No Direct Sponsor
        |
Commerce
        |
Successful Transaction
        |
HIVE Commission = 0
        |
SA evaluated independently

6.45 Example — Purchase With Sponsor

Member B
Direct Sponsor = A

100 sets x Rp10,000
= Rp1,000,000

Commerce confirms eligible sale
        |
HIVE evaluates A
        |
9% of eligible sponsored sale
        |
Rp90,000 sponsorship

SA is evaluated separately.

6.46 Example — SA Discount

Product Value: Rp300,000
Member Uses:   2 SA
SA Reference:  Rp30,000 each

SA Benefit:    Rp60,000
Other Payment: Rp240,000

Commerce records the transaction and the SA system records movement of the two specific SA serials.

6.47 Example — Full SA Purchase

Product Value: Rp300,000
Member Uses:   10 SA

10 x Rp30,000
= Rp300,000

Cash Due
= Rp0

The Product is still purchased through Commerce.

The SA serials move according to Treasury rules.

6.48 Refunds and Product Reversals

A refund or cancellation should follow Commerce rules.

Where a transaction affects:

• HIVE commission;
• SA provision;
• SA entitlement;
• SA usage; or
• Product state,

the relevant capabilities should receive appropriate reversal or adjustment events.

Historical records should be preserved.

6.49 Product Dashboard

A member-facing Product view may show simple information such as:

MY PRODUCTS

Active
2

Completed
4

Recent Order
ORD-10025

Continue Journey
[Open Product]

The interface should focus on the member's Product experience rather than exposing internal engine terminology.

6.50 Frequently Asked Questions

What is Product?

Product is the MICROBA capability responsible for Product definitions, Product selection, and Product-specific experiences.

Do I need to participate in HIVE to buy a Product?

No.

Do I need a sponsor?

No.

Can I purchase directly from MICROBA?

Yes.

Can a Visitor view Products?

Approved public Product information may be visible to Visitors.

Do I need to join before purchasing?

Where the Product requires a member identity, you will be guided through JOIN or SIGN IN before the commercial transaction is completed.

Does Product process my payment?

No. Commerce owns payment and the order lifecycle.

Does Product create the Commerce order?

Product creates the validated commercial request. Commerce creates and owns the order.

What is a Living Snapshot?

It is the validated Product state committed for a transaction before Commerce processes the order.

Can Product prices change?

Yes, according to approved Product administration rules.

Will a future price change alter my old order?

No. Historical Commerce snapshots should remain intact.

What is the current example standard price?

The current model under discussion uses Rp10,000 per set for the relevant Product example.

Does buying more automatically change the unit price?

Not unless an approved pricing or discount rule says so.

Can SA reduce the amount I need to pay?

Yes. Eligible SA may be used as a purchasing benefit according to programme rules.

What is the current SA reference value?

Rp30,000 per SA.

Can I use two SA on a Rp300,000 purchase?

Under the current model, two SA represent Rp60,000 of purchasing benefit, leaving Rp240,000 to be settled by another approved method.

Can I pay 100% using SA?

The current architecture permits a fully SA-funded eligible purchase where programme rules allow it.

Does Product limit how many SA I can use?

Product should follow the approved SA/Commerce rule rather than imposing an arbitrary limit.

What happens to SA used in a purchase?

The specific SA serials move according to the SA/Treasury rules and can become available for future recycling.

Does the SA disappear?

No.

Does using SA create new SA?

Not merely because SA was used. New entitlement follows eligible sales and SA rules.

Does every Product purchase create HIVE commission?

No. HIVE commission requires a valid Direct Sponsor and an eligible sponsored sale.

Can I earn HIVE commission on my own Product purchase?

No.

Can my personal purchase contribute to SA provision?

Eligible personal sales may contribute according to SA rules.

What is the current SA provision reference?

3% of eligible sales.

Does Rp300 of provision mean I own a fractional SA?

No. Fractional economic provision remains backend provision until the whole-SA entitlement threshold is reached.

Does Product mint SA?

No.

Who decides whether an SA is recycled or newly minted?

The SA/Treasury mechanism checks Treasury first and mints only the shortage.

Does Product own my order?

No. Commerce owns the order.

Does Product own my sponsor relationship?

No. HIVE owns the Direct Sponsor relationship.

Does Product own my Knowledge progress?

No.

Can a Launch event sell a Product?

A Launch event may lead to a Product purchase, but the Product and Commerce capabilities remain responsible for their respective parts of the transaction.

What happens if my order is refunded?

Commerce processes the commercial reversal and related capabilities adjust their affected records through the appropriate reversal mechanisms.

6.51 Chapter Summary

Product is the MICROBA capability responsible for Product definition and Product experience.

The core rules are:

• Product participation does not require HIVE;
• a sponsor is not required to purchase;
• Product owns Product configuration and Product-specific journey

state;

• Membership owns member identity;
• Commerce creates and owns orders and payments;
• Product sends a validated commercial request to Commerce;
• committed Product state can be preserved as a Living Snapshot;
• the browser is not trusted as the authority for price or commercial

values;

• historical orders preserve their original commercial snapshot;
• HIVE evaluates eligible direct sponsorship separately;
• personal purchases do not generate self-sponsorship commission;
• SA operates independently from HIVE;
• eligible sales may contribute to SA provision;
• the current SA provision reference is 3% of eligible sales;
• the current SA reference value is Rp30,000;
• SA can provide a purchasing benefit;
• the architecture supports 100% SA-funded eligible purchases;
• SA used in purchases moves to Treasury according to SA rules;
• Treasury SA is recycled before new SA is minted;
• Product does not mint or recycle SA;
• Product, Commerce, HIVE, SA, Knowledge, Launch, and Profile retain

clear ownership boundaries; and

• Product changes must not silently rewrite historical commercial

records.

6.52 Source-of-Truth Note

This chapter is the general source of truth for MICROBA Product behaviour.

Product owns Product definitions, Product configuration, Product selection, Product-specific validation, and Product journey state.

Membership owns identity. Commerce owns orders, payment, commercial snapshots, and transaction status. HIVE owns direct sponsorship. SA owns SA provision, entitlement, serial identity, Treasury circulation, and recycling. Knowledge owns learning progress. Launch owns events.

The Rp10,000-per-set example, 3% SA provision reference, Rp30,000 SA reference value, 9% HIVE rate, and full-SA purchasing capability reflect the current approved system direction. Detailed public wording, discount presentation, eligible-sales treatment, fulfilment rules, and legal/accounting terminology may be refined in their dedicated chapters before publication.