Launch: Event Management

5.1 Introduction

Launch is MICROBA's event-management capability.

It allows eligible MICROBA members to create, submit, manage, publish, and close events connected to the MICROBA ecosystem.

Launch is designed to support genuine community activity rather than simply listing promotional dates.

A Launch event should have:

• a clear identity;
• a real organizer;
• a date and time;
• a venue or location;
• an intended audience;
• approved event information;
• appropriate visual assets;
• a lifecycle from planning to completion; and
• a post-event record when the event has ended.

The core principle is:

**A Launch event is a real, auditable community activity with a

beginning, a live period, and a documented conclusion.**

5.2 Who Can Use Launch?

Launch is a member capability.

A member may be allowed to create and manage events according to current membership, identity, and permission rules.

Not every public Visitor is automatically allowed to create a Launch event.

Conceptually:

Visitor
   |
JOIN / SIGN IN
   |
Member
   |
Eligible for Launch
   |
Create Event

Specific eligibility restrictions can be defined by Launch policy.

5.3 Purpose of Launch

Launch exists to help members organize genuine MICROBA-related activity.

Examples may include:

• community gatherings;
• Product introduction sessions;
• educational sessions;
• public presentations;
• private member events;
• local community activities;
• campaign events;
• learning sessions;
• member meetups; and
• other approved MICROBA experiences.

Launch should not be treated merely as a generic calendar.

It is a structured event record connected to MICROBA identity, governance, community, and history.

5.4 Event Lifecycle

A Launch event follows a controlled lifecycle.

A simplified model is:

DRAFT
  |
SUBMITTED
  |
ADMIN REVIEW
  |
APPROVED
  |
PUBLISHED / SCHEDULED
  |
LIVE / EVENT DATE
  |
COMPLETED
  |
CLOSED

Additional statuses may include:

• rejected;
• changes requested;
• postponed;
• cancelled; or
• archived.

The exact implementation may evolve, but the system should preserve the event's lifecycle and history.

5.5 Creating an Event

A member begins by creating an Event Draft.

The draft should collect the information required to describe the event clearly.

Core event information includes:

• Event Name;
• Event Date;
• Start Time;
• End Time or expected duration where applicable;
• Venue;
• Location;
• Audience Type;
• Event Visibility;
• Event Description;
• Banner or approved event image;
• Organizer identity; and
• relevant contact or participation information where approved.

The organizer should provide accurate information.

5.6 Event Name

The Event Name should clearly identify the activity.

It should not be misleading or intentionally impersonate an official MICROBA event unless the organizer is authorized to present it that way.

Examples:

MICROBA Community Introduction — Bandung

MICROBIOSM Learning Session — Jakarta

Member Gathering — Surabaya

The naming standard may later be refined by Launch branding rules.

5.7 Date and Time

Every event must have a valid date and time.

The system should store time in a reliable form and preserve the relevant timezone.

This is especially important because MICROBA may operate across different countries and local timezones.

Conceptually:

Event Date
Local Start Time
Local End Time
Timezone

A member should see the event in the local context intended by the organizer.

5.8 Venue and Location

An event may have a physical venue.

The event record may include:

• Venue Name;
• Address;
• City;
• Country;
• map/location information; and
• relevant access notes.

Where appropriate, location may be selected from a guided location tool or entered manually.

The organizer is responsible for ensuring the location is accurate enough for participants to find the event.

5.9 Audience

The organizer should identify the intended audience.

The current Launch model supports:

• Public Event
• Private Event

Public Event

A Public Event may be discoverable by people outside a restricted member group.

It may appear in appropriate public Launch listings.

Private Event

A Private Event is intended for a controlled audience.

Access may be limited by:

• invitation;
• member eligibility;
• event-specific access;
• private link; or
• another approved rule.

Private does not mean the event is exempt from governance or review.

Both public and private events remain subject to Launch rules.

5.10 Event Visibility

Visibility and audience are related but should remain conceptually clear.

An event may be:

Publicly Visible
Private / Restricted

Visibility determines who can discover or access the event listing.

The underlying event record remains available to authorized system administrators for governance and audit.

5.11 Event Banner

Each Launch event may include an Event Banner.

The banner should:

