Visitor

4.1 Introduction

A Visitor is a person who interacts with MICROBA before becoming a member, or who uses public MICROBA experiences without creating a Living Identity.

Visitor is an important part of the MICROBA journey because MICROBA is designed to remain open.

A person should be able to discover MICROBA, understand its purpose, explore appropriate public knowledge and products, and decide whether to join without first being forced into HIVE or assigned to a sponsor.

The core principle is:

**Discovery comes before membership, and membership comes before

member identity-dependent capabilities.**

A Visitor may arrive independently or through a genuine HIVE invitation.

Both journeys are valid.

4.2 Visitor Is Not a Member

A Visitor does not yet have a canonical MICROBA Living Identity unless they are an existing member browsing while signed out.

Conceptually:

VISITOR
   |
Public MICROBA Experience
   |
JOIN
   |
Email Verification
   |
Identity Bootstrap
   |
MEMBER

Visitor activity and Member activity should not be confused.

A Visitor may browse public information, but member-owned capabilities require an authenticated Living Identity where applicable.

4.3 Public Access

MICROBA may make selected experiences publicly accessible.

These may include:

• Home;
• Discover;
• Experience;
• Science;
• Community;
• public Articles;
• public Product information;
• JOIN;
• SIGN IN;
• public programme explanations;
• selected FAQs; and
• other approved public content.

Public access should provide enough information for a person to understand MICROBA before deciding to join or purchase.

Not every capability must be public.

Private member information and identity-dependent experiences remain protected.

4.4 The Public MICROBA Journey

A typical independent Visitor journey may be:

Search / Social / Direct Visit
          |
        MICROBA
          |
     Public Content
          |
   Explore / Learn
          |
     Product Interest
          |
       JOIN
          |
     Living Identity
          |
       Purchase

A Visitor should not need an affiliate relationship simply to enter this journey.

4.5 Independent Visitors

A person may discover MICROBA independently through:

• search engines;
• social media;
• public Articles;
• direct website access;
• public events;
• media;
• word of mouth without tracked sponsorship;
• Product discovery; or
• another public channel.

An independent Visitor can join and purchase normally.

If no valid Direct Sponsor relationship exists:

Visitor
   |
JOIN
   |
Member
   |
Purchase
   |
No Direct Sponsor
   |
HIVE Commission = 0

Other applicable mechanisms, including SA provision, follow their own rules.

4.6 Sponsored Visitors

A Visitor may also arrive through a genuine HIVE invitation.

Example:

Member A
   |
Shares Invitation / QR
   |
Visitor B
   |
MICROBA
   |
JOIN
   |
Living Identity B
   |
Direct Sponsor Attribution A

The Visitor still creates and owns their own MICROBA identity.

The sponsor does not create or own the Visitor's account.

4.7 Referral Links

HIVE may provide a member-specific referral link.

A referral link helps MICROBA understand the source of an introduction.

Conceptually:

microba.co/...
      |
Referral Attribution
      |
Visitor
      |
JOIN

Following a referral link does not itself create a commission.

The link provides attribution context.

A sponsorship benefit requires the later conditions defined by HIVE, including a valid relationship and eligible commercial activity.

4.8 Member QR Invitations

A member may share a MICROBA QR invitation.

The QR may direct the Visitor to an appropriate public or JOIN experience while carrying safe attribution information.

Example:

Member QR
   |
Visitor scans
   |
MICROBA invitation page
   |
Explore / JOIN
   |
Valid attribution

The QR should not expose unnecessary private member information.

Scanning a QR does not:

• create a sale;
• create SA;
• create a sponsorship commission; or
• make the Visitor a member.

Those events require their own valid processes.

4.9 Referral Code

Where appropriate, MICROBA may support a referral code.

The code may be:

• embedded automatically in a referral link;
• carried through a QR journey; or
• entered during JOIN where permitted.

Referral code handling should be simple for the Visitor.

The system should validate the code before establishing sponsor attribution.

An invalid or expired referral code should not prevent an otherwise legitimate person from joining MICROBA unless an approved rule specifically requires it.

4.10 Attribution Before Registration

MICROBA may temporarily preserve referral attribution before the Visitor creates an account.

Conceptually:

Visitor follows A's invitation
          |
Temporary Attribution = A
          |
Visitor explores MICROBA
          |
Visitor chooses JOIN
          |
Registration
          |
Attribution validated
          |
Living Identity created
          |
Direct Sponsor relationship established

The exact technical method may use an approved session, signed token, or another safe attribution mechanism.

The User Manual defines the behaviour, not the implementation technology.

4.11 Attribution Is Not Identity

Visitor attribution and member identity are separate.

Before JOIN:

Visitor Session
Referral Source: A

