Compared To
JacqOS is sometimes mistaken for a workflow engine, a RAG pipeline, a domain-driven-design framework, or a smarter LLM agent loop. It is none of these. The difference is not stylistic — it is paradigmatic. This page names the paradigm flips and points to the deeper docs for each.
The unifying axis underneath every contrast on this page is model-theoretic vs imperative: JacqOS programs declare what is true and what must hold; the platform computes the model and proves the constraints. Every other difference — observation-first truth, derivation with provenance, structural containment, golden fixtures — is a downstream consequence of that stance. See Model-Theoretic Foundations for the formal treatment.
The diff at a glance
Section titled “The diff at a glance”| Axis | Conventional pole | JacqOS pole |
|---|---|---|
| Truth surface | Workflow graph or orchestration DAG (LangGraph, Temporal, Airflow) | Append-only observation log; every workflow-like view is a derived read model |
| State model | Mutable variables, aggregate roots, bounded contexts | Computed worldview over a stratified Datalog evaluator |
| Information retrieval | Similarity retrieval over a vector index (RAG) | fact derivation with explicit provenance back to observation |
| Coordination | Orchestration graph, message passing, ReAct loop | Shared derived reality; agents read observation and emit intent against the same ontology |
| LLM containment | Prompt guardrails or a policy layer | Structural relays: every model output lands in candidate.* or proposal.* |
| Correctness gate | Human review of generated code, plus integration tests | Declared invariant plus deterministic golden fixtures; the engine proves satisfiability |
| External I/O | Ambient I/O — code calls the network whenever it wants | Explicit effect capability list (http.fetch, llm.complete, blob.put, blob.get, timer.schedule, log.dev); undeclared use is a hard load error |
Each row gets its own section below.
1. JacqOS vs workflow orchestrators (LangGraph, Temporal, Airflow)
Section titled “1. JacqOS vs workflow orchestrators (LangGraph, Temporal, Airflow)”Axis: observation-first vs workflow-first.
Workflow orchestrators model an application as a graph of steps that mutate state. The graph is the system of record: what ran, in what order, with which side effects. When you replay, you replay the graph; when you debug, you read the graph.
JacqOS has no workflow graph. The system of record is the append-only
observation log. Every fact, intent, and effect receipt is
derived from observations through a stratified Datalog
evaluator and carries explicit provenance back to the
observations that produced it. If you want to see “what ran in what
order,” you write a read model over observations and effects — but
the read model is not authoritative truth. Truth lives in the log.
This is why JacqOS programs replay exactly on a clean database. The observation-first foundations page describes the single deterministic pipeline:
Observation → Atoms → Facts → Intents → Effects → (new Observations)Workflow-first systems lose causality information at every mutation. Observation-first preserves it by construction, which is what makes golden fixtures function as a cryptographic behavioral contract instead of a flaky integration test. See also Atoms, Facts, Intents for the six durable planes that hold each stage of derivation.
Compliance and audit consequence: every intent and every
effect traces back to the specific observation that produced it.
There is no “the workflow did this” black box; there is a witness
graph the platform already maintains.
2. JacqOS vs RAG pipelines
Section titled “2. JacqOS vs RAG pipelines”Axis: derivation with provenance vs similarity retrieval.
RAG pipelines fetch chunks of text by embedding distance against a vector index and feed the chunks back to a model. The model summarizes whatever was nearby in the embedding space. The retrieval step has no notion of why the chunks are relevant — only that they were close.
JacqOS does not provide a managed RAG primitive in V1. It does not
ship a vector store, an embedding index, or a semantic-search
runtime. When JacqOS apps need to know something, they derive it:
mappers extract atom evidence from each observation, and .dh
rules derive fact records with full provenance back to those
observations.
The difference shows up the moment a derived answer is wrong. With
RAG, you can tell which chunks were retrieved; you cannot tell why
the model believed them. With JacqOS, every fact is a node in the
witness graph — follow the provenance edges backward and you
arrive at the exact observation that produced it. That is the
“zero-code debugger” North Star applied to information retrieval.
See Visual Provenance for the Studio
surface that walks these edges, and
Atoms, Facts, Intents for how
provenance is recorded.
If your app genuinely needs embedding retrieval, you call an LLM as
an explicit effect capability (llm.complete) and route its
output through the candidate.* relay so the ontology can ratify it
before any rule trusts it. Embeddings can be a tool; they are not
the truth surface.
Compliance and audit consequence: “how did the system conclude X?” has a literal answer — a finite chain of derivation edges rooted in immutable observations — instead of a probabilistic similarity score.
3. JacqOS vs aggregate-root / DDD bounded contexts
Section titled “3. JacqOS vs aggregate-root / DDD bounded contexts”Axis: derived model vs mutable state.
Domain-driven design models an application as a graph of aggregates that own state and enforce invariants through methods. Bounded contexts partition the domain; each context has its own mutable model that callers update through commands and read through queries.
JacqOS does not have aggregate roots, bounded contexts, or commands
that mutate state. Application state is a computed model — the
stable model of a stratified Datalog program over the
observation log. There is no OrderAggregate.confirm() that
mutates an Order row. Instead, the relevant .dh rules derive
order_confirmed(order) whenever the supporting atom evidence is
present, with full provenance.
CLAUDE.md’s “Ontology-First Vocabulary” section is explicit on
this: workflows, aggregates, and bounded contexts are not
first-class primitives in JacqOS. Treating them as such collapses
the evidence and interpreted-fact planes that JacqOS keeps strictly
separate. The six durable planes — observation, blob ref, atom
batch, fact, intent, effect — are what
Atoms, Facts, Intents walks through.
The practical consequence is epistemic alignment for free.
Every agent that reads the same evaluator over the same lineage
sees the same worldview. There is no “this aggregate’s view of
the order” vs “that service’s view of the order”; the model is the
view, derived from a shared log.
Compliance and audit consequence: there is no hidden state. If
a developer cannot find it in observations, facts, intents, or
effects, it does not exist in the system. Guest code never mutates
a fact directly, never appends an observation directly, and never
takes an action without an explicit effect capability.
4. JacqOS vs plain LLM ReAct loops and agent-orchestration frameworks
Section titled “4. JacqOS vs plain LLM ReAct loops and agent-orchestration frameworks”Axes: containment relays vs prompt guardrails; shared derived reality vs orchestration graph.
A plain ReAct loop hands the model a tool list and a prompt and lets it observe-decide-act in one probabilistic pass. Frameworks like LangChain, AutoGen, and CrewAI add structure on top — graphs of agents passing messages, role prompts, system-prompt guardrails, output parsers — but the safety boundary is still behavioral. The model can talk past it.
JacqOS rejects this paradigm structurally. Per NORTH_STAR.md §6 (“LLMs as Tools, Not Drivers”), models feed two reserved namespaces:
candidate.*for fallible-sensor output — voice parsers, vision labels, LLM extractors. The Fallible Sensor Containment pattern shows the relay end to end.proposal.*for fallible-decider output — LLM-suggested actions like refunds, offers, remediations. The LLM Decision Containment pattern shows how an explicit domain decision rule must ratify a proposal before anyintent.*fires.
Any rule that derives an accepted fact or executable intent
directly from a fallible-tool observation is a hard load error.
This is not a convention, a lint, or a guardrail. It is enforced by
validate_relay_boundaries in the jacqos validator, keyed on
mapper predicate configuration rather than on observation class
strings.
The orchestration story is also different. JacqOS agents do not
message each other, do not share an orchestration graph, and do not
participate in a ReAct loop. They coordinate stigmergically by
reading the same observation log and emitting intent records
against the same ontology. Adding a new agent does not require
rewiring existing ones. See the
multi-agent patterns guide for
the shared-reality coordination model in practice.
Compliance and audit consequence: prompt guardrails fail when the model is adversarial, hallucinating, or just unlucky. Structural containment cannot be talked out of — the rule that ratifies the candidate is the only path to fact, and the rule that ratifies the proposal is the only path to intent. There is no autonomous ReAct loop, no LLM-driven action selection, and no path from a model’s output to the world that bypasses the relay namespace.
What JacqOS deliberately does NOT do
Section titled “What JacqOS deliberately does NOT do”The contrasts above are not accidental. They are scope decisions spelled out in the project’s non-goals. A short, partial list:
- JacqOS is not a workflow orchestration engine — no DAG scheduling, no step retries, no saga compensation, no task-queue semantics.
- JacqOS does not encode truth in workflow graphs or aggregate roots — application state is a computed model derived from an immutable observation log.
- JacqOS does not autopilot LLMs through ReAct loops — every
model output flows through the
candidate.*orproposal.*relay namespace and the ontology must explicitly ratify it. - JacqOS does not provide a managed RAG or vector-search pipeline — facts are derived via stratified Datalog with provenance, not via similarity retrieval.
- JacqOS does not allow direct fact mutation by guest code — facts are derived; observations are the only write surface; effects are explicit and capability-gated.
- JacqOS does not coordinate agents through orchestration graphs — coordination is stigmergic through the shared derived model.
For the full enumeration with rationale, see the project’s
NORTH_STAR.md “Out of Scope” section.
When you might still want a workflow engine, RAG, DDD, or a ReAct loop
Section titled “When you might still want a workflow engine, RAG, DDD, or a ReAct loop”JacqOS is the right substrate when you need provenance, replay, and provable invariants over agent behavior. There are problems where you do not need that, and the comparison frameworks are excellent at theirs:
- A pure ETL pipeline with no agent reasoning is a fine fit for Airflow or Temporal.
- A read-only “chat with your docs” experience without strong audit requirements is a fine fit for an off-the-shelf RAG stack.
- A team with deep DDD muscle memory shipping a CRUD-shaped product without LLM involvement may not need any of the JacqOS apparatus.
- A throwaway prototype where probabilistic, hard-to-audit behavior is acceptable can use a plain ReAct loop.
JacqOS is opinionated because the alternatives have a price. What is JacqOS? lays out the positive case for that opinion; this page lays out what it costs you to disagree.
Where to read next
Section titled “Where to read next”- What is JacqOS? — the physics-engine framing for the platform as a whole
- Observation-First Thinking — the single pipeline that powers every contrast above
- Atoms, Facts, Intents — the six durable planes that keep evidence, derivation, and action separate
- Fallible Sensor Containment and LLM Decision Containment — the structural patterns that replace prompt guardrails
- Model-Theoretic Foundations — the formal account of the unifying axis
- Glossary — every JacqOS term in one place