This repository contains a full-stack, applied data science proof-of-concept for the C.O.R.E. (Cognitive Operation and Reasoning Engine) ecosystem. The project simulates a distributed Edge-to-Central architecture to manage the lifecycle of conversational AI memories.
Business Impact: By engineering a predictive Random Forest classifier to identify and purge low-value memory data, this system was mathematically validated (via A/B financial simulation and Chi-Square testing) to generate a 41.46% reduction in cloud storage costs compared to a baseline standard-retention model.
pip install -r requirements.txtRequires Python 3.9+ and a running PostgreSQL 18 instance. Set your DB credentials in
.envbefore proceeding.
# 1. Generate the synthetic dataset
python scripts/generate_nodes.py
python scripts/generate_memories.py
python scripts/generate_retrieval_logs.py
# 2. Preprocess and engineer features
python scripts/preprocess.py
# 3. Train the Random Forest classifier
python scripts/train_model.py| Notebook | Purpose |
|---|---|
scripts/01_eda.ipynb |
Data diagnostics, signal identification, correlation mapping |
scripts/02_ab_testing.ipynb |
A/B financial simulation and Chi-Square statistical validation |
This module moves beyond flat CSV files by enforcing data integrity at the storage layer:
- Relational Database Design: A PostgreSQL schema enforcing hierarchical device origins, temporal causality, and behavioral data tagging.
- Synthetic Data Pipeline: Because live user data is heavily restricted, this project utilizes a custom Python generation pipeline applying Poisson and Beta distributions to simulate realistic, multi-tier hardware usage patterns and behavioral feedback loops.
- Feature Engineering: Transformed raw voice-interaction logs (RECALL, REFINE, INSPECT) into predictive signals such as semantic decay rates and interaction frequency.
- Predictive Engine: Deployed a Scikit-Learn
RandomForestClassifier(configured with balanced class weighting) to predict strict temporal evaluation actions:KEEP,DECAY, orBIN. - State Persistence: Model weights, label encoders, and feature scaling rules are serialized via
joblibto ensure consistency between the training environment and edge deployment.
A model is only as good as the capital it saves. The baseline accuracy of the engine (51%) was intentionally handicapped by simulating real-world edge data sparsity (where ~90% of memories lack retrieval logs).
To prove viability, the engine was subjected to a financial simulation:
- Control: Storing 6,000 isolated multimodal memories (5MB/payload) indefinitely on AWS S3.
- Intervention: Running the model to classify and purge data, factoring in the micro-cent compute penalty of running the inference matrix.
- Result: The storage savings from predicted
BINactions easily offset the compute overhead, resulting in a 41.46% net cost reduction. - Statistical Proof: A Chi-Square Test of Independence yielded a p-value of
2.22e-267, mathematically proving the classifications were based on learned system patterns, not random variance.
core_ecosystem_dgx/
├── schema/ # SQL DDL definitions (Nodes, Memories, Retrieval Logs)
├── scripts/ # Data generation, preprocessing, model training & notebooks
├── data/ # Generated CSV datasets and training artifacts
├── validation/ # SQL integrity contracts (temporal & referential checks)
├── docs/ # Full project blueprint and engineering log
├── config.py # Behavioral distribution config and generation parameters
├── db_setup.py # PostgreSQL connection utility
└── requirements.txt # Python dependencies
This repository represents the foundational data science build. To transition this prototype into a production-ready system, the following pipelines must be addressed:
This is the question any reviewer will ask. The answer is deliberate.
The False-Negative Acceptance Architecture
C.O.R.E. is designed to record everything — a nostalgic remark, a routine greeting, and a critical health instruction all enter the memory table equally. This is intentional. The system accepts false negatives (storing low-value memories) because the cost of a false positive (permanently losing a high-value memory) is unacceptable in a personal AI companion.
The result is a dataset of 30,000 memory records but only 3,000 retrieval log entries (10%).
This is not a data quality problem. It is the ground truth of how the system behaves: only memories the user genuinely needed were retrieved. Everything else sat untouched.
How This Constrains the Model
The retrieval logs are the primary behavioral signal. They produce total_retrievals and avg_sentiment — the features that tell the model whether a memory mattered. With only 10% of memories ever retrieved, avg_sentiment is NULL for approximately 27,000 rows (imputed as 0.0 in preprocessing). The model is therefore classifying on sparse signal by design.
A 51% macro accuracy under these conditions means the model is still extracting patterns from interaction_depth, initial_importance, and hardware_tier alone for the majority of records. The Chi-Square Test (p-value: 2.22e-267) confirms these classifications are driven by real learned patterns, not random variance.
Topic-Tag Semantic Decay Rates
For unretrieved memories, the system applies a temporal decay penalty governed by the memory's topic_tag. The rate is not uniform — critical context degrades slowly while transient context degrades rapidly:
| Topic Tag | Decay Rate | Rationale |
|---|---|---|
health, family |
Low λ | High personal consequence — slow decay toward KEEP/DECAY |
nostalgia, casual |
High λ | Transient sentiment — fast decay toward BIN |
The model learns these topic-tag-to-decision relationships implicitly from the training distribution, where generation weights were calibrated to reflect this behavioral logic.
The Bottom Line
A 51% accurate model that still produces a 41.46% cloud storage cost reduction — validated by a Chi-Square p-value of 2.22e-267 — proves that accuracy alone is not the right metric for this system. The right metric is: does it correctly identify enough low-value memories to justify its compute cost? The A/B simulation answers yes.
- Because access to proprietary, real-world edge-node conversational logs is restricted, this pipeline relies on synthetically generated data. Poisson and Beta distributions were used to simulate realistic hardware usage patterns. Production deployment requires recalibrating these assumptions against actual noisy, non-linear user behavior. The current model proves the infrastructure works, not that human behavior is perfectly predictable.
- Containerization: Packaging the inference engine and dependencies into a Docker container for hardware-agnostic edge deployment.
- API Gateway: Exposing the model via a REST/gRPC endpoint to allow live C.O.R.E. voice agents to query
cron_decisionverdicts via JSON payloads. - Automated CI/CD: Establishing a continuous training loop (
train_model.py) triggered by the ingestion of new user feedback data.