Skip to main content

The five readiness conditions, in plain English

I won't issue the pass guarantee unless five specific things are true in the database, and "feels ready" is none of them. Each condition is a measurable signal that you've done the work and that the work transferred. The check runs on the server every time you complete a milestone, with no human in the loop. If all five hold, you're inside the window. If any one of them lapses, you're not. That's the whole policy. To start the diagnostic that begins the path to those five conditions, head to claudelab.me.

TL;DR​

  • The pass guarantee has five conditions, all checked by a database function called check_guarantee_eligibility().
  • Conditions one and two: every milestone completed and every phase completed. No skipped work.
  • Condition three: at least two mock exams passed at or above the certification's official passing score.
  • Condition four: at least one gauntlet finished at 80% accuracy or higher.
  • Condition five: live readiness score at 80 or above on the day you sit the exam.
  • All five must be true at the same time. The flag flips back to false if any condition lapses.

Why I check five things and not one​

A single number is easy to game and easy to misread. Mock-test scores swing with question selection. Readiness swings with rest. Milestone completion can be rushed. Each of the five conditions covers a failure mode the others don't catch, and the combination is what the pass guarantee actually rests on. The five conditions answer five different questions: did you finish the curriculum, did you finish the phases, can you score on a real exam, can you do it under pressure, and are you still sharp this week.

Condition 1: every milestone completed​

Every milestone on your roadmap must sit in completed status. Not active, not validation-ready, not failed, not restructured. Completed.

A milestone is the smallest unit of progress on the roadmap. It represents one tight scope of skill, validated by a session where you have to demonstrate you've absorbed it. If a milestone is in any other state, there's a piece of the curriculum you and I haven't agreed is finished. The condition exists because the roadmap is built around your weakest measured domains from the CAT evaluation; skipping a milestone means skipping a gap I already measured.

Restructured milestones don't satisfy this condition either. When you fail a milestone twice, ARIA rebuilds the approach instead of repeating it. The new approach has to be completed on its own terms. The whole point of restructure is that the original path didn't work, so I can't credit it.

Condition 2: every phase completed​

Every phase must also be in completed status. A phase is a group of milestones, and a phase only completes when all its milestones complete and the phase exam passes. Phase exams are the cumulative checkpoints; they catch the case where you completed each milestone in isolation but never proved you can hold the whole phase in your head at once.

This condition is partly redundant with condition one, and that's intentional. Redundancy is a feature here. If a future schema change ever lets a milestone close without rolling up to its phase, this condition catches it. Defence in depth, applied to a refund policy.

Condition 3: at least two mock exams passed​

You need at least two mock exam attempts where your score is greater than or equal to the certification's official passing score. For most AWS certs that's 70%. For some PMI exams it's 75%. A handful of others sit higher.

Two passes, not one. One pass is a coin flip; two passes is a pattern. I don't average them, I don't blend them with your milestone scores, I just count them. Failed mocks don't subtract; they just don't count toward the two.

A mock is not a study session. It's a dry run with the same length and rules as the real thing. Two passes means you've shown twice that the work survives the format.

Condition 4: at least one gauntlet passed at 80% or higher​

At least one gauntlet session must close with accuracy of 80% or above. The gauntlet is the long-form, exam-conditions pressure mode that unlocks at 80% readiness, and it's stricter than a mock: longer, denser, less forgiving on pacing. One pass at 80%+ is the floor.

Why a gauntlet on top of mocks. The mock proves you can score under exam format. The gauntlet proves you can hold accuracy under sustained pressure. Different failure mode. Some people score well on mocks because they hit a comfortable rhythm; the gauntlet finds out whether that rhythm holds when fatigue arrives. If you can't clear 80% on the gauntlet, the test you're about to sit will catch the same thing.

Condition 5: readiness score at 80 or higher​

Your live readiness score, as shown on the readiness gauge, must be 80 or above at the moment the eligibility check runs. Not at some peak in the past. Now.

