AI Project Studio (after the core)استوديو مشاريع الذكاء الاصطناعي (بعد المسار الأساسي)

L104 — From Business Brief to Testable Specification

Learner file. Answers and model solutions are in a separate instructor-only file. Version: U25 Production v1 · Content date: 28 October 2026. Time estimates are planning estimates until learners have tested them. The code in this lesson was run with Python 3.13.16 and pandas 3.0.5 (recorded in D.World's internal Code Test Report); Python 3.13 is the accepted course version. Not run with Python 3.14 or inside JupyterLab.

Bean & Bloom and everyone in it are fictional, and all its data is synthetic. The "recorded AI responses" in ai_transcripts/ were written by D.World for teaching and contain deliberate faults; they are not the output of any particular product.

1. Lesson Identity

Time breakdown (planning estimate): concept and worked example 60 min · guided practice 35 min · independent practice 30 min · knowledge check 10 min · AI 5 min (optional) · workplace task and mini challenge 10 min.

What you need: Python with pandas; practice_files (L104_starter.ipynb; u25_data/bb_brief_email.md, u25_data/bb_sales_weekly.csv, u25_data/bb_stores.csv, u25_data/bb_events_log.csv, u25_data/data_README.md; ai_transcripts/L104_ai_draft_specification.md; examples/L104_bb_specification.md; studio_tools/studio_checks.py).

2. Learning Objective

By the end of this lesson, you will be able to:

• separate a stakeholder's proposed solution from the decision they face;
• write a project specification with analytical questions, testable hypotheses, KPI formulas, scope, non-goals, assumptions, acceptance criteria and risks;
• compute the KPI baseline on the data and check by script that every column the specification names exists;
• review an AI-drafted specification and correct what it invents.

D.World approved objective (verbatim): Convert an ambiguous business request into a testable project specification that names the stakeholder, the decision, the KPIs, the scope and non-goals, the assumptions and the acceptance criteria.

3. Why It Matters

In the AI Project Studio you will use AI assistants for real parts of real projects. An assistant will happily answer whatever you ask, quickly and fluently. That makes the question itself the most important thing you write. If the question is vague, the assistant fills the gaps with guesses, and the guesses look like work.

A project specification is where you remove those gaps before anyone (or anything) writes code: who decides, what they decide, how success is measured, what is out of scope and how you will know the work is done. In L101 you elicited requirements from a stakeholder. Here you turn a messy request into a specification precise enough to be tested: every KPI has a formula you can run, every hypothesis has a test, every acceptance criterion can be checked by someone else.

Key principle: specify the decision, the measures and the acceptance criteria before you analyse; write only what the data can test; and check every name and number in the specification against the data.

4. Concept

The running case for U25 is Bean & Bloom, a fictional chain of eight coffee shops. Its data was built by D.World with known causes, so that you can test explanations (yours and an AI's) against the truth.

Part A — Problem, proposed solution and decision

Read Hana Okafor's email (u25_data/bb_brief_email.md). It contains three different things:

A sales-prediction model would not tell the board why sales fell or what to do. As Google's Rules of Machine Learning puts it in Rule #1: "Don't be afraid to launch a product without machine learning." The email also contains three candidate explanations (the food price rise, the loyalty app, "the council") and one constraint (no new data or surveys before the board meeting).

Part B — KPI definitions: a formula, a period, a comparison

"Sales are declining" has no number. Before you can test anything, define the measure. Load the data and look at its shape:

from pathlib import Path

import pandas as pd

sales = pd.read_csv("u25_data/bb_sales_weekly.csv", parse_dates=["week_start"])
print(sales.shape, "|", sales["week_start"].min().date(), "to", sales["week_start"].max().date())
print(sorted(sales["store_id"].unique()), sorted(sales["category"].unique()))
print(sales.columns.tolist())

(2185, 5) | 2025-01-06 to 2026-09-28
['S01', 'S02', 'S03', 'S04', 'S05', 'S06', 'S07', 'S08'] ['beans', 'coffee', 'food']
['store_id', 'week_start', 'category', 'units', 'revenue_eur']

Now compare two reasonable-sounding definitions of "the decline" for the last 13 weeks (6 July – week of 28 September 2026):

last13 = sales[(sales["week_start"] >= "2026-07-06") & (sales["week_start"] <= "2026-09-28")]
prev13 = sales[(sales["week_start"] >= "2026-04-06") & (sales["week_start"] <= "2026-06-29")]
same_weeks_2025 = sales[(sales["week_start"] >= "2025-07-07") & (sales["week_start"] <= "2025-09-29")]
for name, base in [("vs the previous 13 weeks", prev13), ("vs the same ISO weeks of 2025", same_weeks_2025)]:
    change = last13["revenue_eur"].sum() / base["revenue_eur"].sum() - 1
    print(f"{name:30s} weeks {base['week_start'].nunique()} | change {change:+.1%}")

vs the previous 13 weeks       weeks 13 | change -8.3%
vs the same ISO weeks of 2025  weeks 13 | change -6.0%

Two definitions, two answers. Coffee sales in this chain are seasonal (lower in summer), so comparing summer with spring mixes the decline with the season. The year-on-year comparison on the same ISO weeks (here weeks 28–40) removes most of that. Neither number is "the" answer until the specification says which one is used. A KPI definition therefore has a name, a formula with real column names, a period and a comparison:

yoy_change = (sum of revenue_eur in ISO weeks 28–40 of 2026) / (sum in ISO weeks 28–40 of 2025) − 1

(The numbers above use the raw file; L108 adds the data checks, and the cleaned figure differs slightly.)

Part C — Analytical questions and testable hypotheses

An analytical question is one the data can answer: "Is the fall concentrated in some stores or categories?" A testable hypothesis is a possible explanation together with the test that could support or contradict it:

Writing the test next to each hypothesis forces honesty: the last row is not a hypothesis for this project, however plausible it sounds. It goes to the risk register or to a later project.

Part D — Scope, non-goals, assumptions, acceptance criteria

• Scope: what is in (stores, categories, weeks).
• Non-goals: what you will deliberately not do, so nobody expects it: here, a forecasting model (not needed for the decision), profit analysis (no cost data) and customer behaviour (no customer data).
• Assumptions and constraints: what you take as true without proof, and how you will check it; limits on time, data or money.
• Acceptance criteria: how anyone can tell the work is done and right, written before coding. Each must be checkable: "the year-on-year change is computed two independent ways and agrees to within 0.1 percentage points", not "the analysis is accurate".
• Risk register (initial): what could make the answer wrong or useless, with a mitigation for each.

What can this data establish? It can show where and when revenue changed and whether the timing matches an event. It cannot show profit (no costs), why customers behaved as they did (no customers) or prove a cause beyond doubt (no experiment). Say so in the specification.

Part E — Reviewing an AI-drafted specification

Assistants write specifications that look complete. Read ai_transcripts/L104_ai_draft_specification.md, then run the D.World structure check on the draft. studio_checks.py spec checks the eleven sections, a test for every hypothesis, a formula for every KPI, measurable acceptance criteria, non-goals, risks and, with --data, that every column it names exists:

import sys

sys.path.insert(0, str(Path("studio_tools").resolve()))
import studio_checks

transcript = Path("ai_transcripts/L104_ai_draft_specification.md").read_text(encoding="utf-8")
draft = transcript.split("**Response:**", 1)[1]
Path("ai_draft_spec.md").write_text(draft, encoding="utf-8")
data = ["u25_data/bb_sales_weekly.csv", "u25_data/bb_stores.csv", "u25_data/bb_events_log.csv"]
studio_checks.report(studio_checks.check_spec("ai_draft_spec.md", data), "AI draft")

FAIL S1 all eleven sections present and not empty — non-goals
PASS S2 every hypothesis states its test ('Test:')
PASS S3 every KPI has a formula ('=')
FAIL S4 at least three measurable acceptance criteria — 3 criteria
FAIL S5 at least one non-goal
FAIL S6 at least two risks
FAIL S7 every column named in KPIs and data needed exists in the data — footfall, transactions
AI draft: 2/7 checks passed

Five checks fail, for four problems of form (the missing non-goals section fails two checks), including two invented columns (footfall, transactions): the data has no footfall counts and no transaction counts. Now read the draft yourself for problems no script can find:

1. The decision is "which AI model to deploy": the stakeholder's proposed solution, not her decision.
2. The problem statement already states the cause ("customer behaviour has changed") before any analysis.
3. H2 cannot be tested with this data, and its "test" is to ask another AI.
4. Acceptance criterion 3 (+20% by Q1 2027) is a target nobody stated: an invented commitment.
5. "The data is complete and accurate" is an assumption with no check.

The check passes or fails the form; you are responsible for the truth.

5. Worked Example

Fictional business, synthetic data. The analytics team writes examples/L104_bb_specification.md. Check it the same way:

studio_checks.report(studio_checks.check_spec("examples/L104_bb_specification.md", data), "worked example")

PASS S1 all eleven sections present and not empty
PASS S2 every hypothesis states its test ('Test:')
PASS S3 every KPI has a formula ('=')
PASS S4 at least three measurable acceptance criteria
PASS S5 at least one non-goal
PASS S6 at least two risks
PASS S7 every column named in KPIs and data needed exists in the data
worked example: 7/7 checks passed

Step 1 — Decision: Hana decides, on 20 November, which action to take for the stores and categories whose sales fell (operational fix, price change or wait). The AI model she asked for is recorded as a non-goal.

Step 2 — KPIs: weekly_revenue, yoy_change (ISO weeks 28–40, 2026 vs 2025) and price_per_item, each with real column names.

Step 3 — Hypotheses: H1 food price, H2 local disruption, H3 seasonality, H4 loyalty app, each with its test; "brand" removed as untestable here.

Step 4 — Acceptance criteria: the central number computed two ways (within 0.1 points); every hypothesis labelled with its evidence; every board number traced; rerun from raw files with tests passing.

Step 5 — Baseline: the year-on-year change on the raw file is shown in Part B; L108 adds the data contract and L109 verifies it.

6. Visual Explanation

 REQUEST  "build us an AI model that predicts sales"
    │  separate:  proposed solution | problem | decision & deadline | candidate explanations | constraints
    ▼
 SPECIFICATION
    ├─ decision & stakeholder ─ analytical questions ─ hypotheses (each with its TEST)
    ├─ KPIs: name = formula on real columns, period, comparison ──▶ computed on the data (baseline)
    ├─ scope · NON-GOALS · assumptions (+ how checked) · constraints
    ├─ ACCEPTANCE CRITERIA (checkable, written before coding)
    └─ risks (+ mitigation)
    ▼
 CHECKS:  structure script (sections, formulas, columns exist)  +  your review (decision, invented targets, untestable claims)

Alt text: A request for an AI model is split into five parts: proposed solution, problem, decision and deadline, candidate explanations and constraints. These feed a specification with decision and stakeholder, analytical questions, hypotheses each with a test, KPI formulas on real columns computed on the data as a baseline, scope, non-goals, assumptions with checks, constraints, acceptance criteria written before coding, and risks with mitigations. The specification is checked twice: by a structure script (sections, formulas, columns exist) and by a human review for wrong decisions, invented targets and untestable claims.

7. Guided Practice

In L104_starter.ipynb:

1. Copy each sentence of Hana's email into one of five groups: proposed solution, problem, decision and deadline, candidate explanation, constraint.
2. Compute yoy_change by category for ISO weeks 28–40. Which category fell most?
3. Add a KPI units_yoy_change (units instead of revenue) to a copy of the worked example. Why might revenue and units tell different stories for food?
4. Rewrite the AI draft's acceptance criteria 1 and 2 so that they are measurable, and delete criterion 3. Say in one sentence why you deleted it.
5. Add a fifth hypothesis of your own that the data can test, with its test.
6. Run studio_checks.py spec on your edited specification with --data and fix every FAIL.

8. Independent Practice

A second ambiguous request. Fictional: the product lead of a meditation app writes: "Our app reviews got worse. Fix it." You may assume the team has an export of app-store reviews (date, star rating, app version, country, review text) and the release notes of each app version.

Write project_specification.md with all eleven sections. It must have at least three hypotheses each with its test, at least two KPI formulas using the columns listed above, at least two non-goals and at least three measurable acceptance criteria. Make a small CSV with just the column headers (review_date,star_rating,app_version,country,review_text) and run studio_checks.py spec with --data on it until every check passes. Then write three sentences: what this data can establish, what it cannot, and one assumption you would check first.

9. Knowledge Check — Specifications

Q1. The COO asks for "an AI model that predicts sales". What is this, in specification terms?

• A) The project's decision, which the specification must deliver as stated
• B) A proposed solution, to be recorded and judged against the decision
• C) An acceptance criterion, because it says what must be delivered
• D) A constraint, because it limits the methods the team may use

