One identity, professional role
Your Skipper workspace is part of your Malaka identity — not a separate account.
The additional framework for offering professional sailing services and operating Trips through Malaka — from verification and Experiences or Offers, through Bookings, Trips, Crew, payments and reviews.
Your Skipper workspace is part of your Malaka identity — not a separate account.
Uploaded credentials are not automatically Verified — status is reviewed in context.
Bookings retain recorded terms; accepted Offers retain their accepted version.
Trip execution, Crew, Boat and calendar context are distinct from the Booking transaction.
These are product principles, not final legal clauses.
01 About
These Skipper Professional Terms describe how the professional Skipper role works within Malaka: how the role is activated, how a professional profile and credentials are presented, how Experiences, Departures, Offers, Bookings and Trips relate to one another, and how payments, reviews and professional status are handled.
This document is informational and product-oriented. It explains how the interface and product architecture are intended to work. It does not by itself create, confirm or complete any professional relationship, approval or transaction.
This page shows how being a Skipper fits into Malaka as a product. The parts that carry binding professional or legal obligations are marked and still need approved wording before publication.
02 Framework
Two documents work together for anyone acting as a Skipper.
Apply to use of Malaka generally — to every person using the platform, in any role.
Contain the additional terms relevant when a Malaka user operates in the professional Skipper role. This is that document.
[Relationship and precedence between these documents to be legally defined.]
Final wording must be supplied or approved before publication. Document precedence is not assumed in this prototype.
03 Activation
A Skipper is not necessarily a separate account. One Malaka identity may also act as a Traveller, Crew member, Booking Owner or Group Leader. Professional activation is a role and workspace context on top of your existing identity, not a new sign-in.
The activation flow moves through a series of product steps:
Application status is separate from component verification status. The progress of your overall application is tracked independently from the status of each individual credential or document within it.
Your professional application moves through known product states:
Submitting an application does not itself mean it has been approved.
04 Profile
At a product level, Skipper profile information should accurately represent the Skipper’s experience and services. A profile may include fields such as:
Final contractual accuracy obligations: [To be provided.]
A Skipper profile has a clear boundary between the public professional presentation and the private evidence behind it.
05 Verification
Identity verification is conceptually separate from professional qualification. Confirming who someone is does not, on its own, assess their competence, licensing or fitness for a particular Boat or jurisdiction.
Each credential or document has its own canonical status:
A credential record may capture: credential type, issuer or jurisdiction, issue and expiry dates, a masked identifier, the document itself, and a review status. Malaka does not impose a single universal licence requirement across all contexts.
[Credential requirements and equivalence rules must be defined by applicable context and qualified legal / professional review.]
This prototype does not claim that any one credential equals another, that any certificate is mandatory everywhere, or that any credential is valid worldwide.
Where Malaka shows a verification indicator, it reflects a completed platform check of specific information — not a guarantee of competence, safety, legal compliance, future validity, or fitness for every Boat or jurisdiction.
A credential may later become Expiring soon, Expired, or move a component into Action required. Operational review may be needed in these cases.
Final consequences of an expired credential: [To be defined.] This prototype does not automatically state that all future Trips are cancelled or that an account is terminated.
Additional documents are contextual, not universal. Each request should carry a reason, its context, the document type and a status. Blanket requirements are not assumed.
Identity-verification legal and privacy details, including any processing methods or providers: [To be provided.] No biometric processing, government lookup or specific provider is described here.
06 Status
Professional status describes whether, and how, a Skipper is currently offering services — and is distinct from application status.
[Professional eligibility requirements to be provided based on applicable law and Malaka’s final operating model.]
Minimum age, nationality, residency, work authorization and professional licence category are not defined in this prototype.
[Legal characterization of the relationship between Malaka and Skippers to be provided.]
This prototype does not describe Skippers as employees, independent contractors, agents, suppliers or partners. That characterization awaits final legal analysis.
07 Service modes
Malaka supports three professional work modes. A Skipper may use one or several.
The Skipper creates reusable sailing Experiences and publishes dated Departures for travellers to book.
The Skipper responds to customer Skipper Requests with Offers, without needing an Experience or Departure.
The Skipper may use Malaka operational tools for relevant private or external work, where supported.
Legal and commercial applicability to each mode: [To be defined.]
08 Experiences
An Experience is a reusable product — the story of a sailing holiday rather than a specific dated instance. It may contain a story, region, duration concept, route, itinerary, style, guest fit, yacht fit, booking modes, inclusions, exclusions, practical information, a gallery and an FAQ.
Exact dates, Boat, price and inventory do not live on the Experience — they belong to a Departure.
A Published Experience is not automatically bookable. It becomes bookable only when an appropriate future available Departure exists. This is a product architecture rule.
Experience-content obligations — including accuracy, photos, descriptions, inclusions, safety claims and third-party rights: [To be provided.]
09 Departures
A Departure is the dated, bookable instance of an Experience. It owns the exact dates, Boat, Skipper, booking mode, price, capacity and inventory, availability, and embark / disembark logistics. Legal text should not confuse a Departure with the Experience it belongs to.
A Departure can be sold in different ways, and inventory must avoid double-selling:
The entire boat is booked by one party.
Individual cabins are sold within the same Departure.
Single berths are sold to individual travellers.
Whole-yacht, cabin and berth relationships are operational product rules designed to prevent selling the same space twice.
Final contractual inventory obligations: [To be provided.]
Capacity derives from the Boat and its configuration. [Applicable capacity / safety requirements remain subject to Boat, jurisdiction and professional obligations.] No legal passenger limits or certification are invented here.
Changes to a Departure’s date, Boat, Skipper, price, capacity or booking mode may affect existing Bookings. Recorded Booking terms are not silently rewritten.
Final rights and obligations when a Departure changes after Bookings exist: [To be provided.]
10 Find a Skipper
In the Skipper Only mode, customers post a Skipper Request and Skippers can respond. The flow does not require an Experience or Departure:
This is not an auction. Find a Skipper is not described as bidding, a reverse auction, or “lowest price wins.” There is no professional obligation to undercut another Skipper.
11 Offers
An Offer is a Skipper’s proposal in response to a Skipper Request. It may include a fee, dates, travel costs, accommodation assumptions, onboard expenses, inclusions, exclusions, conditions, a message and a validity period if one is explicitly set. Malaka does not impose a mandatory format or fee.
A revised Offer should preserve its previous versions, and an accepted Booking retains the exact accepted Offer version. Accepted terms are not silently rewritten.
A customer accepting an Offer does not itself mean payment has been processed. Acceptance, Booking and payment remain distinct states.
Final obligations around offer accuracy, availability, validity, withdrawal, revision and acceptance: [To be provided.]
12 Bookings
A Booking is the canonical commercial record. It stores the recorded commercial terms and is reached by two routes:
Experience → Departure → Booking.
Request → Accepted Offer → Booking.
The Booking captures a snapshot of the terms as they stood when it was made.
Later changes to the Experience, Departure or Offer must not silently rewrite an existing Booking. The recorded terms stay with the Booking.
13 Trips
A Trip is the operational layer. It may contain a route, Boat, Crew, documents, a payments summary, messages, a checklist and a meeting point. The Trip is where a booked holiday is prepared and run — it is not the transaction record.
The Trip organises the operational context a Skipper works within, including:
Final legal and professional operational duties: [To be provided.]
Sailing routes may change because of weather, sea conditions, port availability, safety or operational judgment. Malaka does not guarantee a fixed itinerary, and this prototype does not invent financial consequences for route changes. Where relevant, refer to the Cancellation Policy — Page 100 .
14 Boats
A Boat on a Trip has a source type. These are operational relationship labels, not legal ownership conclusions:
A Boat the Skipper presents as their own.
A Boat obtained through a charter arrangement.
A Boat provided by the customer.
A Boat sourced from an external relationship.
Boat records may hold make and model, capacity, cabins, a gallery, documents and assignments. As with credentials, uploaded is not the same as verified, and external or customer-provided evidence is not automatically Malaka-verified. A Boat is not labelled “compliant” as a blanket status.
Final Skipper responsibilities regarding ownership, charter permission, insurance, registration and seaworthiness: [To be legally defined.]
15 Crew
Crew members complete their own traveller information. A Skipper should only access the information that is operationally necessary, according to permissions and context — not unrestricted sensitive data.
A Group Leader sees readiness rather than unrestricted Crew sensitive data. These Terms operate alongside the Privacy Policy — Page 98 .
Sensitive traveller data is protected. Passport or ID scans, full document numbers, emergency contacts, accessibility or practical details, health-related information and payment data must not be exposed beyond an authorized operational need.
Malaka may support generating or checking the readiness of a Crew manifest. This prototype does not state that any manifest is legally sufficient or follows a universal required format.
Final professional confidentiality and data-use obligations: [To be provided.]
16 Calendar
A unified Skipper calendar can bring together published Departures, confirmed Trips, Skipper Jobs, Private Trips, External Charters and Unavailable blocks. A professional should keep availability accurate where applicable.
An empty calendar does not mean available. A Skipper is not treated as legally or operationally available merely because no calendar event exists for a given date.
iCal and Google integrations may be future capabilities. This prototype does not promise calendar synchronization.
Final availability obligations: [To be provided.]
17 Communications
Messaging happens in several contexts: a Trip Group, a private Booking conversation, a Skipper Request / Offer thread, direct customer contact, and Support.
Keep commercial detail out of shared spaces. Customer payment terms, refund details and private Booking discussions should not be placed into shared Trip Group messages.
Professional communication conduct rules: [To be provided.] See also the Community & Review Guidelines — Page 102 .
18 Payments
Three financial concepts are kept distinct and should not be conflated:
What the customer pays.
What is recorded as earned by the Skipper.
What is transferred to the Skipper’s payout destination.
This prototype does not invent when earnings become available, nor a weekly payout, a 7-day release, a minimum balance or a reserve.
[Payment / payout provider and processing terms to be provided.] Malaka remains provider-neutral in this prototype.
[Malaka fees, commissions and any applicable taxes to be provided in the approved commercial terms.]
Malaka may support an Individual or Business billing / payout profile. This prototype does not infer any legal business status from that choice. Professional payout and bank data is private and is never shown in public examples.
19 Cancellations
Cancellation handling is governed primarily by the Cancellation Policy — Page 100 . This prototype does not duplicate or invent cancellation penalties, refund percentages, Skipper compensation or replacement obligations.
Skipper-specific cancellation obligations and remedies: [To be provided.]
If a Skipper can no longer perform a committed Trip, operational escalation may be required. This prototype does not promise a replacement, a refund, a penalty or automatic suspension.
Final rules for Skipper unavailability: [To be provided.]
20 Reviews
Public reviews can be linked to completed Malaka activity. Private feedback is separate, and a Skipper may have public response functionality. Reviews are governed by the Community & Review Guidelines — Page 102 .
No manipulation. As a matter of professional conduct, there should be no harassment, retaliation or manipulation around reviews.
Final contractual review wording and any consequences: [To be provided.] No penalty schedule is invented here.
21 Integrity
Marketplace integrity covers areas such as:
This prototype does not invent non-circumvention penalties.
Off-platform activity: [Any restrictions or obligations concerning off-platform transactions or communications to be provided by legal counsel.] No fee-recovery assumptions are made.
22 Trust & Safety
Malaka may operate controlled Trust & Safety review processes. Reports and allegations are not automatically findings, and no guilt is presumed.
Final professional obligations and any possible account actions: [To be provided.]
Malaka does not promise or guarantee safety. Professional safety responsibilities must be defined by qualified legal and professional review.
[Applicable skipper safety, navigation and maritime responsibilities to be provided.]
Emergencies. Malaka is not an emergency-response service. In an immediate danger or medical emergency, appropriate local emergency services should be contacted.
23 Regulatory
These areas depend heavily on jurisdiction and on Malaka’s final operating model, and are not settled in this prototype. Malaka does not provide tax or legal advice.
Tax: [Skipper tax / VAT / invoicing responsibilities to be provided based on legal / commercial model and applicable jurisdictions.]
Insurance: [Insurance requirements, if any, to be provided.]
Regulatory: [Applicable professional, maritime, charter, immigration, licensing and local regulatory responsibilities to be identified for the operating model / jurisdictions.]
24 Deactivation
Professional status can move between platform states such as Active, Paused and Inactive. Application or verification issues may require review. This prototype does not invent automatic suspension rules; consequential professional actions should be controlled and human-reviewed.
Final grounds, notice, appeal / review and effects of restriction or deactivation: [To be provided.]
Active commitments are not silently erased. A professional status change should not silently remove future Bookings, Trips, payment records or review history.
Operational handling of active commitments during a status change: [To be defined.]
Professional account or role deletion may interact with historical, commercial and legal records, and is handled through Data & Account Requests — Page 104 . This prototype does not promise instant deletion.
[Professional content / IP provisions to be provided.] This prototype does not assume Malaka owns Skipper content, nor grant any licence over photos or Experience content.
[Professional liability, indemnity, limitation-of-liability and mandatory legal protections must be drafted by qualified legal counsel.]
25 Changes
These Professional Terms may be updated over time.
Change and notice process: [To be provided.] No notice period is invented here.
26 Law
Governing law: [To be provided]
Jurisdiction / dispute process: [To be provided]
No governing law or jurisdiction is inferred in this prototype.
27 Contact
[To be provided]
[To be provided]
No contact addresses are fabricated in this prototype.
28 Related
This document sits within Malaka’s wider set of terms and policies.
★ Reference
A quick map of Malaka’s core professional records and what each one is responsible for.
The story, route concept and inclusions — reused across many dated instances.
Exact dates, Boat, price, capacity and availability for one instance.
A Skipper’s proposed terms in response to a Skipper Request.
The canonical record of the agreed commercial terms, preserved as a snapshot.
Route, Crew, Boat, documents and checklist — how the booked holiday is run.
Departures, Trips, Jobs and blocks that show when a Skipper is committed.
Credentials and Boat documents, each with its own verification status.
What is earned and what is transferred — kept distinct from customer payment.
★ Overview
How the professional role fits together, from applying through to earnings and reviews.
Set up the Skipper role and submit an application.
Identity and credentials are reviewed in context.
The professional profile becomes active.
Publish an Experience, or discover Skipper Requests.
Create a Departure, or send an Offer.
A commercial record is created and preserved.
The booked holiday is prepared and run.
Earnings are recorded and reviews may follow.
Product journey — not a legal guarantee of approval or earnings.