Unsafe transitions are blocked before execution.
Named invariants are checked after each fixed point and before any real-world effect executes. The system blocks violating actions instead of logging them after the damage.
Trust
What JacqOS guarantees, what it does not, and what you can verify yourself.
Start here if you need the plain-language version of the boundary: what JacqOS guarantees, what your team still owns, and where to inspect the evidence behind both.
Guarantees
The boundary JacqOS actually gives you.
These are structural properties of a fixed evaluator over a finite, ordered lineage, not promises that depend on the model "behaving."
Facts and intents keep provenance.
Every derived fact and intent traces back to the observations that produced it, which is what makes zero-code debugging and audit review possible.
Replay is deterministic from observations.
The append-only observation log is the truth surface. Replaying a lineage from recorded observations reproduces the same derived state.
Authority boundaries stay explicit.
Model output may inform candidate facts or proposed actions, but the ontology decides whether those suggestions become accepted truth or executable intent.
Declared capabilities bound external actions.
Effects only use declared capabilities. Ambient I/O and undeclared mutations are not part of the execution model.
Non-guarantees
What this boundary does not magically solve.
- JacqOS does not make bad domain rules safe. If you encode the wrong policy, the system will enforce the wrong policy consistently.
- JacqOS does not replace human review where your workflow still requires acceptance, approval, or escalation.
- JacqOS does not claim every use case should be built this way. Low-stakes exploration may not need this level of rigor.
Shared responsibility
What the platform does, and what your team still owns.
- JacqOS owns the execution model: replay, provenance, invariant-satisfaction checks, and capability boundaries.
- Your team owns the ontology, the invariants, the fixture corpus, and the real-world authority model you want enforced.
- Trust comes from both: a strong platform boundary plus a well-specified domain contract.
Verification bundle
The artifacts behind the trust story.
The trust surface is strongest when the artifacts are concrete and inspectable. This is the handoff point between marketing and docs.
Golden fixtures
Deterministic scenario timelines with expected outcomes.
Replay receipts
Reconstruct what happened from recorded observations on a clean system.
Provenance views
Trace a bad outcome back to the exact observation or review step that produced it.
Proof surfaces
Keep the trust page connected to evidence.
Decision-makers rarely want raw internals first, but they do want to know that the evidence exists and is inspectable.
Proof surface Examples
Browse proof-first examples by failure mode and by industry.
Explore → Proof surface Studio TrackSee the human review loop built around invariants, fixtures, replay, and provenance.
Explore → Proof surface TrustRead the guarantees, limits, and verification surfaces in plain language.
Explore → Proof surface Studio DemoRun the deterministic bundled demo before you write any app code.
Explore → Proof surface Verification BundleInspect the artifacts JacqOS exports for review, replay, and audit.
Explore →Next step
Use trust as the bridge into evaluation.
Once the guarantees and limits are clear, the next job is practical: run the demo, inspect a blocked action, open the verification output, and decide if the fit is real.