ProcessOS Is the BPM-Native SDD Reference Architecture¶

Author: Gary Samuelson
Date: June 2026
Series context: This paper builds on the Form Four framework established in The ProcessOS Horizon and Process-First AI: Dimensions of the Running Work Record. It is a working paper shared for peer review.

The core claim: What Camunda announced on May 19, 2026 as ProcessOS — "an agentic operating system for AI-first enterprise transformation" — is, structurally, an SDD framework applied to business process re-engineering. It implements the same disciplines, in the same sequence, with the same governance logic. Camunda didn't use the SDD vocabulary because Camunda is a BPM company, not an engineering methodology company. The structural alignment is exact regardless of the naming.

This paper shows the alignment, applies it to legacy BPM obsolescence planning, and makes the acceleration case.

External sources:

Camunda, ProcessOS: platform architecture, camunda.com/platform/process-os/ (May 2026)
Dumas et al., Fundamentals of Business Process Management, 2nd Ed. Springer, 2018
GitHub Spec Kit, github.com/github/spec-kit (MIT) | arXiv:2602.00180

Part I — What I Saw in the Demo: The Recognition¶

During the ProcessOS demo, I observed that the system appeared to be "built from layers of markdown-defined skills" — and noted the similarity to Spec-Driven Development (SDD) without being able to name exactly why.

That observation is architecturally correct. Here is what the Camunda platform architecture page confirms:

CAMUNDA HUB — ProcessOS Intelligence Layer
┌────────────────────────────────────────────────────────────────┐
│  Discover agent │ Design agent │ Build agent │ Optimize agent  │
├────────────────────────────────────────────────────────────────┤
│       Agent Skills — tools shared across all agents            │
├────────────────────────────────────────────────────────────────┤
│       Organizational Memory — cross-process knowledge          │
│       private to org · stored in Git repo                      │
├────────────────────────────────────────────────────────────────┤
│       Plugins — third-party integrations via MCP               │
│       Catalog — connectors and building blocks, org-wide       │
└────────────────────────────────────────────────────────────────┘
         ↓ deploys · monitors
ORCHESTRATION CLUSTER (Zeebe engine · Operate · Tasklist)
         ↓ orchestrates
Enterprise: Core systems · AI agents · People · APIs

The Agent Skills layer is the markdown-defined skill architecture I noticed. These are structured capability definitions — what each agent can do, what tools it can call, what constraints govern its behavior — shared across all four specialized agents. This is identical in structure to the AGENTS.md / Constitution concept in SDD: the standing constraints that every agent in the system must respect.

The Organizational Memory is a Git-backed knowledge store that persists cross-process knowledge across every engagement. Every process the system has discovered, re-engineered, and deployed gets its decisions recorded here. This is the SDD versioned spec store: the living, auditable artifact that the next implementation builds on.

The Brief — the plain-English process description and KPI selection that starts every ProcessOS engagement — is the SDD spec's Specify phase. Camunda's own description:

"Describe the process in natural language. Define what success looks like: the outcome you're optimizing for and the KPIs that matter. ProcessOS reads both as ground truth, then reconstructs the as-is, designs the to-be, and generates everything needed to run it."

Replace "ProcessOS" with "GitHub Spec Kit" and this sentence describes /speckit.specify. The pattern is the same.

Part II — The Architecture Mapping: ProcessOS Components as SDD Constructs¶

ProcessOS Component	SDD Equivalent	What It Does
The Brief (plain-English process description + KPI selection)	Specify phase — business outcomes, success criteria, scope	Entry artifact that constrains everything downstream
Fitness function (KPIs the re-engineered process must achieve)	Acceptance criteria — non-functional requirements	The measurable contract the implementation must satisfy
Agent Skills (shared across all four agents)	The Constitution — standing constraints governing agent behavior	What the agents can and cannot do; capability bounds
Organizational Memory (Git repo, cross-process, private)	Versioned spec store — living spec that persists and compounds	Audit trail + institutional knowledge across every engagement
Discover agent	Reverse Specify — extract behavioral spec from legacy system	Mines event logs; produces as-is behavioral model
Design agent (Re-engineer)	Specify (Target) + Plan — to-be model + architecture	Redesigns process for AI-native outcomes; generates BPMN
Build agent	Tasks + Implement — bounded units, AI-generated	Generates and deploys the updated process model and workers
Optimize agent (Continuously Improve)	Spec Evolution + monitoring feedback	Monitors KPI performance; triggers new Discover cycle on drift
Plugins (MCP extensibility)	Integration constraints — approved external services	Governed list of what the system may call
Catalog (connectors, reusable building blocks)	Shared component library — Constitution-approved implementations	Building blocks that compound across processes

