> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/technical-guidelines-code-standards-and-tech-stack/ai-assisted-project-conception.md). # AI-Assisted Project Conception ## Project Plan: Generative Artificial Intelligence-Assisted Project Definition and Delivery Setup ### 1. Purpose The purpose of this project is to establish a structured, repeatable process for taking raw customer, operational, commercial and technical context and converting it into a complete delivery-ready project baseline. The process will use human-in-the-loop review and generative artificial intelligence tooling to accelerate the creation of project documentation, knowledge structures, Azure DevOps work item hierarchies, architectural diagrams, technical design artefacts and feature breakdowns. The objective is not to replace project governance or technical assurance, but to create a controlled method for rapidly turning available information into structured, reviewable and delivery-ready outputs. ### 2. Project Objectives The key objectives are to: 1. Gather all available project requirements, background material, commercial context and technical assumptions. 2. Produce a human-in-the-loop project summary that clearly describes the project, proposal, intended outcomes, constraints and delivery approach. 3. Upload validated source material into a dedicated agentic artificial intelligence or GPT project workspace. 4. Use structured prompts to generate a complete brand, knowledge base and wiki hierarchy. 5. Generate a full Azure DevOps work item hierarchy in CSV format for import or manual population. 6. Generate supporting diagrams, including high-level design and low-level design artefacts. 7. Produce key feature breakdowns suitable for backlog creation, estimation, planning and phased delivery. 8. Ensure all generated outputs are reviewed, refined and approved before use as delivery artefacts. ### 3. Delivery Approach The project will follow a staged approach. Each stage will produce a tangible output that can be reviewed, improved and approved before moving into the next phase. The process will begin with information gathering and context consolidation. This will be followed by a human-in-the-loop review phase, where the core project narrative, assumptions and delivery intent are captured in clear language. Once this baseline has been approved, all validated material will be uploaded into a dedicated artificial intelligence project workspace as source material. The artificial intelligence workspace will then be used to generate structured project outputs, including wiki structures, Azure DevOps work item hierarchies, technical diagrams, feature breakdowns and supporting documentation. These outputs will be treated as draft material until reviewed by the project owner, technical lead and any required commercial, legal or security stakeholders. ### 4. Phase 1: Requirements and Context Gathering The first phase will focus on collecting all available material relating to the project. This should include customer requirements, proposal documents, emails, meeting notes, technical assumptions, commercial constraints, delivery risks, existing architecture, relevant standards, security considerations, acceptance criteria and known dependencies. The output from this phase should be a controlled requirements and context pack. This pack should contain the source material required to understand the project properly and should avoid relying on informal memory, disconnected notes or unsupported assumptions. #### Key Activities * Gather customer requirements and stated outcomes. * Collect all existing proposal and commercial material. * Review any Statements of Work, draft agreements, schedules or delivery obligations. * Capture known technical constraints and assumptions. * Identify security, compliance, assurance and data-handling requirements. * Capture existing architecture, platform and integration context. * Identify stakeholders and approval routes. * Record open questions, gaps and unresolved assumptions. #### Outputs * Requirements and context pack. * Assumptions log. * Open questions register. * Stakeholder list. * Initial risks and dependencies log. ### 5. Phase 2: Human-in-the-Loop Project Description The second phase will produce a clear human-reviewed description of the project. This will act as the controlling narrative for the artificial intelligence workspace and all downstream documentation. This paragraph or short section should explain what the project is, why it exists, what problem it solves, who it serves, what the intended outcome is, and what the delivery approach should be. It should also state any boundaries, exclusions, constraints and key assumptions. This human-in-the-loop step is essential because it prevents the artificial intelligence workspace from building the wrong structure from incomplete or misinterpreted information. The project owner should approve this text before it is used as the primary project context. #### Example Human-in-the-Loop Paragraph This project is intended to define, structure and prepare a delivery-ready project baseline for \[Project Name]. The project will consolidate all available requirements, commercial context, technical assumptions and delivery constraints into a controlled knowledge base, then use a dedicated generative artificial intelligence workspace to produce structured outputs including a project wiki hierarchy, Azure DevOps work item hierarchy, architecture diagrams, high-level design, low-level design and feature breakdowns. All outputs will remain subject to human review and approval before being used for delivery, estimation, governance or customer-facing purposes. The objective is to accelerate project mobilisation while maintaining clear human ownership over scope, assumptions, technical design and delivery commitments. #### Outputs * Approved project summary. * Confirmed scope statement. * Confirmed exclusions. * Confirmed assumptions. * Initial delivery narrative. ### 6. Phase 3: Upload Source Material to Agentic Artificial Intelligence / GPT Project The third phase will create a dedicated artificial intelligence project workspace. This workspace should be treated as a controlled source-backed assistant for the project. Only reviewed and relevant material should be uploaded. Source documents should be named clearly and organised logically so that the workspace can reason across them effectively. Where possible, source material should be grouped into requirements, commercial, technical, governance, legal, security, architecture and delivery categories. #### Key Activities * Create a dedicated artificial intelligence project workspace. * Upload the approved project summary. * Upload requirements and context material. * Upload proposal, Statement of Work or commercial documentation where applicable. * Upload architecture notes, diagrams or technical references. * Upload standards, compliance or assurance requirements. * Upload any brand, customer or operational context. * Confirm the assistant can reference the uploaded material accurately. #### Outputs * Dedicated project artificial intelligence workspace. * Uploaded and indexed source pack. * Controlled source list. * Initial validation prompt results. ### 7. Phase 4: Generate Brand, Wiki and Knowledge Hierarchy The fourth phase will use the artificial intelligence workspace to generate the project’s knowledge structure. This should include a complete wiki hierarchy suitable for use in Azure DevOps, SharePoint, Confluence, GitHub or another knowledge management platform. The structure should support project onboarding, governance, technical design, delivery execution, assurance, risk management and support. #### Suggested Prompt Using the uploaded project source material, create a complete project wiki hierarchy for this project. The hierarchy should be suitable for a professional delivery team working in a defence, national security, enterprise or high-assurance environment. Include sections for project overview, background, scope, stakeholders, requirements, architecture, high-level design, low-level design, security, risks, assumptions, decisions, delivery plan, testing, deployment, support and acceptance. Output the hierarchy in a clean nested format and include a short description for each page. #### Outputs * Full wiki hierarchy. * Page descriptions. * Recommended knowledge management structure. * Suggested ownership model for key pages. ### 8. Phase 5: Generate Azure DevOps Work Item Hierarchy The fifth phase will generate a complete Azure DevOps work item structure that can be imported, reviewed or manually populated. The hierarchy should include epics, features, user stories, tasks and acceptance criteria. For larger projects, the output should also include dependencies, priorities, proposed iterations and tags. The CSV output should be structured so it can be transformed into Azure DevOps import format or used as a backlog creation guide. #### Suggested Prompt Using the uploaded project source material and the approved project summary, generate a full Azure DevOps work item hierarchy. Include epics, features, user stories and tasks. For each item include title, description, parent, work item type, priority, area path, iteration path, tags, acceptance criteria and dependencies. Output the result as a CSV-ready table suitable for import preparation. #### Recommended CSV Columns * Work Item Type * Title * Description * Parent Title * Area Path * Iteration Path * Priority * Tags * Acceptance Criteria * Dependencies * Notes #### Outputs * Azure DevOps hierarchy. * CSV-ready backlog table. * Epic and feature map. * User story breakdown. * Task-level delivery structure. * Acceptance criteria draft. ### 9. Phase 6: Generate Diagrams, High-Level Design and Low-Level Design The sixth phase will focus on technical design artefacts. The artificial intelligence workspace should be asked to produce diagrams and supporting design documentation based on the uploaded source material. These should be treated as draft design artefacts until reviewed by the technical authority. Typical outputs should include context diagrams, system architecture diagrams, component diagrams, data flow diagrams, deployment diagrams, integration diagrams, sequence diagrams and security boundary diagrams. #### Suggested Prompt Using the uploaded source material, generate the required technical design artefacts for this project. Include a high-level design, low-level design, system context diagram, component architecture, data flow diagram, deployment view, integration view and security boundary view. Where diagrams are required, provide Mermaid syntax and a written explanation for each diagram. Clearly identify assumptions, unknowns and areas requiring technical validation. #### Outputs * High-level design. * Low-level design. * System context diagram. * Component diagram. * Data flow diagram. * Deployment diagram. * Integration diagram. * Security boundary diagram. * Design assumptions register. * Technical decisions log. ### 10. Phase 7: Generate Key Feature Breakdowns The seventh phase will produce detailed feature breakdowns for planning, estimation and delivery sequencing. Each feature should include the user need, business value, functional requirements, non-functional requirements, dependencies, acceptance criteria, risks and testing considerations. This phase should support product ownership, sprint planning, estimation, architecture validation and delivery governance. #### Suggested Prompt Using the uploaded project source material and the generated Azure DevOps hierarchy, produce detailed feature breakdowns for each key feature. For each feature include the purpose, user need, business value, functional requirements, non-functional requirements, dependencies, assumptions, risks, acceptance criteria, test considerations and recommended delivery sequence. #### Outputs * Feature breakdown catalogue. * Functional requirement mapping. * Non-functional requirement mapping. * Acceptance criteria. * Test considerations. * Delivery sequencing recommendations. * Dependency map. ### 11. Phase 8: Review, Validation and Approval All artificial intelligence-generated outputs must be reviewed before being used as formal delivery artefacts. The review process should include project ownership review, technical review, commercial review where applicable, security review where required and customer review where appropriate. Any gaps, assumptions, hallucinations or unsupported content should be corrected before the artefacts are baselined. #### Key Activities * Review all generated artefacts against source material. * Remove unsupported assumptions. * Confirm scope and exclusions. * Validate technical design. * Validate work item hierarchy. * Confirm acceptance criteria. * Confirm delivery sequencing. * Record decisions and changes. * Baseline approved outputs. #### Outputs * Approved wiki hierarchy. * Approved Azure DevOps backlog. * Approved high-level design. * Approved low-level design. * Approved feature breakdowns. * Updated risks, assumptions, issues and dependencies log. * Baselined delivery pack. ### 12. Governance and Controls The project should remain under human control at all times. Artificial intelligence-generated outputs should support analysis, structure and acceleration, but should not be treated as automatically approved or contractually binding. Where the project relates to customer delivery, commercial obligations, legal documents, security requirements or regulated environments, all outputs must be reviewed by the relevant accountable person before release or use. The following controls should apply: * No customer-facing output should be issued without human review. * No work item should be treated as in-scope unless aligned to the approved scope or Statement of Work. * No technical design should be treated as approved until reviewed by the technical lead. * No legal, commercial or contractual interpretation should be used without appropriate review. * All assumptions must be recorded and tracked. * All major changes must pass through change control. * All acceptance criteria must be agreed before delivery starts. ### 13. Recommended Final Deliverables The final delivery pack should include: 1. Project summary and scope statement. 2. Requirements and context pack. 3. Assumptions, risks, issues and dependencies log. 4. Stakeholder map. 5. Wiki hierarchy. 6. Azure DevOps work item hierarchy CSV. 7. Epic, feature, story and task breakdown. 8. High-level design. 9. Low-level design. 10. Mermaid diagrams. 11. Feature breakdown catalogue. 12. Acceptance criteria catalogue. 13. Test considerations. 14. Delivery roadmap. 15. Review and approval record. ### 14. Success Criteria The project will be successful when: * All source material has been gathered and structured. * A human-reviewed project summary has been approved. * A dedicated artificial intelligence project workspace has been created and populated. * A complete wiki hierarchy has been generated and reviewed. * A complete Azure DevOps work item hierarchy has been generated in CSV-ready format. * Key diagrams, high-level design and low-level design artefacts have been produced. * Feature breakdowns are complete enough to support estimation and delivery planning. * All outputs have been reviewed, corrected and baselined. * The delivery team can move from project discovery into structured execution with clear scope, backlog, design and governance. ### 15. Immediate Next Steps 1. Create the initial requirements and context pack. 2. Draft and approve the human-in-the-loop project description. 3. Create the dedicated artificial intelligence project workspace. 4. Upload all validated source material. 5. Generate the wiki hierarchy. 6. Generate the Azure DevOps work item hierarchy. 7. Generate diagrams and design artefacts. 8. Generate key feature breakdowns. 9. Review, correct and baseline the outputs. 10. Move approved items into the delivery environment.