Q2. Revenue in the last 13 weeks fell more against the previous 13 weeks than against the same weeks of 2025. What does this show?

• A) The definition of the KPI changes the answer, so the specification must fix it
• B) The previous-13-weeks figure is correct because it uses the most recent data
• C) The data contains errors, because two correct methods must give one answer
• D) The decline is smaller than reported, so the board need not be told about it

Q3. Which is a testable hypothesis for Bean & Bloom's data?

• A) "Customers no longer like the brand. Test: ask an AI to analyse sentiment."
• B) "Staff morale fell this summer. Test: interview staff after the board meeting."
• C) "A local disruption hit some stores. Test: store-level change vs events log."
• D) "Competitors opened nearby. Test: assume it is true unless someone disagrees."

Q4. Which acceptance criterion is checkable?

• A) "The analysis is accurate and complete."
• B) "Stakeholders are satisfied with the results."
• C) "The figures are reliable enough for the board."
• D) "The central number agrees two ways within 0.1 points."

Q5. Why does the worked example list "a sales-forecasting model" under non-goals?

• A) Forecasting models are not allowed in D.World projects at this stage
• B) So nobody expects it: it is not needed for the decision on 20 November
• C) Because the data has too few weeks for any forecasting model to work at all
• D) Because the COO withdrew her request after reading the specification draft

Q6. The AI draft names the columns footfall and transactions. What should you do?

• A) Keep them, because an assistant would not name columns that do not exist
• B) Ask the assistant again until it stops naming those two columns
• C) Remove or replace them: the check shows they are not in the data
• D) Create the columns by estimating them from revenue and the seat counts

Q7. The AI draft adds "sales increase by 20% by Q1 2027". What is the main problem?

• A) The number is too high for a coffee chain to reach in a few months
• B) It is not measurable, because "Q1 2027" is not a precise date
• C) It belongs in the risks section, not in the acceptance criteria
• D) Nobody stated that target: it is an invented commitment

Q8. The structure check reports 7/7 for your specification. What does that establish?

• A) The specification has the required form and its named columns exist
• B) The specification is correct and can be sent to the board without review
• C) Every hypothesis in the specification has been tested and supported by data
• D) The assistant that drafted the specification did not invent anything at all

10. AI in Practice (optional, bounded)

Goal: use an assistant to widen your list of interpretations, then keep only what the data can test.

1. Paste Hana's email (it is fictional, so this is safe) and ask: "List eight different interpretations of what this COO needs to decide. For each, say what data would answer it."
2. For each interpretation, mark whether this data (columns listed in u25_data/data_README.md) can answer it. Keep only those it can.
3. Compare the kept list with your analytical questions. Add any you missed.

Boundaries: AI is optional. Never paste confidential business data or personal data into a public AI tool. The assistant proposes interpretations; the stakeholder and the data decide.

11. AI Verification

1. Columns: every column an AI-drafted specification names is checked with studio_checks.py spec --data.
2. Targets and commitments: every number in an acceptance criterion is traced to the stakeholder's words or to your own justified choice; invented targets are deleted.
3. Causes: a cause stated before analysis is turned into a hypothesis with a test.
4. Record: note in your AI collaboration log (L107) what you kept, changed and rejected.

12. Business Lens

A specification is a contract: it saves the cost of answering the wrong question. A model that predicts Bean & Bloom's sales would have taken weeks and told the board nothing about what to do. One page that fixes the decision, the measure and the test of "done" turns a vague worry into a question with an answer, and it protects the analyst: when someone asks later "why didn't you build the AI model?", the non-goals and the COO's approval answer for you.

13. Workplace Task — The Specification Email

Fictional business: Bean & Bloom. Write the email (100–150 words) that sends Hana the specification for approval: the decision as you understood it, the KPI and comparison you will use (and why year on year), the four hypotheses, one thing you will not do and why, and the date you need her approval by.

14. Mini Challenge — Which Weeks?

Fictional business, synthetic data. Finance says: "Compare the last 8 weeks with the same 8 weeks of last year instead."

last8 = sales[(sales["week_start"] >= "2026-08-10") & (sales["week_start"] <= "2026-09-28")]
same8 = sales[(sales["week_start"] >= "2025-08-11") & (sales["week_start"] <= "2025-09-29")]
print(f"weeks {last8['week_start'].nunique()} vs {same8['week_start'].nunique()} | change {last8['revenue_eur'].sum() / same8['revenue_eur'].sum() - 1:+.1%}")

weeks 8 vs 8 | change -5.5%

1. Before you open the output, predict whether the 8-week change will be smaller, similar or larger than the 13-week change.
2. What does the output show?
3. Should the specification use 8 or 13 weeks? Give one reason for each and choose.
4. Write the KPI line you would put in the specification.

Submit before feedback. No solution is provided here.

15. Resources

Required (about 25 min):

• Google for Developers. Rules of Machine Learning: Best Practices for ML Engineering (Martin Zinkevich). Read the overview and Rules #1–#4. https://developers.google.com/machine-learning/guides/rules-of-ml (Opened 28 Oct 2026.)
• AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (Opened 28 Oct 2026.)

16. Person to Follow / Role Model

Martin Zinkevich.

• Verified fact: he is the author of Google's Rules of Machine Learning: Best Practices for ML Engineering, whose first rules are "Don't be afraid to launch a product without machine learning." and "First, design and implement metrics." (developers.google.com, opened 28 Oct 2026).
• Why D.World recommends him: his rules put the measure and the simplest workable approach before any model, which is what a specification does.
• Try this: for your next project, write Rule #2 at the top of your specification and define your KPIs before anything else.

17. Glossary

Review: charter (U17) · requirement and acceptance threshold (L101).

18. Reflection

1. Which sentence in Hana's email was hardest to classify, and why?
2. Which of your acceptance criteria would be easiest to fake, and how would a reviewer catch it?
3. When would you go back to the stakeholder instead of writing an assumption?

19. Next Step

Next: L105 — Data Sourcing, Licensing & Provenance. You record where every dataset in the specification comes from, what you may do with it and how to get exactly the same file again.

20. Assessment Evidence

References

1. Zinkevich, M. Rules of Machine Learning: Best Practices for ML Engineering. Google for Developers. https://developers.google.com/machine-learning/guides/rules-of-ml (ZINK). Supports: Rule #1 "Don't be afraid to launch a product without machine learning."; Rule #2 "First, design and implement metrics."; Rule #4 "Keep the first model simple and get the infrastructure right."
2. Amazon Web Services. AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (AWS-DS). Supports: "Some business problems don't need ML and simple business rules can do a much better job."
3. D.World AI Project Studio Detailed Lesson Map v1.0 (L104 row); decisions S02 (recorded AI responses) and S08 (running case). Internal.

L104 — من موجز العمل إلى مواصفة قابلة للاختبار

ملف المتعلّم. الإجابات والحلول النموذجية في ملف منفصل خاص بالمدرّس فقط. الإصدار: U25 Production v1 · تاريخ المحتوى: 28 أكتوبر 2026. تقديرات الوقت تقديرات للتخطيط إلى أن يختبرها المتعلّمون. الكود في هذا الدرس شُغّل باستخدام Python 3.13.16 وpandas 3.0.5 (مسجّل في تقرير اختبار الكود الداخلي في D.World)؛ وPython 3.13 هو الإصدار المعتمد في المقرر. ولم يُشغَّل باستخدام Python 3.14 ولا داخل JupyterLab.

Bean & Bloom وكل من فيها خياليون، وكل بياناتها مصطنعة. و"ردود الذكاء الاصطناعي المسجّلة" في ai_transcripts/ كتبتها D.World للتعليم وفيها أخطاء متعمَّدة؛ وهي ليست مخرجات أي منتج بعينه.

1. بطاقة الدرس

تفصيل الوقت (تقدير للتخطيط):

• المفهوم والمثال المحلول: 60 دقيقة.
• التدريب الموجَّه: 35 دقيقة.
• التدريب المستقل: 30 دقيقة.
• اختبار الفهم: 10 دقائق.
• الذكاء الاصطناعي: 5 دقائق (اختياري).
• مهمة العمل والتحدي القصير: 10 دقائق.

ما تحتاج إليه: Python مع pandas؛ ومجلد practice_files (L104_starter.ipynb؛ وu25_data/bb_brief_email.md وu25_data/bb_sales_weekly.csv وu25_data/bb_stores.csv وu25_data/bb_events_log.csv وu25_data/data_README.md؛ وai_transcripts/L104_ai_draft_specification.md؛ وexamples/L104_bb_specification.md؛ وstudio_tools/studio_checks.py).

2. هدف التعلّم

في نهاية هذا الدرس، ستكون قادرًا على أن:

• تفصل بين الحل الذي يقترحه صاحب المصلحة والقرار الذي يواجهه؛
• تكتب مواصفة مشروع فيها أسئلة تحليلية، وفرضيات قابلة للاختبار، وصيغ مؤشرات الأداء، والنطاق، وما هو خارج الأهداف، والافتراضات، ومعايير القبول، والمخاطر؛
• تحسب خط الأساس لمؤشر الأداء على البيانات، وتتحقق بسكربت من وجود كل عمود تذكره المواصفة؛
• تراجع مواصفة صاغها الذكاء الاصطناعي وتصحّح ما يختلقه.

الهدف المعتمد من D.World (بنصّه): Convert an ambiguous business request into a testable project specification that names the stakeholder, the decision, the KPIs, the scope and non-goals, the assumptions and the acceptance criteria.

(وبالعربية: حوّل طلب عمل غامضًا إلى مواصفة مشروع قابلة للاختبار تسمّي صاحب المصلحة، والقرار، ومؤشرات الأداء الرئيسية، والنطاق وما هو خارج الأهداف، والافتراضات، ومعايير القبول.)

3. لماذا يهمّك هذا؟

في استوديو مشاريع الذكاء الاصطناعي ستستخدم مساعدات الذكاء الاصطناعي في أجزاء حقيقية من مشاريع حقيقية. والمساعد سيجيب بسرور عن أي شيء تسأله، بسرعة وبطلاقة. وهذا يجعل السؤال نفسه أهم ما تكتبه. فإذا كان السؤال غامضًا، يملأ المساعد الفجوات بتخمينات، وتبدو التخمينات كأنها عمل.

مواصفة المشروع (project specification) هي المكان الذي تزيل فيه هذه الفجوات قبل أن يكتب أي أحد (أو أي شيء) كودًا: من يقرر، وماذا يقرر، وكيف يُقاس النجاح، وما هو خارج النطاق، وكيف ستعرف أن العمل اكتمل. في L101 استخلصت المتطلبات من صاحب مصلحة. وهنا تحوّل طلبًا فوضويًا إلى مواصفة دقيقة بما يكفي لأن تُختبر: لكل مؤشر أداء صيغة تستطيع تشغيلها، ولكل فرضية اختبار، ويستطيع شخص آخر التحقق من كل معيار قبول.

المبدأ الأساسي: حدّد القرار، والمقاييس، ومعايير القبول قبل أن تحلّل؛ ولا تكتب إلا ما تستطيع البيانات اختباره؛ وتحقق من كل اسم ورقم في المواصفة مقابل البيانات.

4. المفهوم

الحالة المستمرة في U25 هي Bean & Bloom، سلسلة خيالية من ثمانية مقاهٍ. بنت D.World بياناتها بأسباب معروفة، حتى تستطيع اختبار التفسيرات (تفسيراتك وتفسيرات الذكاء الاصطناعي) مقابل الحقيقة.

الجزء A — المشكلة، والحل المقترح، والقرار

اقرأ بريد هانا أوكافور الإلكتروني (u25_data/bb_brief_email.md). فيه ثلاثة أشياء مختلفة:

نموذج للتنبؤ بالمبيعات لن يخبر مجلس الإدارة لماذا انخفضت المبيعات ولا ماذا يفعل. وكما تقول القاعدة رقم 1 في Rules of Machine Learning من Google: "Don't be afraid to launch a product without machine learning." (أي: "لا تخشَ إطلاق منتج دون تعلّم الآلة.") ويحتوي البريد أيضًا على ثلاثة تفسيرات مرشّحة (candidate explanations) (رفع أسعار الطعام، وتطبيق الولاء، و"the council"، أي "البلدية") وقيد واحد (لا بيانات جديدة ولا استطلاعات قبل اجتماع مجلس الإدارة).

الجزء B — تعريفات مؤشرات الأداء: صيغة، وفترة، ومقارنة

"المبيعات تتراجع" ليس فيها رقم. وقبل أن تستطيع اختبار أي شيء، عرّف المقياس. حمّل البيانات وانظر إلى شكلها:

from pathlib import Path

import pandas as pd

