Action inventory

Name the action before you automate it

Mara’s fictional F-104 refund is the teaching case that evolves across all six modules: looking up an order, drafting a recommendation, and sending a refund are three different effects. Your workbook export remains a separate learner-authored case whose action, tool, and resource become the canonical identity across the six capstone artifacts.

what you'll be able to do

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.

required no-code practice

Before the lab, complete the local action-boundary workbook. The F-104 teaching ledger continues through GOV.6; the different case you draft and export supplies the one action, tool, and resource that build_starter_bundle.py repeats across all six capstone artifacts. Neither record authorizes an action or judges 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. These three rows begin the teaching ledger that continues through GOV.6. They do not replace the separate learner case exported by the workbook, where one exact action, tool, and resource remain unchanged across all six capstone artifacts. Both cases are fictional; neither represents 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.

commit before answer · GOV.1

Append an action_named event for mara-f104—including the selected action, tool, resource, owner, and limit—before the interface displays “classified” or GOV.2 reads the row. If that append is not confirmed, keep HOLD and do not hand off. The bundled lab validates an independent snapshot; it does not persist this event.

the trap · a label is not authority

If “handle refunds” hides a broader audience or a second external effect, the classification is incomplete and remains HOLD. A passing fictional action record names the review path; it does not authorize execution.

public evidence

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. Before showing your answer or moving to the boundary, persist the selected row as action_named; a failed append means HOLD and no handoff. Treat the lab sample as an independent classification fixture. Then export your separate workbook case; its action, tool, and resource are the canonical identity for the later starter bundle.

lab · action-inventory

Run the offline checker to inspect one independent synthetic inventory slice. It validates fields but does not append action_named or 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.

../labs/action-inventory/ · python action_inventory.py

Key takeaways

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.