Datalox Gated Runtime

Provider-grounded API behavior on the agent's normal call path

Let an agent call the provider's real URL while an isolated Datalox runtime returns stateful simulated behavior without contacting that provider.

Product thesis · Provider packs · Provider foundry · Transparent interception · Delivery interventions · Rollout information boundary · Behavior grounding · Differential and drift · Async provider proof · Behavior harvest · Container injection · veRL / GRPO · THUDM/slime · Runtime schema · Identity schema

The user owns the task, world, agent, verifier, and reward. Datalox supplies resettable provider behavior underneath the API URLs their agent already uses.

During a rollout, the agent starts with the task objective and visible constraints. Provider responses and environment anomalies appear only after the causal interaction that reveals them. Evaluation ground truth remains in trusted generator, oracle, and verifier code.

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 provider-behavior substrate for testing that work.

user-owned world/task/verifier
  -> agent calls https://api.provider.example normally
  -> isolated DNS/TLS routes that authority to Datalox
  -> provider-native credentials select a declared simulated principal
  -> Datalox returns provider-shaped reads, writes, failures, and state changes
  -> the ledger records decisions, responses, and side effects
  -> the user's harness judges the run

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 is owned by the consumer and composes fuel with its tasks, dynamics, verifier, and reward.

• A benchmark is a downstream consumer-owned evaluation.

Fuel is not a benchmark. Datalox reference worlds are integration fixtures, not the primary product. World admission is not automatically proof of provider equivalence.

Fuel has two explicit composition levels:

• A Provider Set co-hosts independently admitted provider releases. The evaluated agent may read one provider and explicitly call another.

• An admitted Composition Pack supplies observed provider-mediated behavior such as webhooks, transforms, delays, retries, ordering, idempotency, partial failure, and compensation. Merely placing providers together never creates those hidden causal edges.

See Provider Foundry and Composition Contract.

Related MCP server: Schema Sentinel

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 provider-runtime contracts;

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

• public probe declarations and capture utilities;

• synthetic reference fixtures for interoperability and regression; 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:

All live provider access is inexpressible in evaluated-agent execution. Approved sandbox reads and writes belong to a separate, manually authorized behavior-authoring process against an exact test account.

For stateful packs, identity is also provider-shaped. A fixed single-principal policy or an explicit mapping from provider-native credential commitments to declared roles lives in the runtime bundle. Agent requests containing internal x-datalox-* control headers are rejected; credentials are consumed at the boundary and excluded from behavior evidence.

For controlled robustness experiments, a consumer may add a switchable seeded delivery intervention around an admitted provider operation. V1 keeps its read-response transformations. V2 can hold an admitted read or write before dispatch, or dispatch it exactly once and send zero HTTP response bytes so the client observes unknown completion. The provider ledger remains the grounded base record; a separate durable trace records the counterfactual or applied intervention. Datalox applies the consumer-owned policy without choosing its distribution, retrying, or normalizing its output.

Verify the transparent runtime offline

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

Core HTTP/MCP gating and offline world execution are package-smoked on Linux, macOS, and Windows. Secure composition event storage, transparent interception control sockets, and rollout-pool serving currently require a POSIX host; use a Linux container for those execution paths on Windows hosts. Unsupported composition storage fails before creating session files with the stable code session_event_platform_unsupported.

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 -m pytest -q \
  tests/test_interception_tls.py \
  tests/test_provider_runtime_bundle.py \
  tests/test_interception_deployment.py

These checks exercise the actual provider-runtime entry point. They:

1. compile a task-free behavior bundle from existing stateful behavior;

2. start a real TLS listener for an exact provider authority;

3. call the unchanged https://provider-authority/... URL;

4. perform a local write and read the resulting state;

5. export and reset through a controller-only Unix socket;

6. prove that the agent cannot reach control paths or read controller secrets;

7. generate Docker and Kubernetes injection artifacts; and

8. keep the provider runtime free of tasks, verifiers, rewards, and upstream clients.

Tenant depth is a separate admitted artifact. A Provider State Profile binds one exact, task-independent reset seed to its provenance, rights, lifecycle coverage, relationships, pagination, mutation probes, and reset-equivalence evidence. It stays in the provider's native state shape and is selected by the operator, never by the model.

