Optimization & provability

// xFlow flow definition — typed IR, not arbitrary code.

defineFlow({
  id: "agent.search-loop",
  version: "1.0.0",
  initial: "agent",
  states: {
    agent: {
      invoke: {
        src: "action:llm.chat@^2",          // ← symbolic, registry-resolved
        input: "$.messages",
      },
      on: {
        TOOL_CALLS: "tools",
        DONE:       { target: "done", guard: "messageBudgetOk" },
      },
    },
    tools: {
      type: "parallel",                     // ← structural, analyzable
      states: {
        search: { invoke: { src: "action:search@^1" } },
        fetch:  { invoke: { src: "action:fetch@^1" } },
      },
      onDone: "agent",
    },
    done: { type: "final" },
  },
})

// Why this is IR and not "JSON wrapping JS":
//  • States, transitions, parallel regions, history are STRUCTURAL.
//  • Actions are SYMBOLIC references (id@version), not inline code.
//  • Guards and inputs are EXPRESSIONS over the run state, not closures.
//  • The whole def is canonical JSON (RFC 8785) + SCXML — analyzable
//    by any tool, in any language, without executing a body.

// xflow.optimize — DSPy-of-flows.
//   Inputs: flow def + metric + dataset + pass set.
//   Output: an equivalent-shaped flow def with rewritten internals.

const optimized = await xflow.optimize(def, {
  metric: "agent.task-success",            // measured against bench
  bench:  "datasets/triage/v3",            // labelled cases
  budget: { tokensPerCase: 8_000, dollars: 50 },
  passes: [
    "prompt-search",                       // search prompts attached to actions
    "branch-reorder",                      // reorder transitions by expected value
    "action-substitution",                 // swap action:llm.chat@^2 → :^3
    "guard-refinement",                    // tighten guard predicates from data
    "parallel-region-inference",           // hoist independent branches
    "dead-state-elimination",
  ],
})

// optimized is itself a flow def — content-addressable, signable,
// publishable. The optimization is reproducible from (def, metric, bench).

// xflow.compile — target-substrate codegen ("ASICs for flows").
//   One IR, many backends. Pick at deploy time, not author time.

await xflow.compile(def, { target: "memory" })       // dev / tests
await xflow.compile(def, { target: "sqlite" })       // local CLI
await xflow.compile(def, { target: "postgres" })     // server prod
await xflow.compile(def, { target: "xsync-s3worm" }) // multi-writer + signed
await xflow.compile(def, { target: "wasm-component" }) // sandbox / portable
await xflow.compile(def, { target: "wdk-flat" })     // for Vercel WDK runtimes
await xflow.compile(def, { target: "halo2-circuit" })// future: ZK execution

// Each backend reads the same IR. xFlow runtime + its substrate adapters
// are reference codegen targets. Authors don't re-shape flows per target.

// xflow.prove — verifiable execution over a flow trace.
//   Given (def, runId), produce a witness/proof that the recorded
//   trace is a valid execution of the IR.

const proof = await xflow.prove(def, runId, {
  backend: "halo2",                        // or "stark", "groth16", ...
  scope: {
    structure: true,                       // trace follows the IR
    actions:   "attestation",              // actions: signed attestations,
                                           //          or in-circuit for pure
    state:     "merkle",                   // run state in a Merkle commit
  },
})

await proof.verify()                       // anyone with the proof + def + commit

// BRAID (OpenServ Labs) — the closest external validation.
//
//   Stage 1: agent generates a Guided Reasoning Diagram (GRD), a
//            machine-readable flowchart in Mermaid syntax encoding
//            the solution logic.
//   Stage 2: agent EXECUTES the GRD deterministically.
//
// Reported results (per OpenServ + Coyotiv research):
//   GSM-Hard:           99% accuracy, 74× lower cost (GPT-5)
//   SCALE Multichallenge: 2.7× accuracy, 30.3× perf-per-$ (GPT-4o)
//
// The shared bet:
//   Separate the PLAN from the EXECUTION.
//   The plan-as-data is the audit and optimization surface.
//
// What xFlow generalizes:
//   • Plan format         BRAID: Mermaid flowchart      xFlow: xState statechart
//                         (DAG-ish)                     (parallel + hierarchical + history)
//   • Plan distribution   per-problem, in-memory        content-addressed registry,
//                                                       id@version, signed
//   • Scope               reasoning workflows           any workflow (incl. reasoning)
//   • Auditability        inspect GRD before commit     signed flow + signed event log
//
// xFlow is BRAID's structural pattern — generalized, persisted,
// statechart-shaped, and applied beyond reasoning to any workflow.

// Why competitors structurally can't reach this layer.

LangGraph
  Nodes are arbitrary host-language functions.
  → no IR, no static analysis, no whole-flow optimization,
    no portable compilation target, no path to ZK/verifiable execution.

Vercel WDK
  Workflow body is a JS function with step() boundaries.
  → step boundaries are introspectable; the BODIES between them are not.
    Definition lives in deploy artifact, not as data.

Temporal
  Workflow body is sandboxed deterministic JS / Java / Go / Python.
  → world-class durability + replay; no notion of flow-as-data,
    no optimizer, no portable IR.

Inngest / Trigger.dev / Mastra / Cloudflare Workflows
  Step memoization or snapshot/resume over host-language bodies.
  → durability story; no optimizer, no portable IR.

xFlow
  Flow body IS the data. Actions are symbolic refs.
  → optimizer, target codegen, and proof generator are tractable
    because there's something to manipulate.