Rows of code-coloured bars on a dark ground, like lines in an editor

Week 7: Code, Quality & Collaboration

Data Science Quick Start for Six Sigma

GitHub, Pull Requests, Version Control & AI Agents

Tim Fraser, PhD

Assistant Teaching Professor, Systems Engineering
Cornell University

SYSEN 5300: Systems Engineering & Six Sigma

for Design and Operation of Reliable Systems

Why Version Control?
- Traceability and auditability in Six Sigma
- One reproducible source of truth for your team
The Core Git Cycle
- Clone, pull, add, commit, push: the 5 essential moves
- Know what to commit and what to exclude
Pull Requests as Quality Gates
- Inspect code and models before merging
- Prevent defects in statistical pipelines
AI Agents in the Loop
- How agents branch, test, and propose pull requests
Hackathon Full-Stack Architecture
- Connect REST APIs (Plumber/FastAPI) to databases and GUIs
- Verify the statistical actions inside your endpoints

Today's quick start

Why GitHub for Six Sigma?
Your Toolkit: Terminal & IDE
The Core Git Cycle
Pull Requests: The Quality Gate
How AI Agents Use PRs
Hackathon Stack: APIs, DB & GUI

01 Why GitHub?

02 The Core Git Loop

03 Pull Requests & Quality

04 AI Agents & Hackathon Stack

Why GitHub in Six Sigma?

01 No Chaos

Stop emailing analysis_v3_final_FINAL.R.

One shared, versioned repository is the single source of truth for your whole team.

02 Traceability

Six Sigma and ISO quality standards demand audit trails.

Every commit records exactly who changed a model, what changed, and why.

03 Defect Control

Isolate experiments on branches.

Never let experimental scripts or broken formulas corrupt your team's production analysis.

Workspace: IDE and the Terminal

Graphical Interface

Your IDE

Posit Cloud / RStudio: ready to code in your browser with zero install
Positron / VS Code / Cursor: modern desktop editors with full Git support
Combines script editor, console, variable explorer, and plot viewer in one window

Command Line

The Terminal

Git Bash (Windows) or Terminal (Mac/Linux)
Available right inside RStudio, Positron, and VS Code via the Terminal tab
Executes Git commands and system tools behind the scenes

Terminal Navigation and Package Setup

# Terminal: navigate to your project folder
pwd                    # print working directory
ls                     # list files
cd team-reliability    # enter project folder

# R Console: load required packages
library(dplyr)
library(ggplot2)

# Terminal: navigate to your project folder
pwd                    # print working directory
ls                     # list files
cd team-reliability    # enter project folder

# Python: import required libraries
import pandas as pd
from plotnine import *

Always check pwd first so your relative paths resolve correctly.

Posit Cloud workspace comes pre-configured with course packages.

What is Git vs. GitHub?

On Your Machine

Git (Local Engine)

A version-control system running locally on your computer
Takes point-in-time snapshots called commits
Keeps full offline history of your edits
Allows you to revert mistakes safely

In the Cloud

GitHub (Remote Hub)

A cloud service hosting your Git repositories
The collaboration center for teammates and instructors
Hosts Pull Requests, code reviews, and automated tests
Serves as your professional data science portfolio

The Core Git Cycle: The 4-Stage Mental Model

You do not need to memorize 50 Git commands.
95% of engineering work is this single cycle:
git pull gets the latest updates
git add stages your modified files
git commit seals the snapshot with a message
git push shares it with the team

Everyday Git Cheat Sheet: The 5 Commands

# Terminal (or RStudio Git Pane buttons)
git clone <repo-url>     # 1. download project once
git pull                 # 2. get teammates' latest edits
git status               # 3. see modified scripts
git add .                # 4. stage modified files
git commit -m "add xbar" #    save snapshot with message
git push                 # 5. upload commits to GitHub

# Terminal (or VS Code / Positron Source Control)
git clone <repo-url>     # 1. download project once
git pull                 # 2. get teammates' latest edits
git status               # 3. see modified scripts
git add .                # 4. stage modified files
git commit -m "add xbar" #    save snapshot with message
git push                 # 5. upload commits to GitHub

Always pull before you start! Pulling first avoids merge conflicts.

Commit early and often with clear, descriptive messages.

What to Commit vs. What to Keep Out

Always Track

Commit to GitHub

Scripts: .R, .py, .qmd, .Rmd
Documentation: README.md and reports
Small datasets: CSV files under 50 MB
Figures & charts: generated plots and diagrams

Never Track (.gitignore)

Keep Off GitHub

Credentials: API keys, tokens, .env files
Personal data: student IDs or confidential rosters
Huge datasets: files over 50 MB (host externally)
Session clutter: .Rhistory, .RData, __pycache__/

What is a Pull Request (PR)?

In professional engineering, you never push directly to main.
You create a feature branch, make your edits, and open a Pull Request.
A PR is a request asking: "Please review these changes and merge them into the main project."
It provides an open discussion forum for teammates to inspect code before it goes live.

Anatomy of a Pull Request

01 The Diff

Green for added lines, red for deleted lines. Full transparent visibility into every change.

02 Description

Explains the context: what problem was solved, what methods were applied, and evidence of results.

03 CI Checks

Automated test scripts verify that the code runs, lints pass, and models converge before merging.

04 Peer Review

Teammates comment on specific lines, suggest improvements, and give formal approval.

Why Pull Requests Matter in Six Sigma

