Runtime Platform Direction

Loop Engine is evolving toward a self-host operational runtime platform: a local-first stack and operational governance substrate you run in your infrastructure. This page states that direction honestly — what exists on npm today, what Loop Engine Cloud adds, and which components are roadmap-only.

→ Runtime Taxonomy · Architecture · Loop Engine Cloud API

Positioning (locked)

| Phrase | Meaning | | --- | --- | | Self-host runtime platform | You operate the governance runtime (@loop-engine/sdk, adapters, stores) in your processes or containers | | Operational governance substrate | Loops + guards + evidence sit under AI and workflow layers — they authorize transitions | | Local-first runtime stack | Default path is install SDK, wire adapters, run in your environment — not a required multi-tenant SaaS |

We describe Loop Engine as infrastructure for governed operational decisions, not as a generic cloud suite or workflow marketplace.

What you can run today (OSS)

| Capability | Status | How | | --- | --- | --- | | Loop definitions (YAML / TypeScript) | Shipped | @loop-engine/sdk, @loop-engine/dsl | | Transition execution + guards | Shipped | @loop-engine/runtime, @loop-engine/guards | | Actors, evidence, events | Shipped | @loop-engine/actors, @loop-engine/events | | Provider / Channel / Integration adapters | Shipped (per adapter) | See runtime connections | | In-process observability helpers | Shipped | @loop-engine/observability, @loop-engine/ui-devtools | | Remote registry client | Shipped | @loop-engine/registry-client (localRegistry, httpRegistry, …) |

Typical today topology: one or more application processes embedding createLoopSystem with chosen LoopStore and EventBus adapters — not a mandatory multi-service mesh.

1npm install @loop-engine/sdk

→ Quick Start

Runtime platform vs Loop Engine Cloud

| | OSS runtime (self-host) | Loop Engine Cloud (hosted) | | --- | --- | --- | | Runs where | Your infrastructure | Better Data operated (loops.betterdata.co) | | Primary job | Govern transitions in your apps | Hosted governance API + managed connectors | | Tenancy | Your app’s isolation model | Multi-tenant control plane | | Connectors | You implement OAuth/secrets | Documented hosted connector paths (Slack, Google, …) | | Docs surface | loopengine.io (this site) | Cloud API page + docs.betterdata.co for company/apps |

Loop Engine Cloud does not replace the OSS runtime model — it hosts governance operations when you want managed connectors and fleet-style control. Better Data application documentation (SCM, CCO, company products) lives on docs.betterdata.co, not loopengine.io.

We do not claim full self-host parity with every Cloud connector or operator feature on day one.

Roadmap-only extensions (not available today)

The following are directional components — runtime extensions and governance layers, not a sprawling separate cloud product. They may ship as optional services you run beside your app processes:

| Component | Role (when shipped) | Category | | --- | --- | --- | | Registry service | Central loop catalog resolution (versioned definitions) | Runtime extension | | Audit / event store | Durable, queryable transition and guard history | Governance layer | | Observability collector | Fleet-wide metrics and timelines from loop events | Operational infrastructure | | Replay service | Reconstruct and analyze past transitions for audit | Governance layer | | Studio | Operator UI for loop inspection (scope TBD) | Governance layer | | Docker Compose runtime | Opinionated local/self-host bundle of OSS + optional services | Local-first stack |

Until each item appears in changelog with a released version, treat it as planned — do not plan production dependencies on it.

1Today (typical)                 Direction (optional self-host services)
2─────────────────               ─────────────────────────────────────
3Your app + @loop-engine/sdk  →   + registry service (roadmap)
4       │                        + audit/event store (roadmap)
5       ├─ adapters              + observability collector (roadmap)
6       └─ your Postgres/Kafka    + replay (roadmap)
7                                 + Studio (roadmap, not announced GA)
8                                 + compose kit (roadmap)

Language we avoid

| Do not say | Why | | --- | --- | | “The Supabase for AI workflows” | Implies hosted DB + auth + realtime product parity we do not ship | | “Full self-host parity with Cloud” | Connectors and control-plane features differ by design | | “Multi-service runtime today” | OSS is embeddable; mesh is roadmap-only | | “Studio is available” | Unless changelog documents a release | | “X for Y” competitor mimicry | e.g. “Temporal for AI”, “Zapier for governance” — obscures the governance substrate |

Prefer concrete primitives: loops, guards, evidence, Providers, Channels, Integrations.

How future services should read

Do frame additions as:

• Runtime extensions — optional processes that help definitions, events, or replay
• Governance layers — audit, policy visibility, operator tooling
• Operational infrastructure — collectors and stores you operate

Do not frame as:

• A second “AI workflow cloud” unrelated to transition governance
• Mandatory microservices for every deployment
• Replacement for your existing data plane or identity system

Choosing a path

1Need governed loops in your app now?
2    → OSS SDK + adapters (self-host)
3 
4Need managed Slack/Google connectors + tenancy API?
5    → Loop Engine Cloud (hosted Integration path)
6 
7Need company / SCM / CCO product docs?
8    → docs.betterdata.co (not loopengine.io)

Related

• Architecture — evidence flow and boundaries
• Runtime Taxonomy — Providers, Channels, Integrations
• Loop Engine vs Workflow Engines — execution vs governance
• Package taxonomy — what to install today