Readiness is a 0-to-100 composite of five inputs: domain average, session frequency, error trend, mock-test average, and a retention factor that decays with inactivity. The full mechanics are on readiness and decay. The reason this condition exists separately from the other four is decay. You can finish every milestone, pass two mocks, clear a gauntlet, then take three weeks off; by the time you sit the exam, your retention has dropped, your session frequency has cratered, and the readiness number has fallen below 80. The data is telling you something. The condition listens.

If readiness slips below 80 after guarantee_eligible flips to true, the flag flips back to false and the 60-day exam window pauses. Get readiness back above 80 and the window resumes from where it left off, not from zero. That's not a punishment, it's a model of what's actually happening in your head between now and exam day.

What happens when all five are green​

The Postgres function check_guarantee_eligibility() runs on the server whenever you complete a milestone validation. The moment all five conditions are simultaneously true, it sets your roadmap's guarantee_eligible flag to true. The dashboard surfaces an exam-ready indicator. Your 60-day exam window starts that day.

You then have 60 calendar days to sit the exam. Sit it inside that window, fail it, send the official score report and your Paddle transaction ID to support@claudelab.me, and the pass-guarantee refund lands within 5 to 10 business days of approval. No claim form, no negotiation. Eligibility was already settled by the data before you walked into the testing centre.

If any condition lapses during the 60 days, the flag flips back to false and the window pauses until you bring the missing condition back into range. There's no penalty other than the pause itself.

Why these five and not other things​

A reasonable person could ask why I don't include "study time logged" or "completion percentage". I deliberately don't.

Study time is not a signal. I've seen people log 80 hours and fail, and 20 hours and pass. What predicts a pass is whether the work hit the right gaps and whether it stuck. Hours on a clock predict neither. A time minimum would reward presence over progress, and the guarantee would start paying out for the wrong reasons.

Completion percentage is a similar trap. Easy to inflate by skimming, and it doesn't tell me whether the material transferred. The five conditions are pass-fail at the unit level. A milestone is completed or not. A mock cleared the official passing score or not. The gauntlet hit 80% or not. Binary signals at the right granularity beat smooth percentages because they can't be partially gamed.

Subjective inputs are out for the same reason. "Confidence rating" surveys are noisy in both directions: anxious learners underestimate, overconfident ones overestimate, and I'd be paying refunds based on self-report. The whole point of check_guarantee_eligibility() reading real data is mechanical judgement. Objective bar, fair refund, concrete path to qualifying.

Common questions​

Who decides whether the five conditions are met?​

Nobody. A Postgres function called check_guarantee_eligibility() runs on the server every time you complete a milestone. It reads your account data, checks the five conditions, and flips your roadmap's guarantee_eligible flag to true the moment all five hold. Support does not judge it. I do not judge it. The data does.

Can I see the flag in the app before exam day?​

Yes. The dashboard surfaces an exam-ready indicator the moment guarantee_eligible flips to true, and the readiness gauge shows the live score that drives condition five. By the time you walk into the testing centre, you already know whether you qualify.

What happens if my readiness drops below 80 after I become eligible?​

The flag flips back to false and the 60-day exam window pauses. Get readiness back above 80 by running roadmap sessions on consecutive days, and the window resumes from where it left off, not from zero.

Do free-play sessions count toward the conditions?​

No. Only roadmap tasks advance milestones, and only milestone completions trigger the eligibility check. Free play is useful for drilling a weak topic on demand, but it's a parallel lane. The streak counts roadmap tasks, not free play, for the same reason.

What if my certification's passing score is unusually high?​

Condition three uses the official passing score for the certification you're preparing for, whatever that number is. AWS exams sit around 70%, some PMI exams sit at 75%, a handful run higher. The two mock-exam attempts must clear the official line, not a generic threshold.

Start the diagnostic​

The five conditions describe the finish line. The starting line is the CAT evaluation, and the path between them is the roadmap ARIA generates from your evaluation. For the wider view of how I run the day-to-day work behind those conditions, the companion piece is AI tutor for cert prep. Run the diagnostic, work the roadmap, watch the conditions flip green one at a time. Start at claudelab.me.