• represent the event accurately;
• follow approved MICROBA visual guidelines;
• avoid misleading claims;
• avoid unauthorized trademarks or protected content; and
• meet required image dimensions or technical requirements.

HIVE or Launch may provide approved poster/banner templates to help organizers create consistent materials.

5.12 Event Poster and Share Assets

Launch may provide share-ready promotional assets.

Examples include:

• event banner;
• social poster;
• QR code;
• event link;
• invitation image; and
• approved social-media share format.

Conceptually:

Approved Event
     |
Launch
     |
Generate Share Assets
     |
Poster / Banner / QR / Link
     |
Social Media / Direct Sharing

These assets help members promote genuine approved events without manually rebuilding event information in multiple places.

5.13 Event QR

A Launch event may have a QR code.

The QR may direct people to:

• event details;
• registration;
• attendance information;
• JOIN where required; or
• another approved event destination.

Scanning the event QR does not automatically create HIVE commission.

If a HIVE relationship is also involved, sponsorship attribution must still follow HIVE rules.

Launch should not silently create sponsor relationships merely because a person attends an event.

5.14 Event Submission

A Draft Event is not automatically public.

When the organizer is satisfied with the details, they submit the event for review.

Conceptually:

Draft
  |
Submit
  |
Pending Admin Review

Submission confirms that the organizer is asking MICROBA to review the event for publication.

5.15 Administrative Approval

All Launch event submissions and material edits must be approved by an authorized Admin before they become effective in the published event experience.

Admin may:

• approve;
• reject;
• request changes;
• place the event on hold; or
• apply another governed status.

This provides quality control and protects the integrity of the MICROBA event ecosystem.

The Admin should not need to recreate the event.

The organizer remains responsible for the event content.

5.16 Why Approval Is Required

Approval helps MICROBA confirm that an event appears genuine and appropriately described.

Review may consider:

• completeness;
• event identity;
• date and time;
• venue;
• audience;
• banner;
• description;
• policy compliance;
• misleading claims;
• duplicated events; and
• other relevant governance concerns.

Approval is not a guarantee of attendance, commercial success, safety, or outcome.

It is a platform governance step.

5.17 Editing Before the Event

An organizer may need to edit an event before its scheduled date.

Examples include:

• correcting a description;
• changing time;
• changing venue;
• updating a banner;
• changing audience information; or
• postponing the event.

Important edits should return to an approval workflow.

Conceptually:

Approved Event
      |
Organizer Edits
      |
Revision Submitted
      |
Admin Review
      |
Approved Revision

The system should preserve revision history where appropriate.

5.18 Postponing an Event

An event may be postponed before its scheduled date.

The organizer should update the event with the new date/time and any related changes.

The postponement should be visible clearly to participants.

A postponement is not the same as deleting and recreating an event.

The original event identity and change history should remain traceable.

5.19 Cancelling an Event

An organizer may cancel an event where necessary.

A cancelled event should have an explicit status.

The event should not simply disappear if people may already have seen or received the event information.

A clear cancellation record helps avoid confusion.

The platform may notify relevant participants or viewers where supported.

5.20 Event Day

On the scheduled event date, the Launch record represents the event as a current or live activity.

The organizer remains responsible for conducting the event.

Launch does not automatically assume that an event occurred successfully merely because its date has passed.

After the event, the organizer must complete the closure process.

5.21 Closing an Event

After the event has ended, the organizer must close the event.

Closing confirms that the event has completed and provides a historical record of what happened.

The closure process may require:

• event photos;
• a summary;
• selected outcome information;
• attendance or participation information where appropriate;
• optional highlights; and
• another approved post-event record.

The goal is to transform a scheduled event into a completed community record.

5.22 Event Photos

The organizer may upload photos after the event.

Photos should:

• relate to the actual event;
• respect participant privacy;
• comply with applicable permissions and consent;
• avoid inappropriate content;
• accurately represent the activity; and
• follow platform content requirements.

Launch should not encourage uploading sensitive personal information merely to prove that an event occurred.

5.23 Post-Event Summary

The organizer should provide a short description of what occurred.

Examples of useful information include:

• what the event covered;
• key activities;
• general participation;
• major learning points;
• community outcomes; and
• relevant next steps.

