Skip to content

Architecture

Model Stack

Type Description
Base Models Pre-trained models for common tasks
Fine-tuned Models Custom models trained on CRED data
Ensemble Models Combined models for improved accuracy
Real-time Models Low-latency inference models

Data Processing Pipeline

Data Sources

  • Structured Data - Databases, APIs, CSV files
  • Unstructured Data - Text documents, images, audio
  • Real-time Data - Streaming data from various sources
  • Historical Data - Time-series data for training

Processing Stages

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Ingest    │ →  │  Preprocess │ →  │  Features   │
│   Data      │    │   & Clean   │    │  Engineer   │
└─────────────┘    └─────────────┘    └─────────────┘
                                             │
                                             ▼
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Deploy    │ ←  │  Validate   │ ←  │    Train    │
│   Model     │    │   & Test    │    │    Model    │
└─────────────┘    └─────────────┘    └─────────────┘
  1. Data Ingestion - Collect and validate input data
  2. Preprocessing - Clean, normalize, and transform data
  3. Feature Engineering - Extract relevant features
  4. Model Training - Train models on processed data
  5. Validation - Test model performance and accuracy
  6. Deployment - Serve models in production environment

Profile vs Person resolution

Rule 0017. Profile is a backend-only warehouse entity; Person is the operational, app-facing identity entity used by all downstream services and the CRED app. Never expose or address Profile rows directly from the app layer.

Entity Layer Store Purpose
Profile Warehouse (cred-dbt) BigQuery Raw aggregate of all ingested identity signals — deduplication input, not directly addressable by the app
Person Operational (cred-model-api) PostgreSQL Resolved, deduplicated entity representing a real individual — the canonical identity used by all APIs and app surfaces

Why this distinction matters

Treating Profile rows as addressable identities causes two classes of bugs:

  • Stale reads — app code may read a pre-merge Profile that has already been resolved into a different Person
  • Fan-out explosions — updating a Profile field triggers reprocessing of every linked Person record

Search keywords: Profile, Person, credentity, identity resolution

Canonical sources

Source Link
cred-dbt identity models (canonical) cred-dbt/docs/identity
Agent rule 0017 (source file) cred-agent-rules/rules/0017-profile-person-resolution.md
Decision record COM-37175

Rule link policy

Rule 0017 is linked directly to the source file in cred-agent-rules. If DOC-2 (fan-out release) is marked complete, update the rule link to point to the published/released location instead.

Link audit

See docs/audits/profile-person-resolution-link-check.md for the automated link-check run against this section.