The problem I kept seeing
Technical education often rewards recognition. You watch a working example, repeat the command and finish with the feeling that the topic makes sense.
Work becomes less tidy. A service can fail for several plausible reasons. Nobody tells you which page of the lesson you are on. You have to decide what evidence matters, rule explanations out and verify that the eventual change solved the actual cause.
That gap between following a working path and investigating a broken one is where CloudCaive begins.
Useful feedback tells you what the evidence showed, where the reasoning weakened and what to practise next. Everything CloudCaive does is that sentence, turned into a product.
What that sentence looks like in the product
In the guided incident on the homepage, the public orders path returns 503 while the application looks healthy. A learner who inspects the Orders API first reads this:
“The Orders API process is healthy, but its database calls fail. The API is affected; it is not the failed component. Inspect its database host next.”
The move was reasonable. The feedback says so, says what the evidence showed, and names the next inspection, and the learner makes the next decision themselves.
The principles behind CloudCaive
Observe the work
A final answer does not reveal enough. CloudCaive looks at what you inspect, the order you work in and whether the conclusion follows from the evidence. In practice that means a report can say something as specific as: you read the logs before you checked whether the Service had any endpoints — a defensible move, one step slower than the evidence allowed.
Make claims no larger than the evidence
A sampled session can support a bounded statement about sampled objectives. It cannot prove permanent mastery, guarantee a job or stand in for an employer-recognised credential. That is why every objective in a report resolves to one of three states — demonstrated, not demonstrated, or insufficient evidence — and never to an unsupported score.
Target the next practice
Feedback becomes useful when it changes what happens next. The drills and incidents that follow a report are selected from the gaps the session actually showed, rather than added as more content for its own sake.
Measure change on something unseen
Repeating the same answer mainly tests memory. So the reassessment is a new incident you have not seen, mapped to the same objectives — a fairer view of whether the investigation itself changed, not just the recall.
How feedback is delivered today
Every piece of feedback in the product today is automated: I write the incidents, the distractors and the feedback sentences, and the product delivers them the moment a decision is made. Reviewed sessions, where I would observe an investigation, grade it against the published rubric and write the report myself, are not part of the free beta or of any current offering. The rubric is published so the standard can be inspected before it is ever sold.
This keeps the claim close to the evidence while the scenario library and delivery experience are being validated. Progress in the learning home reflects learning activity; verified capability evidence is not yet issued. People taking part can challenge unclear feedback directly through the contact form and influence what is built next.
It is a beta because the library and the polish are still growing—not because the core loop is incomplete. The loop is already whole: diagnose, practice and reassess. That is also why the beta is free for everyone until 1 November 2026: the work is worth doing now, and I would rather have you in it than have you wait.
See how the feedback loop works
No implied endorsement
My professional experience informs CloudCaive, including work on systems used in UK national infrastructure. Employers and clients are not presented as partners, sponsors or endorsers of the product. CloudCaive’s assessment claims stand on its own published method and evidence boundaries.
What I can show you directly, I do: my code is on GitHub, my career history is on LinkedIn, and the assessment rubric CloudCaive grades against is published and versioned on this site.
What CloudCaive is trying to become
The long-term aim is a place where engineers go to test their competence honestly and where people building the foundations can learn without being patronised.
That means growing by evidence: useful scenarios, specific feedback, measured improvement and subscriptions people choose to renew. The reputation has to be earned before the platform makes broader claims.