The summary should be factual and understandable.

It should not require a long formal report unless a specific event programme requires one.

5.24 Post-Event Templates

Launch may provide templates to make event closure easier.

Example:

What happened?
[Short Summary]

Highlights
[Key Points]

What did participants do?
[Activities]

What happens next?
[Optional Follow-up]

Templates support consistency without forcing every organizer to write in the same style.

5.25 Closure Review

If Launch governance requires it, post-event closure content may also be reviewed by Admin.

This may include:

• photos;
• summaries;
• edited descriptions; and
• completion status.

The purpose is to protect the quality and integrity of published event history.

5.26 Completed Event Record

Once closed and approved where required, the event becomes part of MICROBA's event history.

A completed event may appear:

• in Launch;
• in the organizer's Profile;
• in relevant community pages;
• in event archives; or
• in other approved discovery experiences.

Conceptually:

Upcoming Event
      |
Event Happens
      |
Organizer Closes
      |
Post-Event Content
      |
Completed Event
      |
Launch History + Profile

This allows a member's real community activity to become part of their MICROBA journey.

5.27 Event in Member Profile

A member's Profile may show Launch activity connected to their identity.

For example:

My Launch Activity

Upcoming Events
2

Completed Events
7

Profile displays the event relationship.

Launch remains the source of truth for event records.

5.28 Event Ownership

Every event should have a clear organizer/owner.

The organizer is the member responsible for managing the event record.

Ownership does not mean the organizer can bypass governance.

Admin approval rules still apply.

Where co-organizers are supported in the future, roles and permissions should be explicit.

5.29 Event Permissions

Launch should use clear capabilities.

Examples may include:

• create event;
• edit own event;
• submit event;
• postpone own event;
• cancel own event;
• close own event;
• upload event photos;
• review event;
• approve event;
• reject event; and
• manage Launch governance.

A normal member should not gain administrative approval capability merely by organizing an event.

5.30 Public and Private Event Privacy

A Public Event may expose approved public information.

A Private Event should limit event details according to the intended access model.

However, an organizer should not use Private status to hide activity from authorized MICROBA governance.

Privacy controls protect participant access, not platform accountability.

5.31 Launch and HIVE

Launch and HIVE are separate capabilities.

A member may use Launch without creating a HIVE commission.

An event may help a member introduce MICROBA to people, but attendance alone is not an eligible sponsorship sale.

Conceptually:

Launch Event
    |
Visitor attends
    |
May later JOIN
    |
HIVE attribution only if valid
    |
Eligible future purchase
    |
Possible HIVE commission

Launch should not create multi-level sponsorship relationships.

5.32 Launch and Visitor

Visitors may be able to discover Public Events.

A Public Event may provide:

• event information;
• location;
• date/time;
• event description;
• approved banner;
• public registration or JOIN path; and
• relevant public contact information.

Private Events require appropriate access.

5.33 Launch and Membership

A Visitor may discover an event before becoming a member.

Where membership is required to attend, register, or interact with a specific event, Launch should guide the Visitor through JOIN or SIGN IN.

Launch should not create its own member account system.

Membership owns identity.

5.34 Launch and Commerce

Some events may be free.

Others may eventually require a commercial transaction.

If payment is required:

Launch
  |
Commercial Request
  |
Commerce
  |
Payment
  |
Confirmed Event Registration

Launch should not implement a separate payment engine.

Commerce owns commercial settlement.

5.35 Launch and SA

Launch activity should not automatically create SA merely because an event exists.

If MICROBA later defines an approved SA benefit for specific event participation or purchase activity, that rule must be explicit.

The current architectural principle is:

Launch records event activity. SA follows SA rules.

5.36 Event Registration

Launch may support event registration where required.

Registration may include:

• member attendance intent;
• public registration;
• invitation acceptance;
• capacity limits;
• waiting list;
• QR admission; or
• another approved process.

Event registration is separate from MICROBA Membership registration.

A member registering for an event already has a Living Identity.

5.37 Attendance

Launch may later support attendance records.

Attendance should not be assumed merely from:

• opening an event page;
• scanning a marketing QR;
• clicking an invitation; or
• registering.

