Storage
Keep approved documents and permitted ticket data in controlled stores. Decide ownership, retention and who can read them.
NERIYA FREE LEARNING LAB · AI + DATA + CLOUD
Build the thinking behind a useful AI system.
Follow one support-team mission from a business problem to a design, a test and a recovery plan. Learn what the components do, why they matter and how to explain your decisions.
A support inbox is growing. What should the team build?
Our fictional company, Cedar Support, receives messages about billing, access and service faults. Staff spend time sorting messages and finding the right guidance. Your mission is to help them respond consistently while keeping people responsible for important decisions.
Your brief
Propose a system that suggests a ticket category, retrieves an approved support article and drafts a response for a person to review. Keep sensitive information out of the learning exercise.
First write the problem in ordinary language: “We want staff to find useful information faster.” Do not begin with a list of services. Decide how you would measure improvement, which mistakes matter most and when a person must take over.
Your evidence: a one-paragraph problem statement, a success measure and a list of decisions reserved for people. This is an original paper-based learning scenario; it does not provision cloud resources or run a live AI model.
Cloud supplies the environment. Your design supplies the boundaries.
Cloud computing provides resources such as storage, processing and networking through a service provider. Physical hardware still exists; the provider operates some layers while your team remains responsible for its own configuration, data and application behavior.
Compute and model access
Run application logic and access a prediction or generation service. Choose resources after defining response-time and cost needs.
Networking and identity
Define how components communicate and which users or services may access them. Grant only the access needed for the task.
Monitoring
Record enough to investigate failures and costs while avoiding unnecessary sensitive content in logs.
Your evidence: annotate the diagram with each component’s owner, input, output and likely failure.
Useful AI starts with information you can explain.
For category prediction, examples need consistent labels. For a document assistant, articles need clear owners and current versions. These are different data needs; a folder of documents is not automatically a training dataset.
ticket_id,message,expected_category
T01,"I need a copy of my invoice",billing
T02,"My password reset link expired",access
T03,"The status page is unreachable",serviceThese fictional rows illustrate a structure, not a dataset large enough to prove a model works. Add varied wording and ambiguous cases before evaluating an approach.
- Write label definitions. Explain how “access” differs from a service outage.
- Remove duplicates and check empty fields. Decide how to handle an unclear message.
- Keep a separate set of examples for evaluation. Do not tune your approach on every example and then report success on those same examples.
- Check permissions and document origin. Use fictional or approved data for practice.
Your evidence: a small data dictionary, a labeling guide and an explanation of what information you would keep out.
Three tools, three different responsibilities.
| Method | Where it helps in our mission | What to test |
|---|---|---|
| Explicit rule | Route a message with an exact account identifier to an existing queue. | Whether the rule matches valid cases and avoids unintended matches. |
| Machine learning | Suggest a category from varied wording using learned patterns. | Per-category performance, confusing examples and behavior on unseen messages. |
| Generative AI | Draft a response using permitted supporting material. | Whether claims are supported, the tone is appropriate and unknowns are handled honestly. |
Retrieval-augmented generation, or RAG, supplies relevant material as context for generation. Retrieval is not the same as retraining the model, and adding sources does not guarantee a correct answer.
Your evidence: explain why a category prediction and a response draft should not be evaluated with the same checklist.
A convincing demo needs a failure test.
Test ordinary messages, ambiguous requests and situations with no approved answer. Compare the proposed approach with a simple baseline, such as current manual routing. Decide success criteria before inspecting the results.
Prediction checks
Track which categories are confused. Overall accuracy can hide poor performance on a rare but important category. Count examples and explain the limits of your small test.
Drafting checks
Review factual support, missing details, harmful assumptions and appropriate escalation. A fluent answer can still be wrong.
Worked example: an unsupported claim
The approved article says, “Staff may request an invoice copy through the billing portal.” A draft says, “Your payment has been refunded.” The draft invents a completed action and must fail the review, even if its tone is friendly.
Your evidence: five test cases, expected behavior, observed behavior and one change motivated by a failure.
Keep the system useful when conditions change.
Define who responds to slow requests, outdated documents and incorrect suggestions. Keep version information for the application, model and sources. Establish a route back to manual processing when the system cannot be trusted.
- Quality: sample reviewed outputs and investigate recurring errors.
- Reliability: measure response time and failed requests; set an escalation route.
- Cost: measure usage and spending against the value of the task.
- Change: test updated articles or models before expanding their use.
- Access: check that a user cannot retrieve documents outside their permission boundary.
Thinking ahead
More capable models and agents can change what you build, but they do not remove the need for ownership, testing and recovery. Treat future capabilities as hypotheses to evaluate rather than guarantees.
Your evidence: a short runbook listing the symptom, first checks, fallback and responsible person.
Stop at each question before opening the model answer.
Exercise 1 · Classify or generate?
A manager wants a ticket category and a polite explanation to the customer. Which output is a prediction, and which is generation?
Reveal a model answer
The category is a prediction. The explanation is generated language. Both need evaluation, but they answer different questions: “Is the category suitable?” and “Is the explanation accurate and supported?”
Exercise 2 · Find the permission problem
A document assistant retrieves a restricted employee handbook for every visitor. Does adding a source citation solve the problem?
Reveal a model answer
No. A citation does not authorize access. Enforce permissions before retrieving or showing the material, and test users with different access levels.
Exercise 3 · Write a recovery step
The category service stops responding. What should staff see?
Reveal a model answer
A clear status and a manual routing option. Avoid silently inventing a category. Record a permitted error event and direct the incident to its owner.
Exercise 4 · Create your portfolio note
Explain the mission in five sentences: problem, design choice, test, failure and improvement. Do not claim to have deployed a system if you only completed a paper exercise.
Reveal a model answer
“I designed a fictional support-assistant workflow to help staff find approved guidance. I separated category prediction from response drafting. I wrote tests for unsupported claims and access boundaries. One draft claimed a refund without evidence, so I marked it as a failure. I added a requirement to check claims and escalate when evidence is missing.”
Bring your design and questions to the Free Neriya Tech Community. You can read this lab freely; sign in to join community conversations.
Start with the responsibility you want to own.
Build your foundations
Choose this route if programming, data or model evaluation is new to you.
AI/ML Foundations & Python →Build on a cloud platform
Explore infrastructure first, then connect it to AI applications.
Cloud Engineering paths →AWS and Azure AI/ML paths →
Own reliable AI operations
Develop the engineering foundation before specializing in deployment and monitoring.
Agentic AI & MLOps Engineering →Own governance and product decisions
Explore requirements, oversight, accountability and useful outcomes.
AI Governance & Assurance →AI Product Owner →
Questions learners often ask
Do I need a cloud account to complete this resource?
No. This orientation uses diagrams, fictional examples and paper exercises. A later deployment lab would need provider-specific instructions, access and a spending plan.
Does cloud replace the need to understand machine learning?
No. Managed tools can reduce infrastructure work, but you still need to understand the problem, data, evaluation and limitations of the approach.
Should I learn every provider at once?
Use one environment for an initial project and learn its responsibilities well. Compare other environments when you can explain your first design.
What can I show after finishing?
A mission brief, annotated architecture, data dictionary, test cases and recovery note. These are evidence of the exercise you completed, not proof of production experience.
Sources and further reading
Explore the official technical documentation below to continue learning.