What we tested
13 real, widely-used software projects Grace had never seen before — including large mature codebases. Real, unfamiliar software is the honest test; it is easy to look good on code you control.
Evidence over assertion
What we tested. What happened.
Grace's claims are backed by observed, counted outcomes on real software it had never seen before — not toy examples and not code we control.
Below: the real numbers, the seven tests behind them, the counting rules, the limitations and how the testing can be repeated.
Headline results
Self-healing, measured.
These are real, measured results from a hands-on testing program — 13 real, widely-used software projects Grace had never seen before, with known faults introduced one at a time so every repair could be checked against the correct answer.
91%
of in-scope problems repaired
109
verified repairs completed
0
repairs observed making things worse
13
unfamiliar real-world projects
4,342
source files under test
30/30
existing developer-written faults repaired
0
false fixes accepted
10/10
planted silent logic faults caught
The larger run covered several long-established, widely-used open-source codebases — thousands of real source files written and maintained by independent development teams over many years. Project identities and repair contents are withheld to protect the code involved; the test conditions, fault categories and counting rules are published so the testing can be repeated.
Live traffic
Real visits to this site.
These numbers are counted from actual visits to this site as they happen — not estimates and not sample data. They update as people arrive.
—
page views, last 30 days
—
distinct visitors, last 30 days
—
pages visited, last 30 days
—
visit records stored to date
Only aggregate counts are published. Individual visitor records are never shown here and are not readable by anyone but the site's own team.
Methodology
How the testing was run.
What we did
Deliberately introduced specific, known problems, one at a time, so the correct fix was always known in advance — and recorded every decision, repair, refusal and rollback Grace made.
How we checked
Every repair was verified independently of the process that produced it. A fix only counts if independent verification confirms it.
How we tried to break it
Fake repairs that did not actually work were presented for approval, to test whether the verifier could be talked into approving something bad. It rejected every one.
The full picture
The tests, one at a time.
Seven tests, run in order of increasing difficulty — from clear breakages to hidden mistakes where the software still runs but quietly returns the wrong answer.
01
Which kinds of problems can Grace actually fix?
Real software problems were sorted into everyday categories — crashes, broken settings, missing links between files, failing tests, slow code and more — and each kind was introduced on purpose and measured.
The result
Grace repaired the large majority across the board, with several categories at 100%. Results are reported category by category, not hidden inside an average.
02
When Grace can't safely fix something, what does it do?
For every problem category, the actual decision Grace made was recorded and counted: fixed and confirmed, or safely handed to a human.
The result
Almost every outcome lands in one of those two columns, because Grace does not guess. It acts when it is certain and gets out of the way when it is not.
03
What is Grace's full coverage today, honestly?
Every problem type was given one clear verdict on a single grid: repaired automatically, safely referred to your team, or not yet exercised in this round.
The result
The unexercised categories are shown openly rather than painted green. Total transparency over a flattering chart.
04
Do the results hold up at a glance?
Every result from the testing program was rolled into one scoreboard — the four numbers that matter most, plus the full per-problem and per-project breakdown.
The result
The track record stays visible at any moment, with no digging and no spin.
05
The hardest test: catching mistakes that don't crash
The most dangerous bugs are the quiet ones — the software runs perfectly, it just gives the wrong answer: a wrong discount, a miscount, a flipped yes or no. Ten of these silent mistakes were planted, one at a time. Then fake repairs that fixed nothing were handed to Grace to see if it could be tricked.
The result
Grace caught all 10, fixed all 10, and rejected every fake repair. It catches silent errors by comparing current behaviour against the last version known to be correct.
06
Did Grace ever make things worse?
The single most important safety question. The outcome of every repair in the entire program was checked — no exceptions, no rounding.
The result
Zero. Across 109 repairs, not once did Grace make anything worse. It fixes, or it safely does nothing, but it does not break.
07
Does it work on real software, not just our examples?
The entire testing program was run against 13 real, widely-used software projects Grace had never seen before.
The result
On every project, Grace fixed the planted problems, and on every project it broke nothing. Real-world evidence, not a staged demo.
Safety behaviour
- Repairs act only inside explicitly granted boundaries.
- Rollback is retained and demonstrated before a repair stands.
- Uncertain cases restore the prior state rather than guessing.
- Each accepted repair keeps a receipt of what changed and why.
Counting rules
- A repair only counts when independent verification confirms it — not when the repairer says it is done.
- A refusal or clean restore on an unsafe problem is counted as a correct outcome, not hidden as a failure.
- Every repair was checked for side effects: 'fixed the fault but broke something else' does not count as fixed.
- When a fix did not hold, Grace restored everything exactly as it was — 100% clean, instant undo when unsure.
- Numbers are reported per category and per project, so strength and weakness are both visible.
Limitations
What this does and doesn't claim.
These results describe a focused, repeatable test set and the problem types exercised within it — a whole class of software emergencies becoming a non-event, fixed automatically and safely, with the rest escalated cleanly to a human.
They do not claim that every possible software fault can be repaired automatically, or that results transfer unchanged to every language, runtime or environment. Coverage is growing, and the uncovered categories are shown openly rather than overstated.
Where Grace cannot establish a safe repair, the correct outcome is a refusal or a clean restore — and that is counted as such, not as a failure to be hidden.
Everything here is real, measured and repeatable. Test conditions, fault categories and counting rules are documented so the same testing can be run again. Proprietary decision machinery is not published.
Evidence