Présentation de notre moteur d'horoscopes¶
Notre moteur d'horoscopes est un moteur d'astrologie déterministe conçu pour des applications de production réelles, et non pour la génération de texte de divertissement. Il combine le calcul de Swiss Ephemeris, l'activation stricte des facteurs et le rendu éditorial, afin que votre application reçoive des résultats de rapports stables, explicables et de haute qualité.
Sur quoi vous travaillez¶
Au moment de l'exécution, le moteur calcule l'état céleste réel et assemble le sens à partir des facteurs astrologiques activés. Pour des charges utiles identiques, les sorties restent stables, byte par byte. Lorsque des entrées de personnalisation sont fournies, les vecteurs au niveau de la maison et du contexte de naissance s'activent pour produire des différences spécifiques à l'utilisateur.
Cela offre à votre équipe : - Résultats prévisibles pour les tests, le contrôle qualité et la mise en cache : les requêtes identiques renvoient toujours le même JSON. - Composition de rapports explicable grâce aux traces factor_details dans chaque section. - Un chemin simple allant des rapports de base aux rapports personnalisés premium. - Profondeur tenant compte des périodes : piles de facteurs quotidiennes (5-6 facteurs), hebdomadaires (10), mensuelles (11) et annuelles (13) avec des poids explicites.
Vue d'ensemble de l'architecture¶
Architecture du moteur complet¶

Architecture Requête-Réponse¶

