{circuit}Open the studio

THE LIVE DATA PLATFORM

Agents and apps
built on
live data.

Your data. Your logic. Your decisions.
One living circuit.

Turn changes into answers with SQL pipelines that stay live — and agents that work right alongside your data.

Build your circuit Explore the platform ↗
{ }SQL at the core. HTTP at the edges.
A CHANGE IN. A WORLD IN SYNC.
One event. Every system in sync. Illustrative account events from Postgres and HTTP flow through the f circuit core to apps and agents, then to live account views, a Kafka topic, and a Postgres snapshot. The highlighted source row names the current event. Postgres accounts / changes AccountCreated AccountCredited AccountDebited +1,250.00 EUR Sample · ACC-1042 HTTP append POST /append TransferRequested TransferApproved TransferSettled TRF-072 · approved Sample · ACC-1042 f{circuit} In sync Readers resume @8812 One commit. Many readers. Apps /accounts ACC-1042 EUR 1,250.00 Delta applied Resume @8812 Agents AccountChecked ACC-1042 Decision: allow Record outcome Own stream · inspectable Live views account_balance EUR 1,250.00 ACC-1042 −1 / +1 applied Kafka topic account.updated EUR 1,250.00 ACC-1042 Offset 8812 Postgres sync account_snapshot EUR 1,250.00 ACC-1042 UPSERT · 1 row
views / high_risk_payments LIVE
-- a query that keeps answering
SELECT customer, COUNT(*) AS n,
       SUM(amount) AS total
FROM payments WHERE risk = 'high'
GROUP BY customer,
  TUMBLE(ts, INTERVAL '1' HOUR);
CHANGE STREAM+1 / −1
−1acme n=3 total=1240.008812
+1acme n=4 total=1915.508812
4 payments · €1,915.50
INTERACTIVE ILLUSTRATION · SAMPLE DATAOFFSET 8812

BUILT AROUND TWO SIMPLE IDEAS
01 /

Stay close to your data.

Your logic and decisions run where the data lives. Every view stays live. Every change reaches your apps and agents as it happens.

02 /

Code is data.

Pipelines are stored, versioned, and forked like the rows they process. Try ten versions on real data. Keep the one that works.

THE CIRCUIT STUDIO / MADE TO BE EXPLORED

What will you build?

Start with an idea. Connect a few components. Make it yours.
Your next application is a circuit waiting to happen.

A LITTLE INSPIRATION

Start with a possibility.

{ }
YOUR IDEAS, CONNECTED
INTERACTIVE CONCEPT
YOUR CIRCUIT0 components

01 Bring data in

02 Make it useful

03 Send it somewhere

✳Add a component. Make a connection.

Drag in a component, choose an example,
or tell the copilot what you have in mind.

STORAGE
Durable storeLive events & module state
CORE
{f}
The foundationDomain language & replication

Add a domain or replication.

Under the hood0 / 11 seams in use⌄

The places where your components connect to the core. Select a socket to explore.

An empty canvas. Endless possibilities.

An interactive vision of what you can build. Components, sample runs, downloads, and cloud deployments are illustrative.

01 / FROM DATA TO DECISION

A better decision.
Without stopping the flow.

Try three ways to approve risky orders on forks of real traffic. Compare the results. Promote the winner. Production keeps moving.

  1. 01Append
  2. 02Decide
  3. 03Fork
  4. 04Simulate
  5. 05Merge
  6. 06Stream
orders / productionINTERACTIVE ILLUSTRATION · SAMPLE DATA
PRODUCTIONv1
Production is servingOFFSET 8812

One stream. Three possibilities.
Run the simulation to compare outcomes.

LIVE VIEWS apps orders_by_statusreports revenue_hourlyagents high_risk_orders

↳ Illustrative outcomes. Each fork runs its own pipeline version. At merge, the fork’s commands are decided again on current production under optimistic locking.

02 / A SMALL INTERFACE. A LOT OF POSSIBILITY.

The data moves.
Your answers move with it.

A SQL file becomes a live pipeline. A change becomes an updated answer. No extra framework between your question and your data.

high_risk_payments.sql
-- fc:pipeline views
CREATE VIEW high_risk_payments AS
SELECT
  customer,
  COUNT(*) AS n,
  SUM(amount) AS total
FROM payments
WHERE risk = 'high'
GROUP BY
  customer,
  TUMBLE(ts, INTERVAL '1' HOUR);
Incrementally maintained
Σ

All the SQL you need.
Only the work that changed.

Aggregates, windows, and as many joins as the question needs. When one row changes, only the affected results are recomputed.

AGGREGATESWINDOWSJOINS
±

A query that keeps answering.

We store changes. Every view you ask for keeps pushing its changes to you, with the full power of SQL behind it.

+1 / −1   ·   LIVE VIEWS   ·   OPTIMISTIC LOCKING

Version your logic.

Pipelines are data, too. Run versions side by side, explore a fork, or roll back in seconds.

VERSIONS / FORKS / SIMULATIONS

Stream over plain HTTP.

Durable Streams let readers resume from an offset. Ordinary proxies and CDNs can fan out your live data.

DURABLE STREAMS / HTTP / CDN

Keep the state. Keep going.

Every app, fork, and agent has its own durable stream. Restarts and restores are positions in that stream.

STATE / CHECKPOINTS / RESTORE

03 / AGENTS, INSIDE THE CIRCUIT

They understand
your data.
And act on it.

