Entry 01
System design
Migration
Ownership
Why I migrated this repository
Repository structure becomes a systems decision once the codebase has to support several services and real ownership boundaries. Migration is less about neatness and more about preventing operational drag.
Related systems: OCM Brain, Energy Simulator
Context
As internal tooling grew into separate services, one repository shape was making backend ownership, reviews and deployments harder to reason about.
Decision
Separate fast-moving UI and utility work from stable production services so the repository mirrors runtime responsibilities more closely.
Tradeoff
Migration adds friction in the short term, but it removes long-term ambiguity about where business logic, service contracts and deployment responsibility live.
Result
The repository stopped behaving like a generic code dump and started acting like a map of system ownership.
Entry 02
Imports
Encoding
Data quality
Fixing encoding issues while importing 900,000 records
At that scale, encoding bugs stop being edge cases. They become part of the import system design. The lesson was to treat cleanup, validation and failure handling as production requirements.
Related system: Data Processing
Problem
Data looked correct in controlled samples and then broke once real files, mixed encodings and malformed rows entered the same import batch.
Approach
Normalize input early, validate row shape before persistence and log failures by batch so reruns are controlled instead of improvised.
Operational Rule
If an import can only succeed with manual babysitting, the import is unfinished.
Result
The workflow became repeatable, safer to rerun and far less dependent on one-off cleanup scripts.
Entry 03
LLM ops
Validation
Anthropic
What I learned integrating Anthropic
Model integration only matters if the workflow around it is explicit. The hard part is not just prompt quality, but making AI behavior operationally safe inside a business process.
Related systems: OCM Brain, Smart OCR
Context
The goal was not to demo a model. The goal was to place language generation inside workflows that sales and operations could actually depend on.
Decision
Treat prompts as one component and surround them with validation, typed outputs and explicit fallback paths before any business action is taken.
Tradeoff
Adding guardrails slows the happy path, but it is the only way to make AI behavior tolerable in production.
Lesson
Operational safety matters more than raw model novelty once a business process is on the line.
Entry 04
Frameworks
Services
Operations
Why I chose Spring Boot
For production systems, convention and operational clarity often beat novelty. The framework choice was driven by service ownership, runtime discipline and maintainability, not by trend.
Related system: OCM Brain
Need
Services had to stay readable, testable and predictable after the initial delivery phase.
Decision
Use Spring Boot as the default backend surface for long-lived services with explicit conventions and strong production tooling.
Tradeoff
It is heavier than minimal frameworks, but that weight buys consistency where operational ownership lasts longer than the sprint.
Result
The framework supports service maturity instead of fighting it once the system becomes a real dependency.
Entry 05
Product systems
Simulation
Reuse
Why I turned pricing logic into a platform
Once a calculation is used by several people, the bottleneck is no longer math. It is inconsistency. The real decision was to stop treating pricing analysis as analyst-owned logic.
Related system: Energy Simulator
Context
Commercial scenarios were being recalculated repeatedly, which created delay, inconsistency and too much person-dependent knowledge.
Decision
Move pricing logic into a shared simulation platform with controlled inputs, stable outputs and a reusable backend flow.
Tradeoff
Building the platform took more effort than writing another script, but it removed repeated manual work from every future run.
Result
Simulation became a product capability instead of a recurring manual exercise.
Entry 06
Validation
OCR
Automation
Why OCR accuracy was not enough
An extraction pipeline is only useful when another system can trust the payload. High accuracy is nice. Trusted structured output is the actual requirement.
Related system: Smart OCR
Context
Raw OCR and LLM outputs looked promising, but downstream systems still needed typed, validated fields before automation could continue.
Decision
Insert schema validation between extraction and downstream automation so malformed outputs fail early instead of silently.
Tradeoff
Validation adds rejection paths and extra handling, but it prevents bad payloads from looking deceptively usable.
Result
The OCR pipeline became operationally safer and much more compatible with backend workflows.