Begin with this role orientation, then the embedded Python course. Continue through software, data, and AI application foundations before the customer-delivery modules. The roadmap teaches the technical prerequisites instead of sending beginners directly into discovery terminology.
Use a simulated support-team engagement throughout the later stages. Build a local document processor first, then an authenticated knowledge service, then a customer pilot with acceptance tests and an operational handoff. Label simulated business results clearly. Real customer data is not required to learn the process.
Everything is self-paced. Experienced engineers can use the foundation exit checks to skip what they can already demonstrate. Beginners should follow the sequence and revisit gaps before adding AI or enterprise complexity.
Exercise: create a portfolio folder for the problem brief, architecture, code, evaluation results, user feedback, and runbook. Write down your starting skills without inflating them.
Check: you know why programming and AI foundations come before integration and delivery, and which artifact will demonstrate each stage.
Follow one customer from discovery to handoff
The specialization uses Northstar Support, a fictional customer with two tenants and a request for faster support work. Its contradictory stakeholder requests, imperfect policies, integration failures, and rollout decisions connect the labs into one delivery simulation. Keep the same assumptions and artifact versions as you progress; changing the scenario silently makes the final evidence hard to assess.
Complete the technical foundation first unless you can demonstrate the shared knowledge assistant's request validation, retrieval, permissions, evaluation, and operational fallback. Experienced engineers can test out by reproducing those artifacts and explaining a failure case for each. Customer-facing work depends on understanding the system you are proposing.
Delivery sequence: discovery brief → baseline and success gates → architecture alternatives → data-readiness report → integrated prototype → access review → user acceptance → staged pilot → incident rehearsal → operator training → handoff → executive recommendation.
Use the lab role cards with a peer when possible. Working alone is valid for practice: label interviews, observations, signoff, and business results as simulated. Never turn an assumed time saving into a measured ROI statement. The objective is to learn an evidence-based delivery process, not to invent a customer success story.
Portfolio rule: retain rejected options, failed tests, customer objections, and changes in scope alongside the successful demo. They show how you make engineering decisions under ambiguity. A polished interface without a current-policy owner, an integration recovery plan, or an operator runbook is an unfinished engagement.
Checkpoint: at every handoff, name the next owner, the artifact they receive, and the decision it enables. If a pilot fails its gates, explain whether to narrow, revise, or stop it. Recommending less automation can be the correct outcome when the evidence supports it.