Membership and Profile

2.1 Introduction

Membership is the foundation of a person's relationship with MICROBA.

A MICROBA member is a person with a canonical Living Identity in the platform. Membership is not the same as purchasing a Product, participating in HIVE, holding SA, or completing Knowledge activities. Those are capabilities connected to the member's identity.

A person may join MICROBA for different reasons. They may wish to learn, purchase products, participate in Product experiences, receive eligible SA benefits, join the community, or later participate in HIVE.

No member is required to become an affiliate or sponsor another person.

The purpose of the Membership and Profile system is to provide one trusted identity that can be used consistently throughout the MICROBA ecosystem.

2.2 Core Membership Principle

The canonical principle is:

One person, one MICROBA Living Identity.

A member should not need multiple accounts to participate in different MICROBA capabilities.

The same identity can connect the member to:

• Profile;
• Product;
• Commerce;
• HIVE;
• SA;
• Knowledge;
• certificates;
• orders;
• member-owned resources;
• milestones; and
• future MICROBA capabilities.

This allows MICROBA to understand the member as one person rather than as unrelated records across different modules.

2.3 What Is a Living Identity?

A Living Identity is the canonical representation of a member inside MICROBA.

It begins when the required identity bootstrap process has been completed.

A Living Identity may contain or connect to:

• Member ID (MID);
• full name;
• preferred name or nickname;
• verified email;
• profile information;
• avatar;
• membership status;
• preferences;
• consent records;
• authentication records;
• capability permissions;
• activity history; and
• relationships to other MICROBA records.

The identity itself remains stable while information around it can evolve.

For example, a member may initially join only to learn. Later they may purchase a Product, receive SA, participate in HIVE, or achieve Knowledge milestones.

These activities extend the member's journey without creating a new identity.

2.4 Joining MICROBA

Joining MICROBA begins the creation of a Living Identity.

The standard JOIN experience should remain simple.

The initial registration form requires only information necessary to establish and protect the account.

Required Information

The current registration model includes:

• Full Name;
• Email;
• Password;
• Confirm Password;
• acceptance of required Terms; and
• acceptance of required Privacy terms.

Optional Information

The JOIN experience may also allow:

• Preferred Name / Nickname; and
• Referral Code or automatically detected referral information.

MICROBA should not require unnecessary personal information during initial registration.

Information such as phone number, date of birth, address, country, avatar, interests, or other profile details can be requested later only when genuinely required.

This principle is called Progressive Profile Completion.

2.5 The JOIN Flow

The canonical registration flow is:

Visitor
   |
JOIN
   |
Validate Registration
   |
Create Pending Account
   |
Send Verification Email
   |
Member Verifies Email
   |
Generate MID
   |
Create Living Identity
   |
Initialize Member Profile
   |
Auto Sign In
   |
Welcome to MICROBA

Email verification is an important boundary.

Before verification, the registration exists as a pending account.

After successful verification, MICROBA can complete the identity bootstrap and create the canonical Living Identity.

2.6 Email Verification

Email verification confirms that the member controls the email address used during registration.

The verification process should:

• use a secure verification link or token;
• expire according to security policy;
• prevent inappropriate reuse;
• record the verification event; and
• continue the identity bootstrap after successful verification.

The system should provide a clear path to resend a verification email when appropriate.

A member should not need to repeat registration merely because a verification email was missed or expired.

2.7 Member ID (MID)

Each Living Identity receives a canonical Member ID, referred to as the MID.

The MID is the stable internal member identifier used throughout MICROBA.

Conceptually:

Person
  |
Verified Account
  |
Living Identity
  |
MID

Other capabilities should reference the canonical MID rather than inventing their own independent member identifiers.

An email address, nickname, display name, or phone number should not replace the MID as the canonical identity key because those values may change.

The MID should remain stable.

2.8 Identity Bootstrap

Identity Bootstrap occurs after successful email verification.

Its purpose is to transform the verified account into a usable MICROBA Living Identity.

The bootstrap process may include:

1. generating the MID;
2. creating the Living Identity;
3. creating the base Profile;
4. initializing default preferences;
5. initializing language or notification preferences;
6. assigning default member capabilities;
7. preparing the member workspace; and
8. recording immutable identity events.

