Name the action before you automate it
Use Mara’s fictional F-104 refund only to learn the first distinction: looking up an order, drafting a recommendation, and sending a refund are three different effects. Then draft a new fictional case in the workbook. Its exported action, tool, and resource become the canonical identity carried through the six capstone artifacts.
By the end, you can classify consultation, proposal, and execution, then record the named action, tool, owner, and limit; keep the record on HOLD when any of those fields is vague.
Before the lab, complete the local action-boundary workbook. The F-104 rows are a classification exercise. The new case you draft and export supplies the one action, tool, and resource that build_starter_bundle.py repeats across all six artifacts. The workbook does not authorize an action or judge safety.
The trap
The trap is plain: A ticket says help with a refund, so the team treats search, recommendation, and payment as one harmless capability.
The move is concrete: Write one action line for every observable effect: look up the order, draft a proposal, and execute the refund. Only the last line changes the customer record.
Read the diagram left to right: a proposal is not execution. The boundary makes the proposed effect, limit, and evidence inspectable before a decision. That is why this record exists: it narrows one external action for review; it is not AGENT repository governance and not SEC threat or risk analysis.
Classification example: the fictional F-104 refund
Imagine that fictional customer Mara requests a refund. The three rows below classify different effects; they are not the canonical identity of the record that continues to the labs and capstone. That identity comes from the new fictional case exported by the workbook, where one exact action, tool, and resource remain unchanged across all six artifacts. This example and its data are fictional; they do not represent customers, payments, or real safety.
inventory = [
{"action":"look_up_order", "mode":"consult"},
{"action":"draft_refund", "mode":"propose"},
{"action":"submit_refund", "mode":"execute"} # changes money
]
# The first two rows do not authorize the third.Do not turn PROMOTE into production authorization. In this course, PROMOTE means only that the fictional record satisfied its stated policy.
NIST AI RMF frames risk management as a voluntary practice; the OWASP agentic list describes risks around actions and privilege. The MCP Authorization draft is still evolving. These sources inform review questions; they do not certify this record. Public sources: NIST AI RMF; OWASP Top 10 for Agentic Applications 2026; MCP Authorization draft.
Your turn
Use action-inventory to distinguish consultation, proposal, and external action. Treat its included sample as another classification example, not as your final record. Then export your workbook case; its action, tool, and resource are the canonical identity for the later starter bundle. If the effect or owner is vague, keep HOLD.
Run the offline checker to inspect one synthetic inventory slice. It does not create the six-artifact record: the workbook export and capstone/build_starter_bundle.py create that editable starter later. Neither result authorizes a real action.
python action_inventory.py- Inventory every external action separately from consultation and proposal.
- The record lets reviewers point to one effect, owner, and limit.
- GOV governs a bounded external action, not repository governance or threat analysis.
Why is “handle refunds” not yet an action record?
It hides three effects with different consequences. Inventory names the one external effect that needs the later boundary.
A draft is sent to Mara instead of shown to the reviewer. What changed?
The proposal gained an external audience and effect. Record it separately; do not inherit the safety of a read-only lookup.
What is deliberately absent after GOV.1?
Authority, confirmation, evidence, and recovery. The inventory begins the record; it does not complete it.