Every structural element of the SDD framework has a named counterpart in the ProcessOS architecture. Camunda did not use SDD terminology — but they independently implemented the same solution to the same problem.

Part III — Why This Makes Sense: Form Four as the SDD Operating Layer¶

The Form Four research established that ProcessOS operates on process models as governed artifacts — not within running process instances. This positions it at a structurally different layer from Forms One, Two, and Three (which operate within instances).

SDD operates at an analogous structural layer relative to code: it governs the specification that constrains what AI agents generate — not the generated artifacts themselves. SDD is the discipline that sits above implementation, just as Form Four sits above execution.

The structural parallel:

Level	BPM	SDD
Runtime	Running process instances (Forms 1–3 participate here)	Deployed code (unit tests, integration tests validate here)
Governance layer	ProcessOS — governs the process model artifacts	SDD spec — governs the implementation artifacts
What the governance layer manages	BPMN process models: discovery, redesign, deployment, improvement	Specs: authorship, validation, versioning, evolution
How governance propagates	Every instance that runs against the deployed model is governed by it	Every AI agent that builds against the spec is constrained by it

ProcessOS is Form Four applied to process models. SDD is Form Four logic applied to implementation specs. They are the same architectural pattern at two different levels of the stack.

The insight this produces: A fully Form Four-governed organization is one where:

ProcessOS governs what process models exist and how they perform (Form Four BPM layer)
SDD governs what the implementation of those processes looks like (Form Four implementation layer)
The Brief + fitness function (ProcessOS) feeds directly into the SDD spec template (engineering)
The Organizational Memory (ProcessOS) and the versioned spec store (SDD) are synchronized — one is the process model record, the other is the implementation record

These two Form Four layers are the architectural backbone of the AI-native organization. Neither is sufficient without the other. ProcessOS without SDD produces well-governed process models implemented inconsistently. SDD without ProcessOS produces well-implemented components governed by hand-authored models that drift from production reality.

Part IV — ProcessOS Applied to the Obsolescence Plan¶

ProcessOS maps cleanly to a three-track legacy BPM obsolescence framework: Track A (Modernize), Track B (Archive), Track C (Retire). ProcessOS automates the parts of each track that previously required manual analytical work.

Track A (Modernize): Full Four-Agent Engagement¶

Legacy Event Logs + System Inventory
        ↓
[Discover Agent] — mines ACT_HI_ACTINST or equivalent
        ↓ produces as-is behavioral model + conformance delta
[Design Agent] — re-engineers for AI-native outcomes
        ↓ produces to-be BPMN + fitness function KPIs
[Brief + SDD Spec] — business team reviews and approves (the hand-off point)
        ↓ spec moves to SDD implementation lifecycle
[Build Agent] — generates process model, workers, connectors
        ↓
[Optimize Agent] — monitors production KPIs continuously
        ↓ triggers new cycle when KPI drift detected

The Discover agent does what a manual "Reverse Specify" step requires — mines the event log, reconstructs the actual executed process (not the documented one), and surfaces the conformance delta (the gap between what was designed and what actually ran). This is Dumas Step 3 ("Complete the process model") done automatically.

The fitness function the Design agent optimizes against is the SDD spec's acceptance criteria. When the business team states "cycle time must reduce by 30%" and "exception rate must fall below 8%," those are the fitness function targets. The Design agent optimizes the to-be model against them and confirms whether the redesign meets them before implementation begins. This is flow analysis (Dumas §7.2) automated.

The Organizational Memory entry from a Track A engagement captures: the discovered as-is model, the conformance delta, the design decisions made, the fitness function targets, and the deployed to-be model. This is the institutional knowledge record of that modernization project — available to every subsequent engagement.

Track B (Archive): Discover Agent + Organizational Memory¶

Track B workflows — dormant or decommissioning — do not need the full four-agent engagement. They need two things: the behavioral record (what the legacy system actually did) and the decommission spec (what it integrated with and what it provided to downstream systems).