A successful bootstrap means the member is ready to enter the MICROBA ecosystem.

Downstream capabilities consume this canonical identity rather than creating their own member accounts.

2.9 Profile

Profile is the member-facing representation of the Living Identity.

It is where the member can view and manage information about themselves and access capabilities connected to their identity.

Profile may present:

• avatar;
• full name;
• preferred name;
• MID;
• profile completion;
• membership information;
• Product activity;
• SA;
• HIVE;
• Knowledge progress;
• orders;
• certificates;
• settings;
• places;
• notifications; and
• other member capabilities.

Profile is a composition layer.

It does not become the owner of every record shown on the screen.

For example:

Profile displays Order
        |
Commerce owns Order

Profile displays SA
        |
SA Registry owns SA

Profile displays Knowledge Progress
        |
Knowledge owns Progress

This separation keeps the platform modular.

2.10 Progressive Profile Completion

MICROBA should not ask a new member for every possible piece of information during JOIN.

Instead, additional information is collected when it becomes relevant.

Example:

JOIN
 |
Name + Email + Password
 |
Living Identity
 |
Member wants delivery
 |
Request Delivery Information
 |
Member wants capability requiring another detail
 |
Request That Detail

This reduces registration friction and avoids collecting information before it is needed.

A profile can therefore become richer as the member's relationship with MICROBA develops.

2.11 Profile Completion Is Not Membership Qualification

A partially completed Profile does not automatically mean that the person is not a valid member.

Membership status and Profile completeness are separate concepts.

For example:

Member Status: ACTIVE
Profile Completion: 65%

The member can still be active.

However, a specific capability may require particular information before it can be used.

For example, delivery may require an appropriate location, while a regulated or identity-sensitive action may require additional verification.

The system should ask for missing information at the point where it becomes necessary.

2.12 Membership Does Not Require a Sponsor

A sponsor is not required to become a MICROBA member.

A valid journey is:

Visitor
   |
Join MICROBA
   |
Living Identity
   |
Member

No sponsor is required.

If the person was genuinely introduced through HIVE, a direct sponsor relationship may be recorded separately.

Therefore:

Membership exists independently of sponsorship.

This distinction is important because MICROBA remains open to people who discover the platform directly.

2.13 Membership Does Not Require HIVE

Every member is not automatically an affiliate.

A member can:

• join;
• complete their Profile;
• learn;
• purchase;
• use Product;
• receive eligible SA benefits; and
• continue their MICROBA journey,

without ever participating in HIVE.

HIVE becomes relevant only when a member chooses to participate in direct sponsorship according to the HIVE rules.

2.14 Direct Purchases by Members

Members may purchase directly from MICROBA.

A member without a sponsor can still make an eligible purchase.

Conceptually:

Member
  |
Purchase
  |
Commerce
  |
No Sponsor
  |
Purchase Completes

The absence of a sponsor does not invalidate the order.

No sponsorship commission is created when there is no eligible direct sponsor.

Other applicable mechanisms, including SA provision, continue according to their own rules.

2.15 Sponsor Relationship and Identity

Where a genuine sponsor relationship exists, it should be associated with the member's identity rather than supplied casually on every checkout.

Conceptually:

Member B
MID: B
Direct Sponsor: Member A

This allows repeat eligible purchases to use a consistent attribution rule.

The sponsor relationship should not be confused with identity ownership.

Member A does not own Member B's account, purchases, Profile, SA, Product, or other member resources.

The relationship exists only for the purposes defined by HIVE.

Detailed sponsor creation, protection, change, removal, and attribution rules belong in Chapter 03 — HIVE.

2.16 Personal Purchase and Self-Sponsorship

A member may purchase for themselves.

However, a member cannot become their own sponsor merely to generate sponsorship commission.

Conceptually:

Member A
   |
Personal Purchase
   |
Commerce
   |
Self-Sponsorship?
   |
NO

Personal purchases may still participate in other applicable MICROBA mechanisms, including eligible SA provision.

This keeps purchasing and sponsorship separate.

2.17 Duplicate Accounts

MICROBA should discourage the creation of duplicate member identities.

Examples include:

• creating another account for the same person to generate artificial

sponsorship;