Managed agents read your schemas, views, and pipelines. Once authorized, they make decisions as data arrives — under the same locking and rules as any other writer.

01

Describe the question.
Build the pipeline.

Start with a business case. An agent writes the SQL and wires the live views.

02

Get a report when you need it.

New reports, created on demand from live data. Your next question doesn’t need a new backlog.

03

Explore more possibilities.

Run tens of candidates on separate forks. Compare outcomes. Keep the best approach.

04

Make decisions in the flow.

Authorize an agent to classify, approve, or reject as data arrives. Inspect its decisions on its stream.

05

Give agents a team.

Agents create and orchestrate other agents, each with its own durable, inspectable state.

04 / THIN CORE. OPEN POSSIBILITIES.

Small at the core.
Yours at the edges.

Live views, locking, checkpoints, forks, and SQL pipelines form the core. Everything else is a module. Yours plug in the same way ours do.

{rs}

NATIVE / RUST

Shape every append.

Rust modules shipped in the server. Transform, seal, guard, decide, and verify as data is written.

TRANSFORMGUARDDECIDEVERIFY
Every module declares what it needs. The core grants exactly that.

BUNDLED TODAY

postgresdebeziumbackuptieringsubscriptionssimulationstamper evidenceprometheustelemetryhealthconsoleagents

BUILT TO BE QUESTIONED

Test the unexpected.
Keep the evidence.

Check a component. Reproduce a failure. Know which promises your tests actually keep.

AVAILABLE

A toolkit for your modules.

Test against an isolated, real core. Exercise permissions, restart a process, and connect each declared capability to an assertion.

Rust · TypeScript · Python
PLANNED WORKFLOW

Turn a failure into a replay.

Our direction for deterministic simulation testing: explore failures, save the seed, and return to the same sequence while you fix it.

DST · repeatable fault scenarios
PLANNED WORKFLOW

Check the rules, too.

The next layer: use TLA+ models to examine the states a design can reach and the rules that should hold across them.

TLA+ · model checking
TRY THE IDEA

A small test. A visible answer.

ILLUSTRATIVE DEMO

Choose what to test. Run it twice with the same seed to see the same trace.

Apply a few changes, replay them, and compare the resulting state.

Enter a whole number from 0 to 999999999. The same scenario, seed and bug setting reproduce the same trace.

EVENT TRACEREADY WHEN YOU ARE
  1. Every step leaves a trace.

    Run a scenario to follow its changes, interruption, and result.

WHAT MUST HOLD3 CHECKS

    Assertions make the expected behavior explicit.

    Same seed. Same inputs. Same trace.Browser-only model · no engine or formal checker runs here.

    Take it into your workflow.Existing toolkit & a preview of what comes next
    IN THE REPOSITORY TODAYAVAILABLE

    Tests with evidence attached.

    From the repository root, run your module project’s tests and require coverage for every declared capability.

    python3 scripts/module.py test /tmp/my-module --strict --json

    Reports distinguish passed, failed, skipped, and not applicable. Strict mode rejects missing coverage and applicable skips.

    Existing engine determinism checkscargo test -p bank --test determinism

    Compare identical event histories across worker counts and replay boundaries.

    PLANNED CLI / COMMAND PREVIEWNOT BUILT YET

    One entry point. More confidence.

    The planned circuit CLI would bring component tests, seeded simulation, and model checks into one guided workflow.

    # Command concept — not available yet
fcircuit test ./my-circuit --suite all --seed 42

    Proposed syntax, not an executable feature today. DST and TLA+ orchestration are part of this planned experience.

    05 / START WHERE YOU ARE

    A new application.
    Or a new way forward.

    Own the process from data to decision. Build on f{circuit} from day one, or put the data you already have to work.

    Your whole application.
    One connected foundation.

    Data arrives as appends. Commands make decisions under optimistic locking. Live views report the outcome. Agents participate where you authorize them.

    Data, logic, decisions, and reports — together.

    Explore the application flow ↗
    YOUR APPLICATION / ONE PLATFORM
    01AppendData arrives
    →
    02DecideLogic runs
    →
    03StreamViews update
    { } f{circuit} data + logic + agents

    ONE STREAM CONNECTS THE WHOLE PROCESS.

    A FEW IMPORTANT DISTINCTIONS

    Different
    by design.

    Familiar interfaces.
    A different foundation.

    SQL and HTTP are the interface.+

    No new framework abstractions to learn. A pipeline is a SQL file, and any HTTP client can append data.

    A change store that keeps answers live.+

    Beyond answering a query once, f{circuit} keeps pushing the changes to that view. It maintains answers incrementally as data arrives, rather than rescanning history each night.

    Durable state, instead of replayed execution.+

    State lives on durable streams. Work can be rerun, forked, and rolled back. Restarts and restores are positions in a stream.

    A record you can read again.+

    A stream is the record itself. Reading it does not consume it. Readers can return to an offset and resume over ordinary HTTP.

    A small core you can extend.+

    Connectors, backup, metrics, the console, and agents are modules. Switch them, replace them, or write your own with explicitly granted capabilities.

    Agents that participate in the pipeline.+

    Agents work with grants you authorize, under the same locking and rules as other writers. Their decisions live on streams you can inspect.

    LESS DISTANCE BETWEEN DATA AND DECISION.

    Everything changes.
    Stay in flow.

    Connect your data. Explore the possibilities.
    Let the best decisions flow into production.

    Build your own circuit