sales = pd.read_csv("u25_data/bb_sales_weekly.csv", parse_dates=["week_start"])
print(sales.shape, "|", sales["week_start"].min().date(), "to", sales["week_start"].max().date())
print(sorted(sales["store_id"].unique()), sorted(sales["category"].unique()))
print(sales.columns.tolist())

(2185, 5) | 2025-01-06 to 2026-09-28
['S01', 'S02', 'S03', 'S04', 'S05', 'S06', 'S07', 'S08'] ['beans', 'coffee', 'food']
['store_id', 'week_start', 'category', 'units', 'revenue_eur']

(الفئات: beans = البن، coffee = القهوة، food = الطعام.)

قارن الآن بين تعريفين يبدو كل منهما معقولًا لـ "التراجع" في آخر 13 أسبوعًا (من 6 يوليو حتى أسبوع 28 سبتمبر 2026):

last13 = sales[(sales["week_start"] >= "2026-07-06") & (sales["week_start"] <= "2026-09-28")]
prev13 = sales[(sales["week_start"] >= "2026-04-06") & (sales["week_start"] <= "2026-06-29")]
same_weeks_2025 = sales[(sales["week_start"] >= "2025-07-07") & (sales["week_start"] <= "2025-09-29")]
for name, base in [("vs the previous 13 weeks", prev13), ("vs the same ISO weeks of 2025", same_weeks_2025)]:
    change = last13["revenue_eur"].sum() / base["revenue_eur"].sum() - 1
    print(f"{name:30s} weeks {base['week_start'].nunique()} | change {change:+.1%}")

vs the previous 13 weeks       weeks 13 | change -8.3%
vs the same ISO weeks of 2025  weeks 13 | change -6.0%

(vs the previous 13 weeks = مقارنة بالأسابيع الـ 13 السابقة؛ vs the same ISO weeks of 2025 = مقارنة بأسابيع ISO نفسها في 2025؛ change = التغيّر.)

تعريفان، وإجابتان. مبيعات القهوة في هذه السلسلة موسمية (أقل في الصيف)، لذلك فمقارنة الصيف بالربيع تخلط التراجع بالموسم. والمقارنة السنوية على أسابيع ISO نفسها (هنا الأسابيع 28–40) تزيل معظم ذلك. ولا يكون أيٌّ من الرقمين هو الإجابة "الصحيحة" حتى تقول المواصفة أيهما يُستخدم. لذلك فإن تعريف مؤشر الأداء (KPI definition) له اسم، وصيغة بأسماء أعمدة حقيقية، وفترة، ومقارنة:

yoy_change = (مجموع revenue_eur في أسابيع ISO من 28 إلى 40 لسنة 2026) / (المجموع في أسابيع ISO من 28 إلى 40 لسنة 2025) − 1

(الأرقام أعلاه تستخدم الملف الخام؛ ويضيف L108 فحوص البيانات، ويختلف الرقم بعد التنظيف قليلًا.)

الجزء C — الأسئلة التحليلية والفرضيات القابلة للاختبار

السؤال التحليلي (analytical question) سؤال تستطيع البيانات الإجابة عنه: "هل الانخفاض متركّز في بعض الفروع أو الفئات؟". والفرضية القابلة للاختبار (testable hypothesis) تفسير محتمل مع الاختبار الذي يمكن أن يدعمه أو يناقضه:

كتابة الاختبار بجانب كل فرضية تفرض الأمانة: فالصف الأخير ليس فرضية لـ هذا المشروع، مهما بدا معقولًا. ومكانه سجل المخاطر أو مشروع لاحق.

الجزء D — النطاق، وما هو خارج الأهداف، والافتراضات، ومعايير القبول

• النطاق (Scope): ما يدخل فيه (الفروع، والفئات، والأسابيع).
• ما هو خارج الأهداف (Non-goals): ما لن تفعله عمدًا، حتى لا يتوقعه أحد: هنا، نموذج للتنبؤ (غير لازم للقرار)، وتحليل الأرباح (لا بيانات تكاليف)، وسلوك العملاء (لا بيانات عملاء).
• الافتراضات والقيود (Assumptions and constraints): ما تعدّه صحيحًا دون إثبات، وكيف ستتحقق منه؛ والحدود على الوقت أو البيانات أو المال.
• معايير القبول (Acceptance criteria): كيف يستطيع أي شخص أن يعرف أن العمل اكتمل وصحيح، وتُكتب قبل البرمجة. ويجب أن يكون كل معيار قابلًا للتحقق: "the year-on-year change is computed two independent ways and agrees to within 0.1 percentage points" (أي: "التغيّر السنوي يُحسب بطريقتين مستقلتين ويتفق في حدود 0.1 نقطة مئوية")، لا "the analysis is accurate" (أي: "التحليل دقيق").
• سجل المخاطر (Risk register) (أولي): ما قد يجعل الإجابة خاطئة أو عديمة الفائدة، مع إجراء للتخفيف لكلٍّ منها.

ماذا تستطيع هذه البيانات أن تثبت؟ تستطيع أن تُظهر أين ومتى تغيّرت الإيرادات، وهل التوقيت يطابق حدثًا ما. ولا تستطيع أن تُظهر الربح (لا تكاليف)، ولا لماذا تصرّف العملاء كما تصرّفوا (لا بيانات عملاء)، ولا أن تثبت سببًا بلا أدنى شك (لا تجربة). اذكر ذلك في المواصفة.

الجزء E — مراجعة مواصفة صاغها الذكاء الاصطناعي

المساعدات تكتب مواصفات تبدو كاملة. اقرأ ai_transcripts/L104_ai_draft_specification.md، ثم شغّل فحص البنية من D.World على المسودة. الأمر studio_checks.py spec يتحقق من الأقسام الأحد عشر، ومن وجود اختبار لكل فرضية، وصيغة لكل مؤشر أداء، ومعايير قبول قابلة للقياس، وما هو خارج الأهداف، والمخاطر، ومع --data يتحقق من وجود كل عمود تذكره:

import sys

sys.path.insert(0, str(Path("studio_tools").resolve()))
import studio_checks

transcript = Path("ai_transcripts/L104_ai_draft_specification.md").read_text(encoding="utf-8")
draft = transcript.split("**Response:**", 1)[1]
Path("ai_draft_spec.md").write_text(draft, encoding="utf-8")
data = ["u25_data/bb_sales_weekly.csv", "u25_data/bb_stores.csv", "u25_data/bb_events_log.csv"]
studio_checks.report(studio_checks.check_spec("ai_draft_spec.md", data), "AI draft")

FAIL S1 all eleven sections present and not empty — non-goals
PASS S2 every hypothesis states its test ('Test:')
PASS S3 every KPI has a formula ('=')
FAIL S4 at least three measurable acceptance criteria — 3 criteria
FAIL S5 at least one non-goal
FAIL S6 at least two risks
FAIL S7 every column named in KPIs and data needed exists in the data — footfall, transactions
AI draft: 2/7 checks passed

(ترجمة المخرجات: S1 كل الأقسام الأحد عشر موجودة وغير فارغة — ينقص قسم ما هو خارج الأهداف؛ S2 كل فرضية تذكر اختبارها ('Test:')؛ S3 لكل مؤشر أداء صيغة ('=')؛ S4 ثلاثة معايير قبول قابلة للقياس على الأقل — 3 معايير؛ S5 هدف واحد على الأقل خارج النطاق؛ S6 خطران على الأقل؛ S7 كل عمود مذكور في مؤشرات الأداء والبيانات المطلوبة موجود في البيانات — footfall وtransactions؛ "AI draft: 2/7 checks passed" = مسودة الذكاء الاصطناعي: نجح فحصان من 7.)

تفشل خمسة فحوص، بسبب أربع مشكلات في الشكل (فغياب قسم ما هو خارج الأهداف يُفشل فحصين)، منها عمودان مختلَقان (footfall، أي عدد الزوار، وtransactions، أي عدد المعاملات): فالبيانات ليس فيها أعداد زوار ولا أعداد معاملات. والآن اقرأ المسودة بنفسك بحثًا عن مشكلات لا يستطيع أي سكربت أن يجدها:

1. القرار هو "which AI model to deploy" (أي: "أي نموذج ذكاء اصطناعي يُنشر"): وهو الحل الذي اقترحته صاحبة المصلحة، لا قرارها.
2. بيان المشكلة يذكر السبب مسبقًا ("customer behaviour has changed"، أي: "سلوك العملاء تغيّر") قبل أي تحليل.
3. H2 لا يمكن اختبارها بهذه البيانات، و"اختبارها" هو أن تسأل ذكاءً اصطناعيًا آخر.
4. معيار القبول 3 (+20% بحلول الربع الأول من 2027) هدف لم يذكره أحد: التزام مختلَق.
5. "The data is complete and accurate" (أي: "البيانات كاملة ودقيقة") افتراض بلا أي فحص.

الفحص يُنجح الشكل أو يُفشله؛ أما الحقيقة فمسؤوليتك أنت.

5. مثال محلول

نشاط خيالي، وبيانات مصطنعة. يكتب فريق التحليلات examples/L104_bb_specification.md. افحصه بالطريقة نفسها:

studio_checks.report(studio_checks.check_spec("examples/L104_bb_specification.md", data), "worked example")

PASS S1 all eleven sections present and not empty
PASS S2 every hypothesis states its test ('Test:')
PASS S3 every KPI has a formula ('=')
PASS S4 at least three measurable acceptance criteria
PASS S5 at least one non-goal
PASS S6 at least two risks
PASS S7 every column named in KPIs and data needed exists in the data
worked example: 7/7 checks passed

(كل الفحوص السبعة ناجحة: "worked example: 7/7 checks passed" = المثال المحلول: نجحت 7 فحوص من 7.)

الخطوة 1 — القرار: تقرر هانا، في 20 نوفمبر، أي إجراء تتخذه للفروع والفئات التي انخفضت مبيعاتها (إصلاح تشغيلي، أو تغيير في السعر، أو الانتظار). ويُسجَّل نموذج الذكاء الاصطناعي الذي طلبته ضمن ما هو خارج الأهداف.

الخطوة 2 — مؤشرات الأداء: weekly_revenue وyoy_change (أسابيع ISO من 28 إلى 40، 2026 مقابل 2025) وprice_per_item، ولكلٍّ منها أسماء أعمدة حقيقية.

الخطوة 3 — الفرضيات: H1 سعر الطعام، وH2 اضطراب محلي، وH3 الموسمية، وH4 تطبيق الولاء، ولكلٍّ منها اختبارها؛ وحُذفت "العلامة التجارية" لأنها غير قابلة للاختبار هنا.

الخطوة 4 — معايير القبول: الرقم المحوري يُحسب بطريقتين (في حدود 0.1 نقطة)؛ وكل فرضية معنوَنة بأدلتها؛ وكل رقم يُعرض على مجلس الإدارة يمكن تتبّع أصله؛ وإعادة التشغيل من الملفات الخام مع نجاح الاختبارات.

الخطوة 5 — خط الأساس: التغيّر السنوي على الملف الخام معروض في الجزء B؛ ويضيف L108 عقد البيانات، ويتحقق منه L109.

6. شرح بصري

 REQUEST  "build us an AI model that predicts sales"
    │  separate:  proposed solution | problem | decision & deadline | candidate explanations | constraints
    ▼
 SPECIFICATION
    ├─ decision & stakeholder ─ analytical questions ─ hypotheses (each with its TEST)
    ├─ KPIs: name = formula on real columns, period, comparison ──▶ computed on the data (baseline)
    ├─ scope · NON-GOALS · assumptions (+ how checked) · constraints
    ├─ ACCEPTANCE CRITERIA (checkable, written before coding)
    └─ risks (+ mitigation)
    ▼
 CHECKS:  structure script (sections, formulas, columns exist)  +  your review (decision, invented targets, untestable claims)

