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:
- Deterministic automation over ad-hoc execution
- Single responsibility per script or service
- Clear state transitions
- Observable pipeline states
- 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: