Engineering Notes Last updated 25 Jun 2026

OCM Brain

Internal AI platform for commercial intelligence, lead scoring and automated insights. Designed as a production system, not a demo workflow.

Mission

Bring AI-assisted commercial intelligence into real business processes with explicit system boundaries.

Current Stack

Spring BootPythonOpenAIAnthropic PostgreSQLKubernetesAWS

Casefile Summary

System Role

Commercial intelligence layer for scoring, prioritization and AI-assisted recommendations.

Primary Users

Internal commercial teams that need ranked leads, fresher context and faster decision support.

Operational Constraint

Useful outputs had to be explainable enough to enter business workflows, not sit in an isolated AI playground.

Why It Exists

To replace fragmented manual analysis with one service-backed system that can score, generate and persist decisions.

Problem

Commercial teams needed faster access to usable insights without turning every workflow into manual research or spreadsheet coordination.

Architecture

Service-oriented boundaries separate orchestration, scoring, document handling and data persistence. The platform is structured to keep LLM interactions isolated from system ownership concerns.

Web / API -> Service layer -> Scoring / Insight workflows
                 |                     |
                 v                     v
             PostgreSQL           OpenAI / Anthropic

Key Decisions

Use Spring Boot for long-lived production services.
Keep AI workflows as explicit service responsibilities.
Favor operational reliability over experimental UI polish.

System Diagram

flowchart LR A["CRM / Lead Sources"] --> B["Enrichment + Crossing Logic"] B --> C["Scoring Services"] B --> D["Insight Generation"] C --> E["Operational Actions"] D --> E C --> F["PostgreSQL / Reports"] D --> F

Operational Flow

01 Input

Lead and consent data arrive

Operational data enters through controlled endpoints instead of manual spreadsheet handling.

02 Enrichment

Context is assembled

System services build the prompt context from internal business data and workflow rules.

03 Scoring

Models generate ranked outputs

Scoring and insight generation run as explicit backend responsibilities with typed outputs.

04 Persistence

Results become operational state

Scores, freshness checks and generated insights are stored for traceability and later use.

Repository Snippet

Based on a real private repository query helper, anonymized to remove credentials and operator identifiers.

with conn.cursor() as cursor:
    cursor.execute(
        """
        SELECT COUNT(*) AS calls
        FROM ocm_log_calls
        WHERE fecha >= CURDATE()
          AND agent = %s
          AND typecall = 'CallAuto'
        """,
        (agent_id,),
    )

Representative Query Surface

Persistence supports scoring, freshness checks and operational traceability.

select lead_id,
       score,
       consent_freshness,
       updated_at
from lead_insights
where updated_at > now() - interval '30 days'
order by score desc;

Decision Record

Context

Commercial teams needed AI support inside a workflow they could trust and reuse.

Decision

Build a service-backed platform where scoring, prompting and persistence are separate responsibilities.

Tradeoff

More backend discipline up front, but far less ambiguity once AI outputs affect business actions.

Result

The platform behaves like an internal product surface rather than a prompt wrapper.

Production Signals

Lead Quality Scoring exposed through service endpoints, not manual operator steps.
Consent Freshness Scoring persisted alongside business context for later decisions.
AI integration stays behind service boundaries so prompt changes do not reshape the whole system.
Storage and query surfaces support both business usage and operational traceability.

Verified Repository Shape

Checked against the current private production repository. The implementation is organized around operational directories instead of one generic application layer.

Verified top-level surfaces include scripts/, exports/ and assets/.
The repo structure explicitly separates automation, extraction and database operations.
The production codebase is Python-heavy, which matches the observed automation and data orchestration role.

Operational Readout

The verified repository shape supports the system claim: extraction pipelines, operational exports and database crossing logic are maintained as first-class backend responsibilities.

Tradeoffs

Hosted model integrations accelerate delivery and quality, but require careful control of dependencies, prompts and business workflow boundaries.

Result

Lead Quality Scoring and Consent Freshness Scoring moved from idea to production workflow, with automated insight generation as a real operating capability.

Operational Evidence

LLMs integrated in production, not isolated in demo tooling.
Business-facing scoring models exposed through service endpoints.
Service boundaries explicit enough to evolve scoring and insight workflows independently.