وصف الرسم: طلب لنموذج ذكاء اصطناعي يُقسَّم إلى خمسة أجزاء: الحل المقترح، والمشكلة، والقرار والموعد النهائي، والتفسيرات المرشّحة، والقيود. وهذه تغذّي مواصفة فيها القرار وصاحب المصلحة، والأسئلة التحليلية، والفرضيات ولكلٍّ منها اختبار، وصيغ مؤشرات الأداء على أعمدة حقيقية تُحسب على البيانات كخط أساس، والنطاق، وما هو خارج الأهداف، والافتراضات مع فحوصها، والقيود، ومعايير القبول المكتوبة قبل البرمجة، والمخاطر مع إجراءات التخفيف. وتُفحص المواصفة مرتين: بسكربت للبنية (الأقسام، والصيغ، ووجود الأعمدة)، وبمراجعة بشرية بحثًا عن القرارات الخاطئة، والأهداف المختلَقة، والادعاءات غير القابلة للاختبار. (نصوص الرسم: REQUEST = الطلب؛ separate = افصل؛ proposed solution | problem | decision & deadline | candidate explanations | constraints = الحل المقترح | المشكلة | القرار والموعد النهائي | التفسيرات المرشّحة | القيود؛ SPECIFICATION = المواصفة؛ decision & stakeholder = القرار وصاحب المصلحة؛ analytical questions = الأسئلة التحليلية؛ hypotheses (each with its TEST) = الفرضيات (لكلٍّ منها اختبارها)؛ KPIs: name = formula on real columns, period, comparison = مؤشرات الأداء: الاسم = صيغة على أعمدة حقيقية، وفترة، ومقارنة؛ computed on the data (baseline) = تُحسب على البيانات (خط الأساس)؛ scope · NON-GOALS · assumptions (+ how checked) · constraints = النطاق · ما هو خارج الأهداف · الافتراضات (+ كيف تُفحص) · القيود؛ ACCEPTANCE CRITERIA (checkable, written before coding) = معايير القبول (قابلة للتحقق، تُكتب قبل البرمجة)؛ risks (+ mitigation) = المخاطر (+ التخفيف)؛ CHECKS: structure script (sections, formulas, columns exist) + your review (decision, invented targets, untestable claims) = الفحوص: سكربت البنية (الأقسام، والصيغ، ووجود الأعمدة) + مراجعتك (القرار، والأهداف المختلَقة، والادعاءات غير القابلة للاختبار).)

7. تدريب موجَّه

في L104_starter.ipynb:

1. انسخ كل جملة من بريد هانا إلى واحدة من خمس مجموعات: الحل المقترح، والمشكلة، والقرار والموعد النهائي، والتفسير المرشّح، والقيد.
2. احسب yoy_change بحسب الفئة لأسابيع ISO من 28 إلى 40. أي فئة انخفضت أكثر؟
3. أضف مؤشر أداء units_yoy_change (الوحدات بدلًا من الإيرادات) إلى نسخة من المثال المحلول. لماذا قد تحكي الإيرادات والوحدات قصتين مختلفتين بالنسبة للطعام؟
4. أعد كتابة معياري القبول 1 و2 في مسودة الذكاء الاصطناعي بحيث يصبحان قابلين للقياس، واحذف المعيار 3. وقل في جملة واحدة لماذا حذفته.
5. أضف فرضية خامسة من عندك تستطيع البيانات اختبارها، مع اختبارها.
6. شغّل studio_checks.py spec على مواصفتك المعدّلة مع --data وأصلح كل FAIL.

8. تدريب مستقل

طلب غامض ثانٍ. خيالي: تكتب قائدة المنتج في تطبيق للتأمل: "Our app reviews got worse. Fix it." (أي: "تقييمات تطبيقنا ساءت. أصلحها.") ويمكنك أن تفترض أن لدى الفريق ملف تصدير لمراجعات متجر التطبيقات (التاريخ، وعدد النجوم، وإصدار التطبيق، والدولة، ونص المراجعة) وملاحظات الإصدار لكل إصدار من التطبيق.

اكتب project_specification.md بأقسامه الأحد عشر كلها. ويجب أن يحتوي على ثلاث فرضيات على الأقل لكلٍّ منها اختبارها، وصيغتين على الأقل لمؤشرات الأداء تستخدمان الأعمدة المذكورة أعلاه، وهدفين على الأقل خارج النطاق، وثلاثة معايير قبول قابلة للقياس على الأقل. واصنع ملف CSV صغيرًا فيه عناوين الأعمدة فقط (review_date,star_rating,app_version,country,review_text) وشغّل studio_checks.py spec مع --data عليه حتى تنجح كل الفحوص. ثم اكتب ثلاث جمل: ما تستطيع هذه البيانات إثباته، وما لا تستطيع، وافتراضًا واحدًا ستتحقق منه أولًا.

9. اختبار الفهم (Knowledge Check) — المواصفات

Q1. يطلب مدير العمليات التنفيذي (COO) "نموذج ذكاء اصطناعي يتنبأ بالمبيعات". ما هذا، بلغة المواصفات؟

• A) قرار المشروع، الذي يجب أن تسلّمه المواصفة كما ذُكر
• B) حل مقترح، يُسجَّل ويُحكم عليه مقابل القرار
• C) معيار قبول، لأنه يقول ما يجب تسليمه
• D) قيد، لأنه يحدّ من الأساليب التي يمكن للفريق استخدامها

Q2. انخفضت الإيرادات في آخر 13 أسبوعًا مقارنة بالأسابيع الـ 13 السابقة أكثر من انخفاضها مقارنة بالأسابيع نفسها في 2025. ماذا يُظهر هذا؟

• A) تعريف مؤشر الأداء يغيّر الإجابة، لذلك يجب أن تثبّته المواصفة
• B) رقم الأسابيع الـ 13 السابقة هو الصحيح لأنه يستخدم أحدث البيانات
• C) البيانات فيها أخطاء، لأن الطريقتين الصحيحتين يجب أن تعطيا إجابة واحدة
• D) التراجع أصغر مما قيل، لذلك لا داعي لإخبار مجلس الإدارة به

Q3. أيٌّ مما يلي فرضية قابلة للاختبار لبيانات Bean & Bloom؟

• A) "العملاء لم يعودوا يحبون العلامة التجارية. الاختبار: اطلب من ذكاء اصطناعي تحليل المشاعر."
• B) "معنويات الموظفين انخفضت هذا الصيف. الاختبار: قابل الموظفين بعد اجتماع مجلس الإدارة."
• C) "اضطراب محلي أصاب بعض الفروع. الاختبار: التغيّر على مستوى الفرع مقابل سجل الأحداث."
• D) "منافسون افتتحوا بالقرب. الاختبار: افترض أنه صحيح ما لم يعترض أحد."

Q4. أي معيار قبول قابل للتحقق؟

• A) "التحليل دقيق وكامل."
• B) "أصحاب المصلحة راضون عن النتائج."
• C) "الأرقام موثوقة بما يكفي لمجلس الإدارة."
• D) "الرقم المحوري يتفق بطريقتين في حدود 0.1 نقطة."

Q5. لماذا يضع المثال المحلول "نموذجًا للتنبؤ بالمبيعات" ضمن ما هو خارج الأهداف؟

• A) نماذج التنبؤ غير مسموح بها في مشاريع D.World في هذه المرحلة
• B) حتى لا يتوقعه أحد: فهو غير لازم لقرار 20 نوفمبر
• C) لأن البيانات فيها أسابيع قليلة جدًا لا يعمل معها أي نموذج تنبؤ على الإطلاق
• D) لأن مديرة العمليات سحبت طلبها بعد قراءة مسودة المواصفة

Q6. تذكر مسودة الذكاء الاصطناعي العمودين footfall وtransactions. ماذا يجب أن تفعل؟

• A) تُبقيهما، لأن المساعد لن يذكر أعمدة غير موجودة
• B) تسأل المساعد مرة أخرى حتى يتوقف عن ذكر هذين العمودين
• C) تحذفهما أو تستبدلهما: الفحص يُظهر أنهما غير موجودين في البيانات
• D) تنشئ العمودين بتقديرهما من الإيرادات وعدد المقاعد

Q7. تضيف مسودة الذكاء الاصطناعي "زيادة المبيعات بنسبة 20% بحلول الربع الأول من 2027". ما المشكلة الرئيسية؟

• A) الرقم أعلى من أن تبلغه سلسلة مقاهٍ في بضعة أشهر
• B) غير قابل للقياس، لأن "الربع الأول من 2027" ليس تاريخًا دقيقًا
• C) مكانه قسم المخاطر، لا معايير القبول
• D) لم يذكر أحد هذا الهدف: إنه التزام مختلَق

Q8. يُظهر فحص البنية 7/7 لمواصفتك. ماذا يثبت ذلك؟

• A) أن للمواصفة الشكل المطلوب وأن الأعمدة التي تذكرها موجودة
• B) أن المواصفة صحيحة ويمكن إرسالها لمجلس الإدارة دون مراجعة
• C) أن كل فرضية في المواصفة اختُبرت ودعمتها البيانات
• D) أن المساعد الذي صاغ المواصفة لم يختلق أي شيء على الإطلاق

10. الذكاء الاصطناعي في التطبيق (اختياري، وفي حدود)

الهدف: أن تستخدم مساعدًا لتوسيع قائمة تفسيراتك، ثم تحتفظ فقط بما تستطيع البيانات اختباره.

1. الصق بريد هانا (فهو خيالي، لذلك هذا آمن) واسأل:

"List eight different interpretations of what this COO needs to decide. For each, say what data would answer it."

وبالعربية: "اسرد ثمانية تفسيرات مختلفة لما تحتاج مديرة العمليات هذه إلى أن تقرره. ولكلٍّ منها، قل ما البيانات التي تجيب عنه."

2. لكل تفسير، حدّد هل تستطيع هذه البيانات (الأعمدة المذكورة في u25_data/data_README.md) الإجابة عنه. واحتفظ فقط بما تستطيع.
3. قارن القائمة التي احتفظت بها بأسئلتك التحليلية. وأضف ما فاتك.

الحدود:

• استخدام الذكاء الاصطناعي اختياري.
• لا تلصق أبدًا بيانات عمل سرية أو بيانات شخصية في أداة ذكاء اصطناعي عامة.
• المساعد يقترح التفسيرات؛ أما صاحب المصلحة والبيانات فهما اللذان يقرران.

11. التحقق من مخرجات الذكاء الاصطناعي

1. الأعمدة: كل عمود تذكره مواصفة صاغها الذكاء الاصطناعي يُفحص بـ studio_checks.py spec --data.
2. الأهداف والالتزامات: كل رقم في معيار قبول يُتتبَّع إلى كلام صاحب المصلحة أو إلى اختيار مبرَّر منك؛ والأهداف المختلَقة تُحذف.
3. الأسباب: أي سبب يُذكر قبل التحليل يتحول إلى فرضية لها اختبار.
4. السجل: دوّن في سجل تعاونك مع الذكاء الاصطناعي (L107) ما احتفظت به، وما غيّرته، وما رفضته.

12. منظور الأعمال

المواصفة عقد: توفّر تكلفة الإجابة عن السؤال الخطأ. نموذج يتنبأ بمبيعات Bean & Bloom كان سيستغرق أسابيع، ولن يخبر مجلس الإدارة بشيء عمّا يجب فعله. أما صفحة واحدة تثبّت القرار، والمقياس، واختبار "الاكتمال"، فتحوّل قلقًا غامضًا إلى سؤال له إجابة، وتحمي المحلل: فعندما يسأل أحدهم لاحقًا "لماذا لم تبنِ نموذج الذكاء الاصطناعي؟"، يجيب عنك قسم ما هو خارج الأهداف وموافقة مديرة العمليات.

13. مهمة عمل — بريد المواصفة

نشاط خيالي: Bean & Bloom. اكتب البريد الإلكتروني (من 100 إلى 150 كلمة) الذي يرسل إلى هانا المواصفة للموافقة: القرار كما فهمته، ومؤشر الأداء والمقارنة اللذين ستستخدمهما (ولماذا سنة على سنة)، والفرضيات الأربع، وشيئًا واحدًا لن تفعله ولماذا، والتاريخ الذي تحتاج إلى موافقتها قبله.

14. تحدٍّ قصير — أي أسابيع؟

نشاط خيالي، وبيانات مصطنعة. يقول قسم المالية: "Compare the last 8 weeks with the same 8 weeks of last year instead." (أي: "قارن آخر 8 أسابيع بالأسابيع الثمانية نفسها من العام الماضي بدلًا من ذلك.")

last8 = sales[(sales["week_start"] >= "2026-08-10") & (sales["week_start"] <= "2026-09-28")]
same8 = sales[(sales["week_start"] >= "2025-08-11") & (sales["week_start"] <= "2025-09-29")]
print(f"weeks {last8['week_start'].nunique()} vs {same8['week_start'].nunique()} | change {last8['revenue_eur'].sum() / same8['revenue_eur'].sum() - 1:+.1%}")

weeks 8 vs 8 | change -5.5%

1. قبل أن تفتح المخرجات، توقّع: هل سيكون تغيّر الأسابيع الثمانية أصغر من تغيّر الأسابيع الـ 13، أم مشابهًا له، أم أكبر؟
2. ماذا تُظهر المخرجات؟
3. هل يجب أن تستخدم المواصفة 8 أسابيع أم 13؟ أعطِ سببًا واحدًا لكلٍّ منهما واختر.
4. اكتب سطر مؤشر الأداء الذي ستضعه في المواصفة.

سلّم عملك قبل أن تتلقى الملاحظات. لا يوجد حل منشور هنا.

15. المصادر

مطلوب (حوالي 25 دقيقة):

