Why incidents reveal more than happy-path tutorials
A tutorial normally tells you which path to follow. An incident does not. A healthy Deployment can sit beside a broken Service, a mismatched selector, an application error or several other plausible explanations.
The useful skill is not remembering one command. It is deciding which evidence will separate those explanations, inspecting it in a sensible order and changing your view when the evidence disagrees.
CloudCaive observes the investigation, not only the final fix. A correct answer reached through guesswork and an evidence-led diagnosis are not treated as the same performance.
What is observed
During a scheduled session, you work through browser-based Kubernetes incident simulations. The founder observes:
- 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.
The simulation is not a real or production cluster. There is no cloud bill, setup burden or live system to damage. The decisions still mirror the kind of investigation expected when Kubernetes workloads fail.
Diagnose, practise, reassess
Diagnose
Investigate an unfamiliar incident. The sampled objectives are assessed against a versioned, published rubric.
Practise
Receive short drills and incident practice aimed at the objectives you did not demonstrate clearly.
Reassess
Meet an unseen equivalent incident and compare your performance against the same rubric.
The practice is composed to remain within the advertised weekly ceiling. A drill or incident may replace another assignment; a newly available scenario is not automatically extra required work.
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. CloudCaive does not turn silence, a missing opportunity or an ambiguous action into a confident score.
Capability states are names, not a completion meter
| State | Meaning |
|---|---|
| Introduced | You have met the concept and its purpose. |
| Practised | You have used it with guidance or targeted repetition. |
| Tested | It has been sampled under defined assessment conditions. |
| Verified | An evidence-backed claim is recorded for the sampled objective and conditions. |
These states do not claim permanent mastery. They describe the relationship between a capability claim and the evidence available at that point.
Why the reassessment is unseen and equivalent
Repeating the same incident would make memory hard to separate from improvement. The reassessment therefore uses a different incident that samples the same objectives at a comparable level of difficulty.
Equivalent does not mean identical. It means the forms are designed to ask for comparable decisions, evidence and reasoning without showing you the earlier answer pattern.
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 capabilities.
CloudCaive serves a different purpose: it gives you a controlled incident, records the decisions you make before seeing the answer, maps the observed performance to named objectives, then uses an unseen equivalent to measure change. Explanation helps you learn; an assessment needs held-back prompts, consistent conditions and bounded claims.
What the report may—and may not—claim
A report is an honest account of sampled performance. It is not a certification, job guarantee, employer-recognised credential or claim that you are ready for every incident of that type.
The founding beta is founder-delivered. Sessions are scheduled personally, the diagnostic material is held back, grading is completed against the versioned rubric, and every report is written by the founder.