Frame Game: Why Autonomous Process AI Needs Pockets of Rigidity

Opening — Why this matters now

The current fashion in enterprise AI is to give agents more tools, more context, and more freedom. The assumption is charmingly simple: if the model can reason, retrieve, plan, and call APIs, then the organization becomes more adaptive. Add a dashboard, call it orchestration, and wait for productivity to bloom like a suspiciously well-funded greenhouse.

The harder question is not whether AI can act. It can. The harder question is what counts as legitimate action when an AI system is operating inside a business process that is partly formal, partly habitual, partly regulated, and partly known only because Susan in operations has been fixing it quietly since 2017.

The paper behind this article tackles precisely that problem. It studies the process frame of an AI-Augmented Business Process Management System, or ABPMS: the representation that gives an autonomous or semi-autonomous process system awareness of the boundaries within which it may act.¹ The authors argue that this frame should not be a single traditional workflow model. It should be a hybrid representation made of procedural models, declarative constraints, and potentially other kinds of process knowledge, executed semi-concurrently.

That sounds abstract. It is not. It is the difference between an AI assistant that merely follows a checklist and an AI operations system that understands: “You may reschedule this appointment, but not before insurance verification; you may skip manual review for low-risk claims, but only if the fraud score is below threshold; you may notify the customer, but not before the underwriter sees the exception.”

In other words: autonomy needs a fence. The interesting design problem is that the fence cannot be a wall.

Background — Context and prior art

Traditional business process management systems are built around process models. These models usually describe how work should proceed: first A, then B, perhaps C or D, then approval, then completion. In procedural process modeling, the model often tries to describe the allowed sequences of activity explicitly. Petri nets, BPMN-like structures, workflow graphs, and process trees belong to this family.

Declarative process modeling takes a different view. Instead of prescribing the full path, it states constraints. For example:

• if activity A happens, B must eventually happen;
• B cannot happen before A;
• A and B cannot both occur in the same case;
• every payment must be preceded by approval.

Declare is one well-known declarative language used in process mining and process modeling. It is useful when the process is flexible, knowledge-intensive, or difficult to describe as a single rigid path. Which, in business, is a polite way of saying: most real work after the PowerPoint leaves the room.

The paper positions itself inside the emerging ABPMS agenda. In that agenda, the process management system is no longer merely a passive execution engine. It becomes an actor that can reason about process state, optimize execution, and adapt behavior over time. But if the system has autonomy, it must also have an explicit representation of what it is allowed to do.

The authors call this representation a process frame. The frame defines behavioral boundaries, but it does not need to fully prescribe every valid execution. This is the central shift.

Traditional workflow model:

“Here is the complete process. Stay inside it.”

ABPMS process frame:

“Here are the constraints, procedures, dependencies, and obligations that define legitimate behavior. Act within them.”

That distinction matters because an autonomous process system may manage multiple related processes, interact with human and non-human agents, and combine formal rules with softer operational knowledge. A single closed workflow diagram is too brittle. A purely free-form agent prompt is too vague. The paper’s proposal sits between the two: a hybrid frame that can combine strict procedural fragments with flexible declarative constraints.

Analysis — What the paper does

The authors conceptualize the ABPMS process frame as a finite set of process specifications. Each specification may be procedural, declarative, or potentially based on another formalism. Each specification has its own activity set. When a global execution trace is observed, each specification only “sees” the projection of that trace onto the activities it governs.

This is where the paper’s open-world move becomes important.

In a normal procedural model, activities outside the model are often treated as violations. If the model says A → B → C, and the log shows A → X → B → C, many conformance approaches treat X as an extra move, something outside the modeled behavior.

The authors argue that inside a process frame, procedural models should also be interpreted under an open-world assumption. A procedural fragment constrains only the activities inside its boundary. Other activities may occur between them, unless another specification says otherwise.

That gives procedural models a constraint-like meaning. A fragment may say: “whenever K happens, L must follow in this local procedure.” It does not automatically say: “nothing else in the organization may happen between K and L.” This is not philosophical softness. It is a practical necessity when many process fragments execute semi-concurrently and overlap through shared activities.

A simple operating example

Imagine an AI system supporting insurance claims. A full claim case may include intake, document review, fraud screening, customer communication, settlement calculation, and payment approval.

One procedural fragment might govern settlement approval:

claim validated → settlement calculated → approval requested → payment released

A declarative constraint might say:

if fraud signal is raised, human review must eventually occur before payment release

Another procedural fragment might govern customer communication:

missing document identified → request sent → response logged

These fragments overlap through activities such as payment released, human review, or request sent, but they do not need to form a single master workflow. The process frame accepts a trace only if every relevant specification accepts its own projection of that trace.

That gives the AI system freedom to coordinate work while respecting multiple local boundaries. It also makes the model compositional: new constraints can be added without rewriting the entire process map.

