Grex 2.0 · October–November 2026
Can a site monitor remember what changed?
Fault identity and resolution worked in a controlled sequence. An overflow stage failed, and schedule delays limited the operating result.
Closed · controlled proof failed
The controlled site correctly reported four new faults, retained their identities and later reported their resolution. But the overflow stage produced no accepted report in three attempts, so the controlled proof failed. All three production windows were eventually accepted; only two arrived within the planned two-hour window.
The experiment, explained
A narrated explanation of recorded results, with synthetic narration and visible English captions. Diagrams explain the method; they are not recordings of execution.
Read the video transcript
Can a monitor remember?
A useful website monitor needs to remember what changed. We tested whether Grex could preserve fault identity, recognize resolution and produce useful reports across repeated observations.
A controlled sequence
The fixture started clean, gained known faults, repeated them, then added an error burst before returning to normal. Expected answers stayed hidden from the workers.
Facts before summaries
Grex computed fault facts from browser observations before writing a summary. A direct workflow summarized the same facts. Independent evaluation checked both the lifecycle and summary quality.
Useful behavior, failed proof
Four faults were detected, retained and later resolved against the last accepted state. But three overflow attempts failed. Correct computed facts did not produce an acceptable complete report.
Delivery also matters
All three production reports were eventually accepted, but only two arrived within two hours. Direct summaries were slightly preferred more often. Manual recovery and compressed timing limit the result.
Fixes are not a rerun
The study closed with its failure visible. Later code fixes did not retroactively pass the overflow stage, and clean production pages did not demonstrate real fault detection.
What were we trying to find out?
Can Grex repeatedly observe a website, preserve fault identity, report resolution correctly and deliver useful summaries on schedule?
Hypothesis
Persistent observations and independent review might produce reliable fault lifecycle reports without repeated operator intervention.
Reconstructed from the prospective case-study objectives, not a registered numerical prediction. The original seven-day schedule was shortened by a recorded amendment; later clean windows used a recorded override after the overflow stage failed.
How the experiment worked
Seed known faults into a controlled site, then remove them and inspect lifecycle reports across repeated observations. Run production observations separately and compare summaries from identical computed facts.
Controlled site
- Clean → 4 faults → same faults
- Overflow → clean → no reopen
Grex reports
- Observe → compute → summarize
- Check → independent review
Basic lifecycle supported · overflow: 0 accepted reports in 3 attempts
Clean windows compare with the last accepted state; overflow resolution was not tested.
Download the method illustration
Sample: Six controlled fixture windows and three scored production windows. A separate retrospective schedule audit was not part of the prospective scored result.
Seed a hidden answer key
Start clean, introduce faults, repeat them, add an error burst, then return to a clean state. Keep expected answers out of worker inputs.
Observe and compute lifecycle
A sandboxed browser collects observations. Deterministic checks compute fault identity, persistence and resolution before the worker writes its summary.
Review the complete report
Mechanical checks and an independent reviewer decide whether each report is acceptable. Correct computed facts alone do not count as end-to-end success.
Compare summaries fairly
A direct Claude workflow summarizes the same pinned computed facts. A blinded evaluator compares nine summary pairs; it does not compare independent crawls.
Controls and differences
- The seeded expected answers were hidden from Grex jobs and checked by a separate evaluator.
- Direct and Grex summaries used identical computed facts, not separate browsing sessions.
- After the overflow stage failed, the final clean windows were explicitly judged against the last accepted four-fault state. This limits the resolution claim.
What happened
| Measure | Result |
|---|---|
| Controlled fixture windows | 6 |
| Overflow-stage accepted reports | 0 / 3 attempts |
| New faults detected and retained | 4 / 4 |
| Production windows eventually accepted | 3 / 3 |
| Production windows within two hours | 2 / 3 |
| Blind summary preference across 9 windows | Direct 5 · Grex 1 · ties 3 |
Basic fault identity survived repetition
The introduced broken link, missing-image effects and script error produced four fault records. All four persisted with stable identity in the next accepted report, then resolved against that accepted state.
Overflow broke the complete workflow
Three attempts failed in sequence: an oversized fault grouping, truncated reviewer evidence, then missing required fault coverage. The computed facts were correct, but none produced an accepted report.
Scheduling still needed intervention
One fixture report was over four hours late. One production report arrived over seven hours late after manual recovery. Eventual acceptance does not establish unattended delivery reliability.
The direct summaries were at least competitive
Across nine blinded comparisons, the direct baseline was preferred five times, Grex once, with three ties. All preferences were slight; one pair compared rejected content and is not evidence of accepted delivery.
What this does not establish
- The final fixture stages were compressed into one day. One no-reopen check 74 minutes after resolution does not establish seven-day persistence.
- The overflow stage never became accepted; resolution of its twenty added console errors was not measured.
- Production observations contained no real faults, so they did not test real-site detection or repair. Monitoring did not fix website issues.
- Platform changes and manual reruns departed from the intended freeze and correction limit. The reviewer and evaluator shared a model family.
- Complete operator effort and all-in economics were not measured.
The decision
Close the bounded study with its failed controlled proof visible. Correct the report-input defects before claiming that overflow and unattended persistence are proven.
What followed
The report-input fixes were subsequently merged, but this record contains no successful repeat of the failed overflow stage. A code fix does not retroactively change the experiment result.
Evidence and further reading
Public summaries retain the reported counts and limitations. Private execution traces and infrastructure details are not published.
- Download the evidence summary
Sanitized aggregate transcription of retained study reports and final closeout evidence. This is not a raw-data release or independent reproduction.