FalsifyConnecting…

AN EXPERIMENT, NOT AN OPINION

No red test,
no accusation.

For solo Python developers and small GitLab teams: ask an AI reviewer to show a failure you can inspect, decide what it means, and keep the accepted test.

  1. Show the failure
  2. Decide on the fix
  3. Keep the test
  4. Release with evidence
Inspect the full review and release workflow

Duo proposes · A human authorizes · CI executes and enforces · Scanners report

  1. 01 Claim
  2. 02 Experiment (red)
  3. 03 Remedy
  4. 04 Promote
  5. 05 Certify
  6. 06 Staging
  7. 07 Production
  8. 08 Watch

NATIVE GITLAB EVIDENCE

A failure. A decision. A test that stays.

Follow the original finding, its accepted fix and the test retained afterward. Open the evidence when you want to check exactly what happened.

Original runs come from the cited native CI jobs. Promotions are joined from the committed ledger certificates and shown only when their hash matches the experiment. MR !5 is a disclosed, deliberately seeded regression: a capability demonstration, not an accuracy measurement.

Loading native evidence…

FOR THE OPERATOR

One next action, in GitLab.

Keep your approvals in GitLab. This read-only guide helps you find the right discussion or job.

Start a review

First verify your installation, then follow the single operator walkthrough.

Prerequisites and walkthrough ↗

Continue an existing review

Generate a fresh guide with the CLI on your machine. It rereads native evidence and rulings through your existing glab login, using the same resolution logic as certification.

python -m scripts.review_guide --mr <MR-number> > submission-private/operator-guide.json

No file is uploaded. This page does not store credentials, execute jobs or authorize a decision.

No guide loaded.

Understand what a guide can and cannot tell you

The public proof page shows completed history. An imported guide is an advisory snapshot, not a live GitLab connection or evidence of current permissions. A changed head, edited source or ruling needs a fresh guide and native revalidation. After promotion, start a human-owned pipeline on the new head before continuing. The guide continues through certification, staging, merge, production and the deployment watch. An action is complete only when its native evidence is present; an imported snapshot cannot execute or approve it.

SCHOLARSHIP DEMO

Make a real API request.

Explore eligibility and submit a disposable demo application.

Connected to this instance
All scholarship and applicant records in this disposable demo are fictional fixtures. They are not available awards.

Loading scholarships…

NATIVE RELEASE EVIDENCE

The latest recorded deployment watch.

Open the exact native job, then inspect its certificate and event history.

Selected by the recorded watch time in this build’s hash-checked ledger. This page does not check the current service or independently authenticate CI. The current source ledger may contain a newer release.

Loading recorded watch…

REVIEW LEDGER

Evidence you can inspect.

Every certified merge request in the committed ledger, newest first: original red evidence where a finding was remedied, the final certified context, and the release path.

This deployment serves a build-time ledger snapshot. Local hashes detect corruption; the viewer does not revalidate CI authority. Open the current GitLab ledger ↗

Loading ledger…

Preview a synthetic evidence example
ILLUSTRATION ONLY · No actual review, approval, or measurement is implied.
Synthetic experiment E-example
Head 1Head 2BaseHuman rulingPromotion
FAILFAILPASSExample: remedy acceptedExample: tests/test_example.py

The original red evidence stays visible after a remedy passes. A sustained contest can resolve a finding without promoting its test.