Home / Ops / More in this area
Updated Jul 12, 2026 · Affirmology_BirthTimeRectification_Spec_v1.md
Jeff's call, 2026-07-12: "we are gonna build a feature in the app to figure that out."
The method is already proven. We did it by hand for Olga (Affirmology_Olga_Rectification_v1.md) and
it worked. This spec turns that one manual rescue into a product.
Somewhere around half of all people do not know their birth time. Every astrology app on the market silently defaults them to 12:00 noon, which quietly destroys the rising sign, the houses, the Midheaven, and often the Moon. The user never finds out. They just get a reading that feels a little off, and they never know why. Randy is sitting in that exact hole right now, and so was Olga.
We can turn the industry's biggest silent data-quality failure into the most magical moment in our onboarding. Instead of asking someone for a fact they do not have, we ask them about their actual life, and then we tell them when they were born.
That is not a form. That is a party trick that happens to be true.
And it is the single best context-harvesting event we could possibly design. Every question we ask to narrow the time is a question about how they love, where their energy goes, and what they are known for. The answers pin the chart AND they feed the Understanding. Per the chatbot audit (3.7, 3.8), context is the differentiator. This is context that people are delighted to give, because they can see exactly what it buys them.
Detect. Flag any person whose birth time is missing, is exactly 12:00, or is self-reported as a guess. Never render an audio off an unverified noon default. That is a hard gate.
Separate what is stable from what swings. Compute the chart across the full candidate window and determine which placements never change (usually planets in signs) and which ones move (rising, house cusps, Midheaven, and the Moon if it crosses a sign). Tell the person plainly what we already know for certain about them. This buys trust before we ask them for anything.
Find the crossings. Inside the window, identify the specific minutes at which something crosses a house cusp or the MC changes sign. Those crossings are the decision boundaries. For Olga there were exactly three, at roughly 9:20pm, 9:55pm, and 10:30pm.
Turn each crossing into ONE either/or question about lived experience. Never astrology jargon. Never "is your Moon in the 7th or the 8th." Ask: "In your closest relationships, do you need the other person to know your depths before you can relax, or do you mostly need it to feel stable and continuous?" Two doors, both flattering, both true of someone. The person answers about their life and never realizes they just placed a planet.
Intersect. Each answer eliminates a slice of the window. The answers converge. Olga's three answers (B, A, A) collapsed a two-hour window to a 35-minute one, and any time inside it produces the same chart.
Confirm, then commit. Show them what we landed on and why, in their language. Rebuild the chart, rebuild the Understanding, release any holds, and only then render audio.
This is a conversation with an oracle, not a wizard with a progress bar. Three to five exchanges. The oracle should: - open by telling them what it already sees clearly (the stable placements), so they feel read before they feel asked - ask ONE question at a time, in plain language, with two vivid doors - react to each answer with genuine recognition, not just "got it" - close by naming the time, and by naming what that time means about them - offer an out: if nothing lands, we can widen the window or work with what is certain
Who delivers it. Per the delivery routing in the chatbot audit (3.3), this is a reading, so it goes through the council. Sophia leads. It must NEVER be improvised by the chat's own head. The crossings and the questions come from the chart math plus the corpus, not from the model's intuition.
Until a birth time is verified, the Origin Soul Song may only use chart factors that cannot change across that person's entire birth day. Anything that could shift with the hour is masked out of the script generator's input entirely. Not softened. Not hedged. Removed.
Do NOT hand-maintain a list of "safe factors." That list is wrong for somebody. Compute it.
THE ALGORITHM (CORRECTED 2026-07-12 by the engine chat, as shipped; supersedes the
original two-point version below)
1. Build the chart FIVE times for that person: 00:00, 06:00, 12:00, 18:00, 23:59 local.
2. Keep only the factors that are IDENTICAL AT ALL FIVE samples. Those are TIME-INVARIANT.
3. Everything else is TIME-VARIANT and masked for this person.
4. The script generator receives ONLY the invariant set. It never sees the rest, so it cannot
reach for it.
WHY THE ORIGINAL TWO-POINT DIFF (00:00 vs 23:59) WAS WRONG: it is blind to ~24-hour-CYCLICAL
factors. The ascendant returns to within a degree of itself across the day, so "Rising: <sign>"
can look identical at both endpoints while having swept ALL TWELVE signs in between. Any factor
with a near-daily period slips through a two-point comparison. Five samples across the day
catch the cycle. LIVE-PROVEN on a real cusp day: a Virgo-to-Libra Sun boundary was correctly
masked, the rising was correctly masked, and one person's Human Design type proved genuinely
all-day stable and was correctly kept.
This is per-person, computed, and provable. It is the only version that is right for everybody. ADDITIONAL SHIPPED BEHAVIOR (engine chat, 2026-07-12): any legacy profile with birth_time exactly 12:00 and no birth_time_known flag now gates as UNVERIFIED (Origin from invariants only, no Mirror or report) until the time is confirmed. Randy Singer renders safely from invariants under this rule.
Why an allowlist fails. The obvious intuition is "Sun sign is safe, rising is not." Both halves of that are traps: - The Sun changes sign on cusp days. Someone born on the day the Sun enters Libra is a Virgo at breakfast and a Libra at dinner. An allowlist says "Sun is safe" and hands them the wrong identity. - The Moon moves roughly 12 to 15 degrees a day, so it crosses a sign boundary within a single day fairly often. Sometimes safe, sometimes not. Only the diff knows which. - Gene Keys LINES are the sharpest trap. A gate spans about 5.6 days of solar motion, so the gate is usually stable. But a LINE is one sixth of a gate, roughly 22 hours. A person's Gene Keys line can absolutely flip inside their own birth day. Any audio that leads with a line for an unverified-time person is gambling. - Human Design is time-dependent almost end to end: profile, authority, defined centers, and the Design calculation itself all key off the exact degree. For an unknown time, assume nearly all of it is unsafe until the diff proves otherwise. - Rising, all houses, and the Midheaven are never safe. The rising sign changes about every two hours. There is no version of this where a noon default gives an honest ascendant.
What is always safe: numerology, which is computed from the birth DATE and the name, and never from the hour. So for an unverified-time person, numerology carries proportionally more of the audio. That is not a downgrade, it is a different door into the same person, and it should be written that way rather than apologized for.
Consequence for the writing, not just the math. An Origin Soul Song built on the invariant set must still feel complete, not hollowed out. It leans on what is certain and goes deeper there, rather than spreading thin across things we are guessing at. A shorter true thing beats a longer maybe.
And then: the moment rectification pins their time, we rebuild the chart, rebuild the Understanding, and offer them a NEW Origin Soul Song with the full picture. That is a genuine gift and a genuine reason to come back. "Now that I know when you were born, let me tell you who you are again."
Randy Singer is blocked on exactly this (noon default, unreliable rising and houses). He is the first real test case after Olga. Run him through it the moment the feature exists, or by hand if it is faster.