# Chapter 3 Reference Solution: Open-Source Ecosystem Mini-Capstone

This reference solution shows one acceptable outcome for the Chapter 3 lab. It is not the only correct answer. A stronger student submission may choose a different tool if the evidence, trade-offs, and review conditions are clear.

## 1. Weighted Matrix Interpretation

Using the starter matrix, the weighted scores are:

| Candidate | Weighted score | Interpretation |
|---|---:|---|
| Airflow | 4.35 | Strong first choice when provider breadth, maturity, hiring familiarity, and classical DAG orchestration matter. |
| Dagster | 4.00 | Strong alternative when asset-centric modeling, local developer experience, and typed software-defined assets are prioritized. |
| Prefect | 4.00 | Strong alternative when Python-native flows, ease of experimentation, and lightweight operations are prioritized. |

The result does not mean Airflow is universally better. It means that for TuranMart’s first production-oriented learning platform, **Airflow fits the stated assumptions slightly better**. If the team values asset lineage and developer experience more heavily, the weights may move Dagster ahead. If the team wants a simpler Python-first operational model, Prefect may become the best first choice.

## 2. Recommended Decision

TuranMart should use **Apache Airflow** as the initial orchestration layer for the learning platform. The decision is justified by Airflow’s mature scheduling model, broad provider ecosystem, documented production patterns, and direct relevance to Chapter 11.

| Decision factor | Evidence-based reasoning |
|---|---|
| Functional fit | The first TuranMart pipelines are scheduled batch jobs with dependencies, retries, and clear task boundaries. |
| Operational maturity | Airflow has a long production history and many published deployment patterns. |
| Integration ecosystem | Providers cover databases, cloud storage, Spark, dbt, Kubernetes, notifications, and many APIs. |
| Learning path | Classical DAG orchestration helps readers understand dependencies before exploring newer asset-centric systems. |
| Reversibility | The decision is revisited after Chapter 11 and after the first realistic incident review. |

## 3. Completed ADR Guidance

A complete ADR should contain context, decision, alternatives, consequences, evidence required before production, and a review date. The most important quality is not length; it is **memory**. A future team member should understand why the decision was reasonable at the time and which assumptions could invalidate it.

A strong ADR includes at least one reversal condition. For this lab, good reversal conditions include the following: TuranMart standardizes on Kubernetes-native execution, team members struggle to test Airflow DAGs locally, asset lineage becomes the dominant modeling requirement, or Airflow provider dependencies create unacceptable maintenance overhead.

## 4. Template Review

The project template is acceptable if it separates raw data, curated data, notebooks, pipelines, transformations, quality rules, documentation, runbooks, tests, and configuration. It should not hard-code a single vendor or service too early. The purpose of Chapter 3 is to create a stable skeleton that later chapters can fill with PostgreSQL schemas, object storage layouts, DuckDB and Spark jobs, Kafka/Flink streams, dbt-style transformations, Airflow DAGs, and observability checks.

## 5. Common Grading Notes

| Submission issue | Feedback |
|---|---|
| Scores are not supported by evidence | Require documentation links, release notes, a proof of concept, or a short benchmark note. |
| Matrix weights do not sum to 1.0 | Ask the student to normalize weights before interpreting scores. |
| ADR chooses a tool but ignores alternatives | Require at least two alternatives and clear consequences. |
| Template contains too many tools | Remind the student that a good platform is the minimum coherent set, not a tool collection. |
| No review trigger is defined | Ask for a date, chapter milestone, incident review, or scale threshold that forces reevaluation. |

## 6. Expected Validation Output

Running the validation script from the repository root should produce output similar to:

```text
Weighted scores
---------------
airflow: 4.35
dagster: 4.00
prefect: 4.00

Validation passed: matrix shape, criteria, and weights are valid.
```