Open BPMReference components for work, case and workflow

Open BPM · Proposed

A reference component with an API and a usable interface

The proposed component should own work state and history while exchanging defined information with domain, identity and rule components.

ProposedReviewed

How it works

Open BPM manages work while other components keep their authority

The proposed core receives defined information, changes work state and returns accepted facts to participant and support views and to other software.

  1. Participant interface

    People see available work, claim it, record a result and understand refusals or errors.

  2. Open BPM core

    The component owns work-item state, queues, deadlines, accepted changes and work history.

  3. Support view

    Support staff find stuck or overdue work and perform authorised recovery actions.

  4. Domain component

    The service supplies a stable business reference and receives relevant work results without giving up record ownership.

  5. Identity and trust

    A trust component supplies the actor, role and authority used to accept or refuse an action.

  6. Rule component

    A versioned rule receives defined inputs and returns a routing or priority decision and explanation.

Read the connections
  • Domain component → Open BPM core: send a work request and business reference.
  • Identity and trust → Open BPM core: supply actor.
  • Open BPM core → Rule component: request a decision using defined inputs.
  • Rule component → Open BPM core: return the versioned result and explanation.
  • Participant interface → Open BPM core: issue authorised work commands and receive views.
  • Support view → Open BPM core: inspect state and request recovery.
Every Open BPM surface in this diagram remains proposed. The domain, identity and rule roles describe information ownership; they do not require separate network services.

Own the state of the work

The Open BPM core should own the identity and lifecycle of cases and work items. It should record queues, claims, deadlines, completion and recovery. It should also publish accepted changes so that other components can respond.

It should not become the authoritative store for appointments, applications or other domain records. A creation request carries a stable reference to the business record and only the information needed to organise the work.

Receive authority and decisions from their owners

An identity and trust component supplies the actor, role and authority used to accept or refuse an action. Open BPM records that context with the work change; it does not invent a person’s permissions.

A rule component may receive defined facts and return a routing or priority decision, its version and an explanation. Open BPM uses that result and records which decision affected the work. The first cREXX rule connection is proposed, not implemented. CoreLang may later provide another business-language source; no Open BPM and CoreLang integration exists today.

Give participants and support staff useful views

The participant interface should show available and claimed work, deadlines, the information needed to act and the result required for completion. A support view should show stuck, overdue or repeatedly failing work and the authorised recovery actions available.

These views are part of the reference component, not decoration added after an API. Keyboard access, clear focus, readable state and useful error messages are expected product behaviour.

Use one stack as an example

One reference implementation may use a Rust service, TypeScript/React interface and cREXX rule. It should first run locally and in a repeatable container arrangement.

Those choices demonstrate one composition. They do not require every user to adopt the same languages or split the component into the same deployable units. Kubernetes work should follow only when it tests workload identity, isolation, network policy or another stated operational question.

Related work

What other projects contribute

  • Architecture Portal defines the logical component role and the questions used to assess it.
  • Public Purpose Lab may use the reference component in a synthetic demonstration.

Status and accountability

Read this page with its boundaries visible

Status

Proposed

Last reviewed

Intended users

  • Architects, implementers, service designers and support staff

Non-goals

  • Making Open BPM the authoritative store for every business record

Active proposals

  • A narrow component will combine work lifecycle, public interactions, participant interface and support behaviour.

Limitations

  • Persistence, identity integration, tenancy and service targets remain undecided.

Next evidence sought

  • Agree the first component responsibilities and show one work journey through each public surface.