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.
Choose the next review step.
An objective, bounded context, and finite candidates.
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.
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.
- 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.
- 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.
- 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.
- 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 contractOptional architecture depthWhy the boundary holds and how the decision loop works+
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.
Keep the state boundary explicit
Represent what can change, what must persist, and which transition the system is evaluating now.
Keep evidence honest
Observed, reported, simulated, disputed, and missing facts keep different labels.
Separate access from authority
Authentication, candidate permission, selection, and execution remain different technical boundaries.
From possibility to a
reviewable result.
Pick a step to see what changes at each part of the path.
Start with one clear question, a finite set of possible next steps, and an explicit limit on what the system may affect.
A DeltaX result identifies what happened inside the bounded evaluation. Any external effect requires its own current checks and separate authority.
Optional data depthInspect the twelve architecture application fields+
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 fitnessWhich 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.
Replay a closed tool-routing case with one permitted local analysis, one stale retrieval, and one blocked external action.
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.No field-specific domain contract · no field-specific API profile · no field-specific runtime evidence · no authority
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+
Should this failover path remain eligible?
Change the state. The decision structure stays fixed.
Refuse the effect path. API access alone cannot create recovery authority.

BOUND
GATE
TRACE
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 draftHosted Evaluate remains a restricted, allowlisted controlled free soak. This draft does not reproduce a live response body. Selection is not execution.
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.
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