• Google for Developers. Rules of Machine Learning: Best Practices for ML Engineering (Martin Zinkevich). اقرأ النظرة العامة والقواعد من 1 إلى 4. https://developers.google.com/machine-learning/guides/rules-of-ml (فُتح في 28 أكتوبر 2026.)
• AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (فُتح في 28 أكتوبر 2026.)

16. شخصية تتابعها / قدوة

Martin Zinkevich.

• حقيقة مُتحقَّق منها: هو مؤلف Rules of Machine Learning: Best Practices for ML Engineering من Google، وأولى قواعده "Don't be afraid to launch a product without machine learning." (أي: "لا تخشَ إطلاق منتج دون تعلّم الآلة.") و"First, design and implement metrics." (أي: "أولًا، صمّم المقاييس ونفّذها.") (developers.google.com، فُتح في 28 أكتوبر 2026).
• لماذا توصي به D.World: قواعده تضع المقياس وأبسط منهج عملي قبل أي نموذج، وهذا ما تفعله المواصفة.
• جرّب هذا: في مشروعك القادم، اكتب القاعدة رقم 2 في أعلى مواصفتك، وعرّف مؤشرات الأداء قبل أي شيء آخر.

17. المصطلحات

للمراجعة: ميثاق المشروع (U17) · المتطلب وحد القبول (L101).

18. تأمّل

1. أي جملة في بريد هانا كانت الأصعب في التصنيف، ولماذا؟
2. أي من معايير قبولك سيكون الأسهل في التزييف، وكيف سيكتشف المراجع ذلك؟
3. متى تعود إلى صاحب المصلحة بدلًا من أن تكتب افتراضًا؟

19. الخطوة التالية

التالي: L105 — مصادر البيانات، وتراخيصها، وأصلها (Data Sourcing, Licensing & Provenance). تسجّل من أين تأتي كل مجموعة بيانات في المواصفة، وما المسموح لك أن تفعله بها، وكيف تحصل على الملف نفسه بالضبط مرة أخرى.

20. أدلة التقييم

المراجع

1. Zinkevich, M. Rules of Machine Learning: Best Practices for ML Engineering. Google for Developers. https://developers.google.com/machine-learning/guides/rules-of-ml (ZINK). يدعم: القاعدة 1 "Don't be afraid to launch a product without machine learning."؛ والقاعدة 2 "First, design and implement metrics."؛ والقاعدة 4 "Keep the first model simple and get the infrastructure right." (أي: "اجعل النموذج الأول بسيطًا، وأتقن البنية التحتية.")
2. Amazon Web Services. AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (AWS-DS). يدعم: "Some business problems don't need ML and simple business rules can do a much better job."
3. D.World AI Project Studio Detailed Lesson Map v1.0 (صف L104)؛ والقراران S02 (ردود الذكاء الاصطناعي المسجّلة) وS08 (الحالة المستمرة). وثيقة داخلية.

L110 — Choose a Domain & Frame the Decision

Learner file. Answers and model solutions are in a separate instructor-only file. Version: U26 Production v1 · Content date: 28 October 2026. Time estimates are planning estimates until learners have tested them. The code in this lesson was run with Python 3.13.16 and pandas 3.0.5 (recorded in D.World's internal Code Test Report); Python 3.13 is the accepted course version. Not run with Python 3.14 or inside JupyterLab.

Cedar Gifts is fictional. Its data is a synthetic replica: it has the variables of the public Online Retail II dataset, but every row was generated by D.World, so lessons can show results without doing your flagship analysis for you. The "recorded AI responses" in ai_transcripts/ were written by D.World for teaching and contain deliberate faults.

1. Lesson Identity

Time breakdown (planning estimate): concept and worked example 55 min · guided practice 35 min · independent practice 35 min · knowledge check 10 min · AI 5 min (optional) · workplace task and mini challenge 10 min.

What you need: Python with pandas; practice_files (L110_starter.ipynb; cg_data/cedar_gifts_transactions.csv and cg_data/data_README.md; examples/L110_candidate_scoring.csv; ai_transcripts/L110_ai_project_brief.md); U26_EXIT/FLAGSHIP_BRIEF.md and U26_EXIT/project_library/.

2. Learning Objective

By the end of this lesson, you will be able to:

• compare candidate projects by decision value, data fit, feasibility and risk, and choose one;
• frame the decision with its stakeholder, success metric, cost of error, scope and evidence requirements;
• compute KPI baselines on the data and mark every claim in a brief as supported or assumption;
• apply the domain risk rules of the chosen industry.

D.World approved objective (verbatim): Select a project domain and frame a decision with its stakeholder, success metric, cost of error, scope and evidence requirements.

3. Why It Matters

In U25 a stakeholder gave you a request. In U26 you choose: a domain, a dataset and a decision worth informing. That freedom is where many portfolio projects go wrong. They start from a famous dataset and look for something to compute, and end with charts that answer nobody's question.

A good project starts from a decision someone could make soon, checks that the data can actually inform it, and states what a wrong answer would cost. Cassie Kozyrkov calls this discipline decision intelligence: "The discipline of turning information into better actions, in any setting and at any scale." In this lesson you practise it on Cedar Gifts, a synthetic replica of the retail data in the D.World flagship RET-F1, before you frame your own flagship.

Key principle: choose the project whose answer would change a decision soon; state the cost of being wrong in both directions; measure the starting point; and write only claims the data can support.

4. Concept

Part A — The data, and what it can and cannot establish

import re

import pandas as pd

cg = pd.read_csv("cg_data/cedar_gifts_transactions.csv", dtype={"InvoiceNo": str, "StockCode": str, "CustomerID": str},
                 parse_dates=["InvoiceDate"])
print(cg.shape, "|", cg["InvoiceDate"].min().date(), "to", cg["InvoiceDate"].max().date())
print(cg.columns.tolist())
uci_variables = ["InvoiceNo", "StockCode", "Description", "Quantity", "InvoiceDate", "UnitPrice", "CustomerID", "Country"]
print("same variables as listed on the UCI page:", cg.columns.tolist() == uci_variables)

(43942, 8) | 2009-12-01 to 2011-12-09
['InvoiceNo', 'StockCode', 'Description', 'Quantity', 'InvoiceDate', 'UnitPrice', 'CustomerID', 'Country']
same variables as listed on the UCI page: True

Each row is one line of an invoice. The UCI page of Online Retail II says that an invoice code starting with "c" indicates a cancellation; the replica follows that rule. What the data can establish: what was sold and cancelled, when, to which (pseudonymous) customer and country, at what price. What it cannot: costs or profit, why an order was cancelled, who the customers are, or what would have happened under another policy.

Part B — Comparing candidate projects

Write several candidate decisions and score them before you commit. Four criteria, scored 1–5: decision value (would the answer change something important?), data fit (does the data contain what the decision needs?), feasibility (can it be done well in about 25 hours?), low risk (can it be done without harming anyone or breaking a rule?).

scores = pd.read_csv("examples/L110_candidate_scoring.csv")
weights = {"decision_value": 0.35, "data_fit": 0.25, "feasibility": 0.25, "low_risk": 0.15}
scores["score"] = sum(scores[c] * w for c, w in weights.items()).round(2)
print(scores[["candidate", "decision", "score"]].sort_values("score", ascending=False).to_string(index=False))

candidate                                                decision  score
       C1         Which product lines to review for cancellations   4.50
       C2 Which lapsed customers to contact with a win-back offer   3.60
       C3             Which countries to prioritise for marketing   2.75

C1 wins mostly on data fit: cancellations are in the data, with dates and products. C2 (win-back) is valuable but the data has no contact history or offer results; L113 returns to it. C3 (countries) suffers from thin data outside the UK. The weights are a judgement: write them down so a reviewer can disagree with them openly.

Part C — Framing the decision

Because a miss costs more than a false alarm here, the decision can accept some false alarms: reviewing a line that turns out fine is cheap.

The data has no product-line column. A line must be derived from the description, with a rule that is written down and tested:

LINES = {"candles": r"CANDLE", "kitchen": r"MUG|BOWL|TEAPOT|EGG CUP", "garden": r"PLANTER|WATERING CAN|BIRD FEEDER|SEED TIN",
         "cards_wrap": r"CARD|WRAP", "lighting": r"LANTERN|LAMP|LIGHTS", "toys": r"TOY|PUZZLE"}


def line_of(description):
    hits = [name for name, pattern in LINES.items() if re.search(pattern, description)]
    return hits[0] if len(hits) == 1 else ("none" if not hits else "ambiguous")


cg["line"] = cg["Description"].map(line_of)
print(cg["line"].value_counts().to_string())
print("descriptions without a line:", sorted(cg.loc[cg["line"] == "none", "Description"].unique()))

line
cards_wrap    9874
candles       7465
kitchen       7341
garden        6472
lighting      6156
toys          5964
none           670
descriptions without a line: ['POSTAGE']

Every product description maps to exactly one line; the only unmapped rows are postage, which are not products. On the real data you would expect descriptions that match no rule or two rules: report them, never hide them.

Part D — KPI baselines

cg = cg.drop_duplicates()
cg["value"] = cg["Quantity"] * cg["UnitPrice"]
cg["cancelled"] = cg["InvoiceNo"].str.startswith("C")
year = cg[(cg["InvoiceDate"] >= "2010-12-01") & (cg["InvoiceDate"] < "2011-12-01") & (cg["line"].isin(LINES))]
sold = year[~year["cancelled"]].groupby("line")["value"].sum()
cancelled = -year[year["cancelled"]].groupby("line")["value"].sum()
base = pd.DataFrame({"sold_gbp": sold.round(0), "cancelled_gbp": cancelled.round(0), "rate": (cancelled / sold).round(4)})
print(base.sort_values("rate", ascending=False).to_string())
print("all lines:", round(cancelled.sum() / sold.sum(), 4))

            sold_gbp  cancelled_gbp    rate
line                                       
lighting    266387.0        19020.0  0.0714
garden      212492.0         5515.0  0.0260
toys        140745.0         3321.0  0.0236
candles     118922.0         2601.0  0.0219
kitchen     137362.0         2731.0  0.0199
cards_wrap   40434.0          754.0  0.0187
all lines: 0.037

Lighting stands out: its cancellation rate (7.1%) is about three times that of the other lines (1.9%–2.6%). This is a baseline, not an explanation: L111 checks the data's quality and L113 tests whether the difference is real and when it started.

Part E — Domain risk rules and an AI-drafted brief

Each domain has rules that protect people and the business from over-confident claims. D.World's Studio applies these in every brief, memo and checker:

Read ai_transcripts/L110_ai_project_brief.md, then check each claim against the data:

print("columns include ProductCategory:", "ProductCategory" in cg.columns)
print("any column with costs or margins:", any(k in c.lower() for c in cg.columns for k in ("cost", "margin", "profit")))
print("any column with a cancellation reason:", any("reason" in c.lower() for c in cg.columns))
sold_year = year[~year["cancelled"]]
print("UK share of value sold:", round(sold_year.loc[sold_year["Country"] == "United Kingdom", "value"].sum() / sold_year["value"].sum(), 3))
print("highest cancellation rate:", base["rate"].idxmax())

columns include ProductCategory: False
any column with costs or margins: False
any column with a cancellation reason: False
UK share of value sold: 0.893
highest cancellation rate: lighting

5. Worked Example

Fictional business, synthetic replica. The analytics team frames C1 for the buying manager.

Step 1 — Candidates: three decisions scored; C1 (product lines to review) 4.50, ahead of C2 and C3.

Step 2 — Frame: stakeholder, decision (at most two lines), success metric (cancellation rate by value), cost of error (a miss costs more than a false alarm), scope (Dec 2010 – Nov 2011), evidence requirements.

Step 3 — Baseline: lighting 7.1% against 1.9%–2.6% for the other lines; all lines 3.7%.

Step 4 — Claims: every claim in the brief labelled supported, assumption or unsupported; the word "profitable" removed; the invented target removed.

6. Visual Explanation

 CANDIDATES ──score──▶ decision value · data fit · feasibility · low risk (weights written down) ──▶ choose C1
    ▼
 FRAME: stakeholder · decision · success metric · COST OF ERROR (false alarm vs miss) · scope · evidence requirements
    ▼
 DATA:  derive what is missing (product line from description, rule tested) ──▶ KPI BASELINE per line
    ▼
 BRIEF: every claim → supported | assumption | unsupported   +   DOMAIN RISK RULES (no "profitable" without costs …)

Alt text: Candidate decisions are scored on decision value, data fit, feasibility and low risk with written weights, and C1 is chosen. The decision is framed with stakeholder, decision, success metric, cost of error comparing false alarms and misses, scope and evidence requirements. Missing information, the product line, is derived from the description with a tested rule, and a KPI baseline is computed per line. Every claim in the brief is labelled supported, assumption or unsupported, and the domain risk rules are applied, such as never saying "profitable" without cost data.

7. Guided Practice

In L110_starter.ipynb:

1. Change the weights so that feasibility counts most. Does the choice change? Write one sentence on whether that weighting is defensible.
2. Add a fourth candidate of your own to the scoring table and score it honestly.
3. Compute the cancellation rate by line by count of lines instead of value. Does lighting still stand out?
4. Find the share of rows with no CustomerID. Which of the three candidates does this affect most, and why?
5. Rewrite the AI brief's five points so that each is supported, labelled as an assumption, or removed.

8. Independent Practice

Your flagship brief. Read U26_EXIT/FLAGSHIP_BRIEF.md and the Project Library index. Choose RET-F1 (Online Retail II, real data) or propose your own flagship (approval rules in the brief).

1. Write three candidate decisions for your data and score them (template templates/candidate_scoring_template.csv), with your weights.
2. Write docs/project_brief.md (template) for the chosen one: stakeholder, decision options, success metric with formula, cost of error in both directions, scope and non-goals, evidence requirements, and the domain risk rules that apply.
3. Compute at least two KPI baselines on the real data and put them in the brief.
4. Mark every claim in your brief as supported (with the output) or assumption.

9. Knowledge Check — Framing

Q1. Which candidate project is usually the best choice?

• A) The one that uses the largest and best-known public dataset available
• B) One whose answer would change a decision soon, with data that fits
• C) The one that needs the most advanced machine-learning method to solve
• D) The one that produces the largest number of charts for your portfolio