Actual attendance requires an appropriate event process if MICROBA chooses to record it.

5.38 Event Capacity

An event may have a capacity.

If capacity is used, Launch should provide clear states such as:

Available
Nearly Full
Full
Waitlist
Closed

The organizer should not manually promise attendance beyond the system's approved capacity logic where capacity control is enabled.

5.39 Event Timezone

Timezone handling is important for event accuracy.

An event record should preserve the timezone associated with the scheduled event.

A user viewing an event from another region may be shown:

• the event's local time; and/or
• a converted local time,

depending on interface policy.

The source event time should remain unambiguous.

5.40 Event History

Launch should preserve meaningful event history.

Examples include:

• event created;
• submitted;
• approved;
• edited;
• postponed;
• cancelled;
• opened;
• closed;
• post-event content added; and
• closure approved.

History supports auditability and member trust.

5.41 No Silent Deletion

An event that has already been published or used should not be silently erased merely to hide a mistake.

Where correction is required, Launch should use an explicit state or history-preserving update.

For example:

Published
   |
Incorrect Date
   |
Revision Submitted
   |
Approved Correction

This is preferable to deleting the entire historical event record.

5.42 Notifications

Launch may notify relevant people about important event changes.

Examples include:

• event approved;
• event rejected;
• changes requested;
• event postponed;
• event cancelled;
• event starting soon;
• event closure required; and
• closure approved.

Notification channels may include in-platform notifications and approved email notifications.

5.43 Event Reminder

Where supported, members may receive reminders before an event.

Reminder behaviour belongs to Launch or notification policy and should respect the member's preferences and consent settings.

A reminder does not create attendance or sponsorship activity.

5.44 Event Integrity

Launch events should represent genuine activities.

The system may reject or flag events that appear:

• fabricated;
• duplicated;
• intentionally misleading;
• impersonating another organizer;
• using false venues;
• violating MICROBA policies; or
• created solely to manipulate another programme benefit.

Launch should maintain a clear governance trail for these decisions.

5.45 Event Moderation

MICROBA may moderate event descriptions, images, comments, or post-event materials where applicable.

Moderation should be performed according to approved policies.

Administrative moderation should be distinguishable from organizer edits.

5.46 Launch Dashboard

A member-facing Launch dashboard may show:

MY LAUNCH

Drafts
2

Pending Approval
1

Upcoming
3

Completed
12

The member can then open the appropriate event record.

The dashboard should prioritize clear event states rather than technical workflow terminology.

5.47 Admin Launch Dashboard

An Admin view may show operational information such as:

LAUNCH REVIEW

Pending Events        8
Pending Revisions     3
Closure Reviews       5
Upcoming Approved    42
Attention Required    2

This allows governance without requiring administrators to search individual member Profiles manually.

5.48 Launch and Articles

A completed event may inspire future Article content, but an event record and an Article are not the same object.

Launch owns:

• event lifecycle;
• event identity;
• event schedule;
• event closure; and
• event history.

Articles own:

• educational or editorial content.

If an Article references a Launch event, it should link to or cite the event rather than duplicating event ownership.

5.49 Launch and Knowledge

An event may include educational content, but attendance does not automatically equal Knowledge completion.

Knowledge milestones should follow Knowledge rules.

If MICROBA later creates a formal Knowledge activity linked to an event, the relationship should be explicit.

For example:

Launch Event
    |
Includes Approved Knowledge Session
    |
Knowledge Activity
    |
Separate Knowledge Completion Rule

5.50 Example Launch Journeys

Journey A — Public Event

Member Creates Draft
        |
Adds Name, Date, Time, Venue, Audience, Banner
        |
Submits
        |
Admin Approves
        |
Public Event Published
        |
Event Happens
        |
Organizer Adds Photos + Summary
        |
Closes Event
        |
Completed Event Appears in Launch + Profile

Journey B — Private Event

Member Creates Event
        |
Visibility = Private
        |
Admin Approves
        |
Invitation Shared
        |
Approved Audience Accesses Event
        |
Event Completes
        |
Organizer Closes Event

Journey C — Postponed Event

Approved Event
      |
Organizer Needs New Date
      |
Postpone / Edit
      |