• creating dummy accounts to manipulate transactions;
• creating identities for people who do not genuinely control those

accounts; or

• repeatedly registering the same person to obtain programme benefits.

The system may use identity controls and verification mechanisms to detect or prevent inappropriate duplication.

Where a legitimate duplicate occurs accidentally, the platform should use an approved recovery or resolution process rather than treating both identities as independent members indefinitely.

2.18 Authentication

Authentication proves that the person accessing MICROBA is genuinely authorized to use the identity.

Authentication may include:

• email and password;
• secure session management;
• email verification;
• password reset;
• additional verification mechanisms; and
• future authentication methods.

Authentication is not the same as authorization.

A successful login proves access to an identity. It does not automatically grant permission to every capability.

2.19 Sign In

An existing member uses SIGN IN to access their Living Identity.

The experience should remain simple:

Email / Identifier
        |
Password
        |
Authenticate
        |
Member Session
        |
My MICROBA

If credentials are incorrect, the system should provide a safe and useful response without exposing unnecessary security information.

Successful member authentication should lead the member into the appropriate member experience.

2.20 Forgot Password

Members must be able to recover access securely.

The canonical flow is:

Forgot Password
      |
Enter Email
      |
Reset Request
      |
Secure Reset Link
      |
Set New Password
      |
Reset Completed
      |
Sign In / Continue

Reset tokens should be:

• secure;
• time-limited;
• single-use; and
• invalidated appropriately after successful use.

Password recovery should not reveal whether an unrelated person's account exists in a way that creates unnecessary privacy or security risk.

2.21 Authorization

Authorization determines what an authenticated identity is allowed to do.

The platform follows the distinction:

Identity proves who you are.

Authentication proves you are genuine.

Authorization determines what you may do.

Consent determines what you have agreed to.

A member should only access capabilities and resources they are authorized to use.

For example, being signed in as a member does not automatically provide administrative access.

2.22 Ownership

Every protected member resource should have clear ownership or an equivalent access relationship.

Examples may include:

• Profile information;
• orders;
• Product records;
• certificates;
• SA holdings;
• Knowledge progress; and
• member-owned places.

A member should not gain access to another member's protected information merely by knowing their MID, email, URL, or another identifier.

Ownership checks must be enforced by the system rather than only hidden in the interface.

2.23 Consent

MICROBA records required and optional consent separately.

Examples may include:

• Terms acceptance;
• Privacy acceptance;
• optional communications;
• programme-specific consent; and
• future capability-specific consent.

Consent should be:

• versioned;
• auditable;
• associated with the correct identity; and
• recorded with appropriate context.

If important terms change, the system can determine whether renewed consent is required.

2.24 Member and Administrator Are Different Roles

Ordinary membership and MICROBA administration are separate identity contexts.

A MICROBA administrator is not automatically treated as an ordinary member.

Likewise, an ordinary member does not automatically gain administrative privileges.

Conceptually:

MICROBA Identity System
       |
   +---+---+
   |       |
Member   Admin

If the same real person legitimately requires both member and administrative access, the relationship must be explicit and managed according to the administrative security model.

Administrative access should never be inferred merely because someone is a member.

2.25 Member Privacy

A member's Profile is not automatically a public directory.

MICROBA should distinguish between:

• private information;
• information visible to the member;
• information required by a capability;
• information shared with another member for a legitimate interaction;

and

• information intentionally made public.

The platform should avoid exposing personal information simply because it exists in Profile.

Each capability should request only the information necessary for its responsibility.

2.26 Member Status

Membership may have system states.

A simplified model may include:

PENDING
   |
Email Verified
   |
ACTIVE

Additional controlled states may be required for operational reasons, such as:

• suspended;
• restricted;
• closed; or
• recovery-required.

A status change should be recorded and auditable.

Status should not be silently changed merely because a member has not purchased, sponsored, or used the platform recently unless an approved membership rule explicitly requires it.

2.27 Member Activity Is Not Member Identity

MICROBA should distinguish who the member is from what the member does.

For example:

Identity
MID-000123
Name: Maya

Activities
- Purchased Product
- Read Knowledge
- Received SA
- Sponsored Member

Activities may increase, decrease, expire, reverse, or change.

The underlying identity remains the same.

