Enterprise Onboarding, Regional Data Center, Tenant Provisioning and Access

This manual explains how an enterprise moves from first conversation to approved access in MBT, how its data is isolated, where it can be hosted, and how it is handed back and deleted when the engagement ends. Where something is a contractual option rather than a live default, it is labelled as such.

Before enterprise access is enabled, the organisation and HRMBT Labs agree the commercial and legal framework. Access is enabled only after the enterprise contract is signed.

• Bilateral NDA — protects the client's confidential information and MBT's proprietary methodology.
• Master services agreement — records the agreed scope, usage level and operating mode. Solo mode (individual researchers, each with private studies) is what the software delivers today; shared team workspaces are not currently available and are not offered as live.
• Data protection addendum — records lawful basis, processing purposes, retention and the agreed hosting region.
• Regional data center — the current default hosting region is Asia Pacific (Singapore). A different region can be requested and scoped in the contract: EU (Frankfurt), UK (London), North America (Virginia), India (Mumbai), GCC (UAE / Bahrain) or Australia (Sydney). A requested region is provisioned only once contractually agreed; it is not active by default.
• AI service keys — the enterprise decides whether MBT's managed AI services are used, or whether its own keys are supplied under the contract.
• Other considerations — named authorised users, security review contacts, internal approvals and the offboarding terms in Stage 6.

• Each researcher requests access with a business email address. Personal mailboxes are blocked.
• The address is verified with a one-time code.
• A pending request is created for MBT Team review; the email domain is matched against registered organisations.

• The MBT Team approves or declines each request in the administrator console.
• On approval the researcher is linked to their organisation, which becomes their tenant, and assigned a usage level (Level 1 by default, up to Level 3).
• There are no payments, trials or self-serve sign-ups.

• Every request resolves the signed-in user's tenant from their approved account. A researcher not linked to an organisation works in a personal tenant.
• Uploaded documents, their search index and storage paths are tagged with the tenant ID and filtered by database access rules.
• Saved studies are private to the researcher who created them.
• Client documents are not sent to outside research services and are not used to train third-party models.

• Corporate subdomains map to the parent organisation unless set up as a separate tenant.
• External advisors can be assigned to a client organisation by the MBT Team.
• Revoking a researcher locks them out immediately.

Inside the workspace and on My projects, each researcher sees a tenant chip beside their email showing the organisation name (or "Individual") and an abbreviated tenant ID. Opening it shows the full tenant ID with a copy button, the signed-in email, usage level, data region and a note that uploaded documents are stored and filtered under that tenant ID.

When an engagement ends, the following procedure is carried out by the MBT Team as agreed in the enterprise contract.

• Freeze — tenant access becomes read-only.
• Handover — an export of uploaded documents, saved studies, reports and decks is prepared and delivered to the organisation.
• Deletion — after the organisation confirms receipt, the tenant's documents, search index, studies, stored files and user access are deleted.
• Confirmation — a written deletion confirmation is issued by HRMBT Labs.