After successful identity creation:

Member B
MID-B
Direct Sponsor: A

The system should not treat a browser cookie, device, IP address, or referral token as the person's canonical identity.

Canonical identity begins through the approved Membership process.

4.12 Visitor Privacy

MICROBA should collect only information reasonably required for the public experience and approved operational purposes.

Public browsing should not expose private member information.

Referral mechanisms should not reveal sensitive sponsor information unnecessarily.

For example, an invitation may safely communicate that a person was invited by a MICROBA member without exposing that member's private Profile data.

Applicable privacy notices and consent mechanisms should be presented where required.

4.13 Visitor and Cookies

MICROBA may use cookies or similar mechanisms for legitimate functions such as:

• session continuity;
• referral attribution;
• language preference;
• security;
• consent preference; and
• appropriate analytics.

Use of these mechanisms should follow applicable privacy and consent requirements.

A cookie should not become the authoritative record of a member's identity or financial entitlement.

4.14 Visitor Language

The public MICROBA experience may support multiple languages.

A Visitor may browse or interact in their preferred supported language.

Language is a presentation layer.

Canonical MICROBA rules should remain consistent regardless of translation.

For example:

English Source Rule
       |
Translation Layer
       |
Indonesian / Malay / Other Language

A translation must not change the underlying programme rule.

4.15 Visitor and the MICROBA Chatbot

The MICROBA chatbot may assist Visitors before they join.

A Visitor might ask:

• What is MICROBA?
• Do I need a sponsor?
• Can I purchase directly?
• What is HIVE?
• What is SA?
• What products are available?
• How do I join?
• Can I use MICROBA without becoming an affiliate?

The chatbot should answer from approved MICROBA documentation.

For public programme questions, the chatbot should prioritize authoritative Manual content over general Articles where the two serve different purposes.

The chatbot must not expose private member information to an unauthenticated Visitor.

4.16 Public Articles

Visitors may read Articles that MICROBA makes public.

Articles are educational or informational content and are distinct from programme rules.

For example:

manual/
Authoritative operational rules

articles/
Educational knowledge

A public Article may explain microbiome science, MICROBIOSM concepts, Product context, research, or other approved subjects.

An Article should not silently redefine Membership, HIVE, Commerce, or SA rules.

4.17 Knowledge Progress for Visitors

A Visitor may be allowed to read public Knowledge content.

However, a Visitor does not yet have a canonical MID to which permanent Knowledge progress can safely belong.

Therefore, permanent confirmed-reading progress should normally be associated with a Living Identity.

Conceptually:

Visitor reads Article
        |
Public Reading
        |
No canonical member progress yet

After JOIN:

Member reads eligible Article
        |
Confirm Read
        |
Knowledge records progress
        |
MID

If MICROBA later chooses to preserve pre-registration reading activity, it should use an explicit and safe claim/merge process rather than assuming browser activity belongs to a newly created member.

4.18 Visitor and Product Discovery

Visitors may be able to view public Product information before joining.

This can include information such as:

• Product purpose;
• Product presentation;
• price;
• available purchase options;
• educational context;
• general journey explanation; and
• approved FAQs.

Member-specific Product information remains protected.

Public Product discovery should help a Visitor make an informed decision before registration or purchase.

4.19 Visitor and Commerce

Commerce may support a journey that begins with a Visitor, but identity requirements should be satisfied before a transaction that requires a MICROBA member identity is committed.

A conceptual journey is:

Visitor
   |
Select Product
   |
JOIN / SIGN IN if identity required
   |
Living Identity
   |
Commerce Order
   |
Payment

Commerce should not invent a fake member identity merely to complete an order.

If MICROBA later supports true guest checkout for a particular Product, that must be explicitly defined as a separate approved Commerce rule.

4.20 JOIN at the Point of Purchase

A Visitor who decides to purchase may be guided into JOIN without losing their Product selection or legitimate referral attribution.

Example:

Visitor selects Product
        |
Needs Member Identity
        |
JOIN
        |
Verify
        |
Living Identity
        |
Return to intended purchase
        |
Commerce

The experience should minimize unnecessary repetition.

The system should preserve only the safe state necessary to continue the journey.

4.21 Existing Members Browsing as Visitors

An existing member may visit MICROBA while signed out.

Until authenticated, the system should treat the session as unauthenticated for protected capabilities.

The platform should not expose private member data merely because the browser was previously used by that member.

After SIGN IN:

Unauthenticated Session
        |
SIGN IN
        |
Authenticated MID
        |
Member Experience

4.22 Visitor to Member Conversion

The transition from Visitor to Member occurs through Membership, not HIVE or Commerce.

Canonical flow:

VISITOR
   |
JOIN
   |