In Six Sigma, catching defects early costs 10x to 100x less than fixing them downstream.

Peer Review Prevents Silent Errors: A typo in an index formula or wrong degrees of freedom breaks entire reliability estimates.
The Inspection Gate: A PR is the quality inspection station between raw exploratory code and validated models.
Shared Accountability: Nobody works in an unverified silo; the team reviews and stands behind every script.

How AI Agents Use Pull Requests

The Risk

Unchecked AI Commits

Letting an AI write directly to main is hazardous
Models can hallucinate parameters or break existing tests
Silent failures undermine confidence in statistical data

The Best Practice

Agent Pull Requests

Modern coding agents (Cursor, Claude Code) create their own branch
The agent writes code, runs unit tests, and captures proof
It opens a draft Pull Request with its diff and evidence
You (the human engineer) review and merge

The Agent Collaboration Workflow

The Golden Rule: The Human in the Loop

Code that runs is not necessarily code that is right.
An agent may choose the wrong test, assume normality when data is skewed, or omit degrees of freedom.
Your Responsibilities as the Engineer:
- Read the PR diff line by line before accepting it.
- Verify statistical assumptions against textbook principles.
- Run the analysis yourself to confirm results make sense.

You hold the engineering sign-off authority. Never outsource judgment to an algorithm.

Giving AI the Right Context

Vague Prompt (Poor Output)

"Write code to make an X-bar control chart."

Guesses column names and dummy data
Imports external libraries you don't use
Ignores Cornell SYSEN house coding style

Context-Rich Prompt (Accurate Output)

"Using @workshops/onsen.csv, calculate X-bar and R limits with @functions/functions_process_control.R."

Sees exact variable names and types
Reuses existing course helper functions
Matches textbook formulas exactly

Project Rules: Standing Context

# AGENTS.md or .cursor/rules in your repository
---
description: "Course coding style for SYSEN 5300"
globs: "*.R"
---
- Use = for assignment, not <-
- Use %>% tidyverse pipes
- Source functions/ rather than installing packages
- Never commit credentials or answer keys

# AGENTS.md or .cursor/rules in your repository
---
description: "Course coding style for SYSEN 5300"
globs: "*.py"
---
- Use pandas and plotnine
- Follow PEP 8 style standards
- Source functions/ rather than installing packages
- Never commit credentials or answer keys

Standing Instructions: Saved in AGENTS.md or .cursor/rules
Loaded automatically on every session
Ensures teammates and AI assistants follow identical style

Hackathon Preview: Connecting GUI → REST API → Database

In the upcoming Six Sigma Hackathon, you will build an interactive statistical tool.
You'll connect a Front End / GUI to a REST API backed by a Database.
You will likely use AI coding agents to build the GUI and wire connections.
Your core job: You must understand what your API does—the exact statistical action and formula inside each endpoint!

The Backend Engines: Plumber & FastAPI

R Language

Plumber

Turns ordinary R scripts into REST APIs using comment annotations (#* @get, #* @post).
Calls your native R functions directly: runs lm(), t.test(), ANOVA, or control charts.
Returns calculated Cpk indices, p-values, or chart data serialized as standard JSON.

Python Language

FastAPI

High-performance, modern Python web framework based on standard type hints.
Exposes endpoints (@app.post("/anova")) executing scipy.stats or statsmodels.
Automatically generates interactive documentation (Swagger UI) for testing your endpoints.

Data & Interaction: Database and GUI

Data Store

Database

Stores raw inspection lots, run charts, and experimental observations safely.
Provides structured relational tables (SQL) or cloud databases (PostgreSQL, SQLite, Supabase).
Ensures models always query persistent data rather than hardcoded scratchpad files.

User Interface

Front End / GUI

Can be written in anything: simple HTML/JS, Streamlit, Shiny, Gradio, or React.
Lets an operator enter factor levels, upload sample batches, and click to view control charts.
AI can build this! Give the AI your API spec and ask it to craft a clean GUI.

What Does Your Endpoint Do Statistically?

AI can write boilerplate, but you are responsible for the statistical veracity of calculations.

Every endpoint performs a concrete statistical action: /capability, /two-sample-t, /anova.
What inputs are accepted? What degrees of freedom apply? What assumptions are checked?
Never deploy a black-box—inspect the math!

#* Compute process capability Cpk
#* @post /cpk
function(usl, lsl, data) {
  x = as.numeric(data)
  m = mean(x); s = sd(x)
  cpk = min((usl - m)/(3*s), (m - lsl)/(3*s))
  list(mean = m, sd = s, cpk = round(cpk, 3))
}

# Compute process capability Cpk
@app.post("/cpk")
def compute_cpk(spec: SpecPayload):
    arr = np.array(spec.data)
    m, s = np.mean(arr), np.std(arr, ddof=1)
    cpk = min((spec.usl - m)/(3*s), (m - spec.lsl)/(3*s))
    return {"mean": m, "sd": s, "cpk": round(cpk, 3)}

Activity: Your First Repository & Pull Request

1 Sign up on GitHub and clone your team repo

2 Create a feature branch: git checkout -b setup-team

3 Add your names to README.md, commit, and push

4 Open a Pull Request on GitHub and have a teammate merge it

Detailed guide: chapter Using GitHub and AI.

Build Reliable Systems with Version Control & AI

Data Science Quick Start for Six Sigma · SYSEN 5300