Q2. Why write down the weights in the candidate scoring table?

• A) So a reviewer can see and challenge the judgement behind the choice
• B) Because the weights make the scores objective and beyond dispute
• C) Because the template does not accept a scoring table without weights
• D) So that every candidate ends up with the same total score in the end

Q3. For the product-line review, a miss costs more than a false alarm. What follows?

• A) The review must only include lines that are certain to be faulty
• B) The analysis should not recommend any review until all data is perfect
• C) Reviewing a line that proves fine is acceptable; a missed fault is worse
• D) Costs of errors do not matter, because reviews are a routine part of the job

Q4. The data has no product-line column. What is the right approach?

• A) Ask an assistant to assign each product to a line and then use its answer
• B) Drop the idea of product lines and analyse individual products only
• C) Use the ProductCategory column that most retail datasets contain
• D) Derive lines with a written rule, test it, report what it can't map

Q5. UK customers bring 89% of value sold. Why may the brief not call them "the most profitable segment"?

• A) There is no cost data, so the profit of any segment cannot be known
• B) 89% is not high enough to call any segment the most profitable
• C) The UK is a country, not a customer segment, in this kind of data
• D) Profit can only be measured for customers who have a customer ID

Q6. Lighting's cancellation rate is 7.1% against about 2% for other lines. What is this number?

• A) Proof that the lighting supplier delivered a faulty batch of products
• B) A baseline that still needs quality checks and a test of its timing
• C) An error, because cancellation rates cannot differ so much between lines
• D) A reason to stop selling lighting products from next month onwards

Q7. Which statement follows the finance domain risk rule?

• A) "These 40 transactions are fraud and the cards should be blocked."
• B) "The model has found the fraudsters among our card customers."
• C) "Flags show likely fraud, so customers can be contacted about it."
• D) "These 40 transactions are flagged for review; none is confirmed."

Q8. The AI brief says cancellations are "mainly customers changing their minds". How should it be labelled?

• A) Supported, because it is the most common reason for cancellations
• B) Unsupported but harmless, so it can stay in the brief without a label
• C) An assumption: the data records no reason for any cancellation
• D) Supported, because the assistant has seen data from many retailers

10. AI in Practice (optional, bounded)

Goal: widen your list of candidate decisions, then keep only those your data can inform.

1. Give an assistant your dataset's column names (not the data) and ask: "List ten decisions a business could make with data that has these columns. For each, say which columns it needs."
2. Reject every decision that needs data you do not have (costs, reasons, customer details).
3. Score the survivors with your weights; log the interaction.

Boundaries: AI is optional. Give schemas, not data. The assistant proposes candidates; your scoring and the stakeholder decide.

11. AI Verification

1. Columns: every column an AI brief mentions exists in the data.
2. Words with obligations: "profitable", "fraud", "caused", "guaranteed" are checked against the domain risk rules and the data.
3. Numbers: every number in the brief is recomputed (here: 89.3% of value sold).
4. Record: label every claim supported, assumption or unsupported, and log the interaction.

12. Business Lens

The best project is the one whose answer changes a decision soon. Cedar Gifts' buying manager can act on "review lighting" next week; "UK customers are the most profitable" would have sent marketing after a claim nobody can check. Scoring candidates and stating the cost of error takes an hour and decides whether the next 25 hours are useful.

13. Workplace Task — The Framing Note

Fictional business: Cedar Gifts. Write the note (100–150 words) to the buying manager: the decision as you framed it, the success metric and its baseline, why a miss costs more than a false alarm here, what the data cannot tell you (reasons for cancellation), and what you will deliver next.

14. Mini Challenge — What Is at Stake?

Fictional business, synthetic replica. How much cancelled value would lighting have had in the year if its rate had been the average of the other five lines?

others = cancelled.drop("lighting").sum() / sold.drop("lighting").sum()
excess = cancelled["lighting"] - others * sold["lighting"]
print(f"other lines' rate {others:.4f} | lighting excess cancelled value £{excess:,.0f} of £{sold['lighting']:,.0f} sold")

other lines' rate 0.0230 | lighting excess cancelled value £12,904 of £266,387 sold

1. Before you open the output, estimate the excess in pounds from the baseline table.
2. What does the output show?
3. Does this amount justify a supplier review that costs a few days of staff time? What else would you want to know?
4. Write the sentence for the brief's cost-of-error section.

Submit before feedback. No solution is provided here.

15. Resources

Required (about 25 min):

• UCI Machine Learning Repository. Online Retail II. Read the dataset page: variables, period, licence, citation. https://archive.ics.uci.edu/dataset/502/online+retail+ii (Opened 28 Oct 2026.)
• AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (Opened 28 Oct 2026.)

16. Person to Follow / Role Model

Cassie Kozyrkov.

• Verified fact: her home page describes her as "Decision Intelligence Pioneer" and defines decision intelligence as "The discipline of turning information into better actions, in any setting and at any scale." (kozyr.com, opened 28 Oct 2026).
• Why D.World recommends her: she starts every data project from the decision and its consequences, which is how this lesson chooses a flagship.
• Honest note: her page also contains text addressed to AI tools; D.World quotes only her self-description and definition.
• Try this: before you open your flagship data, write the decision in one sentence and the cost of being wrong in each direction.

17. Glossary

Review: project specification (L104) · capstone proposal (L101).

18. Reflection

1. Which weight in your scoring table would a sceptical reviewer challenge first?
2. In your flagship, which error costs more: a false alarm or a miss?
3. Which of your claims would you most like to be true, and is it labelled honestly?

19. Next Step

Next: L111 — Build a Data & Evidence Pack. You document and test the data before you rely on it.

20. Assessment Evidence

References

1. Chen, D. (2012). Online Retail II. UCI Machine Learning Repository. https://archive.ics.uci.edu/dataset/502/online+retail+ii (ORII). DOI 10.24432/C5CG6D; CC BY 4.0. Supports: variables; "c" invoice code = cancellation; period 01/12/2009–09/12/2011.
2. Amazon Web Services. AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (AWS-DS). Supports: business value before method.
3. Kozyrkov, C. Home page. https://www.kozyr.com/ (KOZYR). Supports: role model (quoted).
4. D.World AI Project Studio Detailed Lesson Map v1.0 (L110 row); decisions S05–S07 and S19. Internal.

L110 — اختر مجالًا وصُغ القرار

ملف المتعلّم. الإجابات والحلول النموذجية في ملف منفصل خاص بالمدرّس فقط. الإصدار: U26 Production v1 · تاريخ المحتوى: 28 أكتوبر 2026. تقديرات الوقت تقديرات للتخطيط إلى أن يختبرها المتعلّمون. الكود في هذا الدرس شُغّل باستخدام Python 3.13.16 وpandas 3.0.5 (مسجّل في تقرير اختبار الكود الداخلي في D.World)؛ وPython 3.13 هو الإصدار المعتمد في المقرر. ولم يُشغَّل باستخدام Python 3.14 ولا داخل JupyterLab.

Cedar Gifts خيالية. وبياناتها نسخة مصطنعة مطابقة (synthetic replica): لها متغيرات مجموعة البيانات العامة Online Retail II نفسها، لكن كل صف فيها أنشأته D.World، حتى تستطيع الدروس عرض النتائج دون أن تؤدي عنك تحليل مشروعك الرئيسي. و"ردود الذكاء الاصطناعي المسجّلة" في ai_transcripts/ كتبتها D.World للتعليم وفيها أخطاء متعمَّدة.

1. بطاقة الدرس

تفصيل الوقت (تقدير للتخطيط):

• المفهوم والمثال المحلول: 55 دقيقة.
• التدريب الموجَّه: 35 دقيقة.
• التدريب المستقل: 35 دقيقة.
• اختبار الفهم: 10 دقائق.
• الذكاء الاصطناعي: 5 دقائق (اختياري).
• مهمة العمل والتحدي القصير: 10 دقائق.

ما تحتاج إليه: Python مع pandas؛ ومجلد practice_files (L110_starter.ipynb؛ وcg_data/cedar_gifts_transactions.csv وcg_data/data_README.md؛ وexamples/L110_candidate_scoring.csv؛ وai_transcripts/L110_ai_project_brief.md)؛ وU26_EXIT/FLAGSHIP_BRIEF.md وU26_EXIT/project_library/.

2. هدف التعلّم

في نهاية هذا الدرس، ستكون قادرًا على أن:

• تقارن بين المشاريع المرشّحة بحسب قيمة القرار، وملاءمة البيانات، والجدوى، والمخاطر، وتختار واحدًا منها؛
• تصوغ القرار مع صاحب المصلحة، ومقياس النجاح، وتكلفة الخطأ، والنطاق، ومتطلبات الأدلة؛
• تحسب خطوط الأساس لمؤشرات الأداء على البيانات، وتصنّف كل ادعاء في الموجز إلى مدعوم أو افتراض؛
• تطبّق قواعد المخاطر الخاصة بالقطاع الذي اخترته.

الهدف المعتمد من D.World (بنصّه): Select a project domain and frame a decision with its stakeholder, success metric, cost of error, scope and evidence requirements.

(وبالعربية: اختر مجالًا للمشروع، وصُغ قرارًا مع صاحب المصلحة، ومقياس النجاح، وتكلفة الخطأ، والنطاق، ومتطلبات الأدلة.)

3. لماذا يهمّك هذا؟

في U25 أعطاك صاحب مصلحة طلبًا. وفي U26 أنت من يختار: مجالًا، ومجموعة بيانات، وقرارًا يستحق أن تُقدَّم له المعلومات. وهذه الحرية هي المكان الذي تنحرف فيه كثير من مشاريع البورتفوليو. فهي تبدأ من مجموعة بيانات شهيرة وتبحث عن شيء تحسبه، وتنتهي برسوم لا تجيب عن سؤال أحد.

المشروع الجيد يبدأ من قرار يمكن أن يتخذه شخص ما قريبًا، ويتحقق من أن البيانات تستطيع فعلًا أن تفيده، ويذكر ما تكلّفه الإجابة الخاطئة. وتسمّي Cassie Kozyrkov هذا الانضباط ذكاء القرار (decision intelligence): "The discipline of turning information into better actions, in any setting and at any scale." (أي: "علم تحويل المعلومات إلى أفعال أفضل، في أي سياق وبأي حجم."). وفي هذا الدرس تتدرب عليه مع Cedar Gifts، وهي نسخة مصطنعة مطابقة لبيانات التجزئة في المشروع الرئيسي RET-F1 من D.World، قبل أن تصوغ مشروعك الرئيسي أنت.

المبدأ الأساسي: اختر المشروع الذي ستغيّر إجابته قرارًا قريبًا؛ واذكر تكلفة الخطأ في الاتجاهين؛ وقِس نقطة البداية؛ ولا تكتب إلا الادعاءات التي تستطيع البيانات دعمها.

4. المفهوم

الجزء A — البيانات، وما تستطيع إثباته وما لا تستطيع

import re

import pandas as pd

cg = pd.read_csv("cg_data/cedar_gifts_transactions.csv", dtype={"InvoiceNo": str, "StockCode": str, "CustomerID": str},
                 parse_dates=["InvoiceDate"])
