PROJECT 01

End-to-End AI System Development

Project Overview

This case study focuses on my approach to systems architecture and technical program management: translating requirements into workstreams, defining interfaces and restructuring development dependencies to protect a milestone.

Capabilities Demonstrated

[1]

Translating system requirements into workstreams with defined responsibilities and deliverables.

[2]

Restructuring development to enable parallel work and resolve blocking schedule dependencies.

[3]

Using simulation and subsystem testing to verify functionality before full-system integration.

[4]

Defining system architecture through component boundaries, data flows and technical interfaces.

PROJECT CONTEXT

System Purpose

Auryc is an applied AI system used to forecast raw materials prices with two targeted use cases:

Auryc is an applied AI system used to forecast raw materials prices with two targeted use cases:

Materials Procurement and Manufacturing Planning

By integrating price forecasts into existing procurement workflows, teams are better able to evaluate when to purchase materials, how much inventory to source and how price changes could affect project costs. The system is most useful for long-lead procurement where purchasing decisions are made months before materials are needed.

Consulting and Financial Analysis

By forecasting commodity market price fluctuations, the system allows commercial clients whose revenue depends on raw-material prices to understand their exposure to changing materials costs and adjust their business strategy accordingly.

By forecasting commodity market price fluctuations, the system allows commercial clients whose revenue depends on raw-material prices to understand their exposure to changing materials costs and adjust their business strategy accordingly.

How It Works

The system works by identifying basic market components, and grouping certain relationships into “reaction fingerprints,” i.e. recurring patterns in how prices fluctuate over time. Then, a combination of statistical analysis, deterministic analysis and machine learning inference evaluates these reactions in context to generate and combine signals. Finally, the outputted signals inform likely direction and potential extent of price movements within certain confidence boundaries.

Personal Scope

I co-founded the company, hired a small team and raised seed funding for the development phase between June 2025 and December 2025. During development, I led end-to-end program management including concept of operations, requirements definition, system architecture, workstream decomposition, testing and milestones across the project’s R&D phase spanning January 2026 to September 2026.

PART I

System Architecture & Workstream Definition

This section explains how I organized system development into workstreams with defined responsibilities, deliverables and interfaces.

This section explains how I organized system development into workstreams with defined responsibilities, deliverables and interfaces.

1.1 Defining Workstreams and Interfaces

Developing Auryc required coordinated work across signal research, data infrastructure, feature engineering, model development and system integration. After collaborating on system requirements, I independently developed a work breakdown structure that organized development into eight workstreams with distinct responsibilities and deliverables. I defined the interfaces between system components by identifying the inputs each required and the outputs it supplied to other parts of the system. This structure clarified the scope of each workstream and the handoffs needed to coordinate development and testing.

1.1 Defining Workstreams and Interfaces

Developing Auryc required coordinated work across signal research, data infrastructure, feature engineering, model development and system integration. After collaborating on system requirements, I independently developed a work breakdown structure that organized development into eight workstreams with distinct responsibilities and deliverables. I defined the interfaces between system components by identifying the inputs each required and the outputs it supplied to other parts of the system. This structure clarified the scope of each workstream and the handoffs needed to coordinate development and testing.

Table 1.1: Workstream Responsibilities and Deliverables

Ownership & Collaboration

Colors indicate my ownership and collaboration within each workstream.

Owned by me

Led by me with business direct report

Collaborated with ML engineer

Owned by ML engineer

ID

Workstream

Responsibility

Principal deliverables

WS1

Program Management & Stakeholder Coordination

Coordinate priorities, milestones and communication across the program.

Work breakdown structure, milestone tracking and stakeholder reports

WS2

Systems Architecture & Requirements

Define system functions, component boundaries and interface requirements.

System architecture, interface definitions and implementation specifications

WS3

Signal Research & Rule Development

Translate candidate market behaviors into defined signals and decision rules.

Signal definitions, trigger conditions and decision rules

WS4

Data & Streaming Infrastructure

Supply live and historical market data for development and operation.

Streaming pipeline, historical-data access and latency improvements

WS5

Feature Engineering & Training Data

Convert market observations and research definitions into model-ready inputs.

Structured features, labeled examples and training datasets

WS6

ML Development & Integration

Develop models and connect their outputs to the decision system.

Trained models and inference integration

WS7

Execution Integration & Risk Controls

Connect decision outputs to execution with defined risk controls.

Execution specifications, brokerage integration and execution telemetry

WS8

Verification, Validation & Performance Analysis

