Home / Ops / More in this area

Affirmology Content + Generation Model - decisions (2026-07-13)

Updated Jul 13, 2026 · Affirmology_ContentModel_Decisions_v1.md

Affirmology Content + Generation Model - decisions (2026-07-13)

Locked with Jeff tonight. This is the cost, availability, and library model the app is built around. It supersedes the "daily fresh render" assumption in earlier Wave 1 notes.

1. No daily regeneration

The Daily Pair (and the Aries daily practice) is a fixed, crafted set the person replays. We do NOT regenerate morning and night audio every day. Repetition is how an affirmation installs, every audio stays human-checked, and cost stays sane. Novelty across the week comes from the deeper structures arriving on their own days and from the app layer, not from re-rendering the base set.

2. The starter suite is full on day one, and needs no context

A new person must arrive to a rich library without having to pick a context first. At signup we auto-generate the audios we can derive from their chart alone, no questions asked: - Their Origin Soul Song - The Mirror - The Aries daily practice (First Light, The Forge, The Stillness, The Night Tide) Context selection is how they go DEEPER, never how they get their first audio. (Jeff, 7/13: "if they don't select a context until they get into the app, then they don't have new audios right away, so we want a few that don't need it and exist in there.")

3. Everything beyond the starter suite is request-gated by default

Deeper and context-dependent structures generate only when the person asks for them. This protects the cost and, just as important, means we are never mass-producing a version we are about to revise. The staggering is a feature: early requesters help us sharpen a structure, so someone who waits gets the better version.

4. Greenlighting is per-structure, with a release mode

Approving a tested structure is two decisions, both Jeff's: - IS IT AVAILABLE (greenlit) or still in testing. - If available, its RELEASE MODE: request-only (waits to be asked for) OR auto-generate (lands in everyone's library on its own). (Jeff, 7/13: "Unless I change that because I approve new structures, and I likely will.") Default is request-only; auto is a deliberate choice per structure.

5. Star states (the Wheel) map to this exactly

Every star is one audio slot in its constellation. Three states: - dormant - structure not greenlit yet. Faint dashed outline. Not tappable. ("in testing, opens soon") - available - greenlit, request-only. Gold outline + shimmer. Tap to request. - owned - generated and in the person's library. Filled with light. Tap to play. An auto-generate structure skips straight to owned for everyone the moment it is released.

6. Two surfaces tell people what exists

• The live STAR in its constellation (lights when available, fills when owned).
• A browsable CATALOG list of what is open to request, grouped by constellation/theme. Both read from the same availability + release-mode state, so greenlighting one structure updates both.

Implications for build

• The engine needs a per-structure record: {greenlit, release_mode, version}. The catalog and the wheel both render from it. Jeff's greenlight control (roadmap item 4) writes to it.
• The starter-suite generator at signup is context-free and fixed; the request flow is the separate, on-demand path with the optional context box.
• Wheel star state per person = join of (structure availability) and (this person's owned set).