Run the allowed command and blocked question in one session

Question for this chapter

What result and audit evidence does each allowed or blocked request leave?

Why this matters now

A classification label alone does not prove that the action and record followed. Trace the allowed path to coordinate JSON, the blocked path to a rejection reason, and both paths to event publication.

Try it

In Pipelines, start map_agent_event_ingestion first. This event pipeline must be running before the Agent actor can append messages to om_event_history.

Open a new map-control session and use OPR-WORKSHOP-01 as user_id. Submit these requests in order.

1. Show Busan Port Entry/Exit Control Zone
2. Tell me today's patrol history

For each run, inspect intent_classification, control_parameters, and event_log. On the blocked path, also inspect the reason produced by reject_command.

Success looks like this

The first request is classified as UI_CONTROL, and the seeded values for TZ-008 appear as structured JSON.

{
  "lon": 129.036,
  "lat": 35.10405,
  "축척": 10000,
  "안전구역객체ID": "TZ-008",
  "request_id": "REQ-TZ-008"
}

The second request is classified as DATA_QUERY and does not call the zone or coordinate tools. Its reason states that the current Agent automates only UI_CONTROL and that the request requires another approval path.

Interpret the result

Free-form model output is limited to classification and zone-name extraction. The final chart values come from the seeded lookup and a fixed key structure. The external UI receives a constrained JSON contract rather than arbitrary prose.

queued: true means the event entered the queue; it does not mean persistence finished. Refresh om_event_history after the event pipeline processes the message.

Next decision

Both requests have entered the audit queue. Next, distinguish the eight batch reference rows from the two runtime events you just produced.