Hosted Evaluate · controlled free soak
Next availability check
Total soak elapsed

2026-09-16.beta2 · restricted access · x402 off · not GA
Selection is not execution. Offline kit: 2026-09-16.beta1 pinned teaching snapshot.

Hosted 2026-09-16.beta2 · controlled free soak

Hosted bounded review.
Selected or refused.

Send an objective, bounded context, and finite candidates to POST /v1/evaluations. Receive selected or governed_noop_refusal, reason codes, a reviewable trace, and false effect and authority flags. Selection is not execution.

  • Finite candidates
  • Gates before ranking
  • Select or refuse
  • Reviewable trace

Profile: deltax-hosted-bounded-review-evaluation-v1. Access is restricted; x402 is off; not GA.

Sealed teaching example · pinned beta1
What you send

Choose the next review step.

An objective, bounded context, and finite candidates.

A
Analyze missing evidenceanalyze · reported support 0.91
Selected
B
Publish outside the reviewexternal · reported support 0.99
Shadow-only

Gate summary: candidate catalog passed · no-effect boundary passed · trace commit passed.

{
  "outcome": "selected",
  "selected_candidate_id": "analyze-completeness",
  "submitted_candidate_executed": false,
  "external_effect": false,
  "response_authorizes_downstream_action": false
}

With only external candidates: governed_noop_refusal, a null selection, and the same false effect and authority flags.

The product in your workflow

Turn a proposal into
an inspectable next step.

Start with a bounded review assistant. Your agent proposes useful review steps; Evaluate checks the represented candidates against the fixed profile. Your application receives a result it can validate and route.

  1. 01 · Propose

    Make the alternatives explicit.

    For a document with incomplete evidence, offer candidates such as analyze the gaps, compare claims, draft questions, or validate the review. Supply the objective and bounded context.

  2. 02 · Evaluate

    Check eligibility before preference.

    The current profile admits supported review classes. An external-effect candidate stays shadow-only, even if it has the strongest reported support.

  3. 03 · Handle the result

    Continue a useful review—or stop.

    A selected result identifies a submitted review candidate. If no eligible path remains, the response is a governed refusal. Both carry reason codes and a trace.

  4. 04 · Continue the loop

    Bring changed conditions back.

    Your application handles the review step under its own authority and records the outcome. New evidence or candidates mean a new request; selection itself performs no action or learning.

Your integration point: after candidate generation, before the application handles a selected step. Model and orchestration choices stay with your team.

See the request and response contract
Optional architecture depthWhy the boundary holds and how the decision loop works
Why DeltaX

A clear answer needs
a visible boundary.

DeltaX keeps state, evidence, identity, authority, fallback, and result connected so developers can inspect why a path remained valid—or stopped being valid.

01

Keep the state boundary explicit

Represent what can change, what must persist, and which transition the system is evaluating now.

02

Keep evidence honest

Observed, reported, simulated, disputed, and missing facts keep different labels.

03

Separate access from authority

Authentication, candidate permission, selection, and execution remain different technical boundaries.

How it works

From possibility to a
reviewable result.

Pick a step to see what changes at each part of the path.

01 · Bound the decision

Start with one clear question, a finite set of possible next steps, and an explicit limit on what the system may affect.

What this producesA decision small enough to inspect.
Selection is not execution.

A DeltaX result identifies what happened inside the bounded evaluation. Any external effect requires its own current checks and separate authority.

Integration guide

One governed profile.
Zero execution authority.

Learn the protocol against one synthetic offline teaching scenario, then distinguish that pinned kit from the hosted runtime under controlled soak. Verify the kit, inspect the contract, and practice selected, refusal, and error handling without public signup or unrestricted credentials.

Read the integration guide
Optional data depthInspect the twelve architecture application fields
Dynamic systems atlas

Find the boundary
your system cannot lose.

DeltaX is intended for decisions where state moves, evidence conflicts, resources tighten, and an unlicensed transition can damage the system developers are trying to preserve.

Design target · not evidence of consequential fitness
Architecture application fieldsSix high-value developer starting points
Illustrative architecture mappingNo live profile

Which tool call remains valid after context, permissions, and tool state change?

AI agents & tool orchestration

