Klarum

Automations (Process Engine Console)

Generally available
Supplier and issuer
From business

The console over Klarum's process engine: declarative multi-step processes with a narrow auditable DSL, pluggable compute backends, per-step budget envelopes and a live runs ledger.

Catalogue id
automations

Description

What it is

The user-facing surface over Klarum's process engine: a small, typed workflow orchestrator that runs declarative multi-step "processes" against tender/bid data. Each automation is a process definition (process_defs: slug, version, kind, JSONB spec); each firing is a run (process_runs) made of ordered steps (process_steps). The page presents a Catalog (Standard, org_id IS NULL, vs Custom, firm-owned) plus a live Runs ledger. The engine (klarum_core/engine.py) walks a process definition's steps in ordinal order, resolves ${run.inputs.x} / ${steps.<slug>.outputs.y} template references at dispatch time, dispatches each step to a registered compute backend keyed by compute_kind, persists every step, and enforces a per-step/aggregate budget envelope (tokens, latency, cost).

What it helps users do

Fire bid-production work as one click (Standard automations cover the lifecycle: eoi_generation, proposal_generation, opportunity_matching/graph_match_precompute, reference_auto_select, compliance_check/icp_validation, inbound_intake, notification_dispatch, staffing_recommendation, discovery_enrichment); get the right automation suggested in context (per-checklist-item "Suggested for this workspace" strip); author their own automations in plain English (the Prompt new dialog drafts a runnable spec via an LLM); promote a checklist into a reusable template and archive completed work to the Knowledge Base; and audit/export (every run recorded, any output materialised as a branded PDF/DOCX).

Capabilities

  • Catalog of Standard and Custom processes

    Generally available

    Platform-shipped Standard definitions cover the bid lifecycle end to end; an org forks or authors Custom ones alongside them.

  • Runs ledger

    Generally available

    Every firing is recorded step by step with its inputs, outputs, cost and verdict, which is what makes an automated decision auditable after the fact.

  • Budget envelope

    Generally available

    Per-step and aggregate ceilings on tokens, latency and cost, enforced by the engine, so a runaway automation stops rather than billing.

  • Prompt a new automation

    Generally available

    A plain-English description becomes a validated ProcessSpec, capped at four steps and restricted to LLM-only steps so a bad draft can at worst waste tokens.

  • Citation stripping

    Generally available

    The EOI section path post-validates every [ref:id] citation against the supplied reference list and strips hallucinated ids, recording the event.

  • Contextual suggestions

    Generally available

    A first-match-wins regex rule table maps a checklist item to a suggested automation and a reason, deliberately not an LLM call so suggestion stays instant and free.

Engines

  • klarum-core process engine Walks a process definition's steps in ordinal order, resolves template references at dispatch time, dispatches to a registered compute backend, persists every step and enforces a budget envelope.

Keywords

process-engine, runs, steps, backends, budget-envelope, scheduler, dsl

Provenance

This page renders a published artifact. Read the same records as JSON if you would rather check the source than the page.