This separation is important for long-term platform integrity.

2.28 My MICROBA

My MICROBA is the member's primary personal workspace.

It brings together relevant information from multiple capabilities around the member's Living Identity.

It may include:

• welcome identity;
• member avatar;
• Profile access;
• Product journey;
• SA;
• HIVE;
• Knowledge milestones;
• orders;
• certificates;
• settings;
• notifications; and
• future capabilities.

My MICROBA is not a replacement for the engines that own those records.

It is the member-facing composition of their ecosystem.

2.29 Member QR and Invitation Identity

MICROBA may provide a member-specific QR or invitation mechanism.

Its purpose can include allowing another person to begin an appropriate MICROBA journey connected to the member.

A QR code or referral link should not expose sensitive member information.

Where it creates sponsor attribution, the relationship must still satisfy HIVE rules.

A QR scan itself should not automatically create a commission.

The commercial and sponsorship conditions must still be satisfied.

2.30 Profile Data and Other Capabilities

The Profile should not become a universal storage location for information owned by other engines.

Examples:

Member Name
Owner: Profile / Identity

Order
Owner: Commerce

SA Serial
Owner: SA Registry

Knowledge Progress
Owner: Knowledge

Product Journey
Owner: Product

Profile may display these records through approved interfaces.

This architecture allows each capability to evolve without corrupting identity ownership.

2.31 Member-Owned Places

Where MICROBA provides a My Places capability, a Living Place represents a reusable physical location.

A place may contain:

• place name;
• category;
• address;
• coordinates;
• timezone;
• default status; and
• timestamps.

Recipient-specific information such as recipient name, phone number, delivery instructions, and shipping notes does not belong to the Living Place itself.

Those details belong to the relevant Commerce or Order context.

This allows the same physical place to be reused without mixing location identity with transaction-specific recipient information.

2.32 Account Security

Members are responsible for protecting access to their account.

MICROBA should support reasonable security controls, including:

• secure password handling;
• protected sessions;
• verification;
• password recovery;
• audit events;
• access controls; and
• future security enhancements.

Members should never be asked to provide their password to another member, sponsor, or ordinary administrator.

A sponsor does not need a sponsored member's password.

2.33 Account Recovery

Where access is lost, MICROBA should provide an approved recovery process.

Recovery must establish that the person requesting access has legitimate authority over the identity.

Recovery actions should be auditable.

The system should prefer secure recovery mechanisms over manually exposing, sharing, or setting passwords on behalf of another person.

2.34 Closing or Restricting Membership

Where membership must be restricted, suspended, or closed, the system should preserve historical integrity.

Closing an account should not silently delete historical Commerce transactions, SA history, sponsorship records, consent history, or other records that must remain for operational, audit, legal, or reconciliation purposes.

The member-facing account state and historical system records are separate concerns.

2.35 Example Membership Journeys

Journey A — Direct Member

Discover MICROBA
      |
JOIN
      |
Verify Email
      |
MID Created
      |
Living Identity
      |
My MICROBA

No sponsor is required.

Journey B — Member Introduced by HIVE

Affiliate Invitation
       |
Visitor
       |
JOIN
       |
Verify Email
       |
Living Identity
       |
Valid Sponsor Relationship Recorded

The new member owns their own identity.

The sponsor relationship exists separately.

Journey C — Member Purchases Without Sponsor

Member
  |
Product
  |
Commerce
  |
Payment
  |
Order Complete

Sponsorship commission: none.

Applicable SA rules continue normally.

Journey D — Member Purchases With a Valid Direct Sponsor

Member
  |
Valid Sponsor Relationship
  |
Eligible Purchase
  |
Commerce
  |
HIVE Evaluation
  |
Eligible Direct Sponsorship Event

Journey E — Member Later Chooses HIVE

Existing Member
      |
Chooses to Participate in HIVE
      |
Introduces New Person
      |
Valid Direct Relationship
      |
Eligible Future Sales

The member does not need a new MICROBA identity to participate in HIVE.

2.36 Frequently Asked Questions

What is a MICROBA member?

A MICROBA member is a person with a canonical Living Identity in the MICROBA ecosystem.

Is a member automatically an affiliate?

No.

Do I need a sponsor to become a member?

No.