Pending Account
   |
Email Verification
   |
Identity Bootstrap
   |
MID
   |
LIVING IDENTITY
   |
MEMBER

HIVE may provide attribution context.

Commerce may provide purchase intent.

Product may provide the reason to join.

But Membership owns the identity transition.

4.23 No Forced Sponsor Assignment

If a Visitor joins without a valid sponsor, MICROBA should not randomly assign one.

Example:

Visitor joins directly
        |
No valid referral
        |
Sponsor = None

This is a valid state.

Automatically assigning an unrelated sponsor could create a commission for a person who did not generate the relationship.

Open membership is therefore preserved.

4.24 No Sponsor Shopping at Checkout

The Visitor or new member should not be encouraged to select a sponsor at checkout merely to direct commission to someone.

Sponsor attribution should arise from a genuine relationship under HIVE rules.

This prevents behaviour such as:

Purchase ready
    |
Choose any sponsor
    |
Redirect 9%

That is not the intended HIVE model.

4.25 Conflicting Referral Attribution

A Visitor may encounter more than one referral source before joining.

For example:

A's referral
    |
Visitor browses
    |
Later B's referral
    |
Visitor joins

The platform requires a deterministic attribution policy so that the result is predictable and auditable.

The exact rule — for example, first valid attribution, last valid attribution, explicit confirmed sponsor, or another approved method — should be finalized in HIVE operational policy before launch.

Until that policy is locked, the system should not allow arbitrary or hidden attribution behaviour.

Whatever rule is adopted must:

• be consistent;
• be explainable;
• prevent casual manipulation;
• preserve audit information; and
• create at most one valid Direct Sponsor relationship for the member

at a time.

4.26 Expired Attribution

Temporary Visitor attribution may have an expiry period.

If attribution expires before JOIN, the Visitor must still be allowed to join independently.

Conceptually:

Referral Attribution
       |
Expires
       |
Visitor later joins
       |
No valid sponsor attribution
       |
Membership continues normally

An expired referral must not trap or block the Visitor.

The final attribution duration belongs to HIVE policy.

4.27 Visitor Does Not Create Commission

The following activities do not by themselves create HIVE commission:

• website visit;
• page view;
• Article read;
• QR scan;
• referral-link click;
• Product view;
• JOIN page visit;
• registration;
• email verification; or
• creation of a Living Identity.

Commission follows an eligible sale under HIVE and Commerce rules.

4.28 Visitor Does Not Create SA Merely by Browsing

Public activity does not by itself generate SA.

Examples that do not automatically generate SA include:

• browsing;
• reading a public page;
• clicking a referral link;
• scanning a QR;
• joining;
• sharing a page; and
• viewing a Product.

SA provision and entitlement follow the approved SA rules and applicable eligible activity.

4.29 Public Navigation

The public MICROBA experience should remain intentionally simple.

The public header may present MICROBA branding without requiring the full logged-in member navigation.

Public discovery can occur through page content, contextual calls to action, footer navigation, search, Articles, or other approved experiences.

Member navigation becomes available after authentication according to the MICROBA Header Experience.

This keeps the public experience focused on discovery rather than exposing member workspace controls to Visitors.

4.30 Calls to Action

Visitor-facing calls to action should reflect the Visitor's context.

Examples may include:

• Discover MICROBA;
• Explore Science;
• Explore Products;
• Read Articles;
• Join MICROBA;
• Begin My Journey; and
• Sign In.

The interface should not imply that joining HIVE is mandatory for membership.

4.31 Visitor Analytics

MICROBA may measure aggregate public activity for legitimate product, content, performance, and operational purposes.

Examples may include:

• page visits;
• referral source;
• Article engagement;
• Product interest;
• JOIN conversion; and
• public journey performance.

Analytics should not be treated as authoritative member identity data.

Where consent is required, the appropriate consent process should apply.

4.32 Bot and Abuse Protection

Public access may be targeted by automated abuse.

MICROBA may apply reasonable controls to protect:

• JOIN;
• SIGN IN;
• referral attribution;
• public forms;
• Commerce initiation;
• chatbot usage; and
• other public endpoints.

Controls should protect the platform without unnecessarily blocking legitimate Visitors.

4.33 Visitor Support

Visitors should have access to enough support information to make basic decisions before joining.

This may include:

• FAQs;
• chatbot assistance;
• public support contact;
• Product information;
• programme explanations;
• Terms;
• Privacy information; and
• relevant policies.

Private account support should require appropriate identity verification.

4.34 Example Visitor Journeys

Journey A — Independent Discovery

Google / Search
      |
MICROBA Article
      |
Explore Product
      |
JOIN
      |
Verify Email
      |
Living Identity
      |
Purchase

