shubham-soni-coder/telso_churm_eda

1. Repository type and scope

This is a single-purpose exploratory data analysis (EDA) repository, not an application or service. The architecture is a notebook-centered data pipeline that loads a telecom churn dataset, cleans it, performs analysis, and produces visual/report artifacts.

2. Primary input boundary

The main input is Telso_churm_data.csv, a flat file containing customer records and churn labels. It is the only explicit data source in the repo, so the entire analysis flow is file-driven rather than database- or API-driven.

3. Execution environment

The core runtime is Python in Jupyter Notebook. The analysis appears to live in main.ipynb, which acts as both the computation layer and the presentation layer for results.

4. Data processing subsystem

The notebook uses Pandas and NumPy for ingesting, inspecting, and transforming the tabular dataset. This layer handles:

- schema inspection and type checking

- missing-value treatment

- duplicate validation

- basic feature transformation

5. Data quality handling

A key preprocessing step is the cleanup of TotalCharges, where blank values are replaced with 0 and the column is converted to numeric. Another transformation maps SeniorCitizen from numeric flags to human-readable labels (Yes/No) to support clearer analysis and plotting.

6. EDA and analytics subsystem

The analytical core is descriptive rather than predictive. The notebook studies churn through segmented views such as:

- overall churn distribution

- customer tenure vs churn

- contract type vs churn

- senior citizen vs non-senior behavior

- service adoption vs churn

7. Visualization layer

Matplotlib and Seaborn provide the charting layer. They turn the cleaned data into count plots, pie charts, histograms, stacked bars, and heatmaps. In architectural terms, this is the presentation boundary that converts tabular analysis into interpretable business visuals.

8. Output artifacts

The repo produces two main outputs:

- the executed notebook itself, which contains the analysis narrative and embedded plots

- analysis_summary.pdf, a static report artifact for sharing results outside the notebook environment

9. Data flow

The end-to-end flow is straightforward:

CSV dataset → notebook ingestion → cleaning/transformation → exploratory segmentation → visual summaries → PDF/notebook outputs.

There is no feedback loop, model training pipeline, or external service integration.

10. System boundaries

The important boundary is between raw customer data and interpreted business insight. The repo stops at insight generation; it does not include production scoring, deployment, dashboards, or persistence layers. That makes the architecture a local analytical workflow rather than an operational churn system.

11. Project structure implications

The repo is intentionally minimal: one dataset, one notebook, one report, and the README. That means the architecture is centralized and easy to diagram as a single notebook-driven analysis stack with one input source and two output artifacts.

12. Business focus

The analysis is centered on retention signals rather than technical complexity. The key domain factors surfaced by the notebook are contract length, tenure, age group, and service bundle adoption, which are the main business dimensions to represent in any architecture diagram.