Pipeline Déterministe1. Gateway valide l'authentification, les quotas et la politique de requête.¶
- Validation du contrat de requête applique le schéma et les options acceptés.
- Engine détermine la source de signe, la fenêtre de période et la configuration de l'éphéméride.
- Swiss Ephemeris calcule les positions, les aspects et les maisons (lorsque cela est possible).
- Couche d'agrégation échantillonne la période, extrait les événements (aspects, entrées, stations, lunations, éclipses) et classe les facteurs.
- Moteur d'interprétation mappe les spécifications des facteurs au contenu éditorial en utilisant un ordre fixe, des poids explicites et la sélection d'une variante de hachage stable.
- Moteur éditorial génère les récits de section à partir des packs de contenu V2 avec une composition spécifique à la période (ouverture → décalage → résultat).
- Gateway renvoie le payload du moteur plus les enveloppes d'entreprise (
_enterprise,_api_metadata_) pour les métadonnées d'intégration.
Garanties de Déterminisme¶
Le déterminisme n'est pas un hasard — il est appliqué à chaque niveau :
| Garantie | Mécanisme d'application |
|---|---|
| Même payload → mêmes facteurs | Ordre explicite des facteurs par période + poids fixes |
| Même facteurs → mêmes variantes de contenu | Sélection d'index de hachage SHA-256 stable |
| Même variantes → même formulation | Cycle de formulation déterministe à partir des packs de contenu V2 |
| Même formulation → JSON identique | Cohérence de la réécriture éditoriale + déduplication des lignes de séparation des sections |
Cela signifie que vous pouvez hacher deux requêtes indépendantes avec le même corps et obtenir le même résultat, ce qui permet un stockage en cache fiable, des tests de régression QA et un débogage reproductible.
Rapports publics vs Personnalisés¶
Les deux sont des modes valides pour la production. La différence n'est pas de qualité ; c'est la profondeur d'activation.
Mode public (basé sur le signe)¶
Fournissez uniquement un signe et une date du zodiaque. Le moteur produit une lecture stable et partagée pour tous les utilisateurs ayant ce signe dans cette période.
- Idéal pour les flux de public et le stockage en cache rentable (12 signes × 4 périodes × 365 jours = ~17 520 caches uniques par jour)
- Pas de calculs de maisons — les affectations
rising_sign,house_cuspset du corpshousesontnull - Adapté pour un déploiement rapide, les horoscopes de style magazine et les niveaux freemium### Mode personnalisé (tenant compte de la date de naissance)
Fournir le contexte de naissance (birth_time, coordonnées, fuseau horaire) pour activer des vecteurs plus profonds. Deux utilisateurs ayant le même signe peuvent recevoir des éditoriaux différents en raison du changement de position des maisons et du signe ascendant, ce qui modifie les scores des facteurs.
- Champs obligatoires :
birth_time(HH:MM) +birth_latitude+birth_longitude - Débloque : signe ascendant, 12 cuspes de maisons, affectation planète-maison et facteurs axés sur les maisons (
daily_house_focus,weekly_house_focus,monthly_house_focus,yearly_house_focus) - Idéal pour les abonnements premium et les expériences à forte rétention
- Prend en charge des modules d'application plus riches et des canaux de personnalisation
Modèle d'éditorial basé sur les facteurs¶
Le moteur est piloté par des piles de facteurs — des moteurs d'interprétation déterministes calculés à partir de captures célestes et d'agrégation de périodes. Chaque période a un ordre de facteurs défini et des poids explicites.
Piles de facteurs par période¶
| Période | Nombre de Facteurs | Facteurs Clés |
|---|---|---|
| Quotidien | 5-6 | sun_in_sign, moon_in_sign, transits_archetypes, aspects, daily_house_focus |
| Hebdomadaire | 10 | weekly_moon_phase, planetary_focus, retrograde_archetypes, weekly_theme_archetypes, weekly_house_focus |
| Mensuel | 11 | monthly_lunation_archetypes, eclipse_archetypes, outer_planet_focus, monthly_theme_archetypes, monthly_house_focus |
| Annuel | 13 | jupiter_in_sign, saturn_in_sign, nodal_axis, yearly_house_focus, yearly_theme_archetypes |
Couche supplémentaire de familles de rapports dédiée aux piles de facteurs : - Planètes: planet_core_archetypes, planet_condition_archetypes, planet_house_focus, planet_sign_archetypes - Date de naissance: solar_return_tone, birthday_year_reset, natal_sun_house_year_theme - Aspect: Piles basées sur l'aspect dominé, calculé ou surchargé - Transit: Piles basées sur le transit dominant, calculé ou surchargé
Chaque facteur possède un poids explicite (par exemple, moon_in_sign: 1.15 (quotidien), yearly_theme_archetypes: 1.30 (annuel)) qui influence la notation de la section et la dérivation de l'intensité.
Ce modèle évite les dérives aléatoires et maintient le ton éditorial lié aux facteurs calculés, avec une traçabilité complète dans factor_details.
Statistiques d'application personnalisées quotidiennes (Horoscope principal)¶
Pour le mode personnalisé quotidien, le moteur renvoie des blocs de statistiques d'application prêts à l'emploi à data.daily_personalized_stats. Ces blocs sont idéaux pour les cartes de tableau de bord et les widgets de résumé.
Déclencheur d'activation : period=daily et requête de naissance personnalisée incluant à la fois birth_time et coordinates.
Blocs clés :
overall_pulse— score de vitalité quotidienne compositearchetype_scores— décomposition en huit dimensions (wisdom,creativity,confidence,intuition,allure,romance,career,emotions)harmony_discord— les 4 signes harmonieux et les 4 signes discordantselemental_balance— répartition feu/terre/air/eaumomentum_channels— signaux de momentum planétaire
Contrôle de la densité des données :
daily_stats_detail: "full"pour les données complètes du diagramme avec des niveaux de confiance par blocdaily_stats_detail: "compact"pour des charges de données client plus légères (idéal pour les widgets mobiles)
Points saillants de la conception de la requête¶
Le moteur prend en charge des contrôles clairs et typés pour la configuration et le comportement de rendu astrologique. Les options courantes incluent :
| Champ | Type | Objectif |
|---|---|---|
period | chaîne | daily, weekly, monthly, yearly |
sections | tableau | Domaines de vie à inclure (par exemple, general, career, love_singles) |
sign / birth | chaîne / objet | Source du signe (public vs personnalisé) |
target_date | chaîne | Ancre de date explicite (YYYY-MM-DD) pour la reproductibilité |
zodiac_system | chaîne | tropical ou sidereal |
ayanamsa | chaîne | Système d'offset sidéral (lahiri, fagan_bradley, etc.) |
house_system | chaîne | placidus, whole_sign, equal, koch |
node_type | chaîne | Noyau lunaire réel (true) ou moyenne (mean) |
tenant_id | chaîne | Isolation de l'espace de cache pour les environnements multi-locataires ou A/B |
Garanties de forme de réponse dans le Gateway¶
Les réponses du Gateway passent par les données du moteur et ajoutent des wrappers :
_enterprise— informations sur le niveau de plan, les quotas et les limites de débit_api_metadata_— informations sur le point de terminaison, les langues prises en charge et le contexte de la requête
Pour les points de terminaison de rapports basés sur le moteur, _api_metadata_.supported_languages est uniquement en anglais :
Politique de langue et de traduction¶
Les points de terminaison de rapports alimentés par le moteur en direct ne prennent actuellement en charge que lang=en. Cela est intentionnel pour préserver la nuance éditoriale déterministe en production tandis que la fiabilité de la traduction est organisée séparément. La couche d'aide à la traduction de la passerelle (lang=en|es|de|fr|pt) fournit une sortie traduite à la limite de l'API pour tous les points de terminaison de rapports autres que l'horoscope.
Pipeline de contenu : Packs de contenu V2¶
Contenu éditorial provenant de packs de contenu structurés V2 dans le référentiel de contenu du moteur. At runtime, the content repository selects variants deterministically via stable hash selection with a four-level fallback chain:
- Correspondance exacte (type_facteur + valeur_facteur + intensité)
---2. Toute valeur pour factor_type (factor_type + intensity)3. Tout facteur dans la section (section + intensité)
- Modèle de page de secours
This structure ensures editorial variety across intensities while preserving reproducibility for the same seed.
Modèle de confiance : Noyau fermé + Open Source léger¶
Notre moteur de production principal est à source fermée et optimisé pour la fiabilité enterprise, la profondeur et les opérations gérées. Il inclut :
- Rapports personnalisés complets prenant en compte tous les aspects (toutes les périodes)
- Rapports de cycle de naissance avec facteurs de retour solaire
- Suites de rapports incluant : planète, aspect, transit, maison et rapport planète-maison
- Carte de naissance avec rendu SVG configurable
- Mise en cache Redis, métriques, vérifications de santé et mise à l'échelle horizontale
Afin de soutenir les astrologues indépendants et l'évaluation des développeurs, nous fournissons également le moteur open-source lite :
Utilisez OpAstro pour évaluer la qualité du moteur, explorer la logique de calcul des facteurs et vérifier l'intégration de Swiss Ephemeris. Mettez à l'échelle vers les routes d'entreprise de NumerologyAPI pour des couches de rapports plus riches, une couverture plus large des points de terminaison et des opérations de production gérées.
Chemin d'intégration1. Commencer par les rapports de niveau public — quotidiens/hebdomadaires/mensuels/annuels en utilisant uniquement sign. Aucune donnée de naissance n'est requise. Optimiser le cache.¶
- Ajouter des champs de naissance personnalisés — fournir
birth_time+ coordonnées pour débloquer des éditoriaux différenciés tenant compte des aspects astrologiques. - Ajouter des familles de rapports spécialisées — points de terminaison planétaires, aspects, transits et maisons pour des surfaces de produits plus approfondies.
- Ajouter des points de terminaison de naissance — JSON complet du chart de naissance + roue SVG pour la visualisation et les flux de travail astrologiques avancés.
- Optimiser avec des sections — demander uniquement la
sectionsdont votre UI a besoin (par exemple,["general", "career"]) pour réduire la taille des données. - Utiliser
tenant_idpour l'isolation du cache — séparer les niveaux gratuits/premium ou les variantes A/B sans pollution du cache.
Stratégie de mise en cache¶
| Mode | Efficacité du cache | Stratégie |
|---|---|---|
| Public (uniquement les signes) | Élevée — ~17 520 caches uniques par jour | Pré-chauffer le lendemain ; TTL de 1 à 4 heures |
| Personnalisé (tenant compte de la naissance) | Inférieure — par utilisateur | Clés de cache par utilisateur ; TTL de 24 heures ; Redis recommandé |