Evaluate subsystem behavior, integrated operation and performance.

Acceptance tests, integration test results and performance analysis

ID

Workstream

Responsibility

Principal deliverables

WS1

Program Management & Stakeholder Coordination

Coordinate priorities, milestones and communication across the program.

Work breakdown structure, milestone tracking and stakeholder reports

WS2

Systems Architecture & Requirements

Define system functions, component boundaries and interface requirements.

System architecture, interface definitions and implementation specifications

WS3

Signal Research & Rule Development

Translate candidate market behaviors into defined signals and decision rules.

Signal definitions, trigger conditions and decision rules

WS4

Data & Streaming Infrastructure

Supply live and historical market data for development and operation.

Streaming pipeline, historical-data access and latency improvements

WS5

Feature Engineering & Training Data

Convert market observations and research definitions into model-ready inputs.

Structured features, labeled examples and training datasets

WS6

ML Development & Integration

Develop models and connect their outputs to the decision system.

Trained models and inference integration

WS7

Execution Integration & Risk Controls

Connect decision outputs to execution with defined risk controls.

Execution specifications, brokerage integration and execution telemetry

WS8

Verification, Validation & Performance Analysis

Evaluate subsystem behavior, integrated operation and performance.

Acceptance tests, integration test results and performance analysis

Scroll horizontally to view the full table.

1.2 System Architecture

DIAGRAM KEY

Workstream component

External source or platform

System boundary

Information exchanged

Auryc system diagram mapping technical workstreams to components and information handoffs, including model training and operational paths.

Figure 1.1: System Architecture and Workstream Interfaces

  • The diagram above maps the technical workstreams to the system’s functional components, with workstream IDs linking each component to the table above.

  • I defined the interfaces around the information passed between components, including feature definitions, training examples, trained models and structured features.

  • The arrows show these handoffs and distinguish the model-training path from the operational path, where structured features feed the decision engine alongside the trained model and defined rules.

  • Program management (WS1), systems architecture (WS2) and verification and validation (WS8) span the system and are therefore not shown as individual processing components.

PART II

Program Management Case Study

This section highlights one decision from the broader program to illustrate my approach to dependency management and development planning within program management workflows.

Restructuring Dependencies to Protect a Milestone

2.1 Surfacing a Dependency Problem

The original development schedule included some float to absorb delays while meeting the proof-of-concept milestone. Delays in high-speed processing development were consuming that float and leaving insufficient time for downstream testing. Testing of the decision-making layer depended on high-speed processing readiness, so further delays would push that work back and threaten the milestone. The development sequence was workable, but the remaining schedule required an approach that allowed both efforts to progress in parallel.

Dependency visualization

2.2 Resolving the Dependency Chain

I reviewed which aspects of decision-layer testing required high-speed processing and which could proceed using historical and delayed live data. I introduced software-in-the-loop (SIL) simulation to test the decision-making layer while high-speed processing development continued. This removed high-speed processing readiness as a prerequisite for that testing and allowed the two efforts to converge later for full-system integration.

The side-by-side diagram shows how this change replaced the original sequential dependency with parallel development paths.

Original Dev Sequence

Original sequential development flowchart before SIL testing.
Original sequential development flowchart before SIL testing.

Sequential development

Revised Dev Sequence

Revised development sequence with parallel SIL testing and shared integration.
Revised development sequence with parallel SIL testing and shared integration.

Parallel development with shared integration

Figure 2.1: Development Dependencies Before and After SIL

Both sequences begin with an initial decision framework available for testing, combining signal and rule development (WS3) with ML development and integration (WS6). The comparison shows how SIL allowed decision-layer testing under WS8 to proceed alongside high-speed processing development (WS6). Both sequences retain full-system integration and testing (WS8) as the final milestone.

2.3 Implementing SIL Approach

The SIL approach supplied historical and delayed live data to exercise the decision-making layer before the high-speed infrastructure was ready. I used subsystem-specific acceptance tests in Python to evaluate decision accuracy while the infrastructure work continued against its latency requirements. This allowed the decision-making layer to be tested and refined ahead of full-system integration. Full-system integration testing remained necessary to evaluate the combined system’s behavior and performance under live operating conditions.

2.4 Outcome

Using SIL simulation allowed decision-layer testing to progress while the real-time infrastructure was still in development. This preserved time for refinement before full-system integration and helped keep the proof-of-concept milestone achievable. The completed system was subsequently validated through live operational testing and delivered to stakeholders.