EOP Editing Workflow
Overview
The EOP (Emergency Operation Plan) editing workflow lets you submit a request to edit district planning content, facility planning content, functional annex sections, or hazard annex sections, then retrieve the AI-generated result when processing completes. The workflow runs asynchronously by default, with an optional synchronous mode for callers that need an immediate response.
Sequence
What the Kickoff Accepts
Choose the kickoff tool that matches the task:
| Tool ID | When to use |
|---|---|
k12-district-planning-kickoff | District-level EOP planning edits |
k12-facility-planning-kickoff | Facility-level EOP planning edits |
k12-functional-annex-kickoff | Functional annex editing |
k12-hazard-annex-kickoff | Hazard annex editing |
k12-functional-annex-suggest-roles-kickoff | Compatibility endpoint for functional role-suggestion mode |
k12-hazard-annex-suggest-roles-kickoff | Compatibility endpoint for hazard role-suggestion mode |
k12-annex-editing-kickoff | Compatibility endpoint for older integrations |
The four primary endpoints are k12-district-planning-kickoff, k12-facility-planning-kickoff, k12-functional-annex-kickoff, and k12-hazard-annex-kickoff.
For functional and hazard annexes, prompts that normalize to Suggest Roles and Responsibilities automatically route to the suggest-role execution mode. The explicit *-suggest-roles-kickoff endpoints remain available for compatibility and direct invocation.
All kickoff tools accept the same request fields:
| Field | Required | Description |
|---|---|---|
emergencyOperationPlanId | Conditionally | The plan whose annex you want to edit. Organization context still requires emergencyOperationPlan.organizationId |
emergencyOperationPlan | Conditionally | Frontend-provided EOP object. Its id, emergencyOperationPlanId, planId, or eopId is normalized as the plan identifier; organizationId is used directly for district/organization details |
emergencyOperationPlanConfigurationId | Conditionally | Configuration-stage identifier used before a plan ID exists. Organization context still requires emergencyOperationPlanConfiguration.organizationId; mutually exclusive with plan and Master Copy identifiers |
emergencyOperationPlanConfiguration | Conditionally | Frontend-provided configuration object. Its ID aliases are normalized as the configuration identifier; organizationId is used directly for district/organization details |
eopMasterCopyId | Conditionally | Master Copy identifier for pre-EOP template forms such as district plan, facility plan, functional annex, or hazard annex Master Copies. Organization context still requires emergencyOperationPlanMasterCopy.organizationId; mutually exclusive with EOP plan/configuration IDs |
emergencyOperationPlanMasterCopy | Conditionally | Master Copy object for saved or creation-time Master Copy flows. organizationId is used directly for district/organization details |
userId | Yes | Identifier of the requesting user |
roleId | No | Optional role or persona identifier retained for traceability |
userTagIds | No | Alias for selected role/tag IDs. This may be an empty array while frontend tag filling is pending |
roles, userTags, generalUserTags | No | Frontend-provided role/tag objects or names. When present, these role names override backend-resolved role tags for prompt context |
form.field.content | Yes | The current annex content (HTML/rich text). Pass an empty string for prompt-only edits |
prompt | No | Instructions describing the desired changes |
sessionId | No | Correlation ID. Generated automatically if omitted |
requestId | No | Deterministic job ID. Generated automatically if omitted |
waitForResult | No | Set to true to block until the job finishes instead of returning immediately |
Exactly one plan identity source must be provided: emergencyOperationPlanId/emergencyOperationPlan, emergencyOperationPlanConfigurationId/emergencyOperationPlanConfiguration, or eopMasterCopyId/emergencyOperationPlanMasterCopy. District/organization details are resolved only from the explicit organizationId on the selected request object; the workflow no longer discovers organization IDs indirectly from EOP, configuration, or Master Copy IDs.
All EOP kickoff tools accept eopMasterCopyId and draft emergencyOperationPlanMasterCopy objects; QRG generation still requires an EOP plan because it discovers forms from EOP snapshots.
Role Context Behavior
All EOP kickoff variants keep roleId for request identity and auditing, but prompt context is not reduced to that single role.
- the workflow loads the plan's accepted EOP roles as prompt context
- district planning and facility planning treat those roles as soft reference context only
- functional and hazard annex flows are more role-aware, especially when the request moves into role-generation or suggest-role behavior
For district and facility planning, ordinary non-role edits should be grounded in the field content first. The broader accepted role list is still available to the prompt, but those routes do not use the stricter role-scoped batching/enforcement behavior used by the annex role flows.
What the Result Contains
Once the job reaches success, calling k12-annex-editing-result returns:
| Field | Description |
|---|---|
requestId | The tracking ID for this job |
sessionId | The session this job belongs to |
status | Terminal status (success or error) |
message | The edited annex content (HTML) |
isEdit | Boolean indicating whether the content was modified from the original |
If the status is error, the message field contains a description of what went wrong.
Idempotency and Duplicate Detection
Each job is uniquely identified by its requestId. If you submit a kickoff with a requestId that already exists, the system rejects the duplicate rather than creating a second job. This makes retries safe: if your kickoff call times out, you can re-send the same payload and either receive the existing job's tracking info or a clear duplicate-detection message.
When requestId is omitted, the system generates one automatically, so every call creates a new job.
Synchronous Mode
By default the kickoff returns immediately with status accepted. If you pass waitForResult: true, the call blocks until the job finishes and returns the full result payload (edited content, status, and metadata) in a single response.
Use synchronous mode when:
- Your consumer cannot poll (e.g., a single-request integration)
- The edit is expected to complete quickly
Use async mode when:
- You want to submit multiple edits in parallel
- You need to show progress to the user while the job runs
Cancellation
To cancel a pending or in-progress EOP editing job, call k12-cancel-task-request with the requestId. The tool marks the job as cancelled and stops further processing on a best-effort basis.
If the AI agent is mid-processing when cancellation is received, the current operation may complete before the job terminates. Always verify the final status via the status endpoint after issuing a cancel request.
For QRG generation and editing jobs, use k12-qrg-cancel instead.
Status Values
| Status | Meaning |
|---|---|
accepted | Job received and queued |
processing | AI agent is generating edits |
success | Editing complete; result available |
error | Processing failed; check the result message for details |
cancelled | Job was cancelled before completion |