Skip to main content

Architecture Overview

sX GTM Operating System

This page is intended for engineers who want to understand the technical structure behind the sX GTM Operating System before initiating a conversation.

This is not a consumer or B2B SaaS platform. It is structured automation infrastructure.

1. Architectural Philosophy

The GTM OS is designed around five principles:

  1. Deterministic automation over ad-hoc execution
  2. Single responsibility per script or service
  3. Clear state transitions
  4. Observable pipeline states
  5. Replicable deployment

We do not pursue complexity layering. We pursue structured orchestration.

2. Current Engine (Operational Today)

The automation layer is Python-based and organised around controlled stages.

Stage 0 – Build

Content generation and image composition (LLM + deterministic Pillow rendering).

Stage 1 – Watch

Discovery-only watchers detect valid file pairs in controlled directories.

Stage 2 – Ingest

Structured parsing and upload into Notion databases acting as control planes.

Stage 3 – Asset Distribution

FTP or API-based distribution to required endpoints.

Stage 4 – Publish

API-triggered publication (e.g., RecurPost, ESPs).

Each stage is isolated.

Watchers do not publish.

Ingest does not mutate source files.

Publishing does not rewrite upstream state.

Logs are checksum-based and idempotent.

3. Data & Control Planes

Notion

Used as structured control plane:

  • Status transitions
  • Campaign metadata
  • Execution flags

Not used for computation.

OneDrive

Acts as structured file staging:

  • _staging → _LIVE transitions
  • Deterministic folder contracts

GA4 + BigQuery

Measurement and behavioural data aggregation.

Looker

Dashboard layer for commercial visibility.

4. Proposed Platform Layer

We are now introducing a structured service layer.

Backend

Python

FastAPI

Dockerised deployment

Responsibilities:

  • Expose automation jobs via structured endpoints
  • Implement job execution abstraction
  • Handle environment configuration
  • Provide health-check endpoints
  • Provide authentication and role control

No microservices architecture.

Single service boundary.

Frontend

React / Next.js Operator Console

Responsibilities:

  • Module navigation (Reach, Connect, Ops, etc.)
  • Job initiation controls
  • File intake interface
  • Status and log visibility
  • Dashboard rendering
  • Role-based access

This is a control surface over a working engine.

5. Deployment Model (Current Direction)

Hybrid managed infrastructure.

Web Layer

Hosted server instance running:

  • FastAPI
  • React
  • Nginx
  • Docker

Controlled Node

Mac Mini-based execution environment for:

  • Script execution
  • Secure internal connectivity
  • OneDrive watchers

Remote administration via secure access.

Future provisioning automation will reduce setup time and configuration drift.

6. Provisioning & Replication (In Development)

v1 goal:

Automated environment provisioning that:

  • Installs dependencies
  • Generates validated .env configuration
  • Registers services
  • Runs connectivity validation
  • Produces deterministic health reports

CLI-based provisioning preferred for v1.

7. What This Is Not

  • Not microservices-based architecture
  • Not Kubernetes-managed cluster
  • Not consumer SaaS at scale
  • Not ML-driven system

The system is deterministic and commercially grounded.

8. Technical Challenges We Are Solving

  • Codifying manual orchestration into structured services
  • Maintaining idempotent job execution
  • Preserving clean separation between build, ingest and publish layers
  • Reducing deployment time via provisioning automation
  • Ensuring observability without overengineering

9. Engineering Expectations

We value:

  • Clean service boundaries
  • Explicit contracts
  • Controlled side effects
  • Documentation
  • Practical deployment strategy

We avoid:

  • Premature scaling architecture
  • Infrastructure theatre
  • Complexity without commercial benefit

10. Where This Can Go

Short term:

Replicable managed infrastructure platform.

Medium term:

Private instance deployment model.

Long term (conditional):

Productised SaaS layer, if market forces justify it.

The architecture is being built deliberately to preserve optionality.

If you would like to discuss the architecture in more depth, please contact:

This email address is being protected from spambots. You need JavaScript enabled to view it.