Generated proposal
API REPAIR / STRUCTURAL CONTROLS
Untrusted generation.
Deterministic control.
For integration engineers fixing API clients that return HTTP 200 but silently lose or corrupt data. API Repair Bench puts NVIDIA Nemotron proposals through an enforced repair protocol: a bound contract, remote Nebius Sandbox checks and one correction maximum. The model cannot deploy a patch or extend its loop.
Propose → validate → execute remotely → compare → correct once → stop.
Try the pagination repair Watch the uninterrupted live demoFICTIONAL INCIDENT / REAL INTEGRATION FAILURE PATTERN
A successful request can still lose the next page.
The client returns the first page and stops. The repair must follow cursors, preserve duplicate rows, cross empty pages and stop a loop before another request.
- Broken client
- HTTP 200 · page one only
- Declared contract
- Every page, original order, duplicates preserved
- Review outcome
- Named checks, generated code and a downloadable record
NVIDIA NEMOTRON × NEBIUS SANDBOX
Inspect the failure. Review one correction.
Start with the recorded invoice attempt: four of nine checks passed. Open its one allowed correction to see what recovered. No new provider call is made.
September 11 · same-contract recovery
Five checks recovered. Zero check regressions. Both attempts remain available.
Original synthetic cases · Replay mode uses no model credits; the separate live workspace runs on Nebius · Candidate-runtime observations are not execution attestation. A changed contract is a new experiment, not proof of self-correction.
Review required
- 1Understand failure
- 2Inspect patch
- 3Review evidence
- 4Export
Baseline contract failed
A small change. An explicit contract.
BEFOREbroken implementation
PROPOSEDreviewed reference
Inspect the evidence, not just the answer.
Documented checks from the local reference fixture suite. These results do not represent a live model or remote sandbox run.
Execution boundary: only reviewed built-in reference functions were run locally. Candidate-generated code is never executed by this interface.
Know exactly what you are reviewing.
A transparent boundary between a useful demonstration and a production claim.
- Data origin
- Original fictional API fixtures
- Repair origin
- Human-reviewed reference implementation
- Execution evidence
- Local built-in fixture report
- Live model calls in this view
- None
- Deployment authority
- None — export for independent review
This desk demonstrates the workflow. Live generated repairs require separately verified provider access, isolated execution, and an evidence record bound to the exact candidate.
SAVED PROVIDER EVIDENCE
A separate record of live attempts.
Read published, sanitized receipts. This button never calls a model or executes a repair.
Not loaded. The reference examples above are independent of live provider results.
Attempt log
Saved results · inspection onlyInspect all attempts to inspect individual attempts.
Security features
Process isolation — remote execution, external comparison
Generated code runs in Nebius Sandbox, outside the website's control plane and the development machine. The comparison plan remains outside the candidate runtime.
The execution request supplies no inherited environment, requests disabled networking, and sets a 20-second runtime limit and 64 KiB limit per output stream.
Boundary: candidate and observation runner currently share a Python process inside Sandbox. Independent comparison is implemented; independently trusted observation is the next boundary to establish.
One correction. A finite repair protocol.
One initial proposal. At most one correction after a completed, bound failure. The same contract governs both attempts. A second failure terminates the loop; uncertain effects are not automatically repeated.
The application controls continuation, bounding iterative generation and token consumption. Attempt reservations constrain admission; they are not an account-wide billing guarantee.
Cryptographic binding. Evaluate the identified artifact.
SHA-256 digests identify the contract, proposal and uploaded files. Bundle snapshots, digest verification, upload byte counts and returned run identifiers reject payload changes and mismatched records at those checks.
A changed contract creates a different evaluation. Hash binding establishes artifact consistency; it does not authenticate candidate-reported behavior or attest execution.
Deterministic gates. Model confidence grants no authority.
Application code checks proposal schema, function name and signature, result structure and run binding. Incomplete, malformed or unbound execution results receive no passing verdict.
Passing declared checks permits review and export. Deployment remains a separate human decision.
Challenges and integrity
Failures are part of the evidence model. Failed checks, rejected proposals, truncated responses, uncertain executions and contract revisions retain distinct outcomes. An incomplete observation is never presented as a successful repair.
The September 11 recorded invoice run remains in the evidence archive with its 4/9 → 9/9 same-contract correction, including all four previously passing checks. The current 1:29 live browser demonstration follows two distinct October 13 first-proposal runs: identifier 3/3 and pagination 4/4. Neither needed a correction. The archived recovery and current video remain separate evidence; other failed and incomplete attempts remain in the technical record.
Recovery and measurement errors remain inspectable. A revised interface is a new evaluation, not evidence that a failed correction succeeded. Integrity comes from preserving those distinctions rather than selecting only successful demonstrations.
Next engineering gate: independently trusted observation
Repository-scale repair requires stronger execution and attestation boundaries. Separate candidate execution from the observation runner; restrict access to validation telemetry, comparison data and control credentials; and authenticate observation provenance independently of candidate output. Verify those boundaries with adversarial tests before expanding the agent's authority.
The current single-function protocol provides a controlled surface for establishing those guarantees. Passing checks remain evidence for the declared contract, not production approval.
Try the workflow without coaching.
Integration engineers: try the supplied pagination case, find the stopping reason and export the evidence. Tell us where you hesitated and whether the record would help your next code review.
Send workflow feedback · Read the short test guide
The examples are fictional. A structured external usability study has not yet been completed.