CIS 6930 Spring 26

Logo

Data Engineering at the University of Florida

Code Checkpoint

Due: Monday, March 23, 2026 at 11:59 PM Points: 150 Submission: Push to cis6930sp26-project repository with tag checkpoint

Overview

The code checkpoint evaluates your working implementation. By this milestone, your pipeline should be functional end-to-end with initial results. This is not a prototype—the core functionality should work reliably.

Deliverables

  1. Working Code - Functional MCP servers and LLM orchestration
  2. Tests - Unit and integration tests for core functionality
  3. Documentation - README with setup and usage instructions
  4. Initial Results - Preliminary evaluation on your dataset
  5. Progress Report - Brief document (1-2 pages) summarizing status

File Structure

cis6930sp26-project/
├── README.md              # Setup and usage instructions
├── src/
│   ├── servers/           # MCP server implementations
│   │   └── *.py
│   └── pipeline/          # Orchestration code
│       └── *.py
├── tests/
│   ├── test_servers.py
│   └── test_pipeline.py
├── data/
│   └── .gitkeep
├── results/
│   └── preliminary_results.md
├── docs/
│   └── progress_report.md
└── pyproject.toml

Tagging Your Submission

git tag -a checkpoint -m "Code checkpoint submission"
git push origin checkpoint

Rubric

Criterion Weight Description
Functionality 30% Does the implementation work as intended?
Code Quality 25% Is the code well-written and maintainable?
Testing 20% Is the code adequately tested?
Reproducibility 15% Can others run and reproduce the results?
Documentation 10% Is the code and repository well-documented?

Scoring Scale

Score Meaning
5 Excellent - Production-quality code
4 Good - Minor improvements needed
3 Satisfactory - Functional but needs polish
2 Needs Work - Significant issues
1 Incomplete - Major problems

Detailed Criteria

Functionality (30%)

Score Description
5 All features work; handles edge cases; robust error handling
4 Core features work well; minor edge case issues
3 Main functionality works; some features incomplete
2 Partial functionality; significant bugs
1 Does not run or fundamentally broken

Guiding Questions:

Code Quality (25%)

Score Description
5 Clean, idiomatic code; excellent organization; follows best practices
4 Good code quality; consistent style; well-organized
3 Readable but some issues; inconsistent in places
2 Hard to follow; poor organization; code smells
1 Unmaintainable; no structure

Guiding Questions:

Testing (20%)

Score Description
5 Comprehensive test suite; high coverage; tests edge cases
4 Good test coverage; tests main functionality
3 Basic tests present; some gaps
2 Minimal testing; major functionality untested
1 No tests or tests don’t work

Guiding Questions:

Reproducibility (15%)

Score Description
5 One-command setup; clear instructions; reproducible results
4 Easy to set up; minor clarifications needed
3 Can be reproduced with some effort
2 Difficult to reproduce; missing dependencies or instructions
1 Cannot reproduce

Guiding Questions:

Documentation (10%)

Score Description
5 Excellent README; API docs; inline comments where needed
4 Good documentation; covers setup and usage
3 Adequate documentation; some gaps
2 Minimal documentation
1 No documentation

Example Code Organization

MCP Server Example

# src/servers/transit_server.py
"""MCP Server for Gainesville Transit Data."""

from fastmcp import FastMCP
from loguru import logger

mcp = FastMCP("transit-server")


@mcp.tool()
def get_routes() -> list[dict]:
    """Fetch all active bus routes.

    Returns:
        List of route dictionaries with id, name, and stops.
    """
    logger.info("Fetching transit routes")
    # Implementation here
    return routes


@mcp.tool()
def get_ridership(route_id: str, start_date: str, end_date: str) -> dict:
    """Get ridership statistics for a route.

    Args:
        route_id: The route identifier
        start_date: Start date in YYYY-MM-DD format
        end_date: End date in YYYY-MM-DD format

    Returns:
        Dictionary with daily ridership counts and statistics.
    """
    logger.info(f"Fetching ridership for route {route_id}")
    # Implementation here
    return stats


if __name__ == "__main__":
    mcp.run()

Pipeline Orchestration Example

# src/pipeline/orchestrator.py
"""LLM orchestration for data pipeline."""

from anthropic import Anthropic
from loguru import logger


class PipelineOrchestrator:
    """Coordinates MCP servers using LLM reasoning."""

    def __init__(self, model: str = "claude-sonnet-4-20250514"):
        self.client = Anthropic()
        self.model = model

    def extract_and_validate(self, source: str) -> dict:
        """Extract data from source and validate quality.

        Args:
            source: Name of the data source to process

        Returns:
            Extraction results with validation report.
        """
        logger.info(f"Processing source: {source}")
        # LLM orchestration logic here
        return results

Test Example

# tests/test_servers.py
"""Tests for MCP servers."""

import pytest
from src.servers.transit_server import get_routes, get_ridership


class TestTransitServer:
    """Tests for transit MCP server."""

    def test_get_routes_returns_list(self):
        """Routes should return a non-empty list."""
        routes = get_routes()
        assert isinstance(routes, list)
        assert len(routes) > 0

    def test_get_routes_has_required_fields(self):
        """Each route should have id, name, and stops."""
        routes = get_routes()
        for route in routes:
            assert "id" in route
            assert "name" in route
            assert "stops" in route

    def test_get_ridership_invalid_route(self):
        """Invalid route should raise ValueError."""
        with pytest.raises(ValueError):
            get_ridership("invalid-route", "2026-01-01", "2026-01-31")

Initial Results Format

Your results/preliminary_results.md should include:

# Preliminary Results

## Dataset Summary

| Metric | Value |
|--------|-------|
| Records processed | X,XXX |
| Data sources | N |
| Date range | YYYY-MM-DD to YYYY-MM-DD |

## Extraction Results

| Source | Records | Fields | Completeness |
|--------|---------|--------|--------------|
| Transit | X,XXX | XX | XX% |
| Utilities | X,XXX | XX | XX% |

## Quality Metrics

| Metric | Baseline | LLM Pipeline |
|--------|----------|--------------|
| Precision | X.XX | X.XX |
| Recall | X.XX | X.XX |
| F1 | X.XX | X.XX |

## Observations

- Key finding 1
- Key finding 2
- Current limitations

## Next Steps

- [ ] Task 1
- [ ] Task 2

Review Checklist

Reviewers will verify:

Functionality

Code Quality

Testing

Reproducibility

Documentation

Common Issues to Avoid

  1. Hardcoded paths - Use relative paths or configuration files
  2. Missing dependencies - Run uv pip compile to capture all requirements
  3. API keys in code - Use environment variables
  4. No error handling - Add try/except for external API calls
  5. Monolithic functions - Break large functions into smaller pieces
  6. No logging - Use loguru for debugging and monitoring

Submission Checklist

Resources

back