Datalox Gated Runtime

Stateful, resettable, verifiable API worlds for tool-using agents

Run long agent workflows against provider-shaped systems without giving the evaluated agent live provider write access.

Product thesis · Provider packs · Behavior grounding · Behavior harvest · Portable packages · World admission

Datalox sits between an agent and its tools. It decides what every call does, mutates resettable local state, records the execution, and verifies the final workflow.

Most tool benchmarks ask whether a model can answer a question or complete one API call. Real work is longer. It crosses roles and systems, creates related objects, waits for asynchronous jobs, encounters conflicts, and leaves durable state behind. A plausible final message does not prove that the workflow was correct.

Datalox provides the execution substrate for testing that work.

task
  -> agent calls HTTP or MCP tools normally
  -> Datalox gates every call
  -> replayed reads and local writes change resettable world state
  -> the ledger records decisions, responses, and side effects
  -> hidden verifiers judge the final state and workflow evidence
  -> the run becomes replayable evidence

What Datalox is—and is not

The vocabulary is deliberate:

• Fuel is a reusable gated provider/API building block: operation contracts, behavior recipes, transitions, verifier atoms, provenance, and known gaps.

• A world composes fuel into a stateful environment with roles, tasks, reset, dynamics, and hidden verification.

• A benchmark consumes worlds to evaluate agents.

Fuel is not a benchmark. A provider pack is not automatically a complete world. World admission is not automatically proof of provider equivalence.

Related MCP server: Enterprise MCP Gateway and Tool Registry

Provider-shaped surfaces already represented

The current inventory spans infrastructure, business operations, healthcare, science, and other specialized systems. Every tile below links to a public probe declaration or grounding contract that can be inspected in this repository.

Infrastructure and observability

Business operations

Healthcare, science, and specialized operations

Presence in this grid means that a provider or project is represented by a probe, connector, capture path, pack, or world input. It does not mean that every core operation is implemented, provider writes were observed, provider data is publicly redistributed, or a local world is production-equivalent. Those are separate, checked claims described in Provider Core Completeness and Provider Behavior Grounding.

Provider names and logos belong to their respective owners and do not imply affiliation or endorsement. Brand icons are served by Simple Icons; neutral specialized-domain tiles in docs/assets/provider-tiles/ are self-authored and are not official provider logos.

What is open source

The Apache-2.0 release contains:

• the HTTP and MCP gating runtime;

• policy, replay, shadow-state, denial, ledger, and audit primitives;

• versioned provider-pack, behavior-recipe, and world-bundle contracts;

• validators, compilers, admission checks, and verifier composition;

• public probe declarations and capture utilities;

• a fully synthetic, stateful commerce reference world; and

• a deterministic public-source builder and release gate.

Raw provider responses, credentials, tenant identifiers, sandbox transcripts, and compiled provider behavior programs are not automatically open data. They remain excluded unless each artifact has an explicit redistribution basis and passes the public-data gate. Open source users can capture and compile their own authorized provider packs without publishing those payloads.

See Data Release Policy for the exact boundary.

What happens on every tool call

The runtime makes one explicit decision:

Live provider writes are intentionally inexpressible in the runtime. Approved sandbox writes belong to a separate, manually authorized behavior-authoring process against an exact test account.

Try a complete world offline

Requirements: Python 3.11 or newer. No provider account, API key, network connection, or model is required.

git clone https://github.com/Oshawott324/datalox-gated-runtime.git
cd datalox-gated-runtime
python -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev]'
python scripts/demo/offline-world-smoke.py

The demo does more than ping an endpoint. It:

1. creates a fresh commerce-operations world;

2. discovers role-scoped provider-shaped tools;

3. reads initial state;

4. performs a multi-step workflow containing real local mutations;

5. verifies the final state and workflow evidence;

6. destroys and resets the world;

7. proves equivalent capabilities, observations, and initial state; and

8. replays the workflow and proves an equivalent final export.

It exits nonzero if mutation, verification, functional reset, or replay equivalence fails.

Build a provider-grounded world

The default workflow is sandbox-first:

audit official sandbox or disposable reference system
  -> declare the smallest complete operation-family scope
  -> execute reviewed behavior recipes outside the runtime
  -> capture before / write / duplicate / failure / after evidence
  -> compile the evidenced slice into reusable fuel
  -> compose fuel into a resettable world
  -> verify state, failures, reset, and known gaps

Do not rebuild a provider sandbox merely to increase a provider count. Local reimplementation is justified when a concrete requirement needs offline scale, deterministic reset, parallelism, missing sandbox behavior, controllable failures, lower cost, or a distributable partner environment.

Start with Provider Packs, then read Provider Behavior Grounding and World Admission Rubric.

The portable construction path is provider-neutral. Current depth work applies the same authoring, compilation, differential, reset, admission, OCI, HUD, and Harbor contracts to specialized operational systems instead of treating one well-built commercial sandbox as the product. The checked provider-by-provider status and exact claim boundaries are summarized in Provider Behavior Grounding.

Repository map

Develop and verify

With the locked uv environment:

uv sync --frozen --extra dev
uv run pytest -q
uv run ruff check . --select E4,E7,E9,F

Build and verify the exact public tree:

uv run python scripts/public_release.py check
uv run python scripts/public_release.py build --out .tmp/public-source
uv run python scripts/public_release.py verify-built --source .tmp/public-source

The release gate fails closed on unclassified data, missing or changed digests, private machine paths, unresolved public documentation links, unexpected files, test failures, formatting failures, or package-build failures.

Current status

Datalox currently proves deterministic gated execution, stateful local worlds, functional reset, replayable evidence, and verifier-driven evaluation. It does not claim that every represented provider is core-complete or behaviorally equivalent to production.

The project is early. The most valuable contributions are complete behavior programs, stronger reset and failure evidence, reusable verifier atoms, and well-scoped worlds—not raw endpoint count.

Contributing, security, and governance

Read CONTRIBUTING.md before submitting code or provider material. Do not put credentials, tenant data, provider payloads, or sandbox write transcripts in a public issue or pull request.

Security reports follow SECURITY.md. Project decisions and release authority are described in GOVERNANCE.md, and support channels are described in SUPPORT.md.

Licensed under the Apache License 2.0.