Regulated software, safe to build fast.
Process Core is an open-source platform for software whose business processes must run reliably, traceably and under control: its own workflow engine, versioned decisions, human tasks, tenant isolation, permissions and verifiable audit evidence — one core your teams build on.
Apache 2.0 · Self-hosted · Go · PostgreSQL · NATS
- 01Application receivedkyc-application@1.2 · valid
- 02Personal data protectedpayloadRef · encrypted
- 03Risk rule evaluatedrisk-score@2.0.1 · sha 9c41…f2
- 04Review task completedapproved · identity bound
- 05Result storedstate committed
- 06Evidence package writtenverified
□ system · ◯ humanReplay reconstructs, never re-executes
The KYC reference flow from the repository, as its transition journal records it. Names and hashes are illustrative.
01 — The problem
A business process is more than a request.
An application accepts data, calls other systems, evaluates rules, waits for a person and continues later. Meanwhile services fail, messages arrive twice, rules change and tasks stay open for days. And afterwards, someone has to be able to answer four questions:
- 01Which customer or tenant was affected?
- 02Who was allowed to take the action?
- 03Which version of the rule applied?
- 04Why did this result come about?
Process Core bundles these foundations. Your application describes its processes, data and decisions; the platform runs them under control and keeps the technical evidence. Teams stop rebuilding the same security and reliability mechanisms in every project.
02 — Capabilities
Built for workflows that cannot simply be restarted.
Run processes and resume them
The workflow engine executes versioned definitions: automated steps, human tasks, branches, parallel flows, timers, events, subprocesses, bounded retries and compensation. Every instance has durable state. Every transition lands in a journal — committed in one transaction with the state and the follow-up actions. After a restart, execution continues where it stopped.
Evaluate decisions reproducibly
Rules run as versioned decision definitions. Each result carries evidence of the definition, its content, the input, the output and the evaluation semantics — bound together by content hashes. A later rule change never rewrites the identity of an earlier decision.
Bring people into the flow
Human tasks are part of the process model: offered, claimed, returned, completed — with responsibility and deadlines bound to the instance. The Studio's task inbox renders forms from versioned schemas. Completing a task is checked against permissions and state and recorded like any other step.
Release changes under control
Definitions, rules, schemas and modules are immutable, versioned artifacts. Publishing and activating are separate steps, and the core enforces the four-eyes principle: whoever publishes cannot activate — on every path, not just in the interface. Running instances stay pinned to their exact versions; for supported states, controlled migrations come with preview, impact check and approved waves.
Separate tenants and access
Identity, permissions, policies and tenant context are checked at one common ingress. Database policies and separate bus permissions add two further layers. Studio, CLI and services share the same rules, and the acting person's identity is kept all the way into the audit.
Make evidence verifiable
The audit records actions and actors; the journal records how an instance evolved; both are tied to the exact definitions used. Audit exports are cryptographically verifiable, and evidence packages let you reconstruct a run later. Protected personal data is stored encrypted, referenced instead of copied, and can be erased by destroying its key.
Connect your own logic
Versioned APIs, a message bus and a Go SDK with contract types, signing and integration building blocks. Your own computations run as WebAssembly modules in a separate runner — with limits on memory, compute, time and I/O, and no free network or file access.
03 — Where AI fits
An agent is one step among others.
Process Core does not run models — it runs the process around them. An AI agent is called like any other service task: with the same bounded retries, the same permissions, the same journal. A versioned rule decides whether its result is applied or goes to a person. Because the process is pinned to its definition, the model behind a step can change without rewriting the process.
* Measured, not claimed
Four figures from real runs.
Each one is bound to a commit and kept as evidence.
- 291,000 / 291,000transitions committed in a four-hour chaos soak with five forced owner failures — none lost, none duplicated
- ≤ 14.7 suntil a standby runner takes over after the active owner is killed
- 21 msp99 transition commit in the final window of the same run
- 192 / 192cross-tenant attack paths denied across all 64 endpoints — zero foreign records
* Commit-bound four-hour chaos soak at 20 events/s on a single-host profile · cross-tenant pentest, 15 Sep 2026 · each run kept with source tree hash and evidence file
04 — Working with it
Four ways in.
Process Core Studio
Web interface for modelling, publishing, approving and observing processes — and for working through human tasks.
PCFlow
The visual workflow editor inside Studio, with model checks, version comparison, a runtime heatmap and migration views.
pc command line
Scriptable access for development and CI: signed requests, artifact management, audit exports and environment checks.
APIs and SDK
Connect your own applications, services and automations to the same platform functions — under the same rules.
05 — Example
A customer check, end to end.
Know your customer — the reference flow that runs through the whole project.
- 01An application creates a case for its tenant and starts the process.
- 02Inputs are validated against a schema. Sensitive content goes through the protected payload path.
- 03An automated step or a versioned rule assesses the case.
- 04A person receives a review task, works through its form and completes it under their own identity.
- 05The process continues and stores its result.
- 06History and audit record which versions, inputs, results and actors were involved. Evidence packages allow a technical review later.
The same principle carries over to other domains. Which rules apply, which systems are involved and when a person has to approve is decided by your application.
06 — Architecture
Three processes. Your infrastructure.
- process-cored
- Identities, tenants, artifacts, data operations, decisions, workflow ingress and audit.
- pc-wfrun
- Executes and resumes workflow instances; work is distributed across partitions.
- pc-noderun
- Runs released WebAssembly modules in isolation, with bounded resources.
- pc-studio
- Optional. Connects the web interface and handles browser sign-in and sessions.
- PostgreSQL
- Holds the authoritative transactional state.
- NATS JetStream
- Distributes messages between processes and services.
- S3-compatible storage
- Larger content, modules, snapshots and evidence packages.
A state change and the message it triggers are stored together; delivery can be retried without losing the change. Process Core runs on your own infrastructure — from a local sandbox to a hardened single-host deployment with automatic TLS, pinned images, backup and restore.
07 — Who it is for
For teams building applications with binding processes.
Process Core pays off when several of these come together:
- Processes connect several systems and human decisions.
- Cases must survive waiting times, retries and outages.
- Several customers need separate data and rights.
- Changes to rules must be reviewed and approved.
- Decisions must be traceable later, technically.
- Software and data should run in-house.
Your domain rules and the design of your application stay with your team. Process Core provides the shared foundation for execution and control.
08 — Open source
Open code. Versioned contracts. Your infrastructure.
Process Core is licensed under Apache 2.0. Open source code, versioned contracts and self-hosting make technical review, integration and long-term development possible — with or without us. Which of your processes cannot simply be restarted?