You define plans, resolvers, and action handlers. Jexie does the rest.
Most systems that do non-trivial background work eventually accumulate a mix of:
These pieces work — until they don’t. When something goes wrong, it becomes hard to answer simple questions:
Jexie replaces that pile of glue with a single, explicit execution layer.
Jexie separates background processing into three developer-owned concerns, and makes everything else a platform responsibility.
A plan describes what should happen:
Plans are declarative. They describe intent, not mechanics.
A resolver answers a simple question:
Resolvers are typically queries or views. They are read-only, deterministic, and free of side effects.
Action handlers contain real code. Each handler:
Handlers never manage orchestration, retries, or concurrency.
Once plans, resolvers, and handlers are defined, Jexie owns:
Developers are intentionally prevented from re-implementing these concerns.
Jexie treats execution as a narrative, not just a status.
Each run records:
When integrated with a business rules engine (BRE), Jexie can also record:
This makes post-mortems and audits explainable instead of speculative.
Jexie is an execution engine. It runs work. Other systems may influence what should run, but Jexie is responsible for how it runs.
Jexie is designed for teams that:
If you have ever said “we should really rewrite this job framework someday”, Jexie is probably for you.
You define plans, resolvers, and action handlers. Jexie does the rest.