For the full build and injection commands, see Transparent Interception.

Use provider packs in veRL / GRPO

Current veRL users can keep their normal V1 ToolAgentLoop, function tools, dataset, rewards, and GRPO command. Datalox wraps each (uid, session_id) rollout sibling with a private reset provider state and workspace. Provider tools still call the exact provider HTTPS URL; a trusted node-local pool runs those calls inside the sibling's internal Docker network.

datalox-gate rollout provider-set \
  --bundle /opt/datalox/providers/provider-a \
  --out /opt/datalox/rollout-providers.json

datalox-gate rollout pool-serve \
  --provider-set /opt/datalox/rollout-providers.json \
  --runtime-image datalox-gated-runtime:local \
  --task-image datalox-verl-provider-call:example \
  --capacity 64 \
  --artifacts-root /var/lib/datalox/rollouts \
  --socket /run/datalox/rollout-pool.sock

For admitted behavior across multiple providers, use rollout pool-serve-composition with a registry-backed Provider Set v2, Composition Pack, composition admission, fixed episode seed, and fixed initial delivery-scheduler time. It serves the same pool socket, so the veRL agent-loop YAML, function tools, GRPO launch command, and AgentLoopOutput do not change. The model and dataset cannot choose those operator-owned composition inputs.

The adapter returns veRL's original AgentLoopOutput object unchanged. See the checked veRL and GRPO rollout integration for the agent-loop YAML, @function_tool example, task image, dataset fields, launch fragment, isolation contract, and verification commands.

Current THUDM/slime users can keep the normal --custom-generate-function-path, --custom-rm-path, and --custom-config-path workflow. One provider-state lease surrounds the user's original custom-generation call; Sample or list[Sample] outputs and reward semantics remain owned by slime and the user. See the checked THUDM/slime integration and its boundary-safe provider callback, dispatcher image, configuration, and launch fragment under integrations/slime/.

Build provider behavior for your 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
  -> compile an authority-bound provider runtime bundle
  -> inject that bundle into the consumer's isolated world
  -> let the consumer 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 Transparent Interception.

The portable construction path is provider-neutral. Current depth work applies the same authoring, compilation, differential, reset, provider-runtime, and container-injection contracts to specialized operational systems instead of treating one well-built commercial sandbox as the product. HUD, Harbor, OpenEnv, and custom harnesses remain downstream owners of their worlds. The checked provider-by-provider status and exact claim boundaries are summarized in Provider Behavior Grounding.

Measure faithfulness and drift

The evaluated-agent runtime never contacts providers. A separate datalox-author executable runs a reviewed behavior recipe against an authorized sandbox, simulator, or disposable reference service. It emits a sanitized capture, a portable behavior program, and a grounding measurement bound to their exact bytes plus the connector, recipe, and frozen harvest engine.

datalox-gate provider differential runs that program against one immutable Provider Release profile three times: initially, after resetting the mutated instance, and in a newly materialized instance. provider drift compare compares a later authorized acquisition; provider drift assess separates provider change from replica mismatch; and the append-only assessment registry derives freshness at a trusted time.

This is program-scoped evidence, not a provider-wide label. The retained OpenLMIS contact-update program is the first restricted real-write checkpoint that passes the immutable-release differential and both reset-equivalence checks. See Provider Differential and Drift for the contracts and complete command sequence.

For harnesses that consume native MCP servers, the same provider runtime can be projected without rewriting provider behavior. The EnvFactory adapter emits its native tool, metadata, scenario, and config paths and includes a pinned patch for state-isolated pass@k execution. See EnvFactory Provider Adapter.

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 exact-authority TLS interception, zero runtime provider clients, task-free provider bundle compilation, stateful local behavior, controller-only reset/export, Docker/Kubernetes injection, digest-bound behavior acquisition, three-run immutable-release differential execution, and append-only drift assessment. All 48 registered provider-scoped assets pass compilation and reset under this contract; that does not mean all 48 are core-complete, writable, or behaviorally equivalent to the provider. Only an individual complete behavior program with a passing differential attestation earns that bounded claim. The exact structural result is in docs/reports/provider-runtime-coverage.json. Public checkouts can validate that report with python scripts/check_provider_runtime_coverage.py --validate-report; the full controlled source superset uses --check to recompile every underlying asset.

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.