ProcessOS's Discover agent produces the behavioral record automatically from the event log. The Organizational Memory entry becomes the shelf artifact — stored in Git, versioned, available for future reconstruction.

Track B previously required:

Manual process mining or SME interviews → now: Discover agent from event logs
Manual documentation of exception paths → now: conformance delta from Discover
Manual integration contract documentation → now: connector catalog entry + Organizational Memory

Track B in a ProcessOS-enabled organization reduces to: run Discover, review output, confirm Organizational Memory entry is accurate, close the record. What previously took 1–3 days per workflow becomes hours.

The key insight for Track B: ProcessOS's Organizational Memory is not just an archive. Because it stores everything in Git with version history, the decommissioned workflow's behavioral record is recoverable, diffable, and auditable. If a downstream system later reports an unexpected behavior, the organization traces it to the decommissioned workflow's Organizational Memory entry. The shelf artifact is automatically structured, versioned, and searchable.

Track C (Retire): Catalog Entry Only¶

Track C workflows — unambiguously obsolete — require only a Catalog entry confirming they have been decommissioned and what connectors or building blocks they used. Those connectors remain in the Catalog for reuse in future processes. The workflow closes with a single Organizational Memory note.

The Compounding Effect¶

The Camunda platform page is explicit about a property that manual obsolescence planning cannot match:

"The tenth process is dramatically faster than the first."

This compounding effect comes from the Organizational Memory and Catalog accumulating institutional knowledge across every engagement. By the time an organization has run ProcessOS on ten legacy workflows:

The Organizational Memory contains every design decision made across all ten engagements
The Catalog contains every connector built for any of those ten processes, reusable on the eleventh
The Discover agent has built pattern recognition from ten conformance analyses

Manual obsolescence planning does not compound. Each engagement starts from near-zero. ProcessOS changes the economics of the obsolescence program from a linear cost curve to a declining marginal cost curve.

Part V — The SDD Value Promise: Measured in ProcessOS Results¶

The foundational value question for any new methodology is: what is the measurable return?

ProcessOS answers with production numbers. These are not theoretical — they are from named customers in Camunda's published case studies:

Metric	Traditional BPM Re-engineering	ProcessOS-enabled
Discovery phase	2–3 months (workshops, consultants)	1–2 weeks (event log mining)
Re-engineering phase	1–2 months	1 week
Build & deploy phase	3–6 months	2–4 weeks
Optimization	Quarterly or never	Continuous, backtested
Finnova case	15–30 minute onboarding form	Same task: minutes
R-KOM case	8 hours average ticket response	Near real-time
Danica case	Customer onboarding: months	Customer onboarding: days

The velocity comes precisely because ProcessOS implements SDD disciplines (brief → agents → build → validate) as an automated, governed pipeline. The brief is the spec. The fitness function is the acceptance criteria. The Organizational Memory is the versioned spec store. The four agents implement the four SDD phases. Remove any of those elements and the cycle time reverts to manual.

A legitimate concern about spec-first methods is that they accelerate toward a failure-revealing milestone rather than avoid failure. ProcessOS's answer: yes, but the milestone moves to the Brief. If the brief is incoherent — KPIs contradictory, scope undefined, business logic unresolved — the Discover and Design agents surface it in week 1–2, not in week 24 when the system is live in production. The brief is the cheap failure layer. Every failure that surfaces in the brief costs hours. The same failure in production costs months.

The SDD Cost-of-Failure Stack, Applied to BPM¶

