IoT
Real-world flows: devices, sensors, events, signals, constraints, physical execution, and hardware that waits, reacts, fails, and recovers.
IoT · EIP · BPMN · Qubit · Priostack · Memory
I see systems as flows of meaning.
Some flows move through IoT devices. Some through messages. Some through BPMN processes. Some through human decisions. My work is about making those flows executable, portable, observable, and intelligent.
Qubit was born from a simple frustration: the stack required to run one executable model was becoming heavier than the model itself.
Not a digital resume.
A map of how I think about IoT, integration, execution, process architecture, and change.
The thesis
Automation is not the end of modeling. It is the moment modeling becomes responsible.
For years, organizations have drawn process diagrams to align people. Then execution begins, and the diagram becomes too fragile, too technical, too infrastructure-heavy, or too disconnected from reality.
My work starts in that gap. I explore how models can become portable, how integration can become visible, how execution can build memory, and how architecture can help decide what transformation is worth doing.
Genesis
The problem was never the diagram. It was the weight required to make it run.
My first experiments were at the intersection of IoT, Enterprise Integration Patterns, and BPMN. I was trying to describe real-world behavior as executable flows: devices, messages, decisions, waiting states, retries, gateways, and events.
BPMN gave me a language for orchestration. EIP gave me a language for integration. But as the ideas became more executable, the stack kept growing: engines, brokers, adapters, deployment layers, monitoring, cloud services, and runtime dependencies, sometimes just to run a single model.
That frustration led me to Qubit: a portable execution substrate designed to run flows, services, and orchestration logic on any hardware, from IoT environments to cloud infrastructure.
An early IoT flow modeled with BPMN: initialization, verification, waiting, reading, printing, reset, and stop conditions.
The map of my thinking
My ideas are not separate topics. They are one evolving chain.
Enterprise Integration Patterns
EIP taught me that systems exchange meaning through messages: channels, routers, filters, splitters, aggregators, translators, correlation, and pipelines.
Read Two-Layer ArchitectureBPMN
BPMN taught me how decisions unfold over time: orchestration, state, human tasks, events, rules, waiting, retries, incidents, and long-running execution.
The stack problem
The more executable the models became, the heavier the platform became. The infrastructure required to run one meaningful model started to outweigh the model itself.
Qubit
Qubit is my answer to that weight: a portable execution substrate for flows, services, and orchestration logic, designed to be installable on any hardware.
DevRevolt
DevRevolt exists because execution should not be trapped inside heavy platforms. It is the movement around Qubit, WebAssembly services, and runtime sovereignty.
Visit DevRevoltPriostack
Priostack is the cloud service built on top of the Qubit engine: BPMN, DMN, CMMN, EIP, process intelligence, tutorials, and architecture-to-execution in one environment.
Visit PriostackGeometric Memory
If executions leave traces, those traces can form shapes. If they form shapes, they can be compared. If they can be compared, a process can recognize drift and abnormal behavior.
Read Geometric MemoryContract-Based Modeling
CBM connects process needs, departmental commitments, cost, value, and transformation decisions so architecture can become accountable, not only descriptive.
The ecosystem
Qubit is the substrate. DevRevolt is the movement. Priostack is the cloud service.
I do not see these as disconnected projects. They are different layers of the same search: how to make execution lighter, portable, modular, observable, and intelligent.
Runtime substrate
Qubit
A portable execution substrate for flows, services, and orchestration logic. Qubit is designed to be installable on any hardware, from IoT devices and local machines to edge environments and cloud infrastructure.
Movement
DevRevolt
The ecosystem around Qubit: portable execution, WebAssembly microservices, runtime sovereignty, decentralized service ideas, and freedom from unnecessary infrastructure gravity.
Visit DevRevoltCloud service
Priostack
The cloud service built on Qubit, focused on BPMN, DMN, CMMN, EIP, process intelligence, tutorials, geometric memory, and architecture-to-execution thinking.
Visit PriostackThe core ideas
The current state of my work lives around structure, memory, and transformation.
A
AOPM — Aspect-Oriented Process Modeling
BPMN breaks when every concern is forced into one diagram. AOPM is my way of modeling processes as systems: core flows stay readable, cross-cutting concerns become reusable patterns, and change becomes safer.
- Singleton Proxy Pattern for stable coordination.
- Retry, Strategy, Observer, and Audit as reusable process aspects.
- Separation of business intent from technical behavior.
B
Geometric Memory — processes that remember shape
Most engines report what happened. I am interested in whether what happened was normal. Geometric Memory turns execution paths into trajectories, compares them against learned normal behavior, and detects unusual workflows without enumerating every bad rule.
- Cell IDs encode execution context, not just task identity.
- Shape vectors create geometric signatures of process runs.
- Fréchet distance compares trajectories while preserving order.
C
CBM — Contract-Based Modeling
Capabilities are not enough. Transformation needs commitments. CBM introduces contracts between process needs and departmental services so transformation can be prioritized with structure, cost, value, and accountability.
- Capabilities treated as commitments, not labels.
- Transformation decisions supported by formulas and simulation.
- Architecture connected to execution and economic trade-offs.
Why this is different
I am not building another BPM narrative. I am trying to expand the mental model.
Common BPM thinking
Model the flow. Automate the tasks. Monitor incidents. Add rules when something goes wrong. Accept that diagrams become complex and platforms become heavy.
My direction
Model the structure. Make integration explicit. Separate concerns. Make execution portable. Let runtime build memory. Compare trajectories. Treat architecture as a decision system.
Where it came from
My ideas came from struggle, experiments, and production pressure.
I did not arrive at process architecture through theory. I arrived there by trying to connect worlds that were not supposed to meet: IoT, integration patterns, BPM engines, portable runtimes, software architecture, and the messy reality of enterprise systems.
IoT taught me that processes exist outside software
Before enterprise BPM, I was already thinking about flows in IoT: devices waiting for signals, modules reacting to events, sensors producing context, and hardware behavior that looked surprisingly close to process orchestration.
Software architecture gave me language
I later moved deeper into software and completed a Master in Software Architecture. That shift gave me the tools to translate my systems mindset into code, integration, modularity, and enterprise design.
Air France changed everything
At Air France, I fell in love with two disciplines that still shape my work today: Enterprise Integration Patterns with Apache Camel and BPM with Camunda. EIP taught me how systems exchange meaning. BPM taught me how organizations execute decisions over time.
Hackathons became my laboratory
I kept trying to merge IoT, EIP, and BPMN. Hackathons became the place where I tested ideas, prototypes, and concepts before they had names. I was not just building demos. I was searching for a smaller execution substrate.
Qubit came from the stack becoming too heavy
As the models became executable, the stack kept growing. Engines, brokers, adapters, deployments, monitoring, cloud dependencies, too much weight just to run a single flow. Qubit became my attempt to make execution portable again.
Priostack became the cloud expression of Qubit
Qubit gave me the substrate. Priostack became the cloud service built on top of it: a place where BPMN, DMN, CMMN, EIP, process intelligence, tutorials, and architecture-to-execution could converge into one executable environment.
DevRevolt became the sovereignty branch
DevRevolt exists because I believe execution should be portable, installable, and free from unnecessary infrastructure gravity. It is where Qubit connects to WebAssembly, edge deployment, IoT hardware, and runtime independence.
For whom I build
I write for the people I used to be, the teams I worked with, and the architect I became.
My work is intentionally layered because my journey was layered: from trainee to developer, from integration to BPM, from DevOps to architecture, from production pressure to original methods.
For juniors and trainees
To show that architecture is not a title you receive. It is a way of learning systems patiently, one constraint at a time.
For developers
To provide concrete patterns, GitHub examples, and executable tutorials that connect code, integration, and process logic.
For BPM consultants
To go beyond diagrams and learn how to structure BPMN models so they remain modular, readable, and maintainable under pressure.
For architects
To connect process execution, integration, governance, memory, and transformation decisions into one coherent architecture.
Writings & experiments
The library is where the vision becomes concrete.
I use articles, tutorials, field notes, and experiments to make the ideas testable. Some pieces are conceptual. Others are practical. Together, they form the public notebook behind Priostack, Qubit, and DevRevolt.
Article
Geometric Memory and Process Trajectories
A process execution is not only a list of events. It can become a shape. This article explores how runtime paths can be encoded, compared, and used to detect anomalies.
Read articleArticle
Two-Layer Architecture: BPM + EIP
A practical architectural view that separates process runtime from enterprise integration patterns: routers, filters, splitters, aggregators, translators, and correlation.
Read articleTutorial
Agentic Credit
A hands-on tutorial showing how BPMN, DMN, CMMN, ArchiMate, geometric memory, and AI-assisted decisions can work together in a concrete credit scenario.
Open tutorialArticle
Tracing Data Evolution
An early reflection on context, DIKW, and why data only becomes meaningful when interpretation, domain context, and decision-making enter the system.
Read on LinkedInManifesto
Why Wasm Microservices Are the Future
A DevRevolt article on WebAssembly as a lightweight execution primitive for portable, isolated, language-agnostic microservices.
Read on MediumField notes
Qubit experiments
Public notes and experiments around portable execution, WebAssembly services, embedded orchestration, declarative routing, and flow-based thinking.
Read on RedditShort notes
Ideaswave
A place for fragments, intuition, sketches, and short public thoughts while the larger ideas are still forming.
Follow on MastodonMore coming
GitHub, YouTube, demos, and tutorials
I will keep adding links to source code, walkthroughs, prototypes, process patterns, architecture notes, and videos as the ecosystem grows.
Suggest a topicBooks as manifestos
Two books. One direction: go beyond notation.
These books are not product brochures. They are my attempt to give language to what I kept seeing in the field: process models need structure, and architecture needs accountability.
Beyond BPMN
The future of process modeling with AOPM
Manifesto 01
Beyond BPMN
A book about making process automation modular, reusable, and survivable. It introduces AOPM and the Singleton Proxy Pattern as a response to BPMN models that collapse under complexity.
- Core flows should stay readable.
- Cross-cutting behavior should become reusable aspects.
- Process models should be designed like systems.
Beyond ArchiMate
The architecture of digital transformation using CBM
Manifesto 02
Beyond ArchiMate
A book about making architecture actionable. It introduces Contract-Based Modeling and a transformation evaluation approach to connect capabilities, commitments, value, cost, and timing.
- Capabilities should become commitments.
- Transformation should be evaluated, not guessed.
- Architecture should support decisions, not only diagrams.
Roadmap
The vision is unfolding in public.
I am not presenting a finished empire. I am documenting the construction of a system of thought, from the first trainee years to the architecture layer I am building now.
Articles, books, and tutorials
I publish the concepts through Priostack, books, LinkedIn, Medium, Mastodon, and practical tutorials.
GitHub examples and live tutorials
I will push concrete examples to GitHub and allow people to test tutorials directly on Priostack.
Qubit public availability
Qubit will become publicly available as the portable execution substrate behind the ecosystem, with a target horizon of around two years.
Continue the conversation
Talk to me if you are trying to make execution lighter, smarter, and more understandable.
I am interested in IoT flows, portable runtimes, WebAssembly services, Camunda 8 platform thinking, BPMN modeling strategy, Enterprise Integration Patterns, process anomaly detection, architectural governance, and the future of executable transformation.