Final Project in Python

This capstone project pulls together every piece from the TensorFlow course: Conv2D layers for extracting spatial features, Dropout for regularization, callbacks for controlled training, and the Keras save/load API for deployment. None of these techniques matters in isolation — a working production system comes from choosing the right combination for the problem in front of you and stringing them together correctly, from raw data to a served prediction.

The mission is deliberately concrete: classify 128x128 satellite images into one of four terrain types (Forest, Desert, Water, City). That constraint — 2D image input, several mutually exclusive output classes — is what should drive every architectural decision that follows, starting with the very first convolutional layer down to the loss function used to train it.

Treat the rest of this lesson as an interview walkthrough. Each step presents a real production decision — architecture, regularization, training loop, deployment format — and asks you to justify the correct choice, the same way a senior engineer would reason through a proposed model design before writing a single line of code.

The 128x128 satellite image classification task fixes two properties that should drive every downstream decision: the input is a 2D grid (an image with height, width, and channels), and the output is one of four mutually exclusive categories — Forest, Desert, Water, or City.

Because the input is spatial, a Convolutional Neural Network is the correct starting point. Convolutional filters exploit the fact that nearby pixels are correlated, learning edge and texture detectors that a plain Dense network would have to rediscover per-pixel with far more parameters. An LSTM would be the wrong tool here — it's designed for sequential data with a time axis, not a single static image.

Because the four classes are mutually exclusive — a tile is Forest OR Desert OR Water OR City, never a mix — the correct output layer is a Dense layer with 4 units and a softmax activation, trained with categorical_crossentropy loss. Softmax forces the four output probabilities to sum to 1, and categorical_crossentropy is the loss function built to score exactly that kind of one-of-many prediction.

The two wrong answers in this scenario are wrong for specific, testable reasons — not just 'the wrong vibe.' An LSTM ending in a Sigmoid layer with mse loss conflates three separate mismatches: LSTMs model sequences, Sigmoid outputs an independent probability per class (appropriate for multi-label problems, not mutually-exclusive ones), and mse is a regression loss, not a classification loss.

A pure Dense network with binary_crossentropy has its own mismatch: binary_crossentropy is built for two-class or multi-label problems where each output is an independent yes/no decision, not for a single choice among four mutually exclusive classes. Feeding it four classes will still technically run, but the gradients it produces won't push the model toward a correct 4-way decision.

The correct answer satisfies all three constraints at once: a CNN to process the 2D spatial input, a final Dense(4, activation='softmax') layer to produce four probabilities that sum to 1, and categorical_crossentropy to compare that probability distribution against the true one-hot label during training.

A training accuracy of 99% against a validation accuracy stuck at 65% is one of the clearest signals in deep learning: the model isn't learning to recognize forests, deserts, water, and cities — it's memorizing the specific pixels of the training images. Every epoch after the gap opens is spent overfitting harder, not generalizing better.

This gap is diagnostic, not cosmetic. A model that memorizes training examples has effectively built a lookup table rather than learned features, which means anything even slightly different from the training set — different lighting, a slightly different crop, a satellite pass from a different day — will fool it. In production, that 65% validation number is a far better estimate of real-world performance than the misleadingly perfect 99% training number.

The fix has to change the model's capacity to memorize, not just tune a hyperparameter. That's exactly what the next step covers: adding regularization strong enough to force the network to spread its learned representation across many neurons instead of a few that happen to memorize specific training examples.

Of the available options, only one directly attacks the memorization problem: inserting a Dropout layer — commonly at a 50% rate — right before the final Dense layers. During training, Dropout randomly zeroes out a fraction of neuron activations on every forward pass, which prevents any single neuron (or small co-adapted group of neurons) from being solely responsible for recognizing a specific training image.

Switching the optimizer from Adam to SGD doesn't address capacity or memorization at all — it changes how gradients are applied, not what the network is capable of memorizing. Adding ten more Conv2D layers makes the problem strictly worse: more parameters means more capacity to memorize the training set, which is the opposite of what an overfitting model needs.

Dropout is disabled automatically at inference time — Keras handles this through the layer's training argument — so the full network is used for real predictions. The randomness only exists during training, where it acts as a built-in ensemble that forces redundancy into the learned features.

Kicking off a long training run and walking away introduces a new category of risk that has nothing to do with the model's architecture: what happens if the run finishes early, crashes partway through, or — worse — keeps training long after it has stopped improving and quietly overfits itself back into the ground?

A training job with no supervision is a training job with no safety net. If the process dies at epoch 40 of a planned 100, all progress is lost unless it was saved somewhere. If it runs the full 100 epochs unsupervised, there's no guarantee the model saved at the end is the best one — it might be an overfit version from a much later epoch.

The professional answer to 'how do I trust an unattended training run' isn't a manual step performed after the fact — it's configuring the training loop itself, before you walk away, to save its own progress and know when to stop.

The callbacks argument of model.fit() is exactly the mechanism designed for this. Passing a list containing EarlyStopping and ModelCheckpoint(save_best_only=True) solves both problems from the previous step in one line: EarlyStopping monitors a metric — typically validation loss — and halts training once it stops improving for a set number of epochs, while ModelCheckpoint writes the model's weights to disk every time validation performance improves.

Calling model.save() immediately before model.fit() saves the untrained, randomly-initialized model — completely useless. And 'telling TensorBoard to save the model' confuses TensorBoard's job: it logs metrics and visualizations for monitoring, it does not manage checkpoint files.

