Home / Ops / More in this area

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

Updated Jul 01, 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).

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.