Project Brief: The Mission Blueprint

Module: 6: The Builder's Workshop: From Zero to Deployed AI Solution Lesson: 2: Mission Control: Applying Elite Systems Engineering to AI Projects

1. Objective

Your objective is to act as the lead systems engineer for a new, mission-critical AI feature. You will create a "Mission Blueprint"—a comprehensive project plan based on the NASA project lifecycle model. This document will detail every phase of the project, from stakeholder expectation management to the final verification and validation plan. This project will test your ability to apply a rigorous, disciplined engineering process to a complex AI system, ensuring it is set up for success from day one.

2. The Mission

Imagine you are the lead engineer at a major financial institution. The bank wants to deploy a new AI-powered feature in its mobile app called "Proactive Fraud Intervention." This feature will analyze a user's transaction patterns in real-time and, if it detects a high probability of fraud, will automatically freeze the user's account and send them an alert.

This is a mission-critical feature. If it fails (e.g., it fails to detect fraud), the bank and its customers could lose millions. If it has too many false positives (e.g., it constantly freezes legitimate accounts), it will cause massive customer frustration and damage the bank's reputation. Failure is not an option. The project must be managed with the utmost rigor.

Your mission is to create the Mission Blueprint that will guide the development of this feature.

3. Your Task

You will create a project plan that follows the key phases of the NASA Systems Engineering Lifecycle. You are not building the feature itself, but creating the detailed plan for how it would be built.

4. Key Requirements

Your Mission Blueprint must include the following sections, corresponding to the NASA lifecycle:

1. Stakeholder Expectations Definition:

   • Identify the key stakeholders for this project (e.g., Head of Fraud Prevention, Head of Customer Experience, Head of Legal & Compliance, the end-user/customer).
   • For each stakeholder, define their primary expectation or concern. What does success (or failure) look like from their perspective?

2. Technical Requirements Definition:

   • Translate the stakeholder expectations into a set of at least five specific, measurable, and testable technical requirements.
   • Example of a good requirement: "The system shall detect at least 99.5% of fraudulent transactions over $1000." or "The system shall have a false positive rate of no more than 0.1% (i.e., no more than 1 in 1000 legitimate transactions shall be incorrectly flagged as fraud)."

3. Logical Decomposition:

   • Break down the "Proactive Fraud Intervention" system into at least four major logical subsystems.
   • Example subsystems: A "Data Ingestion Engine" that processes transaction data, a "Risk Scoring Model" that analyzes the data, an "Account Freezing Mechanism" that interacts with the bank's core systems, and a "User Notification Service."

4. Design Solution Definition (High-Level):

   • For each of the subsystems you identified, write a brief, high-level description of the proposed design solution. You do not need to go into deep technical detail.
   • Example for the Risk Scoring Model: "We will use a Gradient Boosting Machine (XGBoost) model, trained on the last 5 years of historical transaction data. The model will be re-trained on a monthly basis." Justify your design choices and any significant trade-offs made (e.g., why XGBoost over a neural network for this specific problem).

5. Product Verification Plan:

   • This section answers the question: "How will we know if we built the thing right?"
   • For each of the technical requirements you defined in Step 2, describe the specific test you will run to verify that the system meets that requirement.
   • Example: "To verify the 99.5% detection rate, we will run the system against a curated test dataset of 1 million historical transactions, including 10,000 known fraudulent transactions."

6. Product Validation Plan:

   • This section answers the question: "How will we know if we built the right thing?"
   • Describe the plan for how you will validate that the final, working feature actually meets the stakeholders' expectations. This often involves a phased rollout or a pilot program.
   • Example: "We will first roll out the feature in 'silent mode' for one month, where it will flag suspicious transactions but not take any action. We will then run a two-week pilot program with a small group of 1,000 volunteer customers to gather feedback before a full launch."

5. Format and Deliverable

• Format: A single, well-structured Markdown document.
• Length: Approximately 1000-1500 words.
• Deliverable: A .md file named Mission_Blueprint.md.

7. Tips for Success

• Be Precise: Systems engineering demands precision. Use clear, unambiguous language in your requirements and descriptions.
• Think from the Stakeholder's Perspective: When defining expectations, put yourself in the shoes of each stakeholder. What truly matters to them?
• Visualize the Flow: Even if you don't create a formal diagram, mentally walk through the entire lifecycle. Does each phase logically lead to the next?
• Anticipate Failure: A good plan considers what could go wrong. Think about potential risks and how your verification and validation steps address them.

6. Evaluation Criteria

Your blueprint will be evaluated on the following criteria:

• Rigour and Specificity (50%):
  • How thorough and specific is your plan for each phase of the NASA lifecycle?
  • Are your technical requirements measurable, testable, and directly traceable to stakeholder expectations?
  • Is your verification and validation plan clear, robust, and does it effectively address both "building the thing right" and "building the right thing"?
• Systems Thinking (30%):
  • How well did you deconstruct the problem into logical subsystems and define their interfaces?
  • Does your plan show a clear understanding of the relationships and dependencies between the different parts of the project?
  • Does it demonstrate an ability to manage complexity effectively?
• Clarity and Professionalism (20%):
  • Is the document well-organized, professional in tone, and easy for a project stakeholder to understand and approve?
  • Is the language concise, impactful, and free of unnecessary jargon?
  • Does it effectively communicate the rigor of your engineering approach?