Venture & brand onboarding

How ventures plug into the platform

A venture onboards onto the platform the way a tenant moves into a building with shared services: it gets its own secured space, inherits the building's power and water, and signs up for the house rules. This page is the map of that process — what a venture consumes, what it may never do, and the order the pieces land in.

The consumption contract

Ventures build against published platform packages, consumed through the scoped package registry with versions pinned to locked releases. Three rules are absolute:

1. Consume, never fork. Ventures never copy platform source into their own tree. A fork is an un-audited second platform the day it is made.
2. Never publish. Ventures ship applications, not packages; the publishing boundary belongs to the platform layers (see the layer model).
3. Pin versions. Locked releases keep every environment on the same contract; upgrades are deliberate events, not ambient drift.

Where the platform needs venture-specific behavior — a different asset type, a custom domain rule — the platform defines the interface and the venture registers its implementation. Behavior is injected downward; imports never point upward.

The venture SDK wrapper

Each venture keeps one internal SDK package that wraps the platform's published packages behind a resolver pattern:

sdk/
  triangle/     types.ts  real.ts  mock.ts  resolver.ts
  payments/     types.ts  real.ts  mock.ts  resolver.ts
  compliance/   types.ts  real.ts  mock.ts  resolver.ts

The types define the venture's own stable contract; real.ts binds the published platform client; mock.ts returns local stub data; the resolver picks per environment. Two properties fall out of this: local development degrades gracefully when platform services are absent (stubs with a warning, not a crash), and interim implementations are mechanically findable when the real package ships.

Identity onboarding

User identity lands through the standard exchange, never through a side channel:

1. 1

   Sign in at the session layer

   The person authenticates through the shared front door — the same Triangle sign-on every surface uses.

2. 2

   Exchange for a platform token

   The venture's backend exchanges the session for a platform access token scoped to that venture: role, compliance tier, and brand context included. The mechanics are at Triangle sessions & tokens.

3. 3

   Provision by webhook, not by login

   Accounts and memberships are created by verified provisioning webhooks. The exchange endpoint never auto-creates a user — an unlinked identity is refused, not improvised.

4. 4

   Inherit tenant scoping automatically

   Every server-side query the venture makes runs with the venture's context injected at the transaction level. The venture cannot read outside its boundary even by accident — the same database isolation mechanics every platform consumer gets.

The isolation rules

• Ventures manage their own operational data and never write into platform-owned schemas.
• No cross-database foreign keys into platform databases. Entity resolution goes through the platform's published API surface, not through joins.
• Platform-to-venture updates (profile changes, status changes) arrive as signed sync webhooks — see webhooks & the event substrate.

The telemetry duty

Onboarding is not finished when sign-on works. Ventures stream transactional audit events to the event substrate on their own namespaced topics — written to the local record first, then emitted — feeding platform telemetry and the operations dashboard. This is what makes a venture's activity reconstructable in the same audit trail the platform itself keeps.

Boundary

This page is architectural orientation for teams planning an integration. Registry coordinates, credentials, environment values, and provisioning runbooks ship with authenticated developer access.