Can I purchase without a sponsor?

Yes.

What happens to sponsorship commission when I have no sponsor?

No direct sponsorship commission is created for that purchase.

Can I join only to learn?

Yes.

Can I join only to purchase MICROBA products?

Yes.

Do I need to sponsor anyone to keep my membership?

No, unless a future specific membership programme explicitly establishes such a rule. The current membership model does not require recruitment.

Can I become involved in HIVE later?

Yes. HIVE participation does not require a second MICROBA identity.

Can I sponsor myself?

No.

Can I create another account to sponsor myself?

No. Duplicate or dummy identities should not be used to manufacture sponsorship benefits.

What is my MID?

Your MID is your canonical MICROBA Member ID.

Can my MID change when I change my email?

The canonical MID should remain stable even if editable profile information changes.

Is my email my member identity?

Your email is part of authentication and communication, but the canonical platform identity is represented by your Living Identity and MID.

Why do I need to verify my email?

Verification helps confirm that you control the email address used to establish the account and allows MICROBA to complete identity bootstrap securely.

Why doesn't JOIN ask for all my information?

MICROBA uses Progressive Profile Completion. Additional information should be requested only when it becomes relevant.

Does an incomplete Profile mean my membership is invalid?

No. Profile completion and membership status are separate.

Can a specific capability require additional information?

Yes. A capability may request information genuinely required to perform its function.

Does my sponsor own my account?

No.

Can my sponsor see everything in my Profile?

No. Sponsor relationships do not automatically grant access to private Profile information.

Can my sponsor change my account?

Not merely because they are your sponsor.

Can I change my sponsor?

Sponsor changes are governed by HIVE rules. They should not be casually changed at checkout to redirect commissions.

Can an administrator see my password?

The system should not expose member passwords to administrators.

Can an administrator set my password for me?

Normal recovery should use secure reset or invitation mechanisms rather than sharing or manually exposing passwords.

Is an administrator automatically a member?

No. Administrative and member identities are distinct contexts.

Can one person legitimately have member and admin access?

Yes, where explicitly authorized and managed according to the administrative identity model.

What is My MICROBA?

My MICROBA is the personal member workspace that brings together relevant capabilities around the member's Living Identity.

Does Profile own my orders?

No. Commerce owns order records. Profile may display them.

Does Profile own my SA?

No. SA ownership/holding and serial history are managed by the SA system and displayed through Profile.

Does Profile own my Knowledge progress?

No. Knowledge owns the learning progress record and Profile may present it.

What happens if I forget my password?

Use the secure Forgot Password process to request a time-limited reset.

What happens if my verification link expires?

The system should provide an appropriate way to request a new verification link.

Can I create a new account instead of recovering my old one?

Members should recover their existing identity where possible rather than creating unnecessary duplicates.

Can MICROBA suspend an account?

The system can support controlled membership states such as suspended or restricted where justified by approved rules.

Does account closure delete all transaction history?

Not necessarily. Records required for transaction integrity, audit, reconciliation, or legal obligations may need to remain.

2.37 Chapter Summary

MICROBA Membership is built around one canonical Living Identity.

The core rules are:

• one person should use one canonical MICROBA identity;
• the MID is the stable member identifier;
• JOIN begins with minimal required information;
• email verification precedes full identity bootstrap;
• additional information is collected progressively;
• membership does not require a sponsor;
• membership does not require HIVE participation;
• direct purchasing without a sponsor is allowed;
• members cannot sponsor themselves;
• duplicate or dummy identities should not be used to manufacture

benefits;

• a sponsor relationship does not create ownership over another

member;

• authentication, authorization, consent, and ownership remain

separate concerns;

• ordinary membership and administrative identity are separate;
• Profile presents the member experience but does not take ownership

of every capability's data; and

• My MICROBA brings the ecosystem together around the member's Living

Identity.

2.38 Source-of-Truth Note

This chapter is the general source of truth for MICROBA Membership and Profile principles.

Detailed rules belonging specifically to HIVE, Product, Commerce, SA, Knowledge, administration, or another capability are defined in their dedicated chapters.

Public wording, legal terminology, verification methods, privacy implementation, and interface design may be refined before publication without changing the underlying Membership architecture unless an approved architecture revision is made.