Where the gap is discovered	Cost in a ProcessOS engagement
In the Brief (scope, KPI, contradictions)	Hours — business conversation, spec revision
In the Discover phase (conformance delta reveals missed complexity)	Days — design adjustment before any implementation
In the Design phase (fitness function analysis shows redesign won't meet KPI)	Days — redesign iteration
In the Build phase (worker or connector spec is incomplete)	Days — spec update before code is generated
In production (KPI monitoring reveals regression)	Weeks — Optimize agent triggers new Discover cycle

ProcessOS pushes every discovery upward toward the cheaper layers. That is the SDD value proposition, implemented.

Part VI — The SDD Brief Template: ProcessOS's Missing Front-End¶

ProcessOS's brief input — "describe the process in natural language, define what success looks like" — is powerful but under-specified for complex enterprise processes. The brief Camunda shows in their demo is deliberately simple: plain English + KPI checkboxes.

For complex legacy workflows, that simplicity is a gap. A brief that says "re-engineer the commercial underwriting process to be faster" does not give the Design agent enough to work from. It will make assumptions. Those assumptions will be plausible. Some will be wrong.

An SDD executable spec template provides the structured Brief that ProcessOS's Design agent actually needs:

SDD Spec Section	What ProcessOS Needs	Why
Business Outcomes + Success Criteria	Fitness function KPIs with thresholds	Without thresholds, the Design agent cannot evaluate whether a redesign meets the goal
Scope Boundaries	Explicit in-scope / out-of-scope	Without this, the Design agent expands scope to adjacent processes
Business Logic & Rules	Gateway conditions, decision rules	Without these, the Design agent infers rules from event log frequencies — which reflects what happened, not what should happen
Verification Criteria	Acceptance criteria for each logical path	Without these, the Build agent has no validation contract
Open Questions	Deferred decisions that must not be implemented	Without these, the Build agent implements its own answer to unresolved questions

The recommendation: Use the SDD spec template as the ProcessOS Brief for any complex engagement. The structured Brief replaces the natural-language description and gives the Discover and Design agents explicit constraints to work within — rather than having them infer constraints from the event log alone.

This is also the organizational fix for the problem of business teams delivering unstructured requirements. With ProcessOS, the brief goes to the Discover agent, not to engineers. But an unstructured brief to the Discover agent produces the same problem as an unstructured prompt to a coding agent: it makes assumptions to fill every gap. The SDD spec template structures the brief so the agent gets explicit constraints, not guessed ones.

Part VII — Putting It Together: The ProcessOS-Enabled BPM + SDD Organization¶

The full architecture, integrating Form Four, BPM, SDD, and ProcessOS:

FORM FOUR LAYER (ProcessOS — governs process models)
┌─────────────────────────────────────────────────────────────────┐
│  1. Business team + Discover agent: produce as-is behavioral    │
│     model from event logs (Reverse Spec automated)              │
│                                                                 │
│  2. Business team + Design agent: produce to-be model +         │
│     fitness function (Target Spec + Plan automated)             │
│                                                                 │
│  3. SDD BRIEF (structured) → Brief reviewed at hand-off point   │
│     Business approves Sections 1–3; Engineering adds Section 4  │
│                                                                 │
│  4. Build agent → Implement (spec-anchored, CI-validated)       │
│                                                                 │
│  5. Optimize agent → monitors KPIs continuously                 │
│     → triggers new Discover cycle on drift                      │
└─────────────────────────────────────────────────────────────────┘
         ↓ deploys governed BPMN models
FORM 1–3 EXECUTION LAYER (Camunda 8 / Zeebe — runs process instances)
┌─────────────────────────────────────────────────────────────────┐
│  Form One: User tasks with AI inference support                 │
│  Form Two: Service tasks with AI worker execution               │
│  Form Three: Bounded agentic subprocesses                       │
│  All three governed by the BPMN model ProcessOS produced        │
└─────────────────────────────────────────────────────────────────┘
         ↓ produces event logs
HISTORY LAYER (ACT_HI_ACTINST equivalent / Zeebe event store)
┌─────────────────────────────────────────────────────────────────┐
│  Every task execution logged · timestamped · typed              │
│  → Feeds back to ProcessOS Discover on next cycle               │
│  → Organizational Memory updated continuously                   │
└─────────────────────────────────────────────────────────────────┘

The governance loop that closes everything:

Event logs accumulate from production execution (Persistence — one of the three runtime dimensions)
Optimize agent monitors KPIs against fitness function (spec-derived acceptance criteria)
When KPI drift exceeds threshold, Optimize triggers a new Discover cycle
Discover mines updated event logs, produces revised as-is model
Design proposes redesign options, tests against fitness function
Structured Brief reviewed at human governance gate
Build deploys revised BPMN model
New instances run against revised model → event logs accumulate → repeat

This is the BPM lifecycle from Dumas §1.4 (Process Identification → Discovery → Analysis → Redesign → Implementation → Monitoring → back to Identification), executed with Form Four governance at the process model level and SDD discipline at the implementation level. What previously required six phases of manual professional work now runs as a governed, AI-accelerated continuous loop.

The Obsolescence Plan Within This Architecture¶

Legacy workflows under review are inputs to ProcessOS's Discover agent — not inputs to a manual analysis project. The Discover agent:

Mines the legacy event log (or BPMN model if logs are unavailable)
Produces the conformance delta (Reverse Spec)
Generates an Organizational Memory entry (shelf artifact for Track B)
Surfaces the modernization scope (Track A vs. Track B vs. Track C determination)

The human governance gate becomes the decision point: review the Discover output, confirm the Track assignment, approve the structured Brief if Track A. Engineering does not begin until that gate passes.

The measure of success for the obsolescence program, in ProcessOS terms:

Track A completions: time from legacy event log extraction to deployed re-engineered process in production
Track B completions: Discover output + Organizational Memory entry confirmed by process owner
Track C completions: Catalog decommission entry logged
Portfolio-level: conformance delta improvement across all Track A modernizations (KPI improvement vs. as-is baseline)

Part VIII — What Camunda Didn't Call SDD (And Why It Doesn't Matter)¶