The useful managerial translation is simple: the process frame is not documentation. It is a runtime governance layer.

Implementation logic — From directly-follows to eventually-follows

The paper then turns to automated discovery: how can such a process frame be discovered from historical event logs?

This is where things become technically interesting, and slightly cruel to conventional process mining.

Many process discovery algorithms rely heavily on directly-follows relations: B frequently occurs immediately after A, so the model infers a relation between A and B. This works reasonably well when the process is relatively isolated and sequential. It becomes unreliable when multiple process specifications operate semi-concurrently.

Suppose a local procedural fragment requires K → L. In the global event log, however, another activity C from a different specification may occur between K and L. The global trace becomes:

K, C, L

The local relation between K and L still holds when projected onto the fragment’s activity set. But the directly-follows relation has disappeared from the global trace. A discovery method that depends too much on direct adjacency may conclude that K and L are not connected. The model then becomes a confident little liar, which is the least convenient kind.

The authors therefore explore discovery based on eventually-follows relations, especially through Declare constraints. Instead of asking only “what activity comes immediately next?”, the discovery process asks broader temporal questions: if A occurs, must B eventually occur? Can B occur before A? Do A and B alternate? Does one branch have to complete before another join activity occurs?

The paper’s central discovery idea is to identify declarative constraints that correspond to procedural fragments. Once those constraints are detected, some of them can be replaced with equivalent Petri-net fragments. This creates what the authors call pockets of rigidity.

This phrase is worth keeping. It reverses the older “pockets of flexibility” idea. Instead of starting with a rigid procedural model and adding flexible regions, the paper starts from a broadly declarative, permissive frame and extracts rigid procedural sub-behaviors where they are structurally appropriate.

For enterprise AI, that is exactly the right direction. Most organizations do not need one giant perfect process model. They need local islands of strictness inside oceans of mess.

Findings — Results with visualization

The authors test whether common procedural behaviors can be recovered from discovered Declare constraints under the open-world assumption. They focus on four control-flow constructs:

1. sequence flow;
2. parallelism, or AND;
3. exclusive choice, or XOR;
4. inclusive choice, or OR.

Each construct is considered under four cardinalities:

1. mandatory: 1…1;
2. optional: 0…1;
3. mandatory repeatable: 1…n;
4. optional repeatable: 0…n.

That gives 16 procedural variants. The paper reports that 14 of the 16 variants can be accurately discovered through the considered Declare constraints, with the remaining two requiring post-processing. Not a magic wand, but a useful one. The distinction matters.

The paper’s treatment of repetitions is especially important. Many real operational processes repeat: a customer resubmits documents, a claim goes back for clarification, a maintenance job cycles through inspection and repair, a purchase order gets corrected. Declarative constraints that work over a whole trace can behave strangely when repetitions occur.

For example, a global “not co-existence” constraint may incorrectly force all loop iterations to choose the same branch. If a customer chooses option A in the first iteration and option B in a later iteration, the constraint may treat that as invalid even though the process allows different choices across iterations.

To manage this, the authors rely on templates such as Not Chain Succession, which constrains immediate succession without forbidding legitimate later repetition. They also introduce or use additional ternary templates:

The authors also test non-block-structured behaviors. That is a meaningful extension because textbook process models often love neat blocks: split, branch, join, continue. Real processes prefer spaghetti with governance aspirations. The paper shows that the same constraint approach can capture examples involving overlapping optional regions, overlapping repeatable regions, overlapping AND branches, and overlapping XOR choices.

This does not mean full generality has been solved. The authors are careful not to claim that. But it does show that the approach is not limited to the clean little diagrams that live in methodology slides and frighten no one.

The operating pattern

The paper’s discovery flow can be summarized as follows:

This is a sober view of automation. The discovered model is not truth. It is a negotiable artifact: useful, incomplete, and dangerous if worshipped.

Implications — What this means for business and AI automation

The paper is technical, but its implications for AI automation are direct.

1. AI agents need process boundaries, not just prompts

Many agentic automation prototypes use instructions like “follow company policy” or “escalate risky cases.” That is not a governance system. It is a hope with a JSON wrapper.

A process frame gives the system a formal structure for what must happen, what may happen, what must not happen, and where activities interact. For high-value operations — claims, finance, compliance, procurement, healthcare administration, public utilities — this matters more than marginal improvements in language fluency.

2. Open-world procedural models fit messy organizations better

The paper’s open-world treatment of procedural fragments is highly practical. Most businesses cannot model every process from end to end. They can, however, model critical fragments:

• approval must precede payment;
• inspection must precede certification;
• customer notice must follow outage confirmation;
• manual review must occur after a high-risk flag;
• refund cannot be issued before identity verification.

Those fragments should constrain the system without pretending to describe everything else happening around them. That is exactly what the process-frame view allows.

3. Process mining should produce governable frames, not decorative maps

