01: Task 1.1 Analyze Requirements and Design GenAI Solutions

AIP-C01 Mapping

Content Domain 1: Foundation Model Integration, Data Management, and Compliance Task 1.1: Analyze requirements and design GenAI solutions.

Task Goal

Turn ambiguous business goals into an architecture that is feasible, measurable, secure, and maintainable. In practice, this means deciding when the solution should be prompt-only, RAG-based, agentic, or customized, then validating those decisions before large-scale rollout.

Task User Story

As a GenAI solutions architect for MangaAssist, I want to translate product goals, operational constraints, and compliance requirements into a production-ready AWS architecture, So that the business gets a credible path from idea to launch instead of a demo that collapses under real traffic, governance, or cost pressure.

Task Architecture View

graph TD
    A[Business Problem] --> B[Requirement Discovery]
    B --> C[Capability Map]
    C --> D{Pattern Choice}
    D -->|Prompt-only| E[Simple FM Integration]
    D -->|RAG| F[Retriever + Vector Store]
    D -->|Agentic| G[Tools + Orchestrator]
    D -->|Customization| H[Fine-Tuned or Adapted Model]

    E --> I[POC Hypotheses]
    F --> I
    G --> I
    H --> I

    I --> J[Measure Quality Cost Latency Risk]
    J --> K[Reference Architecture]
    K --> L[Reusable Standards and Guardrails]
    L --> M[Implementation Backlog]

Scenario Packs

Task 1.1 now uses split scenario packs instead of one oversized runbook file per skill.

Each scenario file now includes design-review questions so you can use the pack for exam prep, architecture reviews, and interview drills.

Skill 1.1.1: Create Comprehensive Architectural Designs

User Story

As a principal solutions architect, I want to design a GenAI architecture that reflects business outcomes, user journeys, system dependencies, and technical limits, So that engineering teams build the right system the first time instead of overbuilding or under-designing the platform.

Deep Dive

The hardest part of GenAI architecture is not drawing boxes. It is making the right early decisions about where the intelligence should live.

For MangaAssist, a strong design would avoid a single giant "chatbot" box. Instead it would split the system into:

• Intent and routing layer for deciding whether the request needs retrieval, tools, or direct generation.
• Retrieval layer for product, policy, and support knowledge.
• Generation layer using Amazon Bedrock for response synthesis.
• Operational control layer for caching, guardrails, monitoring, and evaluation.

Architecture Deliverables

• Context diagram showing user entry points, Bedrock, data sources, and safety boundaries
• Capability map separating direct FM use, RAG, tool calling, and escalation
• NFR matrix covering latency, cost, availability, privacy, and auditability
• Decision log explaining why Bedrock-native models, custom models, or hybrid patterns were chosen
• Rollout plan describing MVP vs later-stage expansion

Acceptance Signals

• Architecture clearly maps every business capability to a runtime pattern
• Constraints such as latency budget, region, cost ceiling, and compliance are explicit
• The design identifies failure boundaries and fallback paths early
• Teams can derive implementation epics directly from the architecture

Skill 1.1.2: Develop Technical Proof-of-Concept Implementations

User Story

As a GenAI program lead, I want to run focused proof-of-concept experiments on Amazon Bedrock before full-scale delivery, So that we validate feasibility, value, and operating characteristics with evidence instead of intuition.

Deep Dive

A good POC is not a miniature product. It is a disciplined experiment that removes the largest unknowns first.

A Bedrock POC should usually include:

• A small but representative golden dataset
• One baseline design and one challenger design
• Instrumentation for latency, token usage, failure categories, and qualitative review
• Explicit exit criteria, including "do not proceed" conditions

POC Work Breakdown

1. Define the top 2-3 questions the program must answer.
2. Build only the minimum architecture needed to test those questions.
3. Capture outputs, logs, latency, and cost at request level.
4. Review results with both technical and business stakeholders.
5. Convert findings into a go/no-go decision or a narrowed next phase.

Common POC Failures

• Using perfect handpicked examples instead of realistic user traffic
• Measuring only demo quality while ignoring cost and latency
• Treating a prompt success as proof that the operating model is production-ready
• Skipping negative cases such as harmful inputs, partial data, or retrieval misses

Acceptance Signals

• Each POC is tied to explicit business and technical hypotheses
• Results include success cases, failure cases, and operating constraints
• The team can say what should scale, what should change, and what should be rejected
• The POC produces reusable artifacts such as prompt templates, test sets, and telemetry hooks

Skill 1.1.3: Create Standardized Technical Components

User Story

As a platform architect, I want to define reusable GenAI building blocks and governance standards, So that multiple teams can deliver consistent, safe, and supportable solutions without reinventing the core platform each time.

Deep Dive

Standardization is how a one-team success becomes an organizational capability.

Use the AWS Well-Architected Framework and the Generative AI Lens as a review checklist, not a paperwork exercise. They help ask the right questions:

• Is the system resilient when a model endpoint or region is degraded?
• Is the data pipeline observable and governed?
• Are prompts, models, and retrieval indexes versioned?
• Is there a clear mechanism for rollback and audit?

Standardization Artifacts

• Reference architecture diagrams
• Reusable IaC modules for model routing, guardrails, and logging
• Shared prompt and evaluation templates
• Security and privacy control checklists
• Design-review scorecards aligned to the Well-Architected pillars

Acceptance Signals

• New GenAI projects start from a standard blueprint instead of a blank page
• Teams use common metrics, logging shapes, and deployment gates
• Design reviews can quickly spot deviations from approved patterns
• Platform teams can upgrade or harden shared components centrally

Intuition Gained After Task 1.1

The biggest lesson from Task 1.1 is that GenAI architecture is decision architecture. The real work is choosing the right operating pattern for the problem, not adding an LLM to every step.

You also learn that a POC is valuable only when it reduces uncertainty. If it does not produce a sharper decision about quality, cost, latency, safety, or rollout risk, it is only a demo.

Finally, standardization changes the scale of your impact. A strong architect does not just design one solution. They create reusable components, review habits, and operating guardrails that let many teams build well at the same time.

References

• 04-architecture-hld.md
• 04b-architecture-lld.md
• Evaluation-Systems-GenAI/
• Security-Privacy-Guardrails/