Architecture and Operating Model

This page explains how the product is structured as a system, not just as a UI.

Obelisk is a control plane. The UI matters, but the operating model is what makes the product durable.

System Layers

1. Identity And Session Layer

The platform uses authenticated sessions with an active organization bound into session state.

Core ideas:

• users authenticate before accessing protected product surfaces
• the current organization is carried in session as activeOrganizationId
• product behavior changes depending on whether the user is in a personal, organization, or admin context

This is what lets the same account move between account-level views, organization workspaces, and platform administration.

2. Tenant And Access Layer

Obelisk is built around organization-scoped work.

Access control is enforced through:

• authenticated procedures for signed-in users
• organization-aware procedures that require an active organization
• membership validation before organization data is returned
• a two-tier role system:
  • platform role
  • organization role

This matters because organization scoping is not just a navigation concept. It is part of the server-side execution model.

3. Product Surface Layer

The system is exposed through three major surfaces:

• personal workspace pages
• organization workspace pages
• admin console pages

Organization pages are where most operational work happens. Admin pages exist for cross-organization governance, intervention, and platform health.

4. Execution Layer

Operational actions do not rely on optimistic UI alone.

The product persists execution state through queue-backed models such as:

• provisioning tasks
• provisioning audit logs
• deployment records
• alert events and delivery history

This creates a more reliable operating model for actions such as:

• create
• redeploy
• suspend
• resume
• deprovision

The result is a system where teams can inspect what happened, not just what they hoped happened.

5. Commercial Layer

Monetization is built into the same operating model rather than being bolted on externally.

This includes:

• subscriptions
• invoices
• payment method management
• credits
• auto top-up

Because these are organization-scoped, billing and usage can be understood close to the workflows that consume them.

6. Observability And Governance Layer

The product exposes multiple levels of operational visibility:

• organization activity feeds
• analytics and audit logs
• admin notifications
• platform alerts
• structured logging and Sentry context in server procedures

This makes the platform easier to operate as the team grows and responsibilities split across roles.

Operating Principles

These principles show up repeatedly across the codebase and product behavior:

• identity comes first
• organization context is explicit
• protected actions should be role-aware
• execution should be durable and inspectable
• platform governance should be separate from tenant operations
• monetization should stay close to operational usage

Why This Model Scales

Many internal tools break down because they are only collections of pages.

Obelisk scales better when teams treat it as:

• a system of record for workspace operations
• a governed surface for automation
• a durable execution log for runtime actions
• a commercial control plane for paid platform behavior

That operating model is more important than any single feature page.

What To Read Next

• Permissions and Tenant Model
• Route Map
• Security and Governance
• Use Cases and Team Fit
• API Keys and Public Deployment API