My own question when reviewing the ProcessOS architecture: why didn't Camunda bring in the SDD terminology?

The answer: Camunda's audience is BPM practitioners, process architects, and enterprise IT leaders — not software engineers adopting AI coding practices. The SDD vocabulary comes from the AI-assisted software engineering world. Camunda is addressing the process management world. They use the vocabulary their audience knows: fitness functions, process mining, conformance checking, BPMN.

The structural alignment exists regardless of vocabulary. What matters for practice is recognizing that:

The Brief = the Specify phase. Structuring the Brief using the SDD spec template makes the Design agent's work more precise.
The fitness function = acceptance criteria. Framing KPIs as acceptance criteria (with explicit thresholds, time horizons, and measurement methods) gives the Design agent a testable contract, not a vague goal.
The Organizational Memory = the versioned spec store. Treating it as the authoritative record of every design decision — and linking each decision to the fitness function targets that justified it — creates the audit trail that compliance requires.
The Agent Skills layer = the Constitution. Extending the Agent Skills definitions with explicit constraints from the SDD Constitution (data classification rules, approved external services, AI worker confidence thresholds) governs what the Build agent can produce.

The practical implication: When configuring ProcessOS for an organization's first engagement, the setup work is:

Define the Organizational Memory seed — the standing constraints, architecture decisions, and data governance rules that apply to all process re-engineering in this organization
Define the Agent Skills layer — what the Discover, Design, Build, and Optimize agents are allowed to do, and what they must not
Structure the Brief template — the SDD spec template, pre-populated with the organization's standard KPI dimensions and scope constraints

That setup work IS the SDD Constitution for the organization's ProcessOS deployment. It governs every engagement that follows. Done once, it compounds across every process the system touches — which is exactly the "tenth process is dramatically faster than the first" effect Camunda describes.

Summary¶

Claim	Evidence
ProcessOS is structurally an SDD framework	The Brief (Specify), fitness function (acceptance criteria), Organizational Memory (versioned spec store), Agent Skills (Constitution), and four-agent cycle (four SDD phases) map exactly
ProcessOS is Form Four applied to BPM	It operates on process models as governed artifacts, not within running instances — the defining characteristic of Form Four
ProcessOS automates the Reverse Spec	Discover agent mines event logs and produces as-is behavioral model without manual SME interviews
ProcessOS automates Track B archival	Organizational Memory entry is the shelf artifact; Discover output is the behavioral record
The SDD spec template is the structured Brief	The six-section template gives ProcessOS's Design agent explicit constraints vs. inferred ones
The acceleration is real	Finnova 70–80% faster onboarding; R-KOM near-instant ticket response; discovery 1–2 weeks vs. 2–3 months
The compounding effect changes the economics	Organizational Memory and Catalog reduce marginal cost per engagement; tenth process dramatically faster than first

ProcessOS is the BPM-native implementation of the SDD parallel-tracks model. My instinct in the demo was correct. The architecture confirms it.

Form Four research: Samuelson 2026b (The ProcessOS Horizon) | Samuelson 2026c (Process-First AI: Dimensions of the Running Work Record)
ProcessOS architecture: camunda.com/platform/process-os/ (May 2026)
SDD reference: GitHub Spec Kit (github.com/github/spec-kit) | arXiv:2602.00180
BPM reference: Dumas et al. 2018, §1.4 (BPM Lifecycle), §9.4 (Executable Transformation)