Repeat the conditions.
Fixed inputs, explicit boundaries, expected results, and negative controls make a change reviewable. CR’s public summary describes the corresponding reliability approach.
CR case study ↗02 / EXECUTERun controlled checks
TEST ENGINEERING / INTERACTIVE PUBLIC DEMONSTRATION
Put the checks
to work.
Run a small verification suite, change an authentication time boundary, and see why missing or misattributed evidence should stop a conclusion.
2 enginesAuthentication replay + evidence coverage
9 checksBaseline behavior and negative controls
Local executionCalculations stay in your browser
These are independently authored public teaching engines. They do not execute private CR/RAI code or run a Splunk search. The authentication fixture is derived from the public 64-event CSV; the evidence examples use two explicitly defined training records.
01 / START WITH THE BASELINE
Run the nine checks.
Checks always use the unchanged baseline settings: five failures and an inclusive 600-second window. Replay controls below affect a separate experiment.
Ready. Checks have not run in this browser session.
| Result | Check | What it verifies |
|---|---|---|
| Run the checks to calculate results. | ||
02 / AUTHENTICATION ENGINE
One second can change the result.
Replay all 64 training events. Try a 599-second window, then restore 600 seconds. Compare the exact finding rows with the frozen five-finding baseline.
Ready. No replay has run.
| UTC time | Username | Source IP | Failures |
|---|
The replay table is empty until a run produces findings.
Baseline comparison uses timestamp, username, source IP, and failure count. A changed result is an experiment with different rule settings, not a production accuracy score.
Read the actual Splunk boundary investigation ↗03 / ATTRIBUTED-EVIDENCE ENGINE
Keep the disagreement visible.
Source A reports 4; Source B reports 6. Test whether a structured report includes both observations and preserves each source’s value.
Structured input
Select a scenario and run the coverage check.
Computed disposition
Ready. No coverage check has run.
The result will state whether attribution and coverage match the supplied records.
This checks structured coverage and attribution. It does not determine whether a source is true or validate arbitrary natural-language claims.
Explore the RAI engineering principles ↗04 / WHY I TEST THIS WAY
Small examples of larger engineering concerns.
Test the reason to hold.
Missing support and misattribution are useful failure cases. RAI’s public summary explains why disagreement and authority should stay visible.
RAI case study ↗Source, reproducibility, and receipt details
The browser fixture is generated from the public CSV and frozen expected findings. Their SHA-256 values are included in a downloaded receipt, along with the engine version, run times, and calculated results.
Run receipts are snapshots. Changing a control does not rerun it. Downloads include the last completed baseline and any completed replay or coverage run.
Inspect the engine source ↗ · Inspect the Node checks ↗
The nine browser checks are separate from the original four-lab suite’s 76 Python tests and the additional case-specific tests. They do not certify production detection, semantic truth, or private CR/RAI implementations.