AI Agents guaranteed
not to break your
business rules

JacqOS puts a mathematical boundary between AI reasoning and real-world action. Agents reason freely inside a secure inner world — but only actions that satisfy your declared invariants for the current evaluator can reach the outside.

See a blocked action Read the docs Talk to us

jacqos.studio / blocked-action-receipt 01/04

Failure modes · 01

Most agent stacks break in the same four places.

Four expensive failure modes show up in almost every agent deployment. They're not prompt problems — they're structural gaps between reasoning and action. Start here, then inspect the boundary that closes each one.

Unsafe actions

A wrong answer becomes a wrong promise, refund, payout, or mutation that reaches the real world.

Pilot purgatory

The demo looks plausible but nobody can explain how to trust the thing in production.

Hidden state

Graphs and scratchpads become the truth surface instead of one explicit derived reality.

No evidence story

Without replay, provenance, and fixtures buyers get claims instead of evidence.

The analogy · 02

A physics engine
for your business logic.

Game engines don't let players pass through solid walls — not because the game politely asks, but because the simulation refuses to produce that state. Physics holds.

JacqOS does the same for enterprise action. Your policies, authorities, and invariants are the laws of the world. Every proposed action is tested against them before it can leave the simulation. Violations don't happen — they can't.

Rigid bodies

⇌

Agents, users, services

Forces

⇌

Proposed actions

Collision constraints

⇌

Policies & authorities

Laws of physics

⇌

Named invariants

The paradigm · 03

The AI stack,
re-imagined.

Today's agent stacks treat observability as a footnote and memory as a database you bolt on. JacqOS puts the immutable log at the foundation, turns memory into a derivation from that record, and fuses security with the domain ontology — so the boundary is the architecture, not a wrapper around it.

Most agent stacks today Built on sand The log is an afterthought. Memory is a service. Guardrails are scattered across multiple surfaces, fallable LLMs are treated as the brain.

Memory

bolted-on vector store

Agent Orchestration

graphs, loops, retries

Tools / Function Calls

raw capability to act

LLM

probabilistic reasoning

Guardrails

text filters, prompts, DB rules, DDD aggregates

Logs / Traces

observability, after the fact

no durable ground truth · every layer re-invents state

JacqOS Built on bedrock The log is the foundation. Everything else derives from it with a structural invariant boundary. The guarantee is bounded by the current evaluator and lineage, not delegated to prompt policy.

Agents & Tools

LLMs treated as sensors/tools rather than the brain

Memory

derived from the record, not stored

Ontology + Authorities

who may do what, to what

Invariants (the boundary)

named laws — violations cannot execute

Derivation

facts computed from observations

Immutable Observation Log

append-only. single source of truth.

one record · replayable · signed · ground truth for the entire system

→

Observability isn't a sidecar.

The immutable log is the system's substrate. Traces, audits, and replay all fall out of it for free.

→

Memory is derived, not stored.

What the system "remembers" is whatever the current observations imply — never a stale cache, never a dangling vector.

→

Security lives in the ontology.

Authorities and invariants are part of the domain model, not a middleware layer. The rules engineering ships are the rules risk reads.

The boundary · 04

Five primitives.
One provable boundary.

Observations go in. Facts derive. Agent proposals get checked. Only transitions that satisfy your declared invariants reach real systems — and the whole thing replays.

Observe

Every input — a customer message, a tool response, an effect receipt — is recorded as an append-only observation.

A new support message arrives → it becomes part of the permanent record.

Derive

Policies, approvals, and operational state are computed from the record with plain logical rules.

If the cited policy exists, and the timing matches, then this refund is eligible.

Propose

The model can only suggest. Anything it generates stays a proposal — never a real-world action — until the domain accepts it.

The agent drafts a refund → the refund is a proposal, not a payment.

Check

Every proposal is tested against named invariants. If the invariant isn’t satisfied, the action cannot execute.

If a refund is proposed and it is not eligible, then the action is blocked.

Replay

The same sequence of observations always produces the same derived world — every block, approval, and effect, reproducible on demand.

Same observations in → same decisions out. Every time.

The guarantee

For a fixed evaluator and lineage, an action that violates a named invariant cannot execute — not because the model was asked nicely, but because the transition is structurally unsatisfiable in the ontology layer.

Blocked transitions don't just fail — they produce an inspectable receipt showing the proposal, the derived facts, and the invariant that refused it. Every receipt is replayable.

The rules · 05

Rules your risk team can actually read.

Policies, authorities, and invariants live as plain logical statements — not hidden prompts, not buried middleware. Legal, security, and engineering read the same rules. The dream of BDD, upgraded for the AI-era.

Observation

A refund policy is published on 2026-01-12.

Recorded — never edited, never forgotten.

Derived rule

If the customer cites a policy, and that policy exists, and the timing matches — then the refund is eligible.

Computed from observations. No magic.

Invariant

No refund may be issued unless it is eligible under a real, cited policy.

The boundary. A violating action cannot execute.

Authority

Tier-1 support may propose refunds and messages. It may send messages. It may not commit refunds alone.

Each agent's blast radius, declared up front.

Decision

A refund is ratified only when it is eligible and a human has approved it.

Only an explicit decision lifts a proposal into an action.

Effect

Once ratified, the refund executes — and the payment processor's receipt becomes a new observation.

The loop closes. Everything is replayable.

Authorship & audit · 06

Authored by AI, audited by humans.

JacqOS systems are written by AI coding agents; humans review the surfaces that actually matter — BDD-style scenarios and invariants. Rust, Datalog, and decades of logic programming do the heavy lifting. Logic programming is the most powerful piece of the puzzle — AI models already speak Datalog fluently.

Authorship

AI coding agents write the system.

Agents generate .dh ontology rules and Rhai mappers — a stratified Datalog surface and a sandboxed scripting language that LLMs already handle well. No hand-written Rust, no hidden prompts, no bespoke DSL to learn.

Built on Rust, authored in Datalog.

Pre-deployment review

Humans review invariants and fixtures.

Before anything ships, you review two things: named invariants — your business rules as plain logical statements — and golden fixtures — BDD-style scenarios that replay behavior deterministically. You never read line-by-line generated code.

The review surface humans actually own.

Post-deployment audit

Studio makes production inspectable.

Every production deployment gets Studio: replayable observability, provenance, and audit evidence. Trace any blocked action or derived fact back to the exact observations that caused it. Replay a recorded lineage. Export artifacts your risk team can inspect.

Observability · provenance · auditability.

Your week · 07

What changes in your week.

JacqOS doesn't just change what the system does. It changes what you spend your time on — on both sides of the shipping line.

01 Developer building the agent

Before JacqOS

✗ Prompt-engineer a scenario, hope the demo holds in front of real users.
✗ Bolt on a new filter every time the agent surprises you in production.
✗ Debug regressions by tailing logs at 2am and guessing what the model saw.

With JacqOS

✓ Write a rule. Add a fixture. See the replay. Ship it.
✓ Invariants refuse the action at the boundary — no retry loop, no patchwork filter.
✓ Click backward through provenance to the exact observation that derived the fact.

02 Risk, security, or compliance reviewer

Before JacqOS

✗ Audit by spot-checking traces the engineering team hands you after the fact.
✗ Take engineering's word on what the AI “won't” do in production.
✗ Write a coverage checklist that's stale the day a new prompt ships.

With JacqOS

✓ Read one file of named invariants — the full set of rules the agent cannot cross.
✓ Run the fixtures yourself. Get deterministic pass/fail on every covered path.
✓ Sign a verification bundle that replays on any machine, at any time.