Mission Control ¶

Mission Control is an autonomous work orchestration system on top of Jira.

Its purpose is to connect AIOE Intake Demand to Implementation Work so requests can move from idea to deliverable with less manual task management.

The high-level model is intentionally simple:

One AIOE Intake request can create one or more implementation epics.
Each implementation epic contains the Jira tasks needed to deliver that part of the request.
When the defined outcome measurements have met the expected targets, the intake request is considered complete.

Three Pillars ¶

Mission Control provides visibility across three connected pillars: AIOE Intake, Execution, and Outcomes.

Pillar	Entity in Jira	Mission Control signal	Expectation
AIOE Intake	Intake Epic	`REQ_SOPT_AIOE` plus one `INTAKE_*` lifecycle label	A team requests automation, tooling, integration, reporting, or operational improvement. It should be well-defined and qualified, with clear outcome measurements, enable effective prioritization and delivery decisions.
Execution	Implementation Epic and child Issues	Implementation Epics are linked and tracked from the Intake Epics	Approved demand is converted into accountable delivery.
Outcomes	Deliverable validation child Issues under the implementation Epic	Deliverable validation child Issues are linked and tracked from the Intake Epics	The shipped result from the execution. The implementation Epics include the works collecting measurements too and an Intake request is considered complete only when its expected business outcomes have been achieved.

AIOE Intake ¶

The Intake pillar answers whether a request is understandable, valuable, and ready for a decision. Demand is captured through the intake request form and refined through the intake lifecycle until the problem, value, scope, and outcome measurements are clear. Incomplete requests stay in INTAKE_TUNING until they are corrected.

Execution ¶

The Execution pillar converts approved demand into accountable delivery work. Each intake links to the Epics and Issues that deliver it, with a clear owning team and assignee. When delivery work is created, the intake moves to INTAKE_COMMITTED; if a dependency outside the request scope blocks commitment, it moves to INTAKE_BLOCKED instead. The entity model, mapping, and responsibilities in the rest of this page detail how Execution is tracked.

Outcomes ¶

The Outcomes pillar begins during Intake, not after delivery. Each request defines its expected outcome — baseline metric, target metric, ROI estimate, and operational impact such as MTTR or incident reduction — as part of the Success Measurement section, then compares actual results after delivery. This lets Mission Control distinguish delivered work from demonstrated business value.

High-Level Jira Entity Model ¶

flowchart TD
    A[Intake Request] --> B{Ready for implementation?}
    B -->|Needs clarification| C[Intake refinement]
    C --> A
    B -->|Approved| D[Implementation Epic 1]
    B -->|Approved| E[Implementation Epic 2]
    B -->|Approved| F[Implementation Epic N]

    D --> D1[Jira task]
    D --> D2[Jira task]
    E --> E1[Jira task]
    E --> E2[Jira task]
    F --> F1[Jira task]

    D1 --> G[Deliverable]
    D2 --> G
    E1 --> G
    E2 --> G
    F1 --> G

    style A fill:#dbeafe,color:#0f172a
    style D fill:#fef3c7,color:#0f172a
    style E fill:#fef3c7,color:#0f172a
    style F fill:#fef3c7,color:#0f172a
    style G fill:#dcfce7,color:#0f172a

Responsibilities ¶

Mission Control makes the relationship between Arch Office, Scrum Team, and delivery work explicit.

Area	PO	Arch Office	Scrum Team	Mission Control
PO Intake Review	Clarify and prioritize Intakes based on their business value, customer impact and delivery urgency.			Show intake status and priority.
Arch Office Review	Work with the Arch Office to refine requirements and define project scope. Communicate with customers to reach agreement on scope and key decisions.	Conduct architecture reviews, assess technical feasibility, estimate implementation effort, identify dependencies, and route approved intakes to four Scrum teams.		Show intake status and priority.
Implementation Epic Creation		Define the high-level implementation split. Assign an assignee (implementation owner) and a coach (mentor/support).		Link each implementation Epic back to the intake.
Task Breakdown		Provide architecture context, constraints, and required standards.	Break implementation Epics into Jira tasks and estimate delivery effort.	Keep task progress visible at the intake level.
Delivery Tracking	Follow up the progress and make sure the project goes to correct direction.	Review major risks, dependencies, and architecture-impacting changes.	Execute tasks, update Jira, resolve blockers, and deliver committed work.	Summarize progress, blockers, and delivery health across linked epics and tasks.
Deliverable Validation	Confirm the deliverable satisfies the success measurements.	Confirm the delivered solution satisfies the architectural intent.	Demo, test, document, and release the deliverable.	Connect the final deliverable back to the originating intake.

Mission Control vs Jira ¶

System	Primary role
Jira	Execution engine for implementation epics, tasks, owners, workflow, and sprint tracking.
Mission Control	Orchestration layer that connects intake requests to implementation epics, Jira tasks, responsibilities, and deliverables.

Mission Control should not duplicate Jira as another task board. It should answer the questions that are hard to answer from Jira alone:

Which intake request created this implementation epic?
Which epics and tasks are required to deliver this intake?
Who owns the architecture direction?
Which scrum team owns execution?
What deliverable will close the request?