# Supplier Pulse — Platform Overview

## What is Supplier Pulse?

Supplier Pulse is a B2B SaaS platform for BMW supplier development engineers. It enables structured supplier visits, cycle time measurement, OEE analysis, improvement tracking, factory assessments, and workshop facilitation.

The platform is sold as a managed service to companies. Each company receives a fully isolated environment with its own database, configuration, and user management.

---

## Two-Plane Architecture

```
┌─────────────────────────────────────────────────────────┐
│                  OWNER CONTROL PLANE                     │
│                                                          │
│  Owner Portal  ·  Tenant Registry  ·  Provisioning      │
│  Plan Manager  ·  Entitlement Engine  ·  Audit Log       │
│  Branding Engine  ·  Operational Controls                │
└─────────────────────────────────────────────────────────┘
                            │
          ┌─────────────────┼──────────────────┐
          ▼                 ▼                  ▼
┌─────────────────┐  ┌───────────────┐  ┌───────────────┐
│  Tenant A       │  │  Tenant B     │  │  Tenant C     │
│  BMW Int.       │  │  Acme Corp    │  │  Bosch        │
│  Own DB         │  │  Own DB       │  │  Own DB       │
│  Own Storage    │  │  Own Storage  │  │  Own Storage  │
│  Own Branding   │  │  Own Branding │  │  Own Branding │
│  Own Users      │  │  Own Users    │  │  Own Users    │
└─────────────────┘  └───────────────┘  └───────────────┘
```

---

## Product Modules

| Code      | Module Name       | Description                                      |
|-----------|-------------------|--------------------------------------------------|
| CALENDAR  | Kalender          | Consultant scheduling, visit planning            |
| LSC       | LSC Workshop      | Lean Supply Chain workshop facilitation          |
| OEE       | OEE Analyse       | Overall Equipment Effectiveness tracking         |
| VSM       | Wertstrom         | Value Stream Mapping canvas                      |
| ASSESSMENT| Fabrikanalyse     | 202-question supplier factory assessment         |
| REPORTING | Reporting         | Cross-visit analytics, PDF/Excel exports         |
| REPOSITORY| Datenablage       | Document management, QAF comparison              |
| PROJECTS  | Projekte          | Visit management, cycle time, improvement actions|

---

## Tenant Lifecycle States

```
DRAFT → PROVISIONING → ACTIVE → SUSPENDED → ARCHIVED
         ↓
    PROVISIONING_FAILED (→ retry → PROVISIONING)
```

| State               | Description                                      |
|--------------------|--------------------------------------------------|
| DRAFT              | Created, not yet provisioned                     |
| PROVISIONING       | Environment being set up                         |
| PROVISIONING_FAILED| Setup failed, retry available                    |
| ACTIVE             | Fully operational                                |
| SUSPENDED          | Temporarily blocked (billing, legal, abuse)      |
| ARCHIVED           | Decommissioned, data retained per retention policy|

---

## Feature Entitlement Layers

Every feature access decision passes four gates:

1. **Plan entitlement** — Is this module included in the tenant's plan?
2. **Tenant override** — Is it explicitly enabled or disabled for this tenant?
3. **Role permission** — Does this user's role allow this action?
4. **Operational toggle** — Is there a platform-level kill switch active?

All four must pass. A failure at any layer denies access.

---

## V1 Deployment Model

- One dedicated Supabase project per tenant
- One shared Owner Control Plane database (co-located Supabase schema, `cp_*` prefix)
- One shared codebase deployed per tenant via Vercel (or self-hosted)
- Tenant identity via `TENANT_ID` environment variable per deployment
- Owner Portal: isolated `/owner/` routes in the same Next.js app

---

## Strategic Principles

1. No customer-specific code forks. Configuration and entitlements drive all differences.
2. Owner data and tenant data are never stored in the same tables.
3. Every platform-level action produces an immutable audit event.
4. Provisioning is asynchronous, idempotent, and observable.
5. A failed provisioning job must be safely retryable.
6. Module access is enforced at UI, API, and data layers — never just one.
7. The control plane can always be extracted to its own deployment without redesign.