# Make Mula: useful work, honest offers Open Practice / Make Mula / curriculum 1.0 Estimated guided practice: 4h estimated. This estimate has not been learner-tested. Original practice material · CC BY 4.0 · Non-degree and non-accredited. ## What you will build Decide from actual evidence with inputs, tests and a reproducible handoff. ## Before you start - Portfolio capstone; inspect the worked fixture before beginning. - A text editor/spreadsheet for the manual route. Hosted Python/Jupyter for code exercises; applicable dependencies are in requirements.txt. - For actual AI calls, a legitimate available cloud service and authorised learner credentials; no particular provider or country is mandatory. ## Learning outcomes - Ask three consenting potential users about their current workaround; keep simulations explicitly labelled. - Choose checked reports, approved replies, verified content or a tiny web tool. - Include selling and support time, fees, rework and refund assumptions. - Verify regional payout and identity rules, then use a small appropriate personalised approach with opt-outs. - Keep a reproducible result and disclose safety, rights and regional access limits. ## Activity 1: Find a problem through discovery Estimated time: 35 minutes. ### Outcomes - Ask three consenting potential users about their current workaround; keep simulations explicitly labelled. - Explain and retain a testable result and its limits. An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Ask three consenting potential users about their current workaround; keep simulations explicitly labelled. Inspect the supplied input before using any tool. Write the decision rules in your own words and calculate one small result independently. The reference output is an answer key for this deliberately bounded fixture, not proof of general capability. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. For learners across regions underserved or excluded by mainstream providers: verify country eligibility, language, account/identity requirements, data terms, cost, quota and connectivity before choosing a cloud service. Use only legitimate available alternatives; never bypass restrictions or invent a country/account. No service access? Complete the labelled manual/fixture route without claiming a live AI run. Project clinic: Discovery is listening before proposing automation. Ask about the most recent time the task occurred: what triggered it, who did it, how long it took, what went wrong and what the consequence was. Avoid leading questions such as 'Would you pay for my AI tool?' Ask permission to keep anonymous notes; do not record private documents or collect payment details. Three conversations reveal hypotheses, not a representative market. ### Worked example ```text CONSTRUCTED DISCOVERY NOTE — NOT A REAL CUSTOMER Role: owner of a fictional repair shop. Recent task: copied five enquiry messages into a weekly job list. Current workaround: paper notebook; owner checks every entry. Problem hypothesis: duplicate transcription and missing appointment dates. Unproven: willingness to pay, available budget, accessible payout route. NEXT QUESTION: 'Can you describe the last time a missing date caused a problem?' ``` ### Guided activity 1. Ask three consenting potential users about their current workaround; keep simulations explicitly labelled. 2. Open input.json and expected.json from the practice pack; keep an unmodified original. 3. Record a manual prediction and the relevant rule before consulting the answer key. 4. Perform one small change and predict its effect before rerunning. 5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live. 6. Use the discovery guide in market-evidence.md for three permission-based conversations, or clearly label a rehearsal; separate exact observations from your interpretation. ### Expected evidence - Find a problem through discovery — a saved, inspectable artefact tied to the supplied rule. - A baseline or change-test record with expected/observed results and a limitation. ### Common mistakes - Add a 10-unit refund: net becomes 15 and hourly return 3.75. - Treating a supplied answer key, an authored example or self-review as independent field validation. ### Check your understanding Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested? ### Offline route Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run. ## Activity 2: Build and break one sample Estimated time: 35 minutes. ### Outcomes - Choose checked reports, approved replies, verified content or a tiny web tool. - Explain and retain a testable result and its limits. An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Choose checked reports, approved replies, verified content or a tiny web tool. Establish a baseline before changing prompts or code. Keep the original input immutable. Record expected values, observed values and whether each comparison passed. If the expected file conflicts with a justified policy, investigate rather than forcing a convenient match. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Choose one lane, not a general AI agency: a checked report, approved reply pack, verified content pack or tiny web calculator. Write acceptance criteria before building. A report buyer might require totals that reconcile, visible rejected rows and a readable one-page explanation. Make the same sample manually first so speed and accuracy can be compared. A synthetic shop example remains a portfolio demonstration until a real buyer supplies authorised requirements. ### Worked example ```text SAMPLE OFFER LANE — CHECKED WEEKLY REPORT Input: a fictional three-row expense table; no private customer records. Deliverables: unchanged source.csv, checked summary.csv, a one-page report and rejection log. Acceptance: category subtotals equal the grand total; unsupported causes are omitted. CHANGE TEST: add one valid row; the total and narrative must both update. NOT CLAIMED: a real customer, saved labour or earned revenue. ``` ### Guided activity 1. Choose checked reports, approved replies, verified content or a tiny web tool. 2. Open input.json and expected.json from the practice pack; keep an unmodified original. 3. Record expected and observed values separately; explain every mismatch. 4. Perform one small change and predict its effect before rerunning. 5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live. 6. Select an existing Open Practice report, replies, editing or web project; create the deliverables and write three buyer-readable acceptance criteria. ### Expected evidence - Build and break one sample — a saved, inspectable artefact tied to the supplied rule. - A baseline or change-test record with expected/observed results and a limitation. ### Common mistakes - No paid order obtained: record zero earned income, not the hypothetical price. - Treating a supplied answer key, an authored example or self-review as independent field validation. ### Check your understanding Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested? ### Offline route Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run. ## Activity 3: Price the full workflow Estimated time: 35 minutes. ### Outcomes - Include selling and support time, fees, rework and refund assumptions. - Explain and retain a testable result and its limits. An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Include selling and support time, fees, rework and refund assumptions. Build one inspectable transformation or bounded AI prompt. Keep calculation and validation deterministic where possible. If you make a permitted hosted call, save the actual response separately from the authored examples and verify its material claims; the supplied reference never simulates a live model. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Pricing is a hypothesis, not a number copied from an income guide. In the fixture, a price of 30 minus tool cost 3 and fees 2 leaves 25 before tax. Four hours include two delivering, one selling and one supporting, so the effective return is 6.25 per hour before tax. Equipment, connectivity, foreign-exchange charges and additional rework may reduce it further. A refund of 10 leaves 15 and changes the return to 3.75. If no one pays, earned income is zero. ### Worked example ```text HYPOTHETICAL ECONOMICS — GENERIC CURRENCY UNITS Price: 30; tools: 3; transaction fees: 2. Net before tax: 30 - 3 - 2 = 25. Time: delivery 2h + selling 1h + support 1h = 4h. Effective hourly return before tax: 25 / 4 = 6.25. Refund scenario: (25 - 10) / 4 = 3.75. These are assumptions to test, not a quoted market price or earnings result. ``` ### Guided activity 1. Include selling and support time, fees, rework and refund assumptions. 2. Open hosted-lab.ipynb and the reference code from the practice pack; keep an unmodified original. 3. Record expected and observed values separately; explain every mismatch. 4. Perform A marketplace unavailable in the learner region is a stop condition until a legitimate route is verified. 5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live. 6. Run the supplied cost fixture, then add your own clearly labelled cost assumptions and one refund/rework scenario; do not enter bank or identity documents. ### Expected evidence - Price the full workflow — a saved, inspectable artefact tied to the supplied rule. - A baseline or change-test record with expected/observed results and a limitation. ### Common mistakes - A marketplace unavailable in the learner region is a stop condition until a legitimate route is verified. - Treating a supplied answer key, an authored example or self-review as independent field validation. ### Check your understanding Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested? ### Offline route Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run. ## Activity 4: Check access and test the offer Estimated time: 35 minutes. ### Outcomes - Verify regional payout and identity rules, then use a small appropriate personalised approach with opt-outs. - Explain and retain a testable result and its limits. An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Verify regional payout and identity rules, then use a small appropriate personalised approach with opt-outs. Change one assumption at a time and predict the result first. Retain the failure, the revision and the rerun evidence. A failure is useful information: hiding a bad output or editing a test target after seeing the answer destroys the value of the experiment. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Check access before accepting money: seller-country eligibility, supported receiving method, identity and business requirements, currencies, fees, payout timing and refund handling. Record the official source and date, not a guessed green tick. A locally agreed lawful payment route may be more practical than an unavailable global marketplace, but it still needs verification. Outreach must be appropriate, truthful and small enough to personalise. Mention a demonstration as a demonstration; never claim past clients or savings you have not established. ### Worked example ```text ORIGINAL OUTREACH EXAMPLE — USE ONLY WHEN TRUE Hello [name], I noticed [specific publicly visible task relevant to their work]. I made a small demonstration of [bounded deliverable] using fictional data. I do not know whether it fits your process. Would you be open to a brief look and a question about how you handle this now? No problem if not; I will not add you to a sequence. BEFORE A PAID OFFER: verify the legitimate receiving route and agree scope. LOG: permission, response, objection and next step—not assumed conversion rates. ``` ### Guided activity 1. Verify regional payout and identity rules, then use a small appropriate personalised approach with opt-outs. 2. Open failure-tests.md from the practice pack; keep an unmodified original. 3. Record expected and observed values separately; explain every mismatch. 4. Perform Add a 10-unit refund: net becomes 15 and hourly return 3.75. 5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live. 6. Complete access-check.csv using dated official sources; prepare one truthful personalised approach and record actual responses or an explicitly untested offer. ### Expected evidence - Check access and test the offer — a saved, inspectable artefact tied to the supplied rule. - A baseline or change-test record with expected/observed results and a limitation. ### Common mistakes - Add a 10-unit refund: net becomes 15 and hourly return 3.75. - Treating a supplied answer key, an authored example or self-review as independent field validation. ### Check your understanding Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested? ### Offline route Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run. ## Activity 5: Deliver ethically and hand over Estimated time: 35 minutes. ### Outcomes - Define scope, approvals, rights, revisions, accounting boundaries and support. - Explain and retain a testable result and its limits. An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Define scope, approvals, rights, revisions, accounting boundaries and support. Review what the fixture cannot establish. Explain who owns the decision, where human approval is needed and which access or professional constraints remain. Do not describe a small educational success as production readiness, certification, legal compliance or a guarantee. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. For learners across regions underserved or excluded by mainstream providers: verify country eligibility, language, account/identity requirements, data terms, cost, quota and connectivity before choosing a cloud service. Use only legitimate available alternatives; never bypass restrictions or invent a country/account. No service access? Complete the labelled manual/fixture route without claiming a live AI run. Supporting practice — Ethical records and professional boundaries: Keep revenue, costs, unpaid time and refunds separate. Preserve consent, client approval and conflicts of interest. Do not describe an educational price sheet as accounting, audit or tax advice. Applicable obligations depend on jurisdiction; involve a qualified professional when required. Add a dated cost ledger, confidentiality rule, conflict disclosure and a professional-review boundary. Project clinic: Delivery requires agreement on inputs, scope, acceptance, revisions, payment and maintenance. Ask permission before sending client data to any cloud service; a client saying 'use AI' is not a blanket data-processing agreement. Keep a private cost ledger and record refunds accurately. Use the offer template to exclude medical, legal, tax, investment, safety and employment decisions. Hand over an exportable result and explain which changes need fresh checking; do not lock a learner or buyer into an undisclosed subscription. ### Worked example ```text SCOPE EXAMPLE — NOT A LEGAL CONTRACT Included: one fictional CSV-to-summary demonstration, checked totals, README and one revision. Excluded: bookkeeping, tax filing, live account access, autonomous messages and ongoing hosting. Acceptance: source totals reconcile; rejected rows and limitations are visible. Authority: buyer reviews before use; no external action without separate approval. Support boundary: fix agreed defects for the stated period; new requirements are a new scope. Use qualified local advice for actual contracts and obligations. ``` ### Guided activity 1. Define scope, approvals, rights, revisions, accounting boundaries and support. 2. Open README.md and your evidence log from the practice pack; keep an unmodified original. 3. Record the human decision owner, limitations and any untested service access. 4. Perform one small change and predict its effect before rerunning. 5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live. 6. Add a dated cost ledger, confidentiality rule, conflict disclosure and a professional-review boundary. 7. Complete offer-template.md and handoff-checklist.md; retain approvals, record conflicts and keep professional advice outside the offer. ### Expected evidence - Deliver ethically and hand over — a saved, inspectable artefact tied to the supplied rule. - A baseline or change-test record with expected/observed results and a limitation. - Add a dated cost ledger, confidentiality rule, conflict disclosure and a professional-review boundary. ### Common mistakes - No paid order obtained: record zero earned income, not the hypothetical price. - Treating a supplied answer key, an authored example or self-review as independent field validation. ### Check your understanding Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested? ### Offline route Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run. ## Activity 6: Decide from actual evidence Estimated time: 65 minutes. ### Outcomes - Record acceptance, refunds and net return if a paid pilot occurred; otherwise report the real market-test result without invention. - Explain and retain a testable result and its limits. An offer connects a narrow customer problem to a checked deliverable and a price hypothesis. AI does not create demand. Learn through real permission-based discovery where possible, but label rehearsals and never fabricate sales, experience or testimonials. Record acceptance, refunds and net return if a paid pilot occurred; otherwise report the real market-test result without invention. Deliver a reproducible bundle rather than a screenshot alone. Include inputs, rules, output, failure tests, a short README and residual limitations. Ask another person to follow the instructions if possible; self-review and actual external review must be labelled separately. Policy for this project: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Project clinic: Decide from evidence rather than the excitement of a launch. Track conversations, relevant interest, offers, paid orders, accepted deliveries, refunds, costs and time as separate stages. A friend praising a demo is not a paid customer. A paid pilot is stronger evidence than an intention to buy, but one sale does not establish typical income or repeatable demand. If no buyer agrees, document the obstacle and choose a smaller test, a different problem or a stop decision. Completion rewards honest work and learning, not earning at any cost. ### Worked example ```text CONSTRUCTED DECISION RECORD — NOT ACTUAL RESULTS Conversations: 3; offer discussions: 1; paid orders: 0. What is supported: one person agreed to discuss the problem. What is NOT supported: demand at the proposed price, a repeatable sales channel or any earned income. Decision: revise the sample around the observed missing-date problem and retest once. If a real paid pilot occurs: log acceptance, refunds, actual costs and time with permission; redact identifying details. ``` ### Guided activity 1. Record acceptance, refunds and net return if a paid pilot occurred; otherwise report the real market-test result without invention. 2. Open README.md and your evidence log from the practice pack; keep an unmodified original. 3. Record the human decision owner, limitations and any untested service access. 4. Perform one small change and predict its effect before rerunning. 5. Keep the result and your reasoning in the lesson notes; do not mark a simulated run as live. 6. Write continue/change/stop with evidence for and against; label real, constructed and untested evidence separately and record zero earned income when no payment occurred. ### Expected evidence - Decide from actual evidence — a saved, inspectable artefact tied to the supplied rule. - A baseline or change-test record with expected/observed results and a limitation. ### Common mistakes - A marketplace unavailable in the learner region is a stop condition until a legitimate route is verified. - Treating a supplied answer key, an authored example or self-review as independent field validation. ### Check your understanding Which exact input, rule and expected value would let another learner falsify your conclusion in this activity, and what remains untested? ### Offline route Use the supplied fictional JSON, expected results and paper/text evidence log without a provider account. Manual or constructed completion is labelled; it is not a live cloud integration or trained-model run. ## End-of-path review These are self-check questions, not verified examinations. ### Question 1 For the supplied fixture, what is the expected net_before_tax? 1. 25 2. It cannot be checked against the supplied input. 3. Whatever value the model reports most confidently. Review answer: 1. The independent answer key only validates this constructed fixture. Preserve the source, rerun counterexamples, and disclose what was not tested. ### Question 2 How should you handle the project rule: Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. 1. Silently change the rule to fit an attractive output. 2. State the rule, test it, and record exceptions or unresolved failures. 3. Treat model confidence as proof. Review answer: 2. Rules, source provenance and counterexamples make an output inspectable; an attractive result does not override policy. ### Question 3 If mainstream providers do not serve your region, what is the honest route? 1. Use a false country or borrowed account. 2. Claim the supplied fixture was a real API run. 3. Check legitimate available alternatives, or label the manual/fixture route and its limits. Review answer: 3. Access includes country, identity, language, cost and data terms. Do not bypass restrictions or invent a live result. ## Capstone review rubric Score each criterion 0 (missing), 1 (partial), or 2 (demonstrated). A self-review pass needs at least 8/10 and 2/2 on the critical safety/limits criterion. This is learner practice feedback, not verified assessment. ### Defined task and preserved input Original input and the project policy are retained; the actual question is clear. ### Checked baseline The supplied baseline reconciles field by field; unsupported live-run claims are absent. ### Three failure/change tests All three specified changes have predictions, observed results and explanations. ### Repeatable handoff Another person can follow the README; supporting practice evidence and unresolved limits are included. ### Safety, rights and access honesty [critical] Include selling, delivery, checking and support time. Payment-country eligibility must be verified before selling; no false residency, borrowed accounts or bypassing provider restrictions. Learning completion does not require earning money. Regional access route is legitimate; credentials and private data are absent; manual/constructed work is clearly labelled. ## References - [ILO Start and Improve Your Business](https://www.ilo.org/start-and-improve-your-business-siyb) ## Editorial boundary Original authored practice material; deterministic fixtures build-tested. Not independently expert-reviewed or learner-validated. Time estimates unvalidated. Use fictional/redacted data and your own authorised provider credentials. Never include credentials in this pack or public work.