Research · Study 001
LevrAge Research
The studio is preparing studies of how people frame, read and verify AI output on fictional cases. The aim is to test and improve the learning methods; findings and learner outcomes have not yet been established.
The engine is at its first study. There are no published findings yet; this page says what is being measured and shows the counts as they stand.
Study 001: the AI use check
A seven-minute check on one fictional supplier agreement. It looks at six dimensions of working with AI and is honest about which three it can observe from a browser and which three it cannot.
Observed on the fictional case
Framing the task
Chooses a request whose answer can be checked against a named source.
Demonstrated vs assumed access
Separates what one successful retrieval established from what it did not.
Verification and recovery
Catches the seeded errors in a polished summary without rejecting the claims its source supports.
Not assessable from a self-check
Information boundaries
A read-only walk through connector scopes, accounts and plan settings, done with you. This check never sees your setup.
Authority
A conversation about what the tool and your colleagues may do unasked, where sign-off sits and who owns the result.
Organisational ownership
A written runbook, and a second person walking through it without you.
Evidence levels
| Level | Kind | What it is |
|---|---|---|
| E1 | Self-report | What a person says about their own habits. Recorded as context, never graded. |
| E3 | Observed exercise | What a person did on a fictional case: the request they chose, the conclusions they drew, the seeded errors they caught. |
| E4 | Before and after | The same exercises at least 30 days apart, for people who chose to save a result and come back. |
E2, configuration facts, needs a read-only walk through a real setup with the person and is not collected online.
Never collected
- Anything you typed in your own words
- Your name, company, phone number or job title
- The names of tools or accounts you use, tied to you
- Your raw network address in the application database. Abuse counters use a keyed hash, are not joined to results, expire from decisions after at most 70 minutes, and are removed on the next protected request or maintenance run. Cleanup may be delayed during inactivity or outages.
- Anything from a real inbox, file or account; the check never connects to one
Counts so far
No database snapshot has been published yet. These are not live participation counts.
- Saved participant records
- None yetCounts are published once 25 email-linked participant records have a baseline. Repeat saves do not raise this threshold. Instrument v0.2.
Field notes
Every failure becomes a rule. These are the latest, with the date each rule shipped.
2026-10-26 · v0.1
Failed A draft hero line promised to rerun the test battery every time the models change, before any run existed.
Rule The surface shows dates, never a cadence.
2026-10-26 · v0.1
Failed Two claims inherited from an earlier working session, a scored model ladder and a twelve-week module, did not exist on disk.
Rule Verify every asset before citing it. Check is not done.
How a finding becomes a change
- 01
Observe
Something happens in a session, a drill or a saved result that was not expected.
- 02
Hypothesis
It is written down as a claim that could be wrong, with what would make it wrong.
- 03
Test
A fictional case or an instrument change is designed to put the claim at risk.
- 04
Measure
Counts are taken from the exercises, never from impressions.
- 05
Finding
The claim is kept, edited or killed, with its evidence pointer and confidence.
- 06
Decision
A kept finding becomes a dated change to the method, the instrument or the site.
Convenience sample. Participants reach this page through the studio's own channels; counts describe them, not any wider population.