Overview#
A multi-phase mission plan is only useful if teams can track exactly which steps are done, which are in progress, and which are blocked. The Operational Step domain provides that granularity: each step within a parent mission plan carries its own status, timing, and description, giving supervisors a clear view of progress without needing to read the entire plan.
Key Features#
- Step creation and management within parent mission plans
- Status tracking for each operational step
- Timing and scheduling information per step
- Step listing and detail retrieval for plan monitoring
- Ordered step sequencing for structured operational execution
Use Cases#
Relevant sectors include intelligence agencies, defence, and law enforcement.
- Tracking individual step completion within a larger mission plan
- Monitoring timing and progress across multi-phase operations
- Reviewing step-level details for operational oversight and reporting
Integration#
The Operational Step domain integrates with Mission Plan for parent plan context, Operations Log for activity logging, and Timeline for event sequencing.
Open Standards#
- GraphQL (June 2018 Specification): all queries, mutations, and type definitions for operational steps, templates, and history are exposed through a GraphQL API built with Strawberry, enabling interoperable introspection and client-driven data fetching.
- RFC 7519 (JSON Web Token): every GraphQL operation is authenticated by verifying an RS256-signed JWT against a JWKS endpoint; unauthenticated requests are rejected before any step data is accessed.
- RFC 6750 (OAuth 2.0 Bearer Token Usage): access tokens are transmitted as Bearer credentials and sanitised from logs under RFC 6750 conventions, governing how clients present authorisation credentials.
- ISO 8601: all temporal fields on operational steps, scheduled time (
at_time),created_at,updated_at, and auditchanged_at, are stored with timezone awareness and serialised as ISO 8601 strings. - RFC 4122 (UUID): every operational step, template, and history record is identified by a UUID v4 primary key, ensuring globally unique, collision-resistant identifiers across tenants.
- RFC 6455 (WebSocket Protocol): status changes are broadcast in real time to subscribed clients over persistent WebSocket connections, enabling supervisors to observe step progress without polling.
- RFC 8259 / ECMA-404 (JSON): field-level change records, previous and new state snapshots in the audit history, and AI suggestion context are all structured and exchanged as JSON objects.
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14