Skip to main content

Loop Engine^™

Docs Examples Packages Use cases Partners Catalog Blog Releases Changelog GitHub

Menu

Docs Examples Packages Use cases Partners Catalog Blog Releases Changelog GitHub

Loading

Loop Engine^™

Project

GitHub npm Examples Changelog

Community

Contributing RFC Process Issues

oss@betterdata.co

Better Data

Trust Center Created by Better Data Platform docs Commerce Gateway Commerce Chain Signal Tags security@betterdata.co

Apache-2.0 Licensed · © Loop Engine Contributors

Trademark policy conduct@loopengine.io

Security Privacy Policy Terms of Service Cookie Notice Open Source disclosures

Search docs

Getting Started

Quick Start Installation Your First Loop Architecture

Core Concepts

What is a Loop?The Actor Model Guards and Policy Signals Observability Learning Signals AI as Actor Confidence + Evidence Human Approval Gates Decision Governance Loop Engine vs Workflow Engines Agents and RAG When to Use Loop Engine

Defining Loops

YAML Format TypeScript Builder Loop Library Guards Reference

Running Loops

createLoopSystem Starting Loops Transitions Event Subscriptions Adapters

Packages

Loop catalog

Examples

Overview Expense Approval AI Replenishment Demand Signal Postgres Persistence Event Streaming Infrastructure Change Approval Fraud Review OpenClaw Integration Commerce Gateway

Integrations

⟩ AI Providers

Anthropic / Claude OpenAI Grok (xAI)Google Gemini Perplexity Sonar

⟩ Agentic Platforms

OpenClaw Vercel AI SDK

⟩ Storage Adapters

Postgres Kafka HTTP

⟩ Observability

PagerDuty Governed incident (Perplexity + PD)

⟩ Commerce

Commerce Gateway

Governance

License Contributing RFC Process Changelog

Project

PreviousContributing

RFC Process · Loop Engine

Governance

RFC Process

RFC Process

Significant changes should go through an RFC issue before implementation.

When an RFC is required

Required (from current contributor policy):

breaking changes to core types (@loop-engine/core)

Strongly recommended:

breaking event schema changes (@loop-engine/events)
DSL format changes
governance model changes
new top-level packages with cross-cutting impact

Not usually required:

bug fixes
new built-in guards or signal rules
loop definition additions in loops/
documentation changes

Why event schema changes require extra care

!

Downstream risk

Event payloads are often consumed by analytics and training pipelines.
Unexpected schema changes can corrupt downstream data silently.

Repository guidance currently states: breaking event schema changes require a 6-month deprecation notice.

RFC submission flow

Open GitHub issue with [RFC] in title
Describe:
- problem
- proposal
- alternatives considered
Collect maintainer/community feedback
Land implementation PR linked to the RFC issue

Deprecation policy

Current documented rule in CONTRIBUTING.md:

breaking event schema changes require 6-month deprecation notice

See the repository governance docs for the current maintainer model and decision process:

GOVERNANCE.md
MAINTAINERS.md

On this page

When an RFC is required Why event schema changes require extra care RFC submission flow Deprecation policy