Learning bite
Make the proposal reviewable
A proposed operational change should have a specific target, diff, evidence, and verification plan.
Kubernetes
Git
Predict before you try
Can a plausible model explanation grant authority or establish that the saved case recovered?
Try it: Try the reasoning exercise →On this page
Start with the operational need
A proposed operational change should have a specific target, diff, evidence, and verification plan. Use the same MicroBank contract and operating evidence from Platform engineering. The selected baseline and existing delivery owner must be known before an agent can be given a meaningful task.
The agent wants to restore Ledger. What exactly is it proposing?
In this controlled local scenario, the supported baseline is one Ledger replica, and a recorded change set it to zero.
Ask for a narrow manifest diff restoring that one field.
Include the evidence, expected effect, verification case, and recovery or escalation plan.
The proposal does not approve itself and does not change the cluster.
Review the actual diff before deciding to act.
Work through a bounded example
Proposed diff: Ledger replicas changes from 0 to the supported 1 in a fixed local workload file. Include the source evidence, expected effect, same-case verification, and stop/escalation condition. Reject a proposal that changes an image, namespace, database, or another field outside the scenario.
| Proposal field | Example in this controlled fixture |
|---|---|
| Target | The selected local Ledger workload declaration |
| Change | Only replicas, from the recorded 0 to the supported 1 |
| Evidence | Reviewed baseline plus saved-case and queue observations |
| Excluded changes | Image, namespace, database, and unrelated fields |
| Verification | Same saved case, matching Ledger entry, expected balance |
| Stop condition | Verification missing or failed; preserve evidence and escalate |
This describes a reviewable proposal. It does not grant permission to edit or sync a workload.
This is an offline design and evaluation fixture. No model SDK, agent executor, approval service, or live tool integration is supplied by this Markdown lesson. If you implement one, record its actual behavior and the application profile separately before describing it as working.
Try the reasoning exercise
Write the input, expected decision, allowed tools, forbidden action, observed evidence, and stopping condition. Compare the expected result with a labelled fixture first. For a later authorized local run, retain the exact tool calls and independently checked outcome.
Compare your reasoning
Review a concrete change rather than approving an open-ended instruction. A plausible explanation does not establish that an action was permitted or that the original operation recovered. Keep evidence, proposal, approval, execution, and verification as separate records.
Sources
Prove what you learned
Inspect the result
Record fixture/input, expected decision, allowed/attempted calls, evidence, stop condition and observed outcome.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Use one missing-evidence, injected-instruction or changed-target fixture; predict the correct refusal or escalation.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Try the reasoning exercise”.
- Record fixture/input, expected decision, allowed/attempted calls, evidence, stop condition and observed outcome.
- Explain the transfer challenge and retain the same verification question.
Hint
Separate observations, hypotheses, proposal, independent authorization, execution and verification.
Answer guide: compare after predicting
No. Enforce scope outside generated text and verify the original operation independently.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall the platform support contract and independent GitOps ownership. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.