Home / Ops / More in this area

DECISION: the stored Profile is the canonical source for every audio and reading (2026-07-01)

Updated Jul 02, 2026 · Affirmology_ProfileCanonicalSource_v1.md

DECISION: the stored Profile is the canonical source for every audio and reading (2026-07-01)

Jeff's directive, logged so it is permanent and applies to any audio for anyone, from anywhere.

The rule

The per-person Profile record is the SINGLE CANONICAL SOURCE from which the Origin Soul Song and ALL future audios and readings for that person are created. Systems do NOT recompute chart data fresh each time. They read from the stored Profile.

• On first contact (any intake, anywhere), compute the full chart ONCE and store the Profile.
• Every render and reading thereafter reads from that stored Profile.
• Readings and new audios MAY go beyond it (pull more corpus, go deeper, add transits/timing), but they always START from the stored Profile rather than trying to compute new chart data each time.

What the Profile holds (the canonical record)

Stored three ways (cloud DB profile table + R2 report file + Airtable fields/link), tracked by id, email, and name: - Raw birth inputs exactly as typed (date, exact time, location). - Full computed chart, every system, to the degree: western astrology (with houses, asteroids, nodes, Lilith, Part of Fortune, Vertex), Human Design, Gene Keys, numerology, Vedic. - Current transits + progressions. - A deep read (top-10, who they are, what they are navigating, marketing angles). - (Name-based numerology intentionally excluded for now.)

Why

• Consistency: every audio for a person is built on the identical chart, no drift when code changes.
• Speed + cost: no recompute per render.
• One source of truth for gifts, marketing, and the agents (Hermes, Sophia, the oracles).

NEXT ROUND (staged): dedup on intake + multi-email + reuse-don't-regen

Jeff's directive (2026-07-02): if a person comes to the demo (or anywhere) using ANY of their emails, we must NOT regenerate their profile. Check whether a record already exists first, and if it does, DELIVER FROM THE EXISTING PROFILE for their Soul Song (and any audio). Rules: - Match cascade before generating: email (including ALL of a person's aliases) -> exact birth info (date + time + location). NEVER match on name alone (two different people share names, e.g. the two Alexes). A match = same person. - Multi-email / aliases: one profile answers to multiple emails (add an alias list, not a second row). Colin currently has two rows (cjacobsandassoc@gmail.com, colinconnection@gmail.com) to collapse into one on this round. - Reuse, don't regenerate: if a match is found and the birth data is identical, deliver the Soul Song / audio from the STORED profile. No chart recompute, no new deep read, no wasted money. - Recompute only on correction: if a match is found but the birth data CHANGED (they fixed a typo), update and recompute the profile so it reflects the corrected input; every future audio then flows from the corrected profile.

Enforcement (implementation plan)

1. Every intake builds + stores the full Profile (build_and_store_profile) as the canonical record. DONE (demo intake).
2. The render/script pipeline resolves the person's Profile (by email/id) and uses its stored data as the chart source; it computes fresh ONLY when no Profile exists, then stores it. TO WIRE (touches the proven audio pipeline, so verify chart accuracy with pytest + a test render before shipping).
3. Agents pull from the Profile via a get_profile read-path (Hermes/Sophia/oracles), no recompute. TO BUILD.
4. Applies to ANY audio for anyone from anywhere: demo, app, gifts, readings.

Where this is pushed

• This spec (source of truth for the decision).
• Memory: profile-is-canonical-source.
• To add to Affirmology_PROJECT_STATE.md at the top of the engine/pipeline section.
• Backend: api/profile_report.py (build) + the Profile table + build_and_store_profile (store); the render-reads-from-Profile wiring is the pending careful change.