SpineWorkspace Architecture

1. Rooted access-and-projection tree

Core mental model

• SpineWorkspace is a rooted access-and-projection tree.
• Root: OneAuth (auth.spineworkspace.com) is the single root of trust and access control.
• Branches: Hostnames/subdomains (www, platform, sales, cs, etc.) are projection targets, not separate apps.
• Leaves: Concrete workspace projections rendered by a shared apps/web execution shell.

OneAuth as root

• OneAuth is the authentication and authorization root.
• It resolves, for every session:
  • Identity
  • Tenant
  • Workspace
  • Roles
  • Entitlements
  • Policies
• No other surface (marketing, platform, domain workspace) is allowed to mint or validate auth; all authenticated paths traverse OneAuth first.
• OneAuth also acts as the navigation root: it decides whether a user may enter a projection, and how they should be routed there.

Edges (subdomains) as projections

• Each subdomain is a projection selector, not a state owner:
  • It indicates which workspace shape should load.
  • It never owns credentials, connector state, or business truth; those live in Spine, connectors, memory, and platform services.
• Adding a new subdomain means adding a new projection configuration (host → projection key → Twin + capabilities), not a new app.

Edge types

• Public edge: www.spineworkspace.com

  • Unauthenticated marketing and docs.
  • Owns the story, SEO, solution catalog, and routes into OneAuth when a user chooses to sign in/sign up.

• Identity edge: auth.spineworkspace.com

  • Only surface for login, SSO, delegated host auth, and session lifecycle.
  • Converts an anonymous visitor into an entitled workspace user.

• Control-plane edge: platform.spineworkspace.com

  • Control plane UI for operating Spine itself: integrations, activation, capabilities, governance, agent fleet, observability, portfolio, administration.
  • Only reachable for platform‑scoped roles, always downstream of OneAuth. This mirrors modern SaaS “control plane UI over data planes” patterns.[1]

• Domain workspace edges:

  • founder.spineworkspace.com
  • sales.spineworkspace.com
  • cs.spineworkspace.com
  • marketing.spineworkspace.com
  • finance.spineworkspace.com
  • operations.spineworkspace.com / ops.spineworkspace.com
  • product.spineworkspace.com
  • engineering.spineworkspace.com
  • account-success.spineworkspace.com
  • technical-account-success.spineworkspace.com
  • business-intelligence.spineworkspace.com
  • campaigns.spineworkspace.com
  • knowledge-management.spineworkspace.com
  • revops.spineworkspace.com
  • support.spineworkspace.com
  • brandstore.spineworkspace.com
  • book-of-records.spineworkspace.com
  • … future domains

• All of these are the same apps/web shell; the host only changes:

  • The projection key (which views/entities/canvases to load)
  • The domain Twin configuration
  • The default entry views and domain‑specific affordances

Traversal rules

• If a user hits a domain or platform edge without a valid session:
  • Redirect to auth.spineworkspace.com with the original target encoded.
• After successful authentication:
  • OneAuth resolves tenant, workspace, roles, entitlements, policies.
  • If user is entitled to that projection:
    • Route back to the target host, load apps/web, inject projection key + role context.
  • If user is not entitled:
    • Route to the nearest allowed projection (e.g., default Home) or to an access/upgrade path, according to governance and plans.

Canonical rule: OneAuth determines who may enter; the subdomain determines which workspace projection loads; apps/web renders the shell; Spine, connectors, and agents supply the live work inside it.

---

2. Domain and subdomain map

Root domain & public front-door

