Start with one decision
In the guided incident on the homepage, the public orders path returns 503 while the application looks healthy. The first question is not “what is the fix?” but “what should you inspect first?” Suppose you choose the Orders API.
Feedback: “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.”
That sentence is written for the move you made. A different choice gets a different sentence, and a correct choice gets an explanation of why it separated the explanations.
1 · Recall or choose
Answer a short question, type a command in a safe terminal, or choose the most informative next move.
2 · See specific feedback
Learn why the choice works, what a tempting alternative missed and which concept needs another look.
3 · Return and transfer
Uncertain ideas return on a spaced schedule, then the same objective appears inside a different scenario.
Try the incident on the homepage
What self-paced practice looks like today
Everything below is open now, free during the public beta, and Foundations stays free afterwards.
- Short drills. Plain-language questions that introduce the technical term only after its purpose is clear, with feedback that names the misconception rather than the letter you picked.
- Browser terminal practice. A safe shell with files and processes to explore. Nothing you type can reach a real system.
- Guided incidents. A failing system, evidence to inspect, a repair to make and a fresh user-path check before the incident counts as resolved.
- A route check. If you already have experience, a short adaptive check moves your starting point nearer useful practice. It changes where you begin, not what you have demonstrated.
Assistance is yours to control
CLIVE, the AI guide, is inside every incident. It starts silent.
| Mode | What you see | What it means for the attempt |
|---|---|---|
| No assistance | Nothing is revealed until you ask. | The default. Your decisions stand on their own. |
| Hints | One hint at a time, each narrowing the problem without giving the action. | Requested hints are recorded beside the attempt. |
| Step-by-step | The exact action for the current stage. | The attempt becomes learning-only and earns no progress points. |
During the beta CLIVE answers up to five requests per rolling 24 hours for every verified profile; each response frees up 24 hours after use. Automated feedback is the only feedback in the product today. Nothing is reviewed by a person.
What progress means, and what it does not
The learning home shows one progression: Foundations (Understand → Apply → Connect → Challenge), then Build and Operate, then Design and Improve. Alongside it, capability is described with names rather than a percentage.
| State | Meaning |
|---|---|
| Learning | You have met the idea and its purpose. |
| Practising | You have used it with guidance or targeted repetition. |
| Demonstrated | Sampled under defined conditions with the guide off. Not yet issued. |
| Strengthened | Demonstrated again under changed conditions. Not yet issued. |
Today the interface shows Learning or Practising only. It reflects learning activity. Verified capability evidence is not yet issued, and no overall competence percentage will ever be shown.
Why this is different from asking an AI assistant
An AI assistant can explain a command, suggest possible causes and help you reason through a live problem. Those are useful, and CLIVE does them on request.
CloudCaive adds the part an assistant cannot: a controlled incident, a record of the decisions you make before you see an answer, feedback written for that decision, and the same objective returning later under different conditions so the change is visible rather than assumed.
Reference: how a reviewed session would be graded
CloudCaive publishes the standard any human-reviewed session would be graded against, Rubric v1.0, so the method can be inspected before it is ever sold. Reviewed sessions are not part of the free beta or of any current offering. This section documents the standard; it is not an invitation.
In a reviewed session, a reviewer would observe:
- which evidence you choose to inspect;
- the order in which you inspect it;
- the hypotheses your choices support or rule out;
- whether your conclusion follows from the evidence; and
- whether you verify the result after making a change.
Three evidence outcomes
| Outcome | What it means |
|---|---|
| Demonstrated | The sampled performance met the objective under the session’s stated conditions. |
| Not demonstrated | The observed choices did not meet the objective in this sample. |
| Insufficient evidence | The session did not provide enough evidence to make either claim honestly. |
“Insufficient evidence” matters. Silence, a missing opportunity or an ambiguous action is never turned into a confident score.
Why a reassessment is unseen
Repeating the same incident would make memory hard to separate from improvement, so a reassessment uses a new incident mapped to the same objectives. The two forms are designed to ask for comparable decisions, evidence and reasoning; CloudCaive does not claim they are psychometrically equivalent, because a documented form-comparison protocol has not yet been established.
The claims boundary
Every incident is a browser-based simulation. No real or production system is involved. CloudCaive is not a certification, job guarantee or employer-recognised credential, and it does not publish testimonials or improvement charts as proof.
Feedback describes what a decision revealed. Progress describes learning activity. Any future report would describe only the evidence demonstrated in the sampled session, against the rubric version it cites.