An independent AI and automation learning roadmap

Learn skills you can carry between tools

Start with a small problem whose result you can inspect yourself. You do not need a Tvijo account, an MCP server, a paid model, or a particular editor to follow this roadmap. Paper worksheets, a text editor, and invented records are sufficient. The aim is to build judgment about tasks, evidence, and automation before choosing software. Completing an exercise means producing its stated artifact; it does not imply production readiness or a professional certification.

Use one fictional scenario throughout: a community workshop receives equipment requests. A coordinator checks completeness, assigns a category, and prepares a draft response. No exercise sends that response. Keep names, addresses, and prices fabricated so you can share your work without exposing personal or commercial data.

Stage one: describe the outcome

Write a short task card: actor, input, expected output, allowed actions, prohibited actions, and acceptance. For example, the actor is a workshop coordinator; the input is a request record; the output is a draft containing a category and a missing-information list. Allowed actions are reading the supplied records and drafting text. Sending messages, making purchases, and altering stock are outside the task.

Prepare three cases: complete request, missing quantity, and ambiguous equipment name. Write the expected behavior before consulting any assistant. Acceptance: a peer can decide whether the output passes without knowing which tool produced it. If “helpful” is the only criterion, revise the task into observable checks such as naming the missing quantity rather than inventing it.

Stage two: manage context and evidence

Create a tiny reference sheet defining categories and the workshop's invented rules. Give each rule an identifier and revision date. Ask a peer, or optionally a tool you already have permission to use, to classify a request using only that sheet. Require a rule identifier beside each conclusion. Include one request the sheet cannot resolve.

Acceptance: unsupported claims are marked unknown, a changed rule can be traced to its revision, and outside instructions embedded in a request do not override the task card. This teaches a transferable distinction: source material provides information, while the authorized task defines what the worker may do. More context is useful only when you can identify which part supports the decision.

Stage three: evaluate before automating

Make a small table of expected and observed outcomes for your cases. Record missing information, unsupported claims, and accidental actions separately. A fluent answer can still fail the task. Compare two approaches using the same records: a handwritten checklist and a draft produced by an optional assistant. Record the tool version if known, the date, and the exact input. A requested model name is not evidence of the model actually served.

Acceptance: you can reproduce the comparison, explain each failure, and identify a case where the worker should stop. Do not invent accuracy percentages from an undefined sample. A useful result may be that a deterministic checklist handles this problem adequately; using an AI system is not itself the learning goal.

Stage four: design an automation boundary

Draw a sequence in plain text: receive an invented record, validate required fields, classify it, prepare a draft, request review, and stop. Give each step an input, output, owner, and failure outcome. Specify how duplicate records are recognized. Describe a bounded retry only for a transient read failure; do not retry an external action blindly. Label every step as proposed until evidence shows it ran.

Acceptance: you can interrupt the process and explain what has already happened, what remains pending, and how a reviewer resumes safely. No credentials or live endpoints are required. The platform architecture guide helps later when a measured gap justifies choosing infrastructure.

Capstone: submit a reviewable packet

Collect the task card, reference sheet, cases, comparison table, and process diagram. Add open questions, source dates, and a short change log. Use the spec-driven packet guide to organize them without replacing your team's existing approval process. Ask a peer to review one successful case and one deliberately incomplete case. Acceptance: the reviewer can trace both outcomes to an input and criterion, and the incomplete case remains visibly unresolved.

Next, read the integration directory to assess a candidate interface, or data provenance guide to plan record handling. The existing knowledge practice and adoption paths pages are optional native wiki destinations; following this roadmap does not depend on their availability.

Sources and evidence limits

The roadmap and workshop exercises are original teaching designs, not vendor curriculum or copied source prose. No learner outcomes, live integrations, or comparative tool performance were measured here. An authenticated client connection is not verified. Current installation details, account rights, telemetry settings, and costs require separate checks if you later adopt a tool. You can complete the entire learning sequence offline.