ALI BOYACI

Context

A high-throughput loading facility ran entirely on manual, paper-based operations with no digital traceability. I designed and shipped a real-time control system covering 60+ tanks and 20+ filling lines — owning architecture, implementation, deployment, and on-site telemetry as the sole software engineer on a two-person team over an 8-month deployment.

Constraints

• Strict on-prem infrastructure — no external cloud access.
• Implementation during active 24/7 operations, with zero tolerance for downtime.
• High data density from field devices with hard real-time latency requirements.

What I Built

• Modbus + MQTT data pipeline ingesting live device telemetry into a Node.js backend.
• React control and operator UI for filling lines, built for rugged daily field use.
• Real-time early-warning telemetry that alerts field engineers before unsafe conditions.
• On-prem deployment automation, runbooks, and incident response for a restricted environment.

Result

• Processed 6,000+ real-time operations in the first 4 months with full digital traceability and reporting.
• Prevented an estimated 40–50 incidents and detected 3–4 equipment failures per month before they caused disruption.
• Replaced a fully manual workflow with a stable, auditable digital control system.

Next

• Add predictive maintenance using accumulated telemetry data.
• Expand failover drills and automated load testing.

Context

Most schema validation tools focus on a single data layer — SQL linters check migration syntax, API linters check OpenAPI specs. Real drift happens across layers: a renamed Postgres column can break a downstream CSV export or a partner API consumer. DriftGuard was built to catch these cross-source breaking changes in one unified pipeline.

Constraints

• Must normalize schemas from 7+ heterogeneous sources (databases, APIs, files) into a single comparison model.
• Policy enforcement must be configurable per-team: 5 modes (strict, lenient, default, backward-compatible, forward-compatible).
• Must integrate as a CI gate with non-zero exit codes on policy violations.

What I Built

• Collector architecture with 7 adapters behind a common interface (SQLAlchemy 2.x for databases, pyarrow for files, HTTP clients for APIs).
• Semantic diff engine: type widening taxonomy, constraint-level diffing (PK, FK, unique, numeric ranges), and fuzzy field rename detection via SequenceMatcher.
• Policy engine with 5 enforcement modes and per-resource severity overrides.
• Multi-format reporters: Terminal (Rich), JSON, Markdown, HTML.
• Full test suite: 576 tests, 89% line coverage, ruff + mypy static analysis, and a GitHub Actions CI matrix.

Result

• Published v1.0.1 on GitHub with an architecture guide, CLI reference, adapter guide, and policy rules.
• CI pipeline validated across Python 3.11, 3.12, and 3.13 via GitHub Actions.
• Extensible architecture: new collectors and policy modes plug in without changes to the core diff engine.

Next

• Add collectors for Avro, Protobuf, and Kafka Schema Registry.
• Implement SARIF and JUnit XML reporters for CI/CD integration.

Context

I built a multi-tenant product that uses AI models to interpret travel operations data and return structured results to users.

Constraints

• Each tenant’s data and operations had to stay isolated.
• The model could only run approved backend actions with validated parameters.
• The application had to run end to end on AWS.

What I Built

• A .NET backend with multi-tenant data and service boundaries.
• A React interface for operations teams.
• An integration layer that exposed backend API operations as Groq-powered tool calls.
• AWS deployment and runtime configuration for the full application.

Result

• Built a flow where the AI model can safely run approved application actions.
• Combined backend, frontend, AI integration, and AWS deployment in one product architecture.

Next

• Expand the evaluation set for tool calls.
• Improve model observability and cost tracking.

Context

I built a small Python engine so I could understand, change, and test each part of a RAG system separately.

Constraints

• The library had to stay dependency-light.
• Retrieval steps had to be model-independent and separately testable.
• The test suite had to work without an internet connection.

What I Built

• A document chunking and embedding pipeline.
• NumPy vector storage with BM25 / RRF hybrid retrieval.
• LLM re-ranking, citations, and faithfulness evaluation.
• An offline test suite and CI across multiple Python versions.

Result

• Each part of the RAG pipeline can be changed and tested separately.
• Published the project as open source on GitHub.

Next

• Add adapters for more vector stores.
• Expand the evaluation datasets.