No sponsor is required.

Journey B — HIVE Invitation

Member A
   |
Shares QR
   |
Visitor B scans
   |
Explores MICROBA
   |
JOIN
   |
Attribution validated
   |
MID-B created
   |
Direct Sponsor = A

No commission is created until an eligible sale occurs.

Journey C — Visitor Reads but Does Not Join

Visitor
   |
Reads Public Articles
   |
Leaves

This is a valid public interaction.

No member identity, sponsorship commission, or SA entitlement is created merely from the visit.

Journey D — Visitor Selects Product Before Joining

Visitor
   |
Select Product
   |
JOIN required
   |
Verify
   |
Living Identity
   |
Return to Purchase
   |
Commerce

Journey E — Referral Expires

A referral
   |
Visitor waits beyond attribution period
   |
Attribution expires
   |
Visitor joins directly
   |
No Sponsor

Membership remains available.

4.35 Frequently Asked Questions

What is a Visitor?

A Visitor is someone using a public MICROBA experience without an authenticated member identity.

Do I need an account to view MICROBA?

Not for approved public content.

Do I need a sponsor to explore MICROBA?

No.

Do I need a sponsor to join?

No.

Do I need a sponsor to purchase?

No, subject to any identity requirements of the Product and Commerce journey.

What if I discovered MICROBA myself?

You can join independently. No sponsor needs to be assigned.

What if someone introduced me to MICROBA?

A valid Direct Sponsor relationship may be recorded according to HIVE attribution rules.

Does clicking a referral link make me a member?

No.

Does scanning a member QR make me a member?

No.

Does scanning a QR generate commission?

No.

Does registration generate commission?

No.

When can sponsorship commission be generated?

When a valid Direct Sponsor relationship and an eligible commercial transaction satisfy HIVE rules.

Can I browse Articles without joining?

Public Articles may be read without joining.

Does public reading count toward my permanent Knowledge milestone?

Normally, permanent confirmed-reading progress belongs to a canonical member identity.

Can I join after reading public content?

Yes.

Can the chatbot help me before I join?

Yes. It may answer approved public MICROBA questions without exposing private member data.

Can I purchase directly after finding MICROBA through search?

Yes. You do not need an affiliate.

Will MICROBA automatically give me a sponsor if I do not have one?

No.

Can I choose any sponsor during checkout?

Sponsor attribution is governed by HIVE relationship rules, not casual checkout selection.

What if I follow links from two different affiliates?

A deterministic attribution policy must decide the valid relationship. The final conflict rule will be defined in HIVE policy.

Can an expired referral prevent me from joining?

No.

Does browsing generate SA?

No.

Does joining generate SA automatically?

Not merely because an account was created. SA follows its own eligibility rules.

Does a Visitor have an MID?

No new MID is created until the Membership identity bootstrap is successfully completed.

What if I already have an account but I am signed out?

Protected capabilities remain unauthenticated until you sign in.

Can a sponsor see what I browse?

A sponsorship relationship does not automatically grant access to a person's private browsing or Profile information.

Are public Articles official programme rules?

No. Articles are educational or informational content. The User Manual and dedicated programme documentation provide authoritative operational rules.

4.36 Chapter Summary

The Visitor experience keeps MICROBA open and accessible before membership.

The core rules are:

• a Visitor is not yet a new MICROBA member merely by browsing;
• approved public content can be accessed without a Living Identity;
• Visitors may discover MICROBA independently or through HIVE;
• a sponsor is not required to explore, join, or purchase;
• MICROBA must not randomly assign sponsors to independent Visitors;
• referral links, QR codes, and referral codes provide attribution

context but do not themselves create commission;

• sponsor attribution and canonical identity are separate;
• Membership owns the Visitor-to-Member transition;
• permanent member progress belongs to a canonical identity;
• public Articles are educational content and do not override

programme rules;

• public browsing does not itself generate SA or HIVE commission;
• conflicting referral attribution requires a deterministic, auditable

policy;

• expired attribution must not prevent independent membership;
• public chatbot access must not expose private member information;

and

• the Visitor experience should make discovery simple before asking

for membership information.

4.37 Source-of-Truth Note

This chapter is the general source of truth for MICROBA Visitor behaviour and the transition from public discovery toward membership.

Membership owns identity creation. HIVE owns sponsor relationships and attribution policy. Commerce owns commercial transactions. Knowledge owns permanent learning progress. SA owns SA eligibility and circulation.

Detailed rules in those dedicated chapters take precedence within their respective responsibilities.

Public interface wording, referral expiry duration, attribution-conflict policy, analytics implementation, privacy mechanisms, and other operational details may be refined before publication. Any change to the underlying architectural responsibilities should require an explicit approved revision.