Triangle at the front door
Triangle (secure sign-on) is the shared front door for every surface the platform runs: the public marketing sites, the request-access funnel, and each brand's operator console. One credential covers all of them — there is no separate login per app, per brand, or per location.
The design goal is not convenience alone. A single sign-on means a single place where sessions are issued, rotated, and revoked — and a single identity that permissions attach to, instead of a patchwork of per-system accounts that drift out of sync as people join, move, and leave.
The public funnel
Marketing's /request-access starts the Triangle sign-on process. A request states the person's role — operator, partner, or counsel — and that declaration drives routing: operators land in the correct brand's console, partners enter the developer track, counsel enters the diligence path. Requesting access on a public site is therefore not a lead form with a login bolted on later; it is the first step of a secured onboarding path.
Once credentialed, the same sign-on carries the person from any public page straight into their console. The public site never holds a session of its own — it hands off to Triangle and back.
Identity versus permission
A signed-in session establishes who you are — one durable identity across every surface. What you may do is resolved separately, per brand:
- Permissions attach to the brand you are working in, never to your identity globally.
- Access is never assumed from the first brand you happen to belong to; each brand's grants are explicit and separately reviewed.
- Losing a grant on one brand changes nothing about your standing on another.
This is the identity half of the platform's isolation story. How per-brand data isolation works covers the data half: the boundary that every query, SDK read, and agent action inherits.
Sessions in brief
Sessions are short-lived by design, rotate continuously, and can be revoked centrally — one action ends access across every surface, instead of app-by-app cleanup as someone remembers each system. Multi-factor authentication and passkeys are part of the same front door rather than per-app options.
Builders integrating against the session layer should read Triangle sessions & tokens for the exchange flow, token lifetimes, storage discipline, and key rotation.
Joining, moving, leaving
The one-credential model pays off most at the moments organizations usually handle badly:
- Joining. A new operator gets one identity and the grants their role requires — no per-app account provisioning queue, no shared "front desk" password.
- Moving. A role change is a grant change: the person's identity and history stay intact while their permissions shift to the new role, per brand.
- Leaving. Offboarding is revocation in one place. Access ends across every console and surface at once, and the audit trail keeps the history of what happened before the departure.
Each of these is where a patchwork of per-system logins quietly fails — the account nobody remembered to disable is the one that matters.
What not to do
- Do not rebuild sign-on per brand. A second credential store is a second permission system — unaudited and invisible to the people who approved the first.
- Do not grant access from URL structure. Role resolution happens server-side against explicit grants; a URL is never evidence of authority.
- Do not treat the public site as a session surface. It is an orientation and handoff layer; authenticated state lives behind Triangle, in the console.
Boundary
This page is public orientation. Account provisioning, session internals beyond the orientation level, and environment-specific configuration ship with authenticated developer access.