Data model

The data model is deliberately narrow. Most outbound tools accumulate fifty-plus tables to handle every CRM workflow imaginable; CogniLead does cold outbound only and keeps the surface area small enough that an engineer can map it in their head.

Tables

• signals — raw, immutable, TTL-bound (90 days). One row per ingestion event. Carries source kind, source ref (URL or id), payload JSON, observed_at, expires_at, chainlog_event_id.
• leads — one row per (company, target_product). De-duplicated on intersect. Carries fit_score, jurisdiction, status, last_signal_at, chainlog_event_id.
• sends — one row per (lead, campaign, step). Carries subject_hash, body_hash, agentgate_decision, jurisdiction_routed_to, message_id, chainlog_event_id.
• suppressions — hard gate. Email or domain. Carries reason, source (manual / one-click / bounce / complaint), observed_at, chainlog_event_id.

The chainlog_event_id pointer

Every row in every operational table carries a chainlog_event_id. Render the evidence pack and we follow the pointer to reconstruct the chain: when the signal was observed, which intersect decision admitted it, which personalize call produced the body, which AgentGate decision admitted it, when Resend handed it off, the reply / bounce / complaint stream that followed.

There is no separate "audit log" table. The audit is the Chainlog ledger, and the ledger is queried by following pointers from the operational rows. That means there is exactly one way for the audit to disagree with the application state — Chainlog has been tampered with — and Chainlog rehashes on every read to detect that.

Retention

Signal rows expire 90 days after observed_at and are purged in a nightly job. Suppressed lead rows are kept 30 days after the suppression for forensic visibility, then purged. Send rows are retained 7 years to support DPA audit lookback. Chainlog events are retained for the lifetime of the tenant.