Evidence-driven software maintenance

Software keeps changing
after you ship.

For platform teams maintaining API- and SDK-heavy systems, Refresh watches the world around your code, researches what changed, proposes the smallest safe repair, and proves it before a human decides.

✓ Source-grounded✓ Candidate isolated✓ Human-controlled
extraction-service / repair Recorded live run
↻
External contract changedTavily Extract can return mixed outcomes
JUST NOW
FINAL DECISIONLoading evidence…

The repair is proven; trust controls determine whether it can advance.

→

External changebecomesgrounded repairbecomesverified decision

The product in 30 seconds

One agent. Five accountable moves.

Refresh does not guess from stale model memory. Every repair starts with current evidence and ends with a result a maintainer can audit.

01

Detect

A provider contract, SDK, or platform behavior changes outside your repository.

INPUT · EXTERNAL SIGNAL
02

Research

Tavily finds and extracts the current official source. Refresh preserves the citation and hash.

GROUNDING · TAVILY
03

Repair

NVIDIA Nemotron reasons over the source and proposes one bounded code change through Nebius.

REASONING · NVIDIA + NEBIUS
04

Prove

The baseline reproduces the gap. A disposable runner challenges the candidate against old and new checks.

EVALUATION · TRUSTED RUNNER
05

Decide

The maintainer receives the patch, provenance, test delta, and any unresolved safety limits.

OUTPUT · HUMAN REVIEW

Why Refresh is different

The change starts
outside your repo.

Dependency tools watch versions. Coding copilots wait for prompts. Refresh starts with current external evidence, turns it into a behavioral check, and makes the repair prove it understood the change.

DEPENDENCY TOOLSWatch packages

Excellent when a version moves. Less useful when a documented API contract changes without one.

CODING COPILOTSAnswer prompts

Useful after a developer identifies the problem. The diagnosis and proof still begin with the human.

REFRESHStarts with evidence

Current source → grounded claim → regression check → bounded repair → verified decision.

A real repair, not a mock-up

Follow the evidence.

This walkthrough replays a verified live run. Choose a stage to see what entered, what Refresh produced, and why it mattered.

INPUT · EXTERNAL CHANGE VERIFIED RUN
01 / 05

The API succeeded—and still lost data.

The seeded adapter treated HTTP 200 plus one successful item as total success, silently discarding failed URLs from the same response.

BEFORE · RESPONSE PATHGAP FOUND

The important difference

Refresh does not stop at
“the patch looks right.”

It makes the failure visible first, then proves the candidate against the same behavior. That turns model output into engineering evidence.

BehaviorBeforeAfter
Existing success + failure casesPassPass
Mixed provider responseFailPass
Original behavior preserved3 / 3 checks pass

Proof, not theatre

Every claim leaves a receipt.

The public experience uses recorded evidence from the verified live run. Identifiers are non-secret and trace the runtime path without exposing credentials.

02 · RUNTIME REASONING

NVIDIA through Nebius

Loading model…

Completion
—
Tokens
—
Est. cost
—
03 · TRUST BOUNDARY

Honest by design

  • ✓ Credentials stripped
  • ✓ AST-restricted candidate
  • ✓ Disposable workspace
  • ! Host network isolation unproven
RUN—
TAVILY SEARCH—
TAVILY EXTRACT—
PATCH SHA-256—

Evidence before automation

Ship software that can
keep up with the world.

Refresh turns change into a source-linked, tested, human-reviewable repair.