Interpretation architecture
AI Interpretation Methodology
GetBirthChart calculates chart facts first, selects bounded evidence second, and asks a language model to synthesise only that structured context into reflective prose.
Editorial standards overseen by Luis PhamMethodology
Architecture overview
The public architecture is: Birth details → location and timezone normalization → deterministic `gbc-astro` calculation → canonical structured chart → evidence and placement selection → AI synthesis → user-facing interpretation.
The model is downstream of calculation. Planetary positions, houses and aspects are not generated by the language model and are not recomputed in the browser from prose.
What the AI receives
For a natal reading, the model receives a compact payload containing the reading schema version, the known-time flag, selected chart-evidence objects, selected knowledge fragments and section-level evidence allowlists. Evidence can contain placements, houses, aspects, angles, retrograde state, Moon phase and balance data when those facts exist.
The interpretation context builder deliberately excludes personal identifiers such as the chart UUID, email, coordinates, place label and date of birth from the reading payload. Ask flows additionally provide a bounded user question and sanitized conversation history alongside canonical evidence.
What the AI does not do
The model does not calculate planetary positions, invent an Ascendant or house, override engine output, or turn a missing field into a definitive fact. If birth time is unknown, the evidence selection and prompt rules exclude Rising, houses and angles that require a time.
Interpretation does not establish a diagnosis, legal or financial conclusion, relationship outcome or scientifically validated prediction. It is a symbolic and reflective synthesis of the supplied chart evidence.
Evidence selection and synthesis
The web app builds a canonical evidence map from the chart, resolves relevant knowledge fragments, ranks evidence for each reading section and applies section-specific caps. The model receives the selected evidence IDs and their data rather than an unbounded dump of every stored field.
The reading prompt requires interaction between factors, evidence IDs to stay within each section's allowlist, conditional language and a fixed schema. This keeps the prose focused on chart-supported relationships instead of a sequence of generic placement definitions.
Unknown birth time
Unknown time is carried as a first-class state. The engine omits angles, houses and body house assignments. The product may show planetary signs that remain stable across the local-date interval, but it does not present an uncertain Moon sign as confirmed. The interpretation layer must respect those omissions.
This is a limitation of the available input, not a prompt for the model to fill in a likely time.
Grounding and safety controls
Current controls include structured chart payloads, evidence allowlists, section evidence caps, schema validation, output length checks, repair validation, and prompt constraints against invented facts or unsupported personal history. Ask input is normalized and scanned for prompt-injection patterns; suspicious conversation history is not forwarded as trusted instructions.
These controls reduce unsupported output but do not make generative interpretation infallible. The calculation layer remains the authority for chart facts, and users should treat interpretation as reflective rather than diagnostic or predictive.
Versioning
Interpretation has separate internal versions for context, knowledge, reading profile, prompt and output schema. The current natal reading source records context `context-v2.1`, knowledge `knowledge-v1`, reading schema `reading-v1` and prompt `reading-prompt-v9.2`. Ask and relationship interpretation use their own versioned contracts.
These are implementation identifiers, not claims that a particular wording is permanent. The Changelog records material public changes when they affect the interpretation architecture.