Analyze missing evidenceanalyze · reported support 0.91
SelectedHosted 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.
What you send
Choose the next review step.
An objective, bounded context, and finite candidates.
Publish outside the reviewexternal · reported support 0.99
Shadow-onlyGate 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 workflowTurn a proposal into
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 contractDelivery maturity
Operational soak, offline kit, and unresolved stay separate.
The hosted controlled-soak runtime, the pinned offline developer kit, and future public-access work are three different claims with three different authority boundaries.
- Current
Hosted controlled free soak
2026-09-16.beta2
A controlled free soak of the hosted evaluation runtime with restricted, allowlisted access.
- Call
POST /v1/evaluations- Caller check
- OAuth 2.0 client_credentials ·
deltax:evaluate - Decision evidence
- Reviewable trace · selection never implies execution
- Pinned offline kit
Frozen developer contract snapshot
2026-09-16.beta1
- Wire snapshot
- Offline OpenAPI · fixtures · fail-closed client
- Profile and auth
- One fixed profile · OAuth client-credentials design shape
- Availability
- Historical/pinned kit · not the live soak version
- Unresolved future
Public access, GA, and commercial activation
A successor must separately authorize anything beyond restricted soak access.
- Public credential issuance and unrestricted customer access
- General availability, SLA, and broader identity lifecycle
- Paid/customer x402 admission (disabled during soak)
Separate approval required
Optional architecture depthWhy the boundary holds and how the decision loop works+
Why DeltaXA clear answer needs
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.
How it worksFrom possibility to a
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.
Optional data depthInspect the twelve architecture application fields+
Dynamic systems atlasFind the boundary
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 fitnessArchitecture 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.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+
Distributed service recovery
Should this failover path remain eligible?
Change the state. The decision structure stays fixed.
Blocked · structural next step
Refuse the effect path. API access alone cannot create recovery authority.
HistoricalLocal v0.1 · 29 Jul 2026 capture, authentication, and privacy notes+
Historical · local v0.1 reference captureWatch a bounded request become
Watch a bounded request become
an inspectable result.
This historical capture records local v0.1 on 29 July 2026. Its loopback boundary and /v1/evaluate route describe that prototype. Today, hosted beta2 uses POST /v1/evaluations in restricted controlled free soak.
02Captured request
Captured evaluation request
Schema 1.0One closed, bounded objective
Closed objective profile
Bounded local evidence review · desired external effect: none
Caller authenticationConfigured local bearer possession verified
authentication ≠ candidate authorityAnalyze bounded local informationPriority 0.60 · no state change
SubmittedRequest an external actionPriority 1.00 · consequential effect
SubmittedBoth candidates enter the captured request. Their submitted order and priority do not determine eligibility.
03Gate result
Protected decision boundary
Eligible set · 1Gate before preference
External action excluded
Not permittedExternal and consequential effects remain outside the evaluation domain.
Local analysis admitted
PermittedAll local, nonconsequential gates passed.
Licensed no-op fallback available
AvailableThe licensed no-op remained available but was not selected.
04Result
Captured evaluation result
200 · selectedSelect from the eligible set—or refuse
- Disposition
- selected
- Selected action
- analyze
- External effect
- false
- Execution authority
- false
Selection is review material, not execution. The external candidate was represented and excluded; the response records the eligible local result without causing an effect.
05Trace
Captured trace summary
runtime + auditConnect the result back to the request
runtime_trace
identifier omittedChecked locallyaudit_trace
identifier omittedChecked locallyrequest_anchor
fingerprint omittedChecked locallyexternal_effect
falseclaim_ceiling
private local simulated evaluation onlyThis public-safe summary reports the result and integrity-check outcome without publishing trace identifiers.
Result200selected
Health snapshot200status OK
Trace checks2runtime + audit verified
External effects0authority remains false
Secondary implementation evidenceInspect the point-in-time health and integrity sample+
Point-in-time local sample
VerifiedIntegrity-aware health
01020304
- Service state
- OK
- HTTP status
- 200
- Network boundary
- Loopback only
- Deployment authority
- False
This short capture records one local point-in-time health check. It is not continuous uptime monitoring or a production SLA.
Integrity language matters. Version 0.1 creates content-addressed, hash-linked trace packets; it does not yet apply a private-key digital signature. Candidate identifiers, credentials, private paths, and the raw packet are omitted here. This hosted replay sends no request and does not represent production uptime, public availability, or deployment authority. Inspect the public evidence summary.
Authentication for AI systemsA valid key can open the question.
A valid key can open the question.
It cannot authorize the answer.
AI systems often collapse “has a credential” into “may use a tool.” DeltaX keeps caller proof, identity, delegation, candidate permission, effect authority, freshness, and trace as separate links.
Historical local v0.1 evidence · hosted beta2 uses OAuth client credentialsCredential modelOne shared local bearer
Authorization headerExactly one
Failure responseGeneric 401
Implicit promotion to authorityNever
Historical v0.1
Prove possession—not identity.
POST /v1/evaluate requires exactly one bearer header. The configured secret is at least 32 bytes, compared in constant time, and missing or wrong values receive the same generic 401 before the body is evaluated.
What must remain true
The bearer proves possession of one shared local secret. It does not prove which human, device, organization, model, or agent is calling.
one local bearer · constant-time · generic 401Historical v0.1 is not a complete AI identity system.
It has no per-user, device, workload, or agent principals; no OAuth/OIDC, mTLS, MFA, scoped short-lived credentials, bearer lifecycle service, signed delegation, multi-tenant isolation, cryptographic origin signature, or production IAM claim. Those controls require a separately designed and tested successor.
Historical · local v0.1 privacyYour decision data
Your decision data
can stay with you.
The historical local v0.1 evaluator can process its bounded request without sending the contents to DeltaX or a third-party cloud. Provider-operated data collection is not required for the evaluation path.
Historical local v0.1 evidence · not the hosted beta2 data pathProvider collectionNot required
Server egressNone in tested v0.1
External authorityFalse
Local audit trailRequired
Historical mechanism
The request stays on the local machine.
Version 0.1 listens only on 127.0.0.1, and the tested path makes no server-initiated external network call. Evaluation does not require a DeltaX-operated data service or remote model provider.
Why it matters
Less decision content has to cross systems, reducing the exposure that must be managed elsewhere.
127.0.0.1 · no host option · outbound network falseData-minimizing does not mean data-free.
The operator’s machine keeps a private, redacted central audit and a typed runtime trace so decisions can be reconstructed. Local-first reduces exposure; it does not replace host security, access control, encryption, backups, retention and deletion policy, monitoring, or incident response. Hash linkage is not secrecy, a digital signature, or a security certification.
01
BOUND
GATE
TRACE
The white paperFrom Possibility to
Public architecture document · 2026
From Possibility to
Governed Consequence
A bounded navigation architecture for evidence-aware, recoverable, and traceable adaptive systems.
Read the conceptual foundation behind DeltaX: why evidence, permission, selection, execution, and consequence should remain distinct—and how refusal and recovery fit into the architecture.
Read the white paperExplanatory and non-normative. The paper does not authorize publication, deployment, or external action.
Important boundariesClear answers
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. Historical loopback privacy notes describe local v0.1, not the hosted service.
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