print(cg.shape, "|", cg["InvoiceDate"].min().date(), "to", cg["InvoiceDate"].max().date())
print(cg.columns.tolist())
uci_variables = ["InvoiceNo", "StockCode", "Description", "Quantity", "InvoiceDate", "UnitPrice", "CustomerID", "Country"]
print("same variables as listed on the UCI page:", cg.columns.tolist() == uci_variables)

(43942, 8) | 2009-12-01 to 2011-12-09
['InvoiceNo', 'StockCode', 'Description', 'Quantity', 'InvoiceDate', 'UnitPrice', 'CustomerID', 'Country']
same variables as listed on the UCI page: True

("same variables as listed on the UCI page: True" = المتغيرات نفسها المذكورة في صفحة UCI: نعم.)

كل صف سطر واحد من فاتورة. وتقول صفحة Online Retail II في UCI إن رمز الفاتورة الذي يبدأ بـ "c" يدل على إلغاء؛ والنسخة المطابقة تتبع هذه القاعدة. ما تستطيع البيانات إثباته: ما الذي بيع وما الذي أُلغي، ومتى، ولأي عميل (باسم مستعار) ولأي دولة، وبأي سعر. وما لا تستطيع: التكاليف أو الأرباح، ولماذا أُلغي طلب ما، ومن هم العملاء، أو ما الذي كان سيحدث لو طُبّقت سياسة أخرى.

الجزء B — المقارنة بين المشاريع المرشّحة

اكتب عدة قرارات مرشّحة وقيّمها قبل أن تلتزم. أربعة معايير، يُعطى كلٌّ منها من 1 إلى 5: قيمة القرار (decision value) (هل ستغيّر الإجابة شيئًا مهمًا؟)، وملاءمة البيانات (data fit) (هل تحتوي البيانات على ما يحتاج إليه القرار؟)، والجدوى (feasibility) (هل يمكن إنجازه جيدًا في حوالي 25 ساعة؟)، وانخفاض المخاطر (low risk) (هل يمكن إنجازه دون إيذاء أحد أو كسر قاعدة؟).

scores = pd.read_csv("examples/L110_candidate_scoring.csv")
weights = {"decision_value": 0.35, "data_fit": 0.25, "feasibility": 0.25, "low_risk": 0.15}
scores["score"] = sum(scores[c] * w for c, w in weights.items()).round(2)
print(scores[["candidate", "decision", "score"]].sort_values("score", ascending=False).to_string(index=False))

candidate                                                decision  score
       C1         Which product lines to review for cancellations   4.50
       C2 Which lapsed customers to contact with a win-back offer   3.60
       C3             Which countries to prioritise for marketing   2.75

(ترجمة القرارات: C1 = أي خطوط المنتجات تُراجع بسبب الإلغاءات؛ C2 = أي العملاء المنقطعين يُتواصل معهم بعرض لاستعادتهم؛ C3 = أي الدول تُعطى الأولوية في التسويق.)

يفوز C1 أساسًا بـ ملاءمة البيانات: فالإلغاءات موجودة في البيانات، بتواريخها ومنتجاتها. وC2 (استعادة العملاء) قيّم، لكن البيانات ليس فيها سجل تواصل ولا نتائج عروض؛ ويعود إليه L113. وC3 (الدول) يعاني من قلة البيانات خارج المملكة المتحدة. والأوزان حكم شخصي: اكتبها حتى يستطيع المراجع أن يختلف معها علنًا.

الجزء C — صياغة القرار

ولأن الإغفال هنا يكلّف أكثر من الإنذار الكاذب، يستطيع القرار أن يقبل بعض الإنذارات الكاذبة: فمراجعة خط يتبيّن أنه سليم رخيصة.

البيانات ليس فيها عمود لخط المنتجات. لذلك يجب استنتاج الخط من الوصف، بقاعدة مكتوبة ومختبَرة:

LINES = {"candles": r"CANDLE", "kitchen": r"MUG|BOWL|TEAPOT|EGG CUP", "garden": r"PLANTER|WATERING CAN|BIRD FEEDER|SEED TIN",
         "cards_wrap": r"CARD|WRAP", "lighting": r"LANTERN|LAMP|LIGHTS", "toys": r"TOY|PUZZLE"}


def line_of(description):
    hits = [name for name, pattern in LINES.items() if re.search(pattern, description)]
    return hits[0] if len(hits) == 1 else ("none" if not hits else "ambiguous")


cg["line"] = cg["Description"].map(line_of)
print(cg["line"].value_counts().to_string())
print("descriptions without a line:", sorted(cg.loc[cg["line"] == "none", "Description"].unique()))

line
cards_wrap    9874
candles       7465
kitchen       7341
garden        6472
lighting      6156
toys          5964
none           670
descriptions without a line: ['POSTAGE']

(الخطوط: cards_wrap = البطاقات وورق التغليف، candles = الشموع، kitchen = المطبخ، garden = الحديقة، lighting = الإضاءة، toys = الألعاب، none = بلا خط؛ "descriptions without a line" = الأوصاف التي لا خط لها، وPOSTAGE = رسوم البريد.)

كل وصف منتج يُطابَق مع خط واحد بالضبط؛ والصفوف الوحيدة غير المطابَقة هي رسوم البريد، وهي ليست منتجات. وعلى البيانات الحقيقية، توقّع أوصافًا لا تطابق أي قاعدة أو تطابق قاعدتين: أبلغ عنها، ولا تخفِها أبدًا.

الجزء D — خطوط الأساس لمؤشرات الأداء

cg = cg.drop_duplicates()
cg["value"] = cg["Quantity"] * cg["UnitPrice"]
cg["cancelled"] = cg["InvoiceNo"].str.startswith("C")
year = cg[(cg["InvoiceDate"] >= "2010-12-01") & (cg["InvoiceDate"] < "2011-12-01") & (cg["line"].isin(LINES))]
sold = year[~year["cancelled"]].groupby("line")["value"].sum()
cancelled = -year[year["cancelled"]].groupby("line")["value"].sum()
base = pd.DataFrame({"sold_gbp": sold.round(0), "cancelled_gbp": cancelled.round(0), "rate": (cancelled / sold).round(4)})
print(base.sort_values("rate", ascending=False).to_string())
print("all lines:", round(cancelled.sum() / sold.sum(), 4))

            sold_gbp  cancelled_gbp    rate
line                                       
lighting    266387.0        19020.0  0.0714
garden      212492.0         5515.0  0.0260
toys        140745.0         3321.0  0.0236
candles     118922.0         2601.0  0.0219
kitchen     137362.0         2731.0  0.0199
cards_wrap   40434.0          754.0  0.0187
all lines: 0.037

(sold_gbp = القيمة المبيعة بالجنيه الإسترليني؛ cancelled_gbp = القيمة الملغاة؛ rate = المعدل؛ "all lines" = كل الخطوط.)

الإضاءة تبرز: فمعدل الإلغاء فيها (7.1%) يقارب ثلاثة أضعاف معدلات الخطوط الأخرى (من 1.9% إلى 2.6%). وهذا خط أساس (baseline)، لا تفسير: يفحص L111 جودة البيانات، ويختبر L113 هل الفرق حقيقي ومتى بدأ.

الجزء E — قواعد المخاطر الخاصة بكل مجال، وموجز صاغه الذكاء الاصطناعي

لكل مجال قواعد تحمي الناس والنشاط من الادعاءات المفرطة في الثقة. ويطبّق استوديو D.World هذه القواعد في كل موجز ومذكرة وأداة فحص:

اقرأ ai_transcripts/L110_ai_project_brief.md، ثم افحص كل ادعاء مقابل البيانات:

print("columns include ProductCategory:", "ProductCategory" in cg.columns)
print("any column with costs or margins:", any(k in c.lower() for c in cg.columns for k in ("cost", "margin", "profit")))
print("any column with a cancellation reason:", any("reason" in c.lower() for c in cg.columns))
sold_year = year[~year["cancelled"]]
print("UK share of value sold:", round(sold_year.loc[sold_year["Country"] == "United Kingdom", "value"].sum() / sold_year["value"].sum(), 3))
print("highest cancellation rate:", base["rate"].idxmax())

columns include ProductCategory: False
any column with costs or margins: False
any column with a cancellation reason: False
UK share of value sold: 0.893
highest cancellation rate: lighting

(ترجمة المخرجات: هل تشمل الأعمدة ProductCategory: لا؛ هل يوجد عمود للتكاليف أو الهوامش: لا؛ هل يوجد عمود لسبب الإلغاء: لا؛ حصة المملكة المتحدة من القيمة المبيعة: 0.893؛ أعلى معدل إلغاء: الإضاءة.)

5. مثال محلول

نشاط خيالي، ونسخة مصطنعة مطابقة. يصوغ فريق التحليلات C1 لمدير المشتريات.

الخطوة 1 — المرشّحات: ثلاثة قرارات قُيّمت؛ وC1 (خطوط المنتجات التي تُراجع) حصل على 4.50، متقدمًا على C2 وC3.

الخطوة 2 — الصياغة: صاحب المصلحة، والقرار (خطّان على الأكثر)، ومقياس النجاح (معدل الإلغاء بالقيمة)، وتكلفة الخطأ (الإغفال يكلّف أكثر من الإنذار الكاذب)، والنطاق (من ديسمبر 2010 إلى نوفمبر 2011)، ومتطلبات الأدلة.

الخطوة 3 — خط الأساس: الإضاءة 7.1% مقابل 1.9%–2.6% للخطوط الأخرى؛ وكل الخطوط 3.7%.

الخطوة 4 — الادعاءات: كل ادعاء في الموجز صُنّف إلى مدعوم أو افتراض أو غير مدعوم؛ وحُذفت كلمة "مربحة"؛ وحُذف الهدف المختلَق.

6. شرح بصري

 CANDIDATES ──score──▶ decision value · data fit · feasibility · low risk (weights written down) ──▶ choose C1
    ▼
 FRAME: stakeholder · decision · success metric · COST OF ERROR (false alarm vs miss) · scope · evidence requirements
    ▼
 DATA:  derive what is missing (product line from description, rule tested) ──▶ KPI BASELINE per line
    ▼
 BRIEF: every claim → supported | assumption | unsupported   +   DOMAIN RISK RULES (no "profitable" without costs …)

وصف الرسم: تُقيَّم القرارات المرشّحة بحسب قيمة القرار، وملاءمة البيانات، والجدوى، وانخفاض المخاطر بأوزان مكتوبة، ويُختار C1. ويُصاغ القرار مع صاحب المصلحة، والقرار، ومقياس النجاح، وتكلفة الخطأ بالمقارنة بين الإنذارات الكاذبة والإغفالات، والنطاق، ومتطلبات الأدلة. والمعلومة الناقصة، أي خط المنتجات، تُستنتج من الوصف بقاعدة مختبَرة، ويُحسب خط أساس لمؤشر الأداء لكل خط. وكل ادعاء في الموجز يُصنّف إلى مدعوم أو افتراض أو غير مدعوم، وتُطبَّق قواعد المخاطر الخاصة بالمجال، مثل عدم قول "مربح" أبدًا دون بيانات تكاليف. (نصوص الرسم: CANDIDATES = المرشّحات؛ score = قيّم؛ decision value · data fit · feasibility · low risk (weights written down) = قيمة القرار · ملاءمة البيانات · الجدوى · انخفاض المخاطر (الأوزان مكتوبة)؛ choose C1 = اختر C1؛ FRAME = الصياغة؛ stakeholder · decision · success metric · COST OF ERROR (false alarm vs miss) · scope · evidence requirements = صاحب المصلحة · القرار · مقياس النجاح · تكلفة الخطأ (الإنذار الكاذب مقابل الإغفال) · النطاق · متطلبات الأدلة؛ DATA: derive what is missing (product line from description, rule tested) = البيانات: استنتج ما ينقص (خط المنتجات من الوصف، بقاعدة مختبَرة)؛ KPI BASELINE per line = خط أساس مؤشر الأداء لكل خط؛ BRIEF: every claim → supported | assumption | unsupported = الموجز: كل ادعاء ← مدعوم | افتراض | غير مدعوم؛ DOMAIN RISK RULES (no "profitable" without costs …) = قواعد مخاطر المجال (لا "مربح" دون تكاليف …).)

7. تدريب موجَّه

في L110_starter.ipynb:

1. غيّر الأوزان بحيث يكون للـ جدوى الوزن الأكبر. هل يتغير الاختيار؟ واكتب جملة واحدة عن مدى إمكانية الدفاع عن هذا الترجيح.
2. أضف مرشّحًا رابعًا من عندك إلى جدول التقييم وقيّمه بأمانة.
3. احسب معدل الإلغاء لكل خط بحسب عدد السطور بدلًا من القيمة. هل ما زالت الإضاءة تبرز؟
4. أوجد نسبة الصفوف التي ليس فيها CustomerID. أي المرشّحات الثلاثة يتأثر بهذا أكثر، ولماذا؟
5. أعد كتابة النقاط الخمس في موجز الذكاء الاصطناعي بحيث تكون كل نقطة مدعومة، أو مصنّفة على أنها افتراض، أو محذوفة.

