The Philosophy of Pulsar

Pulsar exists to solve a specific class of problem: systems that are not just CRUD, not just messaging, and not just workflow diagrams, but long-lived operational realities that must move through time in a controlled, auditable way.

At its core, Pulsar treats business processes as durable state machines. That sounds simple, but the philosophy behind it is stricter than most workflow tools. Pulsar assumes that important work should be explicit, deterministic, observable, and secure. It is built for environments where transitions matter, delays matter, authorization matters, and history matters.

Why Pulsar Exists

Most enterprise systems accumulate process logic in the wrong places. Some rules end up in UI code. Some live in controllers. Some live in database triggers. Some are embedded in one-off background jobs. Over time the system becomes difficult to reason about because the actual workflow is spread across too many layers.

Pulsar rejects that model.

Its first principle is that process logic should be visible and durable. If an entity moves from one state to another, that transition should be deliberate, validated, recorded, and recoverable. If a timeout occurs, it should not vanish into logs or ad hoc cron jobs. If access is denied, the decision should be explainable. If a tenant is isolated, that isolation should be enforced below the application layer, not just hoped for in handler code.

This leads to four design beliefs.

1. State is a first-class concern.
2. Time is part of the model, not an afterthought.
3. Policy must be explicit and enforceable.
4. Business variation should not require rewriting the engine.

Pulsar is therefore not a generic app framework. It is a durable state engine for domains where progression, accountability, and controlled intervention matter.

The Core Philosophy

Pulsar is organized around the Protocol-Entity-Plugin model.

Protocol

The protocol is the engine’s idea of physics. It defines what it means for an entity to move safely through a lifecycle. It handles state transitions, retries, waiting, timers, escalation paths, and durable execution. The protocol does not need to know whether the entity is a patient admission, a cold-chain shipment, a grant review, or a cyber incident. It only needs to know what states exist, what transitions are allowed, and what should happen when time or policy intervenes.

This is why Temporal sits at the center of Pulsar. Temporal gives the system memory. A transition is not just a request handled by a web server. It becomes part of a durable workflow that can survive crashes, retries, long waits, and distributed failure.

Entity

The entity is the persistent record of reality. PostgreSQL stores the current state, the payload, the workflow reference, and the audit trail. This is not just storage for convenience. It is the operational ledger of the system.

Pulsar assumes that the current snapshot and the historical record are equally important. The present tells you what the system believes now. The audit log tells you why it believes that, who changed it, what policy allowed it, and when the decision happened.

The multi-tenant model reinforces this philosophy. Tenant isolation is enforced with row-level security, not merely filtered in application code. That is a statement about trust boundaries: correctness should not depend on every future handler remembering to add the right WHERE tenant_id = ... clause.

Plugin

The plugin layer is where business specificity lives. Pulsar uses YAML manifests to define schema types, initial states, allowed transitions, payload shape, timeout behavior, and other workflow rules. That choice is philosophical as much as technical.

It means the engine is stable while the business process remains adaptable. You do not rebuild the platform every time a hospital intake flow changes, a logistics SLA is tightened, or a municipal review path gains another approval stage. You update the manifest and let the same engine enforce the new protocol.

This is the practical expression of decoupling process logic from platform code.

How Pulsar Works

Pulsar works by combining durability, policy, and operational clarity into a single execution path.

An entity is created against a manifest-defined schema. That schema determines the initial state and the allowed progression graph. A Temporal workflow then owns the lifecycle of that entity. Transition requests arrive through the API, are checked against tenant context and authorization policy, and are signaled into the workflow. The workflow validates the move, updates the stored state, records the audit event, and emits any side effects such as notifications, escalations, or billing events.

Timeouts are treated as native behavior, not external plumbing. If a state has a max_duration, that expectation becomes part of the workflow itself. When the duration expires, Pulsar can escalate, notify, auto-transition, or degrade health according to the manifest.

This is important because enterprise process failures are often temporal rather than transactional. The problem is not always that a request failed. The problem is that nothing happened for four hours when something should have.

Security is woven into the flow rather than attached at the edge. Keycloak establishes identity. KrakenD forwards tenant and user context. OPA evaluates authorization using subject, resource, action, and environment attributes. PostgreSQL enforces tenant boundaries at the storage layer. The result is a zero-trust posture that matches the seriousness of the workflows Pulsar is meant to run.

Operationally, the system is designed to remain inspectable. Consul provides service discovery instead of hardcoded addresses. Docker secrets are used instead of leaking sensitive configuration into environment variables. Structured logs, metrics, and audit records are all part of the same worldview: if the platform matters, it must be understandable under pressure.

Where Pulsar Fits

Pulsar belongs in the space between simple CRUD applications and fully bespoke orchestration platforms.

It is the right fit when the system has these characteristics.

1. Work moves through explicit states.
2. Those states have deadlines, ownership, or escalation rules.
3. Authorization depends on roles, attributes, or organizational context.
4. Multi-tenant isolation is mandatory.
5. Auditable history is a product requirement, not a reporting nice-to-have.
6. Different business domains share the same execution model but not the same specific workflow.

That is why Pulsar can support hospital operations, logistics, grants, HR processes, cyber incidents, and other domain workflows with the same engine. The domains differ, but the structural problem is the same: a long-lived entity must move through a governed lifecycle, and the system must prove what happened.

Within the Juaji platform, Pulsar sits as an internal state backbone. It is not only an API surface. It is an execution engine behind the platform’s operational workflows, with KrakenD at the edge, Temporal as the durability layer, PostgreSQL as the system of record, OPA as the policy brain, and Keycloak as the identity source.

The Deeper Design Choice

Pulsar is intentionally conservative in the best sense of the word. It does not chase novelty where determinism is required. It prefers state machines over hidden automation, explicit manifests over scattered conditionals, append-only audit over mutable storytelling, and infrastructure discovery over hardcoded assumptions.

That conservatism is not a limitation. It is the source of trust.

When people use a system to coordinate real operations, they need to know three things.

1. What state is this entity in right now?
2. Why is it in that state?
3. What is allowed to happen next?

Pulsar is designed so those questions have precise answers.

In One Sentence

Pulsar is a durable, policy-aware, multi-tenant state engine built to separate workflow truth from application sprawl and to make operational processes explicit, auditable, and adaptable.

Closing

The philosophy of Pulsar is straightforward: important processes should behave like systems of record, not collections of callbacks.

That is the reason for the PEP architecture. The protocol guarantees execution discipline. The entity preserves reality. The plugin captures business variation. Together they create a platform where workflows can evolve without sacrificing determinism, security, or auditability.