Open specifications, portable processes

In most organisations, the most precise description of how the work goes is the code of the software that runs it. A rule that was once made for a good business reason ends up as a condition somewhere in an application. A responsibility becomes a mix of authorisations and workflow settings. A collaboration with a partner becomes a set of API calls and mappings.

The software keeps working, but the reasons behind it are harder and harder to find. And whoever owns the software, in practice, owns the knowledge of how you work.

In CaseFlows, how you work is written down in an open specification: the case, the phases it goes through, the case roles, what each role can see and do in each phase, and which services are used. Precise enough to run, and readable enough to discuss with the people who do the work.

The files are open: JSON for the structure, markdown for the reasoning. You can read them without CaseFlows, keep them, and take them with you.

The specification is not documentation beside the system. It defines the caseflow the runtime executes: its phases, roles, permissions and rules. The runtime enforces those limits; people, services and AI do the work within them.

That is also where CaseFlows differs from much model-driven software, where a model is translated into code or configuration and the two can drift apart afterwards. Here the runtime reads the specification itself. Changing the specification changes the defined process, without that process having to be rebuilt as application code. How intent becomes a specification is told in From intent to a running system.

Open files are the beginning. Real portability takes three layers, and it helps to be precise about where each stands:

• Open format: the specification is readable and can be taken with you. That is true today.
• Open meaning: a public definition of what a case role is, when a permission applies and what happens when a case changes phase, independent of any runtime. Today that meaning is defined by our schemas and by the CaseFlows runtime; publishing it on its own is our direction.
• Independent execution: other runtimes that run the same specification with the same meaning. Today CaseFlows is the only one.

So what you own today is a readable, portable description of your way of working, in a form people and AI can work with. Running it somewhere else is what the open formats are meant to make possible, not something that exists yet.

Open source made it possible to share, study and improve software without depending on its original developer. Open specifications could do something similar for the way organisations work.

Instead of sharing an application, organisations share what they have learned: the responsibilities, rules, decisions, exceptions and collaboration patterns that make a process work. That knowledge isn’t only for programmers. Process owners, professionals and sector associations can read it, discuss it and improve it.

The specification becomes the shared asset. How it is implemented is meant to remain a choice; today it runs on CaseFlows.

Three promises, each with its own status:

• Ownership: your organisation owns a readable, portable description of how it works. Today.
• Reuse: a specification can be taken over and adapted into your own variant. Possible today within CaseFlows; so far done within our own platforms.
• Interoperability: different suppliers run the same specification. Our direction, and the hardest of the three.

Suppose another organisation has found a good way to handle a certain type of request. If it shared its software, you would probably have to rebuild it to fit your own systems and technical choices.

If it shares its specification, you get what it learned: which case roles turned out to be needed, where responsibility lies, which information matters in which phase, which exceptions came up. You take the caseflow, make your own variant, connect your own services where theirs don’t apply, and develop it further, without waiting for the original author.

When two organisations work together, they don’t have to share their internal caseflows. What they share is the boundary: the case role one hands to the other, with its responsibility, its information, what it may do in each phase, and the result that is expected. That boundary is a specification both platforms understand and both confirm; a change is a new version that both can try on their development environment before it counts.

That is a different kind of sharing from reuse:

• Reusing a specification shares a design for a way of working, at design time. You make your own variant, and there is no shared case.
• Sharing a case role shares a bounded responsibility, while the work runs. You act within agreed limits, in a case that stays with its owner. More in Working across organisations.

Open specifications don’t mean open internal operations. Agreements become explicit and testable; how each side does its part stays its own.

A standard is usually designed, agreed and then applied for years. An open specification stays part of the work. Every case knows the version of the specification it runs under. When people flag that something doesn’t fit, or the same exception keeps coming back, that signal points to the case, and so to the version.

From there a change request is made, a new version is built and tried on the development environment, and only what the process owner approves becomes the next version. New cases start under it; cases already running keep the version they started with, so nobody’s work changes under their feet.

When several organisations build on the same specification, someone has to maintain it, review proposed changes and decide when a new version is ready. And participants on different versions have to be able to keep working while a new one is adopted.

That responsibility could lie with one organisation, a sector association or a community of participants. Our direction is to support shared specifications that organisations can adopt, adapt and improve, without giving up control of their own variant or their own implementation.

Own your way of working. Share what you’ve learned. Choose how it’s implemented. The first runs today, the second within CaseFlows, the third is our ambition.

Runs today

• Open, readable specifications for cases, caseflows, case roles and services, which the runtime executes directly.
• Every case carries the version it runs under; a new version applies to new cases.
• Signals from real cases that become change requests, tried in development and approved by the process owner.
• Boundary agreements between two platforms that both sides confirm, with every change a new version.
• Specifications reused within our own platforms, adapted to each.

Where we’re heading

• The meaning of the specification published on its own, independent of the CaseFlows runtime.
• A place where organisations publish specifications that others can find and adopt.
• Specifications that a sector develops and maintains together, with shared stewardship.
• A second runtime for the same open formats.