8. تدريب مستقل

موجز مشروعك الرئيسي. اقرأ U26_EXIT/FLAGSHIP_BRIEF.md وفهرس مكتبة المشاريع. واختر RET-F1 (Online Retail II، بيانات حقيقية) أو اقترح مشروعك الرئيسي الخاص (قواعد الموافقة في الموجز).

1. اكتب ثلاثة قرارات مرشّحة لبياناتك وقيّمها (القالب templates/candidate_scoring_template.csv)، بأوزانك أنت.
2. اكتب docs/project_brief.md (القالب) للمرشّح الذي اخترته: صاحب المصلحة، وخيارات القرار، ومقياس النجاح مع صيغته، وتكلفة الخطأ في الاتجاهين، والنطاق وما هو خارج الأهداف، ومتطلبات الأدلة، وقواعد مخاطر المجال التي تنطبق.
3. احسب خطّي أساس على الأقل لمؤشرات الأداء على البيانات الحقيقية، وضعهما في الموجز.
4. صنّف كل ادعاء في موجزك إلى مدعوم (مع المخرجات) أو افتراض.

9. اختبار الفهم (Knowledge Check) — صياغة القرار

Q1. أي مشروع مرشّح هو عادةً الاختيار الأفضل؟

• A) المشروع الذي يستخدم أكبر مجموعة بيانات عامة متاحة وأشهرها
• B) مشروع ستغيّر إجابته قرارًا قريبًا، وبياناته ملائمة
• C) المشروع الذي يحتاج إلى أكثر أساليب تعلّم الآلة تقدمًا لحلّه
• D) المشروع الذي ينتج أكبر عدد من الرسوم لبورتفوليو

Q2. لماذا تكتب الأوزان في جدول تقييم المرشّحات؟

• A) حتى يستطيع المراجع أن يرى الحكم وراء الاختيار ويعترض عليه
• B) لأن الأوزان تجعل الدرجات موضوعية وفوق أي نقاش
• C) لأن القالب لا يقبل جدول تقييم بلا أوزان
• D) حتى يحصل كل مرشّح في النهاية على الدرجة الإجمالية نفسها

Q3. في مراجعة خطوط المنتجات، الإغفال يكلّف أكثر من الإنذار الكاذب. ماذا يترتب على ذلك؟

• A) يجب ألّا تشمل المراجعة إلا الخطوط المؤكد أنها معيبة
• B) يجب ألّا يوصي التحليل بأي مراجعة حتى تكتمل البيانات كلها
• C) مراجعة خط يتبيّن أنه سليم مقبولة؛ أما العيب الذي يُغفل فأسوأ
• D) تكاليف الأخطاء لا تهم، لأن المراجعات جزء روتيني من العمل

Q4. البيانات ليس فيها عمود لخط المنتجات. ما المنهج الصحيح؟

• A) أن تطلب من مساعد ذكاء اصطناعي أن ينسب كل منتج إلى خط ثم تستخدم إجابته
• B) أن تتخلى عن فكرة خطوط المنتجات وتحلّل المنتجات المفردة فقط
• C) أن تستخدم العمود ProductCategory الموجود في معظم بيانات التجزئة
• D) أن تستنتج الخطوط بقاعدة مكتوبة، وتختبرها، وتبلغ عمّا لا تستطيع مطابقته

Q5. عملاء المملكة المتحدة يجلبون 89% من القيمة المبيعة. لماذا لا يجوز أن يصفهم الموجز بأنهم "الشريحة الأكثر ربحية"؟

• A) لا توجد بيانات تكاليف، فلا يمكن معرفة ربح أي شريحة
• B) 89% ليست مرتفعة بما يكفي لوصف أي شريحة بأنها الأكثر ربحية
• C) المملكة المتحدة دولة، لا شريحة عملاء، في هذا النوع من البيانات
• D) لا يمكن قياس الربح إلا للعملاء الذين لديهم رقم عميل

Q6. معدل الإلغاء في الإضاءة 7.1% مقابل حوالي 2% في الخطوط الأخرى. ما هذا الرقم؟

• A) دليل على أن مورّد الإضاءة سلّم دفعة معيبة من المنتجات
• B) خط أساس ما زال يحتاج إلى فحوص للجودة واختبار لتوقيته
• C) خطأ، لأن معدلات الإلغاء لا يمكن أن تختلف بهذا القدر بين الخطوط
• D) سبب لوقف بيع منتجات الإضاءة بدءًا من الشهر القادم

Q7. أي عبارة تتبع قاعدة مخاطر المجال المالي؟

• A) "هذه المعاملات الأربعون احتيال ويجب إيقاف البطاقات."
• B) "عثر النموذج على المحتالين بين عملاء بطاقاتنا."
• C) "العلامات تُظهر احتيالًا محتملًا، لذلك يمكن التواصل مع العملاء بشأنه."
• D) "هذه المعاملات الأربعون مُعلَّمة للمراجعة؛ ولم يتأكد أيٌّ منها."

Q8. يقول موجز الذكاء الاصطناعي إن الإلغاءات "في الغالب عملاء غيّروا رأيهم". كيف يجب تصنيف ذلك؟

• A) مدعوم، لأنه أكثر أسباب الإلغاء شيوعًا
• B) غير مدعوم لكنه غير ضار، فيمكن أن يبقى في الموجز بلا تصنيف
• C) افتراض: البيانات لا تسجّل أي سبب لأي إلغاء
• D) مدعوم، لأن المساعد اطّلع على بيانات من كثير من متاجر التجزئة

10. الذكاء الاصطناعي في التطبيق (اختياري، وفي حدود)

الهدف: أن توسّع قائمة القرارات المرشّحة، ثم تحتفظ فقط بما تستطيع بياناتك أن تفيده.

1. أعطِ المساعد أسماء أعمدة بياناتك (لا البيانات نفسها) واسأل:

"List ten decisions a business could make with data that has these columns. For each, say which columns it needs."

وبالعربية: "اسرد عشرة قرارات يمكن أن يتخذها نشاط تجاري ببيانات فيها هذه الأعمدة. ولكلٍّ منها، قل ما الأعمدة التي يحتاج إليها."

2. ارفض كل قرار يحتاج إلى بيانات ليست لديك (التكاليف، والأسباب، وتفاصيل العملاء).
3. قيّم القرارات المتبقية بأوزانك؛ وسجّل التفاعل.

الحدود:

• استخدام الذكاء الاصطناعي اختياري.
• أعطِ المخططات (schemas)، لا البيانات.
• المساعد يقترح المرشّحات؛ أما تقييمك وصاحب المصلحة فهما اللذان يقرران.

11. التحقق من مخرجات الذكاء الاصطناعي

1. الأعمدة: كل عمود يذكره موجز الذكاء الاصطناعي موجود في البيانات.
2. الكلمات التي تحمل التزامات: كلمات مثل "profitable" (مربح)، و"fraud" (احتيال)، و"caused" (تسبّب)، و"guaranteed" (مضمون) تُفحص مقابل قواعد مخاطر المجال والبيانات.
3. الأرقام: كل رقم في الموجز يُعاد حسابه (هنا: 89.3% من القيمة المبيعة).
4. السجل: صنّف كل ادعاء إلى مدعوم أو افتراض أو غير مدعوم، وسجّل التفاعل.

12. منظور الأعمال

أفضل مشروع هو الذي تغيّر إجابته قرارًا قريبًا. مدير المشتريات في Cedar Gifts يستطيع أن يتصرف بناءً على "راجِع الإضاءة" الأسبوع القادم؛ أما "عملاء المملكة المتحدة هم الأكثر ربحية" فكان سيدفع التسويق وراء ادعاء لا يستطيع أحد التحقق منه. وتقييم المرشّحات وذكر تكلفة الخطأ يستغرقان ساعة، ويحددان هل ستكون الساعات الخمس والعشرون التالية مفيدة.

13. مهمة عمل — مذكرة الصياغة

نشاط خيالي: Cedar Gifts. اكتب المذكرة (من 100 إلى 150 كلمة) إلى مدير المشتريات: القرار كما صغته، ومقياس النجاح وخط أساسه، ولماذا يكلّف الإغفال هنا أكثر من الإنذار الكاذب، وما لا تستطيع البيانات أن تخبرك به (أسباب الإلغاء)، وما الذي ستسلّمه بعد ذلك.

14. تحدٍّ قصير — ما الذي على المحك؟

نشاط خيالي، ونسخة مصطنعة مطابقة. كم كانت ستبلغ القيمة الملغاة للإضاءة خلال السنة لو كان معدلها مساويًا لمتوسط الخطوط الخمسة الأخرى؟

others = cancelled.drop("lighting").sum() / sold.drop("lighting").sum()
excess = cancelled["lighting"] - others * sold["lighting"]
print(f"other lines' rate {others:.4f} | lighting excess cancelled value £{excess:,.0f} of £{sold['lighting']:,.0f} sold")

other lines' rate 0.0230 | lighting excess cancelled value £12,904 of £266,387 sold

1. قبل أن تفتح المخرجات، قدّر القيمة الزائدة بالجنيه من جدول خط الأساس.
2. ماذا تُظهر المخرجات؟
3. هل يبرر هذا المبلغ مراجعة للمورّد تكلّف بضعة أيام من وقت الموظفين؟ وما الذي تريد أن تعرفه أيضًا؟
4. اكتب الجملة الخاصة بقسم تكلفة الخطأ في الموجز.

سلّم عملك قبل أن تتلقى الملاحظات. لا يوجد حل منشور هنا.

15. المصادر

مطلوب (حوالي 25 دقيقة):

• UCI Machine Learning Repository. Online Retail II. اقرأ صفحة مجموعة البيانات: المتغيرات، والفترة، والترخيص، وطريقة الاستشهاد. https://archive.ics.uci.edu/dataset/502/online+retail+ii (فُتح في 28 أكتوبر 2026.)
• AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (فُتح في 28 أكتوبر 2026.)

16. شخصية تتابعها / قدوة

Cassie Kozyrkov.

• حقيقة مُتحقَّق منها: تصفها صفحتها الرئيسية بأنها "Decision Intelligence Pioneer" (رائدة ذكاء القرار)، وتعرّف ذكاء القرار بأنه "The discipline of turning information into better actions, in any setting and at any scale." (أي: "علم تحويل المعلومات إلى أفعال أفضل، في أي سياق وبأي حجم.") (kozyr.com، فُتحت في 28 أكتوبر 2026).
• لماذا توصي بها D.World: تبدأ كل مشروع بيانات من القرار وعواقبه، وهذه هي الطريقة التي يختار بها هذا الدرس المشروع الرئيسي.
• ملاحظة صادقة: صفحتها تحتوي أيضًا على نص موجّه إلى أدوات الذكاء الاصطناعي؛ وD.World تقتبس فقط وصفها لنفسها وتعريفها.
• جرّب هذا: قبل أن تفتح بيانات مشروعك الرئيسي، اكتب القرار في جملة واحدة، وتكلفة الخطأ في كل اتجاه.

17. المصطلحات

للمراجعة: مواصفة المشروع (L104) · مقترح مشروع التخرج (L101).

18. تأمّل

1. أي وزن في جدول تقييمك سيعترض عليه المراجع المتشكك أولًا؟
2. في مشروعك الرئيسي، أي خطأ يكلّف أكثر: الإنذار الكاذب أم الإغفال؟
3. أي ادعاءاتك تتمنى أكثر من غيره أن يكون صحيحًا، وهل هو مصنَّف بأمانة؟

19. الخطوة التالية

التالي: L111 — ابنِ حزمة البيانات والأدلة (Build a Data & Evidence Pack). توثّق البيانات وتختبرها قبل أن تعتمد عليها.

20. أدلة التقييم

المراجع

1. Chen, D. (2012). Online Retail II. UCI Machine Learning Repository. https://archive.ics.uci.edu/dataset/502/online+retail+ii (ORII). DOI 10.24432/C5CG6D؛ CC BY 4.0. يدعم: المتغيرات؛ ورمز الفاتورة "c" = إلغاء؛ والفترة من 01/12/2009 إلى 09/12/2011.
2. Amazon Web Services. AWS Cloud Adoption Framework, Business Perspective: Data science. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/data-science.html (AWS-DS). يدعم: قيمة العمل قبل المنهج.
3. Kozyrkov, C. Home page. https://www.kozyr.com/ (KOZYR). يدعم: القدوة (اقتباس).
4. D.World AI Project Studio Detailed Lesson Map v1.0 (صف L110)؛ والقرارات من S05 إلى S07 وS19. وثيقة داخلية.