Home / Ops / More in this area
Updated Jul 12, 2026 · Affirmology_IntakeForm_and_Identity_Spec_v1.md
Jeff, 2026-07-12. Covers the name fields (for the sung-name chant, the etymology hook, and numerology)
and the unknown-birth-time flow. Pairs with Affirmology_BirthTimeRectification_Spec_v1.md.
The form's job is to get them to the audio. The app's job is to deepen.
Never block the gift on a field. Anything someone skips becomes a hook the app can pull on later, which is engagement, not loss. A half-filled form that produced a real audio beats a complete form nobody finished. Everything on this page is editable in the app, forever, and every edit can trigger a rebuild.
And our best people will go further than that. The creators, healers, teachers, and seekers who are our most alive customers very often carry a chosen spiritual name, a dharma name, a stage name, a name they took at an initiation or gave themselves after something broke open. Those names are not quirks to be tolerated. They are frequently the truest thing about the person, and they will judge us instantly by whether we can hold one without flinching.
So: do NOT validate this into a first-name box. Do NOT split it into first and last. Do NOT title-case it, strip it, or "clean" it. Accept the spaces, the capitals, the lowercase, the accents, the multiple words, the single word. Whatever they type IS the name, exactly as typed. That is what the audios say, what the chant sings, and what the app calls them.
The moment someone types "Ravenlight" or "Ma Anand Sarita" or "jeff parker love" and our form hands it back to them politely corrected, we have told them we do not actually see them. 2. Birth date 3. Birth place 4. Birth time - with a first-class "I don't know" option, not buried, not shameful.
Your full name at birth. Why we ask, in the copy: Numerology reads your birth name for one layer of who you are, and the name you go by for another. Both are true. Both are yours. Not decoration. Pythagorean numerology computes Expression, Soul Urge, and Personality from the FULL BIRTH NAME, while the name someone goes by carries a different, current vibration. Two names, two real readings. It also fixes the etymology hook, which breaks when someone types a nickname (the "Jeff, from Geoffrey" problem Code flagged on 7/10). If they skip it: numerology runs on the called name (a different reading, not a wrong one) and the etymology hook is omitted entirely. The app invites them to fill it in later.
Help us find your birth time (shown ONLY if they picked "I don't know") We can figure it out together, by asking you about your life instead of your paperwork. Yes / Not now.
The form gets exactly two name fields: what should we call you and your full name at birth. That is the whole ask.
"Which name do we sing" is NOT a form field. It is an app setting. Putting it on intake is bloat, and it also forces a heavy identity question on someone who has not yet been given anything.
How should we call you? Your dharma name, stage name, nickname, short name. Whatever is actually yours.
"Ravenlight" must sail through. "Master of the Universe" must not. The line is NOT weirdness. A filter tuned on weirdness will reject "Ma Anand Sarita" and humiliate exactly the person we most want.
The line is: is this a NAME (an identity someone holds) or a CLAIM (a title, a boast, a joke)?
1. BLOCK, hard, no "use it anyway" escape hatch. Slurs and hate terms. Sexual or vulgar content ("Big Dick Express"). Impersonation of a real public figure. Brand names. URLs, emails, numbers-only, symbols-only, empty. Over ~40 characters or ~5 words (a name is not a sentence).
This tier is a genuine wall, unlike tier 2. We are not being prudish; we are refusing to build the thing. Our system speaks this name back to the person in first person, hundreds of times, in an intimate voice, and then a choir sings it. We are not rendering a sacred audio that says I am Big Dick Express, and we are not putting our voice actors, our chant, or our brand behind it. There is no version of that we ship, so there is no "use it anyway."
Copy for the block, short and unbothered, no lecture:
We can't use that one. Our audios speak your name back to you, and a choir sings it. Give us a name we can put in that voice.
Use a real profanity and slur list, not a regex someone wrote in ten minutes, and make sure it does not false-positive on real names (the Scunthorpe problem: Cockburn, Dickinson, Fanny, Hoare, Wang, Lipschitz are all real surnames and real people). Match on whole words and known phrases, never substrings.
2. ASK, soft flag, this is where "Master of the Universe" lands. A classifier flags input that reads as a title, boast, honorific, or punchline rather than a name. Signals: leading "The" or "Master/Lord/King/Queen/God of", superlatives, a prepositional phrase, an imperative, a full sentence. The response is NEVER an error. It is a warm question. Do not reject. Ask.
3. ACCEPT everything else, including anything that merely sounds unusual. Unfamiliar is not invalid. Sanskrit, Yoruba, Hebrew, invented, lowercase, one word, four words: fine.
That reads more like a title than a name to us. Here is the thing: our audios speak this name back to you, in your own ears, hundreds of times. And the first time you open the app, we sing it.
So, what do you actually want to hear?
[ Use it anyway ] [ Let me change it ]
Why this works better than a rule. The constraint is not "we disapprove," it is "you are going to hear this." Almost everyone self-corrects the moment they picture a Gregorian chant singing "Master of the Universe," or an affirmation in their own ear saying I am Master of the Universe.
That last one is not just taste, it is a real product concern. A first-person affirmation track that installs grandiosity is not a good outcome for the person listening to it. We have a legitimate reason to care, and it is a caring reason, not a policing one.
When the classifier cannot call it, do not make the user carry our uncertainty. Let them straight through, hold back only the risky artifact, and resolve it behind the scenes.
ACCEPT provisionally -> they proceed, no friction, they get their Origin Soul Song
HOLD the chant -> do not sing a name we are unsure about
QUEUE for human review
HUMAN decides -> app PUSHES the verdict
What to hold, and what not to. Hold the artifacts that are expensive to unsay: the sung chant, and any audio render that speaks the name aloud. Text on a screen is cheap and revocable. A choir singing the wrong thing into someone's ears is not.
The instinct is "use their full name until it's resolved." That is the one fallback that can hurt someone. The exact population most likely to trip an uncertain classifier is the population with a chosen name, and quietly reverting them to the name they were born with, while we "review" the name they chose, is the deadname failure in a different costume. It would read as: we didn't like your name, so we put your old one back.
So while a name is under review: - Keep using what they typed, in text. It is not vulgar (that would be a hard block), it is just ambiguous. Text costs us nothing. - Do not sing. Show "Your welcome chant is being prepared" rather than substituting a name. - Never silently swap in the birth name. If we truly cannot use what they gave us, we ASK them, we do not overwrite them.
The only case where reverting is correct is a HARD BLOCK, and a hard block is not a review. They cannot proceed with it at all, so there is nothing to revert from.
A blanket "hold the chant on any uncertainty" is wrong, and it fails in an ugly direction. The people most likely to trip an uncertain classifier are the people with chosen, spiritual, or non-Anglo names. So a blanket hold means the Michaels and Stephanies hear their name sung on first open, and the woman with the Yoruba name is told her chant "is being prepared." We would have built a system that quietly withholds the sacred moment from exactly the people it would mean the most to. That is the same wound as rejecting them, wearing a politer face.
So the hold decision keys on RISK TYPE, not on uncertainty level.
And there is a pressure valve we already built: the confirm screen. Before the chant plays we show "We'll sing: [name]. [Sing it] [Sing something else]." That means the USER is the decision maker on every question about their own identity. We do not need to hold anything to protect them from their own name.
THE SPLIT
The USER's confirmation answers: "is this the right name FOR ME?" -> never needs a hold
The HUMAN review answers: "can WE put our voice behind this?" -> may need a hold
Only the second ever justifies holding the chant.
| Why it is uncertain | Sing on first open? | Reasoning |
|---|---|---|
| Unfamiliar (a name in a language, script, or tradition the classifier does not recognize) | SING IT. | Unfamiliar is not risky. This is the false-positive trap. Log it, review it later, but sing it. |
| Chosen / spiritual / divergent from the birth name | SING IT. | This is not a risk, it is the point. These are our best people. |
| Reads like a title or a boast ("Master of the Universe") | SING IT, after they confirm. | They saw it on the confirm screen and tapped "Sing it." That is consent. The joke is theirs, and they will change it themselves once they hear it. Harm to them: near zero. |
| Possible vulgarity or slur (near-miss on the block list, novel spelling, leetspeak, obfuscation) | HOLD. | This is the real one. Singing a slur, or humiliating someone with an obscenity in a sacred voice, is unrecoverable. Small population, high harm. Hold and resolve fast. |
| Possible impersonation of a real person | HOLD. | Brand and legal exposure, and it is not their name anyway. |
Everything above the line sings. Only the bottom two hold, and both are rare, because the flagrant versions are already hard-blocked. The residual is genuinely small: novel obfuscations and near-misses.
Target: fewer than 1 percent of names ever hold. If the hold rate climbs above that, the classifier is too twitchy and it is hurting people. Treat a rising hold rate as a bug, not as diligence.
And when we do hold, resolve it in hours, not days. A held chant is a person waiting on a gift we promised them. Put an SLA on it.
When a human approves, the app pushes:
Your name is ready. Come hear it sung.
That is a genuine re-engagement moment, not an administrative ping. The review turns into an event.
If a human declines, the app opens a warm conversation, never a rejection notice. Explain that the audios say it back in first person and a choir sings it, and ask what they want to hear. Same reframe as tier 2. They pick again, and the chant renders.
The review queue is not just for the flagged ones. Every name flows into it, including the ones the classifier waved through. Passed names land in a reviewed-and-clear lane that a human can skim, and a human can override at any time in either direction.
Why this matters more than it sounds:
Skim by exception, not exhaustively. Sort so anything unusual floats up and the Michaels and Stephanies sink. The point is that nothing is invisible, not that a person reads every row.
This needs a real queue: a name_review state on the person, a table with every name (typed name, birth
name, deduced sung name, classifier verdict + score, human verdict, reviewer, timestamp), and a place a
human can clear or override in a minute. Do not let it live in someone's inbox.
This goes fine at 29 people and falls over silently at 2,900, which is exactly the pattern the automation audit warns about. Build the queue now, while it is small and boring.
A false reject costs vastly more than a false accept. The false accept is one silly chant that they themselves will want to change. The false reject lands on a healer with a sacred name, at the moment of first contact, and tells her we do not see her. Never trade that away to avoid a joke.
Note "Use it anyway" is a real button. If someone insists, they get their name. It is theirs.
We infer it. But the inference must be safe by construction, because the downside is not a bad guess, it is singing someone's deadname to them in a sacred voice.
Is name_called a diminutive or variant of a token inside name_birth?
Use a nickname/etymology map (Jeff to Jeffrey or Geoffrey, Pete to Peter, Steph to Stephanie, Bill to
William, Sasha to Alexandra, and so on) plus stem and prefix matching.
The base is ALWAYS name_called. We never overwrite the name they chose with the one they were
given. We only ever consider adding body to it.
SUNG = name_called
+ append the SURNAME from name_birth, but ONLY when ALL of these hold:
(a) the relationship test says DIMINUTIVE (we know it is the same person), AND
(b) name_called is a single token (they have not already given us a surname), AND
(c) the result scans well when sung
Worked examples:
| name_birth | name_called | SUNG | why |
|---|---|---|---|
| Robert James Hartline | Rob | Rob Hartline | diminutive + single token, so borrow the surname for body |
| Stephanie Smith | Steph | Steph Smith | same |
| Jeffrey Alan Parker | Jeff Parker Love | Jeff Parker Love | they already gave us a full phrase. Do not touch it. |
| Peter Nowak | Pete | Pete Nowak | same |
| Sarah Jones | Ravenlight | Ravenlight | DIVERGENT. Sing exactly what they typed. |
| (blank) | Ma Anand Sarita | Ma Anand Sarita | no birth name, sing what we have |
| Michael Chen | Michael | Michael Chen | not a diminutive, but single token, same person, surname adds body |
The divergent case is absolute: sing exactly name_called, and NEVER append the birth surname.
Someone who chose "Ravenlight" does not want "Ravenlight Jones." Someone who left a family name behind
would experience us appending it as an act of violence, however well meant. When the names diverge, the
birth name is not raw material. It is off limits.
Gregorian chant wants roughly two to five syllables, vowel-rich, no hard consonant pileups. - Drop middle names always. Nobody wants "Robert James Hartline" chanted at them. - If appending the surname makes it clumsy, sing the first name alone. Body is a bonus, not a mandate. - Never invent, translate, or Latinize a name to make it sing better. Their name is the name.
On first open, right before the chant plays:
We're about to sing your name. We'll sing: Jeffrey [ Sing it ] [ Sing something else ]
One line, one tap. This is where the third field went. It is not on the intake form, it is surfaced at the exact moment it becomes meaningful and beautiful, instead of as bureaucracy before they have been given anything.
It also converts the deduction from a risk into an act of care. We guessed, we showed our work, and we handed them the pen. Nobody gets deadnamed, because nobody gets sung to without seeing the name first.
"Sing something else" writes name_sung, which then lives in the profile and can be changed forever.
If the relationship test is uncertain, fall back to name_called and still confirm. Ambiguity always
resolves toward the name they chose. Never toward the one they were given.
The chant sings the name they told us to sing. Never defaulted to the birth name, never inferred.
If we sing the birth name by default, then for anyone who changed their name we have just sung their deadname to them, in a sacred voice, as the very first thing that happens when they open the app. For a trans person that is not a small bug; it is the most harmful thing this product could do, delivered in the most intimate register, at the moment of highest trust. The same wound at lower voltage applies to someone who shed a family name, a married name, or an imposed or anglicized name.
Asking makes us the only app that asks. And the answer is context worth more than most of what a chart gives us, because someone who chooses a name other than the one they were given is telling us something enormous about their story. Store it. Treat it as sacred. Never overwrite it with a "more official" name.
Two options were on the table. Option B wins. Do not build Option A.
Option A (rejected): make them rectify on the intake form before they get anything. This is a conversion killer. It asks for work before delivering value, at the exact top-of-funnel moment where funnels die. And the rectification interview only feels magical AFTER they trust us. Before they have heard a word of their own song, it is just a long form.
Option B (locked): they mark "I don't know." We generate the Origin Soul Song from the computed time-invariant set only (see the rectification spec for the 00:00-vs-23:59 diff algorithm). We tell them honestly what we did. The app marks them, and finding their birth time becomes the first thing the app invites them into. Then we rebuild their song with the full picture.
Give first, then ask. The interview becomes a reward instead of a toll.
If we built from the invariant set, say so, in the delivery and on the results page:
You told us you don't know your birth time, so we built this from the parts of your blueprint that do not depend on it. Everything you are about to hear is true. And there is a whole layer still waiting, the moment we find your time together.
Three jobs in one line: it is honest, it makes the song feel intentional rather than diminished, and it plants the app hook before they even open the app.
The app should make rectification the first thing it offers these people, impossible to miss, with the reward attached ("find your birth time with us and we will rebuild your song with the whole picture"). But a hard wall on first open loses people the same way the intake form would. Strong invitation, not a gate. The reward does the work.
First song = the hook. Rectification = the engagement. Rebuilt song = the payoff. That is a better arc than any single perfect song at signup, and it turns our biggest data-quality weakness into a return visit.
Every field above lives in the profile and can be changed at any time: the name we call them, the name we sing, the birth name, the birth time. Changing birth data rebuilds the chart and the Understanding, and should OFFER (not force) a re-render of their audios. Changing the sung name re-renders the chant.
name_called, name_birth, name_sung, birth_time_known (bool) as first-class fields.name_sung. Nothing else may.name_birth when present, and is OMITTED entirely when it is not, per
Jeff's 7/10 rule (use the name hook only when it genuinely lands).birth_time_known = false flips on the time-invariance filter in the engine AND flags the person
for the in-app rectification invitation.