genterist/bkt-jupyter

1. Project purpose

- This repository is a small, notebook-driven demonstration of Bayesian Knowledge Tracing (BKT).

- It is oriented around running experiments on student response data and exporting per-student results.

2. Primary execution model

- The core workflow lives in Jupyter/Colab notebooks: BKT_Implementation.ipynb is the main runnable artifact.

- AboutColaboratory.ipynb appears to be a supporting notebook or onboarding/example file for Google Colab usage.

- bkt_implementation.py is likely a code extraction or reusable Python implementation backing the notebook.

3. Main computational subsystem

- The central subsystem is the BKT inference/estimation logic.

- From the filenames, the implementation likely models student learning states over time using the standard BKT parameters: probability of initial knowledge, learning, slipping, and guessing.

- This logic is probably executed sequentially per student and per observation sequence.

4. Input data boundary

- data.csv is the shared dataset input, likely containing the raw student interaction records used by the notebook.

- Additional files such as stu1.csv, stu10.csv, stu101.csv, and stu1_double_P_T.csv, stu1_double_S_G.csv suggest student-specific datasets or parameter sweep inputs used for experiments.

5. Per-student processing flow

- The architecture appears to be:

- load student interaction data,

- run BKT updates over the sequence,

- produce a derived result file for each student.

- The presence of many exportedResults/stu*.csv files indicates the output is partitioned by student identifier rather than aggregated into a single report.

6. Output / reporting subsystem

- exportedResults/ is the main results boundary.

- Each generated CSV likely contains predicted mastery states, posterior probabilities, or other trace outputs for an individual student.

- BKT-Report.pdf is a static deliverable summarizing the work, likely generated from the notebook content.

7. Session/runtime assumptions

- The README is explicitly centered on Google Colab as the runtime environment.

- Data files are uploaded into an ephemeral session store, so the workflow assumes a notebook runtime with manual file upload and transient local storage.

8. Data persistence characteristics

- Inputs are treated as session-local in Colab, not as a durable backend service.

- Outputs are also session-local unless manually downloaded, which means the repository functions more like a reproducible analysis bundle than a deployed application.

9. Tooling and dependencies

- The repo is built around Python + Jupyter notebooks, with Colab as the execution host.

- There is no sign of a separate package manager, API server, database, or frontend application.

- The architecture is therefore computational and file-based, not service-oriented.

10. Repository structure meaning

- The root contains the main code and data artifacts together, reflecting a compact research/demo project.

- The large number of CSV outputs suggests the notebook was used to run experiments across many students and store each result independently.

11. Likely diagram boundaries

- A useful architecture diagram would show:

- notebook/runtime environment,

- input CSV datasets,

- BKT computation layer,

- per-student exported CSV results,

- optional report/documentation outputs.

- The key boundary is between the Colab notebook session and the file-based inputs/outputs.

12. Overall architecture summary

- This repository is a single-workflow analytical pipeline: notebook-driven BKT computation over CSV data, producing per-student CSV outputs and a report.

- It is not a multi-service system; the important architecture is the flow of data through an interactive Python notebook into generated result files.