Operating pressure
Conflicting instructions, prompt injection, stale retrieval, changing tools, and multi-agent handoffs can alter the decision faster than the plan updates.
Structure to preserve
Source provenance, finite candidate meanings, recipient and resource scope, tool permissions, and the separation between a model proposal and an effect.
DeltaX / API pattern
Represent respond, retrieve, clarify, defer, refuse, and tool-use paths as explicit candidates; apply hard scope and authority gates before preference.
Why this differs
A high-confidence model output stays a candidate. It cannot silently mint permission, broaden the task, or become an executed tool call.
Adversarial inputState driftDelegated action
First developer prototype

Replay a closed tool-routing case with one permitted local analysis, one stale retrieval, and one blocked external action.

Identity and authority boundary

The current API does not authenticate an AI-agent identity or invoke tools. Every effectful integration needs its own principal, delegation, target, and execution contract.

Architecture mapping only · hosted beta2 accepts bounded review candidates, not arbitrary tool execution.
Define the domain contract

No field-specific domain contract · no field-specific API profile · no field-specific runtime evidence · no authority

Twelve fields. Zero implied capabilities.

Each field needs its own versioned domain contract, adapter, tests, evidence, threat model, and explicit authority. These mappings do not inherit capability from another API version, Nyvera, Kairos, or another domain.

Optional concept exampleExplore gates in a synthetic failover illustration
Dynamic-state playground
No API request sent
Distributed service recovery

Should this failover path remain eligible?

Change the state. The decision structure stays fixed.

Change the facts
Blocked · structural next step

Refuse the effect path. API access alone cannot create recovery authority.

DeltaX field diagram showing evidence entering a bounded core and gated paths leaving it
01

BOUND
GATE
TRACE

The white paper

Version 2.0 technical draft · 26 September 2026

External evaluation
for candidate actions

External evaluation and control for candidate actions in synthetic intelligence systems.

The draft explains the control-plane architecture, the hosted Evaluate design snapshot, and evidence from a connectome-derived computational harness. It identifies demonstrated results, limitations, and open research questions.

Read the technical draft

Hosted Evaluate remains a restricted, allowlisted controlled free soak. This draft does not reproduce a live response body. Selection is not execution.

Important boundaries

Clear answers
before access.

A professional experience should make the service boundary easier to understand, not hide it behind polished language.

01Is DeltaX Evaluate live?

Hosted Evaluate is in controlled free soak (2026-09-16.beta2). Access is restricted, x402 is off, and it is not GA. Selection is not execution. The offline kit is the pinned 2026-09-16.beta1 teaching snapshot. There is no public signup, pricing, or SLA.

02Does DeltaX execute the task I describe?

No. Evaluate is a bounded evaluation interface. It can represent finite candidates, exclude ineligible options, and return a selected result or refusal with a reviewable trace. Selection never implies execution. External effects require their own declared and approved authority boundary.

03Does DeltaX authenticate an AI agent?

No. Hosted access uses OAuth 2.0 client_credentials with the deltax:evaluate scope for allowlisted, server-owned principals. That proves an admitted machine caller under server-owned state; it does not prove a human, device, workload, model, or agent identity, and a valid credential cannot become permission to execute a candidate. Public credential issuance is not offered.

04Does a trace prove the result is correct?

No. A reviewable trace helps reconstruct the recorded relation among the request, evidence, gates, result, and next bounded state. It does not prove every input was true or that the selected path was objectively best.

05Does DeltaX need to collect my data?

Hosted beta2 processes admitted requests under restricted access and returns reviewable traces. Submit only the bounded context required by the profile. The beta1 offline fixtures make no network request.

06Does restricted access mean automatically secure?

No. Controlled soak and allowlisting reduce unnecessary exposure, and the runtime rejects many dangerous input and effect paths, but host configuration, token handling, storage, encryption, backups, dependencies, and access policy still matter. Reviewable traces support reconstruction; they are not encryption, digital signatures, or certification.

Plan your integration

Give your next decision
an explicit contract.

Start with the offline kit to exercise selected results, refusals, and failure handling in your client. The hosted Evaluate runtime is under controlled soak with restricted access; it is not generally available.

Start with the developer kit