Submit Revision
      |
Admin Approves
      |
New Date Published

Journey D — Cancelled Event

Approved Event
      |
Organizer Cancels
      |
Status = Cancelled
      |
Participants See Cancellation

Journey E — Event Introduces a New Member

Visitor Attends Launch Event
         |
Learns About MICROBA
         |
Later JOINs
         |
If valid HIVE attribution exists
         |
Direct Sponsor relationship may be recorded

The event itself does not create commission.

5.51 Frequently Asked Questions

What is Launch?

Launch is MICROBA's event-management capability.

Who can create an event?

Eligible MICROBA members according to Launch permissions.

Can a Visitor create an event?

Not through the standard member Launch flow.

What information is required for an event?

Core information includes event name, date, time, venue/location, audience, visibility, description, and approved visual material.

Can I create a Public Event?

Yes, subject to Launch approval and policy.

Can I create a Private Event?

Yes, subject to Launch approval and policy.

Does a Private Event avoid Admin review?

No.

Do events need Admin approval?

The current Launch model requires submissions and material edits to be approved before publication.

Can I edit an event after approval?

Yes, but material changes should return through the approval process.

Can I postpone an event?

Yes.

Can I cancel an event?

Yes.

Should a cancelled event simply disappear?

No. A clear cancellation status is preferable.

What happens after my event is finished?

You should close the event by completing the required post-event record.

What may be required when closing an event?

Photos, a short summary, and other approved completion information.

Can I use a template for the event summary?

Launch may provide templates.

Will completed events appear in my Profile?

They may be displayed as part of your Launch activity.

Does Profile own the event?

No. Launch remains the source of truth.

Can Launch create HIVE commission?

An event alone does not create commission.

Does scanning an event QR create commission?

No.

Can an event help create a valid HIVE relationship?

A Visitor may later enter a valid HIVE journey, but HIVE attribution rules still apply independently.

Can I sell event tickets directly inside Launch?

If an event requires payment, Launch should use Commerce rather than building its own payment system.

Does attending an event generate SA?

Not automatically.

Does attending an event increase Knowledge progress?

Not automatically. Knowledge uses its own completion rules.

Can a completed event become an Article?

An Article may later reference or report on an event, but Launch and Articles remain separate content types.

Can Admin edit my event?

Administrative moderation and governance may affect event status or content according to policy, but changes should remain auditable.

Are event photos public?

Only according to the event's visibility, publication, privacy, and content rules.

What if a photo includes people who do not want to be shown?

The organizer should follow applicable privacy and consent rules before publishing participant images.

Can I delete an event after people have seen it?

Published event history should generally be preserved through explicit statuses and revisions rather than silent deletion.

Does Launch support reminders?

It may, according to notification policy.

Does Launch support capacity limits?

The architecture can support capacity and waitlist rules where required.

5.52 Chapter Summary

Launch is MICROBA's governed event-management capability.

The core rules are:

• Launch is available to eligible members;
• events have a clear lifecycle from Draft to Closed;
• event details include name, date, time, venue, audience, visibility,

description, and approved visual assets;

• Public and Private events are supported;
• event submissions and material edits require Admin approval under

the current model;

• events can be edited, postponed, or cancelled with history

preserved;

• organizers must close completed events;
• closure may include photos and a post-event summary;
• completed events can become part of Launch history and the

organizer's Profile;

• Launch may generate approved banners, posters, QR codes, and share

assets;

• event QR scans do not themselves create commission;
• Launch and HIVE remain separate;
• Launch and Commerce remain separate;
• Launch and Knowledge remain separate;
• event records should be auditable;
• published events should not be silently deleted; and
• genuine event activity is more important than simply creating event

listings.

5.53 Source-of-Truth Note

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

Membership owns identity. HIVE owns direct sponsorship. Commerce owns payments and commercial transactions. Knowledge owns learning progress. Articles own editorial and educational publishing.

Launch owns event identity, lifecycle, submission, approval, scheduling, visibility, completion, and event history.

Public wording, event templates, approval criteria, capacity rules, notification behaviour, privacy implementation, and interface design may be refined before publication without changing the underlying Launch architecture unless an approved architecture revision is made.