Conventional process discovery often produces diagrams that are either too simple to be useful or too complex to be read by anyone with a calendar. The paper points toward a more useful target: process discovery as frame construction.

The output is not merely “the process.” It is a layered boundary model:

• procedural fragments where the business needs strict routing;
• declarative constraints where flexibility is acceptable;
• overlaps where local rules interact;
• unresolved regions where human review is required.

For Cognaptus-style automation work, this is the difference between selling a bot and designing an operating system for delegated work. One has demos. The other has consequences.

4. Human review moves upstream

The authors emphasize that automated discovery alone is unlikely to yield a complete and accurate process frame. Historical logs contain noise, rare valid behavior, systematic mistakes, and missing context. A discovered frame must therefore be reviewed and adjusted.

That changes the role of human experts. They should not manually draw every process path. They should review discovered boundaries, add missing constraints, remove accidental patterns, and decide where autonomy is allowed.

This is a better use of human judgment. It is also less glamorous than saying “the AI learns the process automatically,” which is probably why it is more credible.

5. Hybrid frames can become the missing layer between process mining and agentic AI

The industry currently has three partially disconnected worlds:

A hybrid ABPMS process frame sits between them. Process mining helps discover the frame. Workflow models encode pockets of rigidity. Declarative constraints encode business rules and flexible obligations. Agents operate inside the frame.

That is not a complete product architecture yet. But it is a serious research direction, and serious is refreshing.

Practical reading for implementation teams

For a business building AI-enabled process automation, this paper suggests a more disciplined implementation path.

Start with bounded autonomy

Do not ask, “Which process can AI automate entirely?” Ask:

Which decisions or actions can AI take inside explicitly modeled boundaries?

A claims assistant may request missing documents automatically, but not approve payment. A procurement agent may classify suppliers and draft purchase requests, but not override compliance holds. A utility maintenance agent may triage outage reports, but not change public safety notices without approval.

Separate rigid fragments from flexible constraints

Implementation teams should classify process knowledge into at least four buckets:

This classification is not cosmetic. It determines how the AI system monitors itself, how exceptions are surfaced, and how auditors understand what happened.

Treat logs as evidence, not scripture

Historical event logs show what happened, not necessarily what should happen. They may encode workarounds, mistakes, outdated practices, and missing manual actions. Process discovery should therefore be followed by governance review.

The best implementation loop is:

1. discover candidate constraints and procedural fragments;
2. review them with process owners;
3. mark which patterns are required, allowed, deprecated, or forbidden;
4. build the agent’s action policy around the approved frame;
5. monitor deviations and update the frame deliberately.

This is how automation becomes operational discipline rather than statistical mimicry wearing a blazer.

Limitations and open questions

The paper is not a complete process discovery solution. It is closer to a formal foundation plus feasibility analysis. Several limitations remain.

First, the work focuses on control-flow behavior using Petri nets and Declare. Business processes also involve data conditions, resources, roles, costs, deadlines, risk scores, service-level agreements, and regulatory context. A useful ABPMS frame will eventually need to incorporate those dimensions.

Second, the approach still relies partly on Not Chain Succession, which reintroduces immediate succession information in a targeted way. The authors explicitly note future work on removing or reducing that dependence.

Third, the paper shows that 14 of 16 procedural variants can be discovered through the considered constraints, but repeatable inclusive OR remains difficult. This is not a minor corner case. Inclusive choices with repetition occur in real workflows whenever multiple optional tasks may be selected, repeated, and completed in different combinations.

Fourth, the authors highlight that there may be many behaviorally equivalent process frames. There may be no single “ground truth” representation. For human-facing governance, this is important. A frame that is behaviorally correct but unreadable may be operationally useless. Representation quality becomes a design objective.

That last point deserves more attention. In enterprise AI, interpretability is not just model explainability. It is also process-frame legibility: can managers, auditors, and operators understand the boundaries within which the AI acted?

Conclusion — The frame before the fame

The paper’s contribution is not another promise that AI will reinvent business process management. It does something more useful: it asks what kind of formal boundary model an autonomous process system needs before it is allowed to behave autonomously.

Its answer is hybrid, compositional, and open-world. A process frame should combine procedural and declarative specifications. Each specification should constrain what it knows and ignore what it does not. Overlapping activities create interactions. Discovered declarative constraints can reveal procedural “pockets of rigidity” that make the frame easier to inspect and govern.

For business automation, the lesson is straightforward. Do not build agentic systems that merely imitate past workflows. Build systems that can act inside explicit process frames, discover candidate boundaries from logs, and let humans refine the rules that matter.

Autonomy without a frame is improvisation. Improvisation is wonderful in jazz. In claims processing, airport ground operations, finance approvals, or public utilities maintenance, it is usually called an incident report.

Cognaptus: Automate the Present, Incubate the Future.