• spineworkspace.com / www.spineworkspace.com — apps/marketing
  • Root public front-door of the product ecosystem.
  • All public traffic enters through apps/marketing (www.spineworkspace.com), exposing product narrative, platform capabilities, and the /solutions/* catalog.
  • Acts as the primary discovery & funnel engine, routing users into OneAuth (auth.spineworkspace.com) and domain workbenches (*.spineworkspace.com).

Key subdomains

• www.spineworkspace.com — public marketing (apps/marketing, canonical root)

• auth.spineworkspace.com — OneAuth (identity, SSO, sessions)

• platform.spineworkspace.com — platform control plane (apps/platform)

• Domain workspaces (all powered by apps/web):

  • founder.spineworkspace.com
  • sales.spineworkspace.com
  • marketing.spineworkspace.com
  • finance.spineworkspace.com
  • ops.spineworkspace.com
  • engineering.spineworkspace.com
  • account-success.spineworkspace.com
  • technical-account-success.spineworkspace.com
  • business-intelligence.spineworkspace.com
  • campaigns.spineworkspace.com
  • knowledge-management.spineworkspace.com
  • support.spineworkspace.com
  • brandstore.spineworkspace.com (internal)
  • book-of-records.spineworkspace.com (internal)
  • Future domain workspaces…

Each domain subdomain corresponds to a real domain workspace configuration in apps/web (projection + Twin + capabilities + starter connectors).

---

3. Common Workbench sidebar (IW grammar)

All domain workspaces share a common sidebar grammar in apps/web. Only the Work section is projection‑aware; everything else is shared:

Home — my operational context

• Personal operational dashboard, cross‑domain aggregation.
• Workspace awareness, recent activity, priority ranking, personal KPIs.
• Pending approvals, AI recommendations, quick actions, workspace continuity.
• Personal Twin context and cross‑projection navigation.

My Work — personal execution surface

• Assigned work, delegated work.
• Waiting on others / waiting for me.
• Tasks, goals, deliverables, follow‑ups.
• Approvals and SLA commitments.
• Calendar‑linked work and Twin‑assisted execution.

Inbox — unified operational inbox

• Aggregated from:
  • Email, chat, CRM, tickets, comments, mentions.
  • Notifications, AI‑generated follow‑ups, connector events, workflow events, approval requests.
• With:
  • Priority scoring, deduplication, threading.
  • AI summaries and suggested actions.

Tasks — universal task execution

• Manual tasks, workflow tasks.
• Agent‑generated and connector‑generated tasks.
• Scheduled and recurring tasks.
• Approvals, dependencies, SLA tracking.
• Context‑aware execution surface.

My Queue — dynamic execution queue

• Generated by:
  • Priority engine, OODA loop, signals.
  • Deadlines, dependencies, AI prioritization.
  • Role, current context, business impact, attention management.

Approvals — human-in-the-loop governance

• Publishing, budget, connector and AI approvals.
• Write‑back, customer, deployment, security, and policy approvals.
• Escalation workflows and full audit trail.

Notifications — workspace event stream

• Events from:
  • Connectors, pipelines, agents, skills, workflows.
  • Governance, security, platform, workspace, Twin, human collaboration.
• Intelligently grouped and prioritized.

Recent Work — continuity surface

• Recently viewed entities, edited records.
• Recent conversations, workflows, approvals.
• Recent Twin sessions, canvas work, documents, context.
• “Resume previous work” entry point.

Favorites — pinned operational assets

• Views and dashboards.
• Accounts, campaigns, customers, reports.
• Skills, agents, workflows.
• Documents, canvases, pipelines.

Communications cluster

• Activity Feed — unified operational timeline:
  • CRM activity, emails, meetings, chats, deployments.
  • Customer interactions, agent activity, workflow execution, connector and platform events.
• Email — multi‑provider email workspace:
  • Unified inbox, AI summaries, draft generation, smart replies.
  • CRM/entity linking, Twin memory, knowledge retrieval, workflow initiation.
• Calendar — unified scheduling:
  • Multi‑provider calendars, availability, AI scheduling.
  • Meeting prep, agenda and follow‑up generation, linked entities and workflows.
• Meetings — meeting operating system:
  • Preparation, briefing, live assistance.
  • Recording, transcript, actions, decisions, follow‑ups, memory promotion.
• Chat — unified conversation layer:
  • Slack, Teams, Discord, internal chat, MCP messaging, AI conversations.
  • Context retrieval, entity linking, workspace memory, suggested actions.
• Calls — voice workspace:
  • Call prep, live notes, transcript.
  • CRM linking, entity extraction, tasks, decisions, follow‑ups, memory updates.
• Documents Shared — collaborative document workspace:
  • Google Docs, Office, Notion, Coda, PDFs, internal docs.
  • Semantic indexing, context retrieval, version awareness, AI understanding, knowledge promotion.

Personal cluster

• Notes — personal operational memory:
  • Quick capture, linked entities, AI organization, tags.
  • Knowledge promotion, Twin context, search, continuity.
• Knowledge Base — workspace knowledge graph:
  • Canonical knowledge, policies, procedures, docs.
  • Product, customer, and organizational knowledge.
  • Semantic search, RAG context, source traceability.
• Brainstorming Sessions — collaborative ideation:
  • Whiteboards, structured thinking, AI ideation, Twin collaboration.
  • Decision capture, research, concept evolution, memory promotion.
• Activity — personal operational timeline:
  • Work history, AI activity, decisions, context switches.
  • Workflow participation, learning, memory evolution, workspace interactions.

Work — projection-aware domain workspace

• Routed based on:
  • Role, department, industry, workspace policy.
• Built from:
  • Spine projections, views, canvas, tool capabilities.
  • Twin execution via OODA, skills, agents, workflows.
  • Pipelines, frontend–backend mappings, operational DBs, context gathering, Entity360, continuity memory.
• Each domain projection contains enough operational depth for someone to do their entire job in that domain in the agentic era.

Platform & Administration entries in sidebar

• Platform — shared capability layer (mirrors apps/platform screens):
  • Integration Manager, Connector Marketplace, Activation Hub, Capability Manager, MCP Pool, AI Models, Knowledge, Memory & Continuity, Automation, Pipelines, Governance, Observability.
• Administration — workspace and platform governance:
  • Organizations, workspaces, users, roles, permissions, security, billing, licensing, API access, deployments, feature access, compliance, audit, tenant policies, identity, subscription management.
  • Permission‑aware: users only see admin functions they are allowed to manage.

---

4. apps/platform: control plane UI

Role of apps/platform

• apps/platform is the control plane UI for Spine.
• Every screen in apps/platform is a window onto one or more platform services and agents, never a separate product silo.
• It exposes the control plane for agents + tools + data, analogous to modern AI/MCP gateways and observability control planes.[2][1]

Top-level responsibilities

• Operate Spine across tenants and domains:
  • Integrations & connectors.
  • Capability and MCP tool registry.
  • Activation & readiness.
  • Agent & Twin fleet.
  • Knowledge, memory, pipelines, automation.
  • Governance and observability.
  • Portfolio and administration.

Screen → services → agents → packages matrix

Screen	Primary services	Agents / Twins	Key packages / APIs
Integration Manager	Integration Manager, Connector Marketplace, Capability Manager, Observability (connector)	Discovery Agent, Schema Agent, Adaptive Autotuner, Hermes	connector-contracts, capability-registry, spine-schema, spine-entities
Connector Marketplace	Connector Marketplace, Integration Manager, Billing/Usage	Discovery Agent, Policy Enforcer	connector-contracts, marketplace UI config, governance-core
Activation Hub	Activation Service, Pipeline Orchestrator, Spine Graph Service, OneAccess, Workbench Config, Governance	Discovery Agent, Schema Agent, Twin Manager, Policy Enforcer, Adaptive Autotuner	spine-entities, spine-projections, workbench-config, agent-runtime, governance-core, observability-core
Capability Manager	Capability Manager, OneAccess, Integration Manager, MCP Gateway / MCP Pool	Hermes, Governed Co‑Worker	capability-registry, one-access-core, mcp-gateway, connector-contracts
MCP Pool / Tool Registry	MCP Gateway / MCP Pool, Capability Manager, Observability, Governance	Hermes, Research Subagent, Policy Enforcer	mcp-gateway, capability-registry, governance-core, observability-core
Agent Fleet / Runtime Manager	Agent Runtime Service, Twin Manager, Queue/Job Service, Observability	Triage Bot, Silent Twin, Hermes, Governed Co‑Worker, Discovery Agent, Schema Agent, Adaptive Autotuner, domain Twins	agent-runtime, domain Twin packages, observability-core
Knowledge, Memory & Continuity	Knowledge Service, Memory & Continuity Service, Spine Graph Service	Silent Twin, all domain Twins, Insight Synthesizer	spine-schema, spine-entities, knowledge-memory / memory SDK
Pipelines & Automation	Pipeline Orchestrator, Automation Service, Observability, Integration Manager	Discovery Agent, Schema Agent, Adaptive Autotuner	pipeline orchestration package, spine-schema, spine-entities, observability-core
Governance	Governance Service, Admin Service, Observability, Capability Manager	Policy Enforcer, Governed Co‑Worker, Twins (annotated proposals)	governance-core, Admin SDK, observability-core
Observability	Observability Service, Metric Service, Log/Trace ingestion, Cost/Usage Service	Adaptive Autotuner, Policy Enforcer (signal-driven triggers)	observability-core, metrics/logging libraries, dashboard configs
Portfolio	Portfolio Service, Spine Graph Service (multi-workspace), Metric/Cohort Service, OneAccess	Founder‑Twin, BI‑Twin, Ops/RevOps Twins	spine-projections (portfolio module), spine-entities
Administration (Tenants, etc.)	Admin Service, OneAccess, Billing & Usage	Policy Enforcer (role/governance alignment)	one-access-core, Admin SDK, Billing SDK

---

5. apps/marketing: solutions-by-domain catalog

Role of apps/marketing

• apps/marketing (served at www.spineworkspace.com) is one public Next.js App Router application rooted at apps/marketing/app.
• The Solutions section is organized by domain (Sales, CS, Founder, Engineering, Finance, Ops, etc.) namespaced explicitly under /solutions/*.
• Each solution page is a “pre‑onboard mini domain landing” that:
  • Explains that domain’s workspace and Twin.
  • Shows real Workbench screenshots and flows.
  • Offers domain‑scoped signup/sign‑in that lands the user in the correct domain subdomain in apps/web via OneAuth.

Public URL contract & URL-stability invariant

Top-level product/company routes and /solutions/* namespace routes are distinct canonical URLs and must remain stable:

The Marketing application is a public Next.js App Router application rooted at apps/marketing/app. Top-level route folders represent canonical public URLs, while solution landing pages remain explicitly namespaced under /solutions/*. Internal code organization may change, but public URLs must remain stable unless the same change includes explicit redirects, sitemap updates, canonical metadata updates, and link rewrites.

• Top-level public routes: /, /about, /product, /platform, /spine, /spine-workspace, /services, /integrations, /pricing, /resources, /security, /why
• Solution routes: /solutions, /solutions/customer-success, /solutions/finance, /solutions/finance-leaders, /solutions/founders, /solutions/manufacturing, /solutions/operations, /solutions/professional-services, /solutions/retail, /solutions/revops, /solutions/saas, /solutions/services

Note: /services (top-level product/service narrative) ≠ /solutions/services (solution for services companies). Do not flatten /solutions/* to top-level routes.

Public Marketing versus Authenticated Workbenches

PUBLIC MARKETING: www.spineworkspace.com/solutions/finance
AUTHENTICATED WORKBENCH: finance.spineworkspace.com

Anonymous visitors to domain subdomains (e.g., finance.spineworkspace.com) may be redirected via 302/307 to www.spineworkspace.com/solutions/finance, while authenticated users route to apps/web with the domain projection.

CTA and auth flow

For each domain solution page:

1. CTA click (e.g., “Start with Sales Workspace”) → auth.spineworkspace.com with ?domain=sales (plus campaign params).
2. OneAuth:
   • Authenticates user.
   • Resolves tenant, workspace, roles, entitlements.
3. Activation:
   • If new workspace, uses domain hint to enable the domain projection, suggest connectors, and set first landing to that domain subdomain.
4. Post‑auth redirect:
   • If user is entitled to that domain: route to sales.spineworkspace.com (or relevant subdomain) and load apps/web with the appropriate projection key.
   • If not, present a lightweight “enable [Domain] Workspace” mini‑activation instead of an error.

Content & SEO patterns

• Each /solutions/:domain page:
  • Is optimized around a clear category keyword (“sales workspace”, “customer success workspace”, etc.).
  • Shows real UI and flows instead of abstract AI marketing.
  • Aligns with search intent by focusing on domain‑specific workflows and outcomes (pipeline, QBRs, DORA metrics, ARR waterfall, etc.).

Canonical marketing → Workbench rule

Every Solutions page in apps/marketing must correspond to a real domain workspace configuration in apps/web (subdomain + projection + Twin + connectors), and its primary CTA must route through OneAuth into that exact configuration.

---

6. Platform stack layering

Shared control-plane services (global)

Tenant‑wide, not per‑domain; everything sits on these:

• OneAuth / OneAccess:
  • Identity, SSO, tenants, workspaces, roles, policies, sessions.
• Connector Marketplace & Integration Manager:
  • Host connectors + MCP connectors (definitions, scopes, health, versions).
• MCP Gateway / MCP Pool:
  • Shared MCP client/gateway and registry for all agents and Workbenches.
• Platform backend services:
  • Activation, Capability Manager, Spine Graph, Knowledge & Memory, Agent Runtime, Pipelines/Automation, Governance, Observability, Admin, Portfolio.

Product Package (capability layer, shared, role-aware)

Shared logic, role‑filtered per user:

• Discovery:
  • Enumerates host apps, data, tools, MCP servers.
• Capabilities:
  • Computes “what can be done” (read/analyze/propose/write‑back) per connector, MCP tool, domain, and role.
• Spine cache + anchor keys:
  • Canonical entities and relationships (Entity360).
• Orchestrator + business context:
  • Routes tools and agents while preserving business context (account, opportunity, customer, workstream).
• Loader + Normalizer:
  • Loads data from hosts and maps into Spine entities.
• MCP Connector + tool capability:
  • Unified connector/gateway pattern for MCP tools, exposed into agents and Workbench under auth and policy.[6][2]

Platform backend: packages & services

Key packages:

• spine-schema, spine-entities, spine-projections
• workbench-config
• Connector contracts, capability registry
• mcp-gateway / MCP client packages
• agent-runtime and domain Twin packages
• governance-core, observability-core
• Design system / UI packages

Key services:

• Identity & access: OneAuth/OneAccess, Admin.
• Integration & MCP: Integration Manager, Connector Marketplace, Capability Manager, MCP Pool.
• Graph & knowledge: Spine Graph, Knowledge & Memory.
• Agents & runtime: Agent Runtime, Twin Manager.
• Pipelines & automation: Pipeline Orchestrator, Automation.
• Governance & observability: Governance, Observability, Metrics/Logs/Traces, Cost & Usage.
• Portfolio & billing: Portfolio, Billing & Usage.

User Workbench (apps/web)

• Shared web shell (plus desktop/mobile clients using same API).
• Projection‑aware:
  • Hostname selects projection key and domain Twin.
  • OneAuth/OneAccess and Capability Manager constrain what the user actually sees and can do.
• Embeds:
  • Common sidebar grammar (Home, My Work, Inbox, Work, Platform, Admin).
  • Canvas, views, Twin/OODA affordances (“Store in Spine”, “Ask Twin”, “Assign Twin”, “Approve Twin Action”).
• No local business state; all state flows through Spine, connectors, memory, and platform services.

---

This combined document gives you:

• The rooted access-and-projection model (OneAuth root, subdomains as projections, apps/web as the shell).
• The full domain/subdomain map.
• The common Workbench sidebar grammar.
• The apps/platform control plane UI mapping to services, agents, and packages.
• The apps/marketing solutions catalog and its routing contract into domain workspaces.
• The shared platform stack layering that everything runs on.