With save_best_only=True, ModelCheckpoint overwrites the saved file only when the monitored metric improves, so even if training degrades or crashes at epoch 90, the file left on disk is still the best-performing version seen during the run — not the last one.

Training a good model is only half the job. The second half — getting that trained model into a form another team can actually use — is where a lot of otherwise-solid ML work falls apart, because it requires thinking about the model as a deployed artifact instead of a training-time object.

The scenario that follows deliberately switches perspective: instead of you training the model, another team — the Web Team — needs to consume it inside a completely different system, a Flask API, without access to any of the training code or context you had while building it.

That handoff only works if the saved model file is self-contained and if the consuming team knows the exact input shape and preprocessing the model expects, which is exactly what the final integration check verifies.

A successful, unattended training run ending in a satellite_model.keras file is the deliverable that makes deployment possible, because Keras's native save format captures the full model — architecture, trained weights, and optimizer state — all in one portable file. Anyone with TensorFlow installed can load that file and get an identical model back, without needing the original training script.

That portability is exactly what the Web Team is counting on: they don't need to know how the CNN was designed, how Dropout was tuned, or how EarlyStopping decided when to halt. They only need the file and the exact tensor shape the model expects as input.

That last part — the exact input shape — is where most integration bugs come from. A model trained on 128x128x3 images will not silently 'figure out' a differently-shaped image; it will throw a shape-mismatch error, or worse, silently produce a nonsense prediction if the mismatch happens to still be numerically valid.

Getting a prediction out of a saved model is a fixed three-step sequence, and skipping or reordering any step breaks it. First, keras.models.load_model('satellite_model.keras') reconstructs the full trained model from the file. Second — and this is the step beginners most often get wrong — the uploaded image has to be converted into a NumPy array shaped (1, 128, 128, 3): the leading 1 is the batch dimension, because Keras models always expect a batch of inputs, even when predicting on a single image.

Calling model.fit() followed by model.evaluate() is backwards for this scenario — those are training and evaluation calls, not inference, and re-training a model that's already trained and saved defeats the entire point of saving it. Importing pandas and running a predict.csv isn't a real TensorFlow inference path at all.

Once the image is correctly shaped, model.predict(image) runs a single forward pass and returns the four softmax probabilities, from which the Web Team picks the highest-probability class as the final terrain prediction.

Reaching this point means demonstrating the full lifecycle a production deep learning system actually requires: choosing an architecture that matches the data's shape and the problem's label structure, diagnosing overfitting from the train/validation accuracy gap, applying Dropout to fix it, configuring EarlyStopping and ModelCheckpoint so an unattended training run is safe to walk away from, and finally packaging and loading the trained model correctly for a completely separate consuming system.

None of these steps are optional in a real deployment. Skip the architecture reasoning and the model won't fit the data; skip Dropout and it won't generalize; skip the callbacks and a crashed run loses everything; get the inference shape wrong and the Flask API throws errors in production.

This is the difference between knowing how to call model.fit() and being able to own a deep learning system end to end — and it's the bar this capstone project was built to get you over.

You have reached the end. You know how to build Convolutions, LSTMs, and Custom Layers. You know how to fight Overfitting with Dropout.

Your mission: Build an AI that can look at a 128x128 satellite image and classify the terrain (Forest, Desert, Water, City).

Given that the input data consists of 2D images, and there are 4 mutually exclusive categories, what architecture and loss function MUST you choose?

• →A Recurrent Neural Network (LSTM) ending in a Sigmoid layer, using mse loss.
• →A Convolutional Neural Network (CNN) ending in a Softmax Dense layer, using categorical_crossentropy loss.
• →A pure Dense network using binary_crossentropy loss.

You build a Deep CNN. After 10 epochs, the Training Accuracy hits 99%. But the Validation Accuracy stalls at 65%. You have a critical failure.

What is the most aggressive and effective architectural change you can make to stop this CNN from memorizing the satellite images?

• →Change the optimizer from Adam to SGD.
• →Insert a Dropout layer (e.g., at 50%) right before the final Dense layers to force the network to distribute its learned features across all neurons.
• →Add 10 more Conv2D layers.

You fix the overfitting. You want to train it on the massive company cluster over the weekend. You press "Run" and go home.

How do you ensure that when you return on Monday, the server hasn't wasted days computing an overfitted model, and your best progress is physically saved to the hard drive?

• →Run model.save() immediately before model.fit().
• →Pass a list containing EarlyStopping (to halt training) and ModelCheckpoint(save_best_only=True) to the callbacks argument of model.fit().
• →Tell TensorBoard to save the model.

Now, prepare yourself. We are about to enter the FINAL ADA Defense Protocol. Ensure you understand end-to-end integration.

You arrive on Monday. The training was a success. You have a file named satellite_model.keras. The Web Team needs to use it in their Python Flask API.

ADA DEFENSE: The Web Team has imported TensorFlow. They have the user's uploaded image. What is the EXACT sequence of commands they must run to get a prediction out of your file?

• →First, model.fit(). Then, model.evaluate().
• →First, model = keras.models.load_model('satellite_model.keras'). Then, ensure the image is a Numpy array shaped (1, 128, 128, 3). Finally, run model.predict(image).
• →First, import pandas. Then run predict.csv.

Threat neutralized. System architecture verified. You have officially mastered TensorFlow.

Choose a Real Architecture and Loss. Finish choose_architecture(): 2D image data calls for a CNN; more than 2 classes calls for categorical_crossentropy.