Author: Kilalon
\nCompetition: AI for Agriculture 2025
\nModel Type: 3D CNN (Custom Lightweight Architecture)
\nFinal Score: ~841.2 (Public Leaderboard) | ~822.3 (Private Leaderboard)
\n🧠 Problem Summary
\nThe challenge focused on predicting the percentage of crop disease from hyperspectral image cubes (128×128×125). This was framed as a regression problem with evaluation metrics including MAE and SMAPE.
🧪 Key Experimental Directions
\nI tested a variety of architectures and strategies, including:
Full-Scale 3D CNNs: Initially tested deeper 3D networks, but these proved computationally expensive without GPU acceleration.
\n3D CNNs with larger volumes: Too slow and unstable on CPU, making experimentation difficult (I couldnt even go past the 1 percent T_T)
\nHybrid Models: Explored spectral averaging followed by CNN layers, but did not outperform simpler 3D setups.
\nVision Transformers: Tried flattening spectral channels and feeding into transformer-style inputs. These required GPU-level resources and substantial tuning.
\nXGBoost with spectral means: Performed decently but lacked the spatial context I wanted to preserve. (I remember a point there were not having a GPU really started getting on my nerves, but i reluctantly directed that frustration towards more attempts!)
\nFinal Model (Mini 3D CNN): Settled on a compact 3D CNN working on resized (32×32×32) patches. It generalized well and could be trained on CPU in a reasonable time.
\n(I remember when i first saw its progressing speed and time, i was over the moon!! Little did i know that this model was what would get me to the highs. Looking back on it, i am thinking of trying with a shape of (16, 16, 16), maybe when i am done with exams i could try so)
\n🔎 My Approach: Simplicity after all (Due to CPU constraints Bruh)
\nAs a solo participant without access to a dedicated GPU, my main strategy was to develop a compact, CPU-friendly 3D CNN architecture. I focused on reducing data dimensionality and keeping the training loop efficient, while still extracting meaningful spatial-spectral patterns from the hyperspectral cubes.
Rather than relying on high-compute architectures or flattening features for tree models, I stuck with end-to-end deep learning, with heavy emphasis on practical design over theoretical depth.
\nThe first few models were a starting point to catch on the invalid data, and how everything will go, then i went specifically to where i wanted to be, that attempt, being the best, was preceded and opposed with a lot of tries, but the general succeeding theme was pinpointing the area i will play in, considering my circumstances of not having a GPU, only relaying on CPU, I will put my code in a notebook on Kaggle pretty soon!!
\n🔧 Preprocessing & Feature Handling
\nResized input hyperspectral cubes to (32, 32, 32) dimensions.
Validated .npy integrity to avoid training on corrupt or empty samples.
\nEach image was loaded and preprocessed on-the-fly with augmentation disabled to preserve spectral integrity.
\n🛠️ Final Model Structure (Architecture)
\nA streamlined 3D CNN with three convolutional layers and global average pooling, followed by dense regression output.
Input: (32, 32, 32, 1)
\nConv3D(16) → MaxPool
\nConv3D(32) → MaxPool
\nConv3D(64) → GlobalAvgPool
\nDense(64) → Dropout(0.3) → Dense(1)
\nDense(1) Output (Linear Activation)
Optimizer: Adam (LR = 0.001)
\nLoss: MSE
\nMetric: MAE
\nBatch Size: 1 (greatly improved CPU compatibility)
\nEarlyStopping & ReduceLROnPlateau: Used for stability
\n🧪 Preprocessing Strategy
\nAll .npy volumes were validated and filtered for corruption.
\n(There are 3 invalid files, one empty, other cant be reshaped, and other was invalid)
Files were padded and clipped to consistent shape: 128×128×125.
\nOnly the first 32×32×32 slice was retained and normalized for input.
\nImplemented custom Keras DataGenerator with validation shuffling.
\n⚙️ Training Details
\nHardware: CPU (no GPU available)
Libraries: TensorFlow/Keras + OpenCV for preprocessing
\nCallback Strategy:
\nEarlyStopping (patience=50)
\nReduceLROnPlateau
\nModelCheckpoint
\n📤 Prediction Pipeline
\nAfter training, I built a separate prediction script (predict_cpu.py) that:
Loads .npy files and applies the same preprocessing pipeline.
\nHandles missing or malformed files robustly.
\nReplaces skipped predictions with the mean of valid outputs.
\nOutputs a predictions.csv for submission.
\nThis script made final inference seamless—even on limited hardware—and ensured data quality didn't sabotage predictions.
\n📊 Validation & Testing Strategy
\nUsed an 80/20 train/val split.
Manual hyperparameter tuning via validation MAE.
\nFinal predictions clipped within [1, 100] range, consistent with the target domain.
\n🎯 Lessons Learned
\nYou don't need massive GPUs or transformers to do well—clean preprocessing, thoughtful downsampling, and simple CNNs can go far.
Batch size = 1 was slow but kept memory usage manageable.
\nSeparating training and prediction pipelines made debugging and recovery much easier.
\n(I was not intending on adding this but there was this small thing that helped me through, you all know how most people who come from poor families, struggle a lot and go through a lot to succeed in life, despite having a lot of barriers, they went through, i had the barier of not having a GPU and had to go with CPU most of the time, instead of giving up, i kept going and the model that succeeded was a lighter version of a code that i was intending on running on a relative's pc that had a good GPU but didnt have the chance, so i was playing with the code for a bit and made this light version which did really well!!)
\n💬 Final Thoughts
\nWhile I tried many advanced models, the final solution stood out for its efficiency, reproducibility, and compatibility with real-world constraints. I’m proud to have reached the podium with a fully CPU-trained model built from the ground up—tested, refined, and deployed with care.
This solution represented a careful balance between model complexity and hardware constraints. Despite not relying on GPU acceleration or transformer-based methods, it delivered a highly competitive performance with a clean and interpretable pipeline.
\nThanks to the organizers and community — excited for what's next!
\n(Note: I know it may be a little similar to GOVINDARAM SRIRAM, I added a little more details to be a little different. Apologies for that because i am currently going through exams so i dont have much time to brainstorm!)
", "messages": [ { "id": "3207902", "postDate": "05/23/2025 11:57:37", "content": "Author: Kilalon
\nCompetition: AI for Agriculture 2025
\nModel Type: 3D CNN (Custom Lightweight Architecture)
\nFinal Score: ~841.2 (Public Leaderboard) | ~822.3 (Private Leaderboard)
\n🧠 Problem Summary
\nThe challenge focused on predicting the percentage of crop disease from hyperspectral image cubes (128×128×125). This was framed as a regression problem with evaluation metrics including MAE and SMAPE.
🧪 Key Experimental Directions
\nI tested a variety of architectures and strategies, including:
Full-Scale 3D CNNs: Initially tested deeper 3D networks, but these proved computationally expensive without GPU acceleration.
\n3D CNNs with larger volumes: Too slow and unstable on CPU, making experimentation difficult (I couldnt even go past the 1 percent T_T)
\nHybrid Models: Explored spectral averaging followed by CNN layers, but did not outperform simpler 3D setups.
\nVision Transformers: Tried flattening spectral channels and feeding into transformer-style inputs. These required GPU-level resources and substantial tuning.
\nXGBoost with spectral means: Performed decently but lacked the spatial context I wanted to preserve. (I remember a point there were not having a GPU really started getting on my nerves, but i reluctantly directed that frustration towards more attempts!)
\nFinal Model (Mini 3D CNN): Settled on a compact 3D CNN working on resized (32×32×32) patches. It generalized well and could be trained on CPU in a reasonable time.
\n(I remember when i first saw its progressing speed and time, i was over the moon!! Little did i know that this model was what would get me to the highs. Looking back on it, i am thinking of trying with a shape of (16, 16, 16), maybe when i am done with exams i could try so)
\n🔎 My Approach: Simplicity after all (Due to CPU constraints Bruh)
\nAs a solo participant without access to a dedicated GPU, my main strategy was to develop a compact, CPU-friendly 3D CNN architecture. I focused on reducing data dimensionality and keeping the training loop efficient, while still extracting meaningful spatial-spectral patterns from the hyperspectral cubes.
Rather than relying on high-compute architectures or flattening features for tree models, I stuck with end-to-end deep learning, with heavy emphasis on practical design over theoretical depth.
\nThe first few models were a starting point to catch on the invalid data, and how everything will go, then i went specifically to where i wanted to be, that attempt, being the best, was preceded and opposed with a lot of tries, but the general succeeding theme was pinpointing the area i will play in, considering my circumstances of not having a GPU, only relaying on CPU, I will put my code in a notebook on Kaggle pretty soon!!
\n🔧 Preprocessing & Feature Handling
\nResized input hyperspectral cubes to (32, 32, 32) dimensions.
Validated .npy integrity to avoid training on corrupt or empty samples.
\nEach image was loaded and preprocessed on-the-fly with augmentation disabled to preserve spectral integrity.
\n🛠️ Final Model Structure (Architecture)
\nA streamlined 3D CNN with three convolutional layers and global average pooling, followed by dense regression output.
Input: (32, 32, 32, 1)
\nConv3D(16) → MaxPool
\nConv3D(32) → MaxPool
\nConv3D(64) → GlobalAvgPool
\nDense(64) → Dropout(0.3) → Dense(1)
\nDense(1) Output (Linear Activation)
Optimizer: Adam (LR = 0.001)
\nLoss: MSE
\nMetric: MAE
\nBatch Size: 1 (greatly improved CPU compatibility)
\nEarlyStopping & ReduceLROnPlateau: Used for stability
\n🧪 Preprocessing Strategy
\nAll .npy volumes were validated and filtered for corruption.
\n(There are 3 invalid files, one empty, other cant be reshaped, and other was invalid)
Files were padded and clipped to consistent shape: 128×128×125.
\nOnly the first 32×32×32 slice was retained and normalized for input.
\nImplemented custom Keras DataGenerator with validation shuffling.
\n⚙️ Training Details
\nHardware: CPU (no GPU available)
Libraries: TensorFlow/Keras + OpenCV for preprocessing
\nCallback Strategy:
\nEarlyStopping (patience=50)
\nReduceLROnPlateau
\nModelCheckpoint
\n📤 Prediction Pipeline
\nAfter training, I built a separate prediction script (predict_cpu.py) that:
Loads .npy files and applies the same preprocessing pipeline.
\nHandles missing or malformed files robustly.
\nReplaces skipped predictions with the mean of valid outputs.
\nOutputs a predictions.csv for submission.
\nThis script made final inference seamless—even on limited hardware—and ensured data quality didn't sabotage predictions.
\n📊 Validation & Testing Strategy
\nUsed an 80/20 train/val split.
Manual hyperparameter tuning via validation MAE.
\nFinal predictions clipped within [1, 100] range, consistent with the target domain.
\n🎯 Lessons Learned
\nYou don't need massive GPUs or transformers to do well—clean preprocessing, thoughtful downsampling, and simple CNNs can go far.
Batch size = 1 was slow but kept memory usage manageable.
\nSeparating training and prediction pipelines made debugging and recovery much easier.
\n(I was not intending on adding this but there was this small thing that helped me through, you all know how most people who come from poor families, struggle a lot and go through a lot to succeed in life, despite having a lot of barriers, they went through, i had the barier of not having a GPU and had to go with CPU most of the time, instead of giving up, i kept going and the model that succeeded was a lighter version of a code that i was intending on running on a relative's pc that had a good GPU but didnt have the chance, so i was playing with the code for a bit and made this light version which did really well!!)
\n💬 Final Thoughts
\nWhile I tried many advanced models, the final solution stood out for its efficiency, reproducibility, and compatibility with real-world constraints. I’m proud to have reached the podium with a fully CPU-trained model built from the ground up—tested, refined, and deployed with care.
This solution represented a careful balance between model complexity and hardware constraints. Despite not relying on GPU acceleration or transformer-based methods, it delivered a highly competitive performance with a clean and interpretable pipeline.
\nThanks to the organizers and community — excited for what's next!
\n(Note: I know it may be a little similar to GOVINDARAM SRIRAM, I added a little more details to be a little different. Apologies for that because i am currently going through exams so i dont have much time to brainstorm!)
", "rawMarkdown": "Author: Kilalon\n\nCompetition: AI for Agriculture 2025\n\nModel Type: 3D CNN (Custom Lightweight Architecture)\n\nFinal Score: ~841.2 (Public Leaderboard) | ~822.3 (Private Leaderboard)\n\n\n\n🧠 Problem Summary\nThe challenge focused on predicting the percentage of crop disease from hyperspectral image cubes (128×128×125). This was framed as a regression problem with evaluation metrics including MAE and SMAPE.\n\n\n\n🧪 Key Experimental Directions\nI tested a variety of architectures and strategies, including:\n\nFull-Scale 3D CNNs: Initially tested deeper 3D networks, but these proved computationally expensive without GPU acceleration.\n\n3D CNNs with larger volumes: Too slow and unstable on CPU, making experimentation difficult (I couldnt even go past the 1 percent T_T)\n\nHybrid Models: Explored spectral averaging followed by CNN layers, but did not outperform simpler 3D setups.\n\nVision Transformers: Tried flattening spectral channels and feeding into transformer-style inputs. These required GPU-level resources and substantial tuning.\n\nXGBoost with spectral means: Performed decently but lacked the spatial context I wanted to preserve. (I remember a point there were not having a GPU really started getting on my nerves, but i reluctantly directed that frustration towards more attempts!)\n\nFinal Model (Mini 3D CNN): Settled on a compact 3D CNN working on resized (32×32×32) patches. It generalized well and could be trained on CPU in a reasonable time.\n\n(I remember when i first saw its progressing speed and time, i was over the moon!! Little did i know that this model was what would get me to the highs. Looking back on it, i am thinking of trying with a shape of (16, 16, 16), maybe when i am done with exams i could try so)\n\n\n\n🔎 My Approach: Simplicity after all (Due to CPU constraints Bruh)\nAs a solo participant without access to a dedicated GPU, my main strategy was to develop a compact, CPU-friendly 3D CNN architecture. I focused on reducing data dimensionality and keeping the training loop efficient, while still extracting meaningful spatial-spectral patterns from the hyperspectral cubes.\n\nRather than relying on high-compute architectures or flattening features for tree models, I stuck with end-to-end deep learning, with heavy emphasis on practical design over theoretical depth.\n\nThe first few models were a starting point to catch on the invalid data, and how everything will go, then i went specifically to where i wanted to be, that attempt, being the best, was preceded and opposed with a lot of tries, but the general succeeding theme was pinpointing the area i will play in, considering my circumstances of not having a GPU, only relaying on CPU, I will put my code in a notebook on Kaggle pretty soon!!\n\n\n\n🔧 Preprocessing & Feature Handling\nResized input hyperspectral cubes to (32, 32, 32) dimensions.\n\nValidated .npy integrity to avoid training on corrupt or empty samples.\n\nEach image was loaded and preprocessed on-the-fly with augmentation disabled to preserve spectral integrity.\n\n\n\n🛠️ Final Model Structure (Architecture)\nA streamlined 3D CNN with three convolutional layers and global average pooling, followed by dense regression output.\n\nInput: (32, 32, 32, 1)\nConv3D(16) → MaxPool \nConv3D(32) → MaxPool \nConv3D(64) → GlobalAvgPool \nDense(64) → Dropout(0.3) → Dense(1)\nDense(1) Output (Linear Activation)\n\nOptimizer: Adam (LR = 0.001)\n\nLoss: MSE\n\nMetric: MAE\n\nBatch Size: 1 (greatly improved CPU compatibility)\n\nEarlyStopping & ReduceLROnPlateau: Used for stability\n\n\n\n🧪 Preprocessing Strategy\nAll .npy volumes were validated and filtered for corruption.\n(There are 3 invalid files, one empty, other cant be reshaped, and other was invalid)\n\nFiles were padded and clipped to consistent shape: 128×128×125.\n\nOnly the first 32×32×32 slice was retained and normalized for input.\n\nImplemented custom Keras DataGenerator with validation shuffling.\n\n\n\n⚙️ Training Details\nHardware: CPU (no GPU available)\n\nLibraries: TensorFlow/Keras + OpenCV for preprocessing\n\nCallback Strategy:\n\nEarlyStopping (patience=50)\n\nReduceLROnPlateau\n\nModelCheckpoint\n\n\n\n📤 Prediction Pipeline\nAfter training, I built a separate prediction script (predict_cpu.py) that:\n\nLoads .npy files and applies the same preprocessing pipeline.\n\nHandles missing or malformed files robustly.\n\nReplaces skipped predictions with the mean of valid outputs.\n\nOutputs a predictions.csv for submission.\n\nThis script made final inference seamless—even on limited hardware—and ensured data quality didn't sabotage predictions.\n\n\n\n📊 Validation & Testing Strategy\nUsed an 80/20 train/val split.\n\nManual hyperparameter tuning via validation MAE.\n\nFinal predictions clipped within [1, 100] range, consistent with the target domain.\n\n\n\n🎯 Lessons Learned\nYou don't need massive GPUs or transformers to do well—clean preprocessing, thoughtful downsampling, and simple CNNs can go far.\n\nBatch size = 1 was slow but kept memory usage manageable.\n\nSeparating training and prediction pipelines made debugging and recovery much easier.\n\n(I was not intending on adding this but there was this small thing that helped me through, you all know how most people who come from poor families, struggle a lot and go through a lot to succeed in life, despite having a lot of barriers, they went through, i had the barier of not having a GPU and had to go with CPU most of the time, instead of giving up, i kept going and the model that succeeded was a lighter version of a code that i was intending on running on a relative's pc that had a good GPU but didnt have the chance, so i was playing with the code for a bit and made this light version which did really well!!)\n\n\n\n\n💬 Final Thoughts\nWhile I tried many advanced models, the final solution stood out for its efficiency, reproducibility, and compatibility with real-world constraints. I’m proud to have reached the podium with a fully CPU-trained model built from the ground up—tested, refined, and deployed with care.\n\nThis solution represented a careful balance between model complexity and hardware constraints. Despite not relying on GPU acceleration or transformer-based methods, it delivered a highly competitive performance with a clean and interpretable pipeline.\n\nThanks to the organizers and community — excited for what's next!\n\n(Note: I know it may be a little similar to GOVINDARAM SRIRAM, I added a little more details to be a little different. Apologies for that because i am currently going through exams so i dont have much time to brainstorm!)", "votes": null }, { "id": "3207906", "postDate": "05/23/2025 12:02:58", "content": "I know it is a little long. I think i have went too far with the spacing, apologies for the inconvenience!
", "rawMarkdown": "I know it is a little long. I think i have went too far with the spacing, apologies for the inconvenience!", "votes": null } ], "comments": [ { "id": 3207906, "author_name": "kilalon", "author_url": "", "post_date": "05/23/2025 12:02:58", "content": "I know it is a little long. I think i have went too far with the spacing, apologies for the inconvenience!
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "3207902": "Author: Kilalon\n\nCompetition: AI for Agriculture 2025\n\nModel Type: 3D CNN (Custom Lightweight Architecture)\n\nFinal Score: ~841.2 (Public Leaderboard) | ~822.3 (Private Leaderboard)\n\n\n\n🧠 Problem Summary\nThe challenge focused on predicting the percentage of crop disease from hyperspectral image cubes (128×128×125). This was framed as a regression problem with evaluation metrics including MAE and SMAPE.\n\n\n\n🧪 Key Experimental Directions\nI tested a variety of architectures and strategies, including:\n\nFull-Scale 3D CNNs: Initially tested deeper 3D networks, but these proved computationally expensive without GPU acceleration.\n\n3D CNNs with larger volumes: Too slow and unstable on CPU, making experimentation difficult (I couldnt even go past the 1 percent T_T)\n\nHybrid Models: Explored spectral averaging followed by CNN layers, but did not outperform simpler 3D setups.\n\nVision Transformers: Tried flattening spectral channels and feeding into transformer-style inputs. These required GPU-level resources and substantial tuning.\n\nXGBoost with spectral means: Performed decently but lacked the spatial context I wanted to preserve. (I remember a point there were not having a GPU really started getting on my nerves, but i reluctantly directed that frustration towards more attempts!)\n\nFinal Model (Mini 3D CNN): Settled on a compact 3D CNN working on resized (32×32×32) patches. It generalized well and could be trained on CPU in a reasonable time.\n\n(I remember when i first saw its progressing speed and time, i was over the moon!! Little did i know that this model was what would get me to the highs. Looking back on it, i am thinking of trying with a shape of (16, 16, 16), maybe when i am done with exams i could try so)\n\n\n\n🔎 My Approach: Simplicity after all (Due to CPU constraints Bruh)\nAs a solo participant without access to a dedicated GPU, my main strategy was to develop a compact, CPU-friendly 3D CNN architecture. I focused on reducing data dimensionality and keeping the training loop efficient, while still extracting meaningful spatial-spectral patterns from the hyperspectral cubes.\n\nRather than relying on high-compute architectures or flattening features for tree models, I stuck with end-to-end deep learning, with heavy emphasis on practical design over theoretical depth.\n\nThe first few models were a starting point to catch on the invalid data, and how everything will go, then i went specifically to where i wanted to be, that attempt, being the best, was preceded and opposed with a lot of tries, but the general succeeding theme was pinpointing the area i will play in, considering my circumstances of not having a GPU, only relaying on CPU, I will put my code in a notebook on Kaggle pretty soon!!\n\n\n\n🔧 Preprocessing & Feature Handling\nResized input hyperspectral cubes to (32, 32, 32) dimensions.\n\nValidated .npy integrity to avoid training on corrupt or empty samples.\n\nEach image was loaded and preprocessed on-the-fly with augmentation disabled to preserve spectral integrity.\n\n\n\n🛠️ Final Model Structure (Architecture)\nA streamlined 3D CNN with three convolutional layers and global average pooling, followed by dense regression output.\n\nInput: (32, 32, 32, 1)\nConv3D(16) → MaxPool \nConv3D(32) → MaxPool \nConv3D(64) → GlobalAvgPool \nDense(64) → Dropout(0.3) → Dense(1)\nDense(1) Output (Linear Activation)\n\nOptimizer: Adam (LR = 0.001)\n\nLoss: MSE\n\nMetric: MAE\n\nBatch Size: 1 (greatly improved CPU compatibility)\n\nEarlyStopping & ReduceLROnPlateau: Used for stability\n\n\n\n🧪 Preprocessing Strategy\nAll .npy volumes were validated and filtered for corruption.\n(There are 3 invalid files, one empty, other cant be reshaped, and other was invalid)\n\nFiles were padded and clipped to consistent shape: 128×128×125.\n\nOnly the first 32×32×32 slice was retained and normalized for input.\n\nImplemented custom Keras DataGenerator with validation shuffling.\n\n\n\n⚙️ Training Details\nHardware: CPU (no GPU available)\n\nLibraries: TensorFlow/Keras + OpenCV for preprocessing\n\nCallback Strategy:\n\nEarlyStopping (patience=50)\n\nReduceLROnPlateau\n\nModelCheckpoint\n\n\n\n📤 Prediction Pipeline\nAfter training, I built a separate prediction script (predict_cpu.py) that:\n\nLoads .npy files and applies the same preprocessing pipeline.\n\nHandles missing or malformed files robustly.\n\nReplaces skipped predictions with the mean of valid outputs.\n\nOutputs a predictions.csv for submission.\n\nThis script made final inference seamless—even on limited hardware—and ensured data quality didn't sabotage predictions.\n\n\n\n📊 Validation & Testing Strategy\nUsed an 80/20 train/val split.\n\nManual hyperparameter tuning via validation MAE.\n\nFinal predictions clipped within [1, 100] range, consistent with the target domain.\n\n\n\n🎯 Lessons Learned\nYou don't need massive GPUs or transformers to do well—clean preprocessing, thoughtful downsampling, and simple CNNs can go far.\n\nBatch size = 1 was slow but kept memory usage manageable.\n\nSeparating training and prediction pipelines made debugging and recovery much easier.\n\n(I was not intending on adding this but there was this small thing that helped me through, you all know how most people who come from poor families, struggle a lot and go through a lot to succeed in life, despite having a lot of barriers, they went through, i had the barier of not having a GPU and had to go with CPU most of the time, instead of giving up, i kept going and the model that succeeded was a lighter version of a code that i was intending on running on a relative's pc that had a good GPU but didnt have the chance, so i was playing with the code for a bit and made this light version which did really well!!)\n\n\n\n\n💬 Final Thoughts\nWhile I tried many advanced models, the final solution stood out for its efficiency, reproducibility, and compatibility with real-world constraints. I’m proud to have reached the podium with a fully CPU-trained model built from the ground up—tested, refined, and deployed with care.\n\nThis solution represented a careful balance between model complexity and hardware constraints. Despite not relying on GPU acceleration or transformer-based methods, it delivered a highly competitive performance with a clean and interpretable pipeline.\n\nThanks to the organizers and community — excited for what's next!\n\n(Note: I know it may be a little similar to GOVINDARAM SRIRAM, I added a little more details to be a little different. Apologies for that because i am currently going through exams so i dont have much time to brainstorm!)", "3207906": "I know it is a little long. I think i have went too far with the spacing, apologies for the inconvenience!" }, "source": "meta" }