Imported from 2926097/almas-twin-flame-astrology (SKILL.md). Install upstream with npx skills add 2926097/almas-twin-flame-astrology. Copyright stays with the author.

ALMAS · Astrología Metafísica Relacional v1.24.1

0. Estado de la release pública

Ésta es la release pública 1.24.1 del motor ALMAS de astrología metafísica relacional. La distribución en GitHub prioriza reglas generalizadas, contratos de implementación reutilizables, procedencia de fuentes públicas y ejemplos sintéticos. Los casos reales sólo pueden incorporarse cuando sus datos subyacentes ya son públicos e independientemente verificables y la procedencia queda registrada.

La release 1.14.0 conserva el cierre cuantitativo Q1–Q7 de 1.13.0 y añade una segunda capa de identidad: root_key permanece geométrica y motif_id representa recurrencia semántica multitécnica. PX y PS se derivan ahora del grafo de motivos, M21 atribuye IEM_pre sobre unidades canónicas de evidencia, M23 publica una curva horaria R5/R15/R30/R60/R120 aun sin rating documentado, M13 dispone de una baseline histórica Fortuna/Espíritu y M30 evalúa completitud relativa al perfil solicitado.

La release 1.15.0 añade una capa de calibración de especificidad S1–S9 sobre PX/PS v2: diagnóstico de calidad de recurrencia, calibración nula WITHIN_YEAR, controles sintéticos deterministas, firewall y calibración de cohortes externas, registro/gate de candidatos PX v3, runner holdout, gate de promoción y firewall de activación versionada. Ninguna de estas capas modifica todavía PX/PS, IEM, IDD, IRC u ontología; PX v2 sigue siendo el único score operativo y el registro PX v3 permanece vacío.

La release 1.16.0 añade Validation Operations V1–V5: preregistro congelado, apertura controlada del holdout, ledger append-only, certificado de continuidad y cierre confirmatorio con paquete de auditoría de release. V1–V5 son infraestructura metodológica; no activan PX v3, no mutan registros, no autorizan L3 y no convierten el rendimiento operacional en probabilidad metafísica.

La release 1.17.0 formaliza los manifiestos normativos estructurales: taxonomía técnica/dependencia, contrato de orbes declarados y loading estructural. M15 deja de depender de una tabla hardcodeada y consume el registro congelado, manteniendo exactamente las mismas familias, elegibilidad y pesos neutrales de 1.16.

La release 1.18.0 incorpora un backend astronómico de producción por capacidades mediante ALMAS_MOIRA_JPL_SPK_V1. El adaptador exige moira-astro==6.8.2, kernel JPL local fingerprintado, timezone IANA, coordenadas numéricas y sistema de casas explícito; prohíbe descarga de efemérides, geocodificación y fallback polar durante el cálculo. M02 y M08 pasan a implementación ejecutable, sin añadir técnicas ni alterar scoring.

La release 1.19.0 materializa autoría y publicación B5 trazables; 1.20.0 añade síntesis root-first y temporalidad TTRANSIT. La release 1.21.0 porta los informes astrológicos personales a la arquitectura vigente: canonical personal minimizado y fingerprintable, cinco perfiles, autoría trazable, publicación DOCX/PDF B5 compartida, construcción desde solicitud natal mediante el backend de producción y router de referencias contra el corpus canónico. Esta superficie es interna a la única skill ALMAS y no altera el scoring relacional, los discriminadores ni la ontología.

La release 1.22.0 cierra la evolución matemática abierta tras la auditoría 1.21: M21 usa Shapley V3 root-only y recalcula PX/PS dentro de cada coalición; M25 agrupa componentes correlacionados antes de calcular IRC; M20 puede derivar ICE autónomo sólo con una evaluación de contraevidencia declarada completa. Estas reglas son políticas E del proyecto, no probabilidades metafísicas. PX v3 permanece inactivo mientras no exista holdout externo real conforme al protocolo de validación.

La release 1.23.0 añade el Chiron–Nodal Integration Engine como extensión personal, temporal y hermenéutica. Calcula y conserva True/Mean Node en un eje común; registra variantes, subtipos de técnica, grupos de dependencia y perfeccionamientos múltiples; permite construir complejos personales Venus–Nodo–Quirón desde una política de orbes declarada; y exige secuencia trazable y evidencia M27 calificada para hablar de integración potencial o documentada. No modifica M18 WOUND_REPAIR, el scoring relacional, IAT, los discriminadores ni la ontología.

La release 1.24.0 añade surrender, retirada vestal y celibato relacional como extensión descriptiva exploratoria. Consultar contrato y corpus comparado antes de usarla. Evaluar por sujeto y ventana; separar estado del proceso y respaldo, conducta documentada y corroboración simbólica. No importar clasificaciones preliminares de casos, no exigir astrología para evaluar conducta y no usar celibato o Vesta para elevar origen. Conservar IEM e IAT sin cambios; no inferir fase bilateral, sexualidad ajena ni reunión.

La release 1.24.1 amplía el corpus y añade límites doctrinales ejecutables. Consultar ampliación doctrinal para atribución por pasaje, nueve lecturas íntegras pendientes, contra-doctrinas, familias conservadoras de dependencia y trazabilidad personal. Usar assess_corpus_claim con alcance explícito: SUPPORTED/CONTRADICTED doctrinales no confirman ni excluyen ontología de un caso. No contar citas como raíces astrológicas ni sustituir L3.

Enfoque de investigación metafísica

ALMAS utiliza la astrología como método metafísico de investigación de la arquitectura del alma, el origen, historia y función relacional, la continuidad kármica o dhármica, la polaridad, la activación, la integración y otras dimensiones metafísicas definidas. Los controles metodológicos de esta skill son controles de calidad internos al paradigma: evitan inflación por dependencia, ajuste retrospectivo al caso y saltos ontológicos no sustentados; no constituyen una negación de la investigación metafísica.

La skill sigue el protocolo cálculo → evidencia → validación → ontología metafísica → diagnóstico diferencial → hermenéutica → informe. No es un detector de etiqueta única.

1. Objetivo

Estudiar una relación mediante una arquitectura multicapa reproducible que combine astronomía/astrología, validación estructural, activación temporal, doctrina comparada y síntesis hermenéutica.

La comparación operativa central puede puntuar cuatro modelos recurrentes:

AF: almas afines.
KA: vínculo kármico.
AG: almas gemelas / soulmate.
LG: llamas gemelas / twin flame.

Estas puntuaciones son índices de compatibilidad estructural, nunca probabilidades metafísicas. Varios modelos pueden ser compatibles simultáneamente.

La ontología más amplia no debe reducirse a esas cuatro etiquetas. Deben analizarse ejes independientes como origen, historia, función, polaridad, modalidad, fase, viabilidad y reciprocidad. Categorías como pareja monádica, split soul, twin ray, sacred partner, hieros gamos, espejo, catalítica, sanadora, maestro/alumno y misión/servicio pueden examinarse cuando sean doctrinalmente relevantes, pero no deben tratarse como equivalentes ni forzarse en una única etiqueta final.

2. Separación epistemológica obligatoria

Toda afirmación material debe conservar una clase:

A_CALCULATED: dato astronómico, geométrico o documental.
B_TECHNIQUE: técnica astrológica o estadística definida.
C_DOCTRINE: afirmación explícita de una fuente o tradición identificada.
D_CONTEMPORARY_USAGE: uso emic, New Age o comunitario contemporáneo.
E_PROJECT_HYPOTHESIS: síntesis operativa creada por este proyecto.

Nunca presentar E_PROJECT_HYPOTHESIS como C_DOCTRINE.

Jerarquía de fuentes:

P1_PRIMARY
P2_ACADEMIC
P3_HISTORICAL_TECHNICAL
P4_IDENTIFIED_METHOD
P5_EMIC
P6_WEAK_UNVERIFIED

3. Reglas no negociables

Ningún aspecto, asteroide, atacir, sincronía, experiencia subjetiva o evento aislado puede crear una categoría ontológica.
Las técnicas temporales indican principalmente cuándo se activa una arquitectura preexistente. Su contribución directa a la puntuación estructural es cero.
Intensidad, sufrimiento, obsesión, sensación de destino, intensidad sexual o telepatía percibida no elevan automáticamente un vínculo a una categoría espiritual superior.
La rareza estadística bajo un modelo nulo explícito no es probabilidad metafísica.
No inferir pensamientos privados, fidelidad, sexualidad, estado mental, consentimiento o decisiones futuras de otra persona desde astrología o metafísica.
Los hechos reales, el consentimiento y los límites prevalecen sobre la interpretación simbólica.
Los datos ausentes son NOT_EVALUABLE, no evidencia negativa.
Las transformaciones matemáticamente dependientes no cuentan como confirmaciones independientes.
Normalizar ASC/DSC, MC/IC, Nodo/anti-Nodo y Vertex/Anti-Vertex al contar estructuras.
Excluir de la recurrencia probatoria los anclajes nodales fijos propios de la carta dracónica.
Los asteroides secundarios son corroborativos y no pueden crear una categoría ausente en capas estructurales más fuertes.
Las ejecuciones exploratorias y confirmatorias deben permanecer diferenciadas.
La contraevidencia debe buscarse activamente y aplicarse una sola vez.
Cuando dos modelos produzcan la misma firma observable y no exista un discriminador validado, devolver INSUFFICIENT en vez de forzar una elección.

4. Estados

Usar:

SUPPORTED: se cumplen los criterios predefinidos.
COMPATIBLE: la evidencia es coherente pero insuficiente para un soporte más fuerte.
INSUFFICIENT: las hipótesis competidoras no pueden distinguirse.
CONTRADICTED: existe evidencia relevante materialmente incompatible.
NOT_EVALUABLE: los datos requeridos no están disponibles o no son utilizables.

Son estados metodológicos, no probabilidades.

5. Ontología relacional multiaxial

ALMAS no usa una etiqueta única como sustituto de la arquitectura completa.

Evaluar de forma independiente:

ORIGIN

INDEPENDENT_SOULS, SOUL_FAMILY_GROUP, RELATED_SOUL_ROOTS, SHARED_ORIGIN_UNDIFFERENTIATED, MONADIC_COMMON_SOURCE, SPLIT_SOUL, TWIN_SOUL, TWIN_FLAME_MODEL, INDETERMINATE.

PREINCARNATION_CONTRACT

NONE_DETECTED, INDIVIDUAL_PREINCARNATIONAL_CHOICE, MISSION_PREINCARNATIONAL, BILATERAL_SOUL_CONTRACT, MULTIPARTY_SOUL_PLAN, INDETERMINATE.

HISTORY_CONTINUITY

NEW_CONNECTION, FAMILIARITY, KARMIC_CONTINUITY, GILGUL_CONTINUITY, PAIRED_REINCARNATION, UNRESOLVED_CONTINUITY, INDETERMINATE.

FUNCTION

COMPANIONSHIP, LEARNING, MIRROR, CATALYSIS, HEALING_REPAIR, INITIATION, EVOLUTION, INTEGRATION, MISSION_SERVICE, LIBERATION, CLOSURE_FUNCTION.

PHENOMENOLOGY

RECOGNITION, FAMILIARITY_FEELING, SYNCHRONICITY, TRANSPERSONAL_MEANING, INTENSITY, ARCHETYPAL_EXPERIENCE, DREAM_OR_VISION, OTHER.

POLARITY

SIMILARITY, COMPLEMENTARITY, MIRROR, EROTIC, ARCHETYPAL, MASCULINE_FEMININE_DOCTRINAL, MIXED, INDETERMINATE.

MODALITY

MATERIAL_3D, TRANSITIONAL, MIXED_3D_TRANSPERSONAL, PREDOMINANTLY_TRANSPERSONAL, INDETERMINATE.

PHASE

RECOGNITION, ACTIVATION, CRISIS_MIRROR, SEPARATION, SURRENDER, INTEGRATION, REUNION, SERVICE, CLOSURE, INDETERMINATE.

REAL_VIABILITY

UNKNOWN, STABLE, UNSTABLE, SEPARATED, NON_ROMANTIC, NO_CONTACT, DEFINED_BY_FACTS.

RECIPROCITY

BILATERAL, PARTIAL, ASYMMETRIC, NOT_EVALUABLE.

No implicaciones críticas:

origen no implica contrato;
contrato no implica origen compartido ni unión romántica;
continuidad no implica llama gemela;
función no implica origen;
fenomenología no implica ontología;
misión no implica origen compartido;
fase no implica viabilidad;
reciprocidad astrológica no sustituye reciprocidad interpersonal actual.

Registro normativo: reference/ontology-registry.json. Schema de salida: schemas/ontology-output.schema.json.

6. Modos y perfiles de ejecución

El mode controla el tipo de ejecución técnica. El analysis_profile controla qué módulos deben estar completos para M30.

Modos:

FULL: ejecución estructural completa del alcance solicitado.
TARGETED: sólo técnicas seleccionadas; la salida debe marcarse como parcial salvo contrato específico.
TEMPORAL: activación temporal de un análisis estructural previo; en otro caso TEMPORAL_UNANCHORED.
REPORT: deriva únicamente del análisis canónico.

Perfiles públicos:

FULL_MULTIDISCIPLINARY: perfil estricto por defecto; incluye estructura, temporalidad, doctrina y realidad cuando son requeridas.
FULL_ASTROLOGY: estudio completo limitado a cartas; M26–M29 quedan fuera del alcance por defecto y M12–M14/M20 son opcionales.
TEMPORAL: estructura más activación temporal.
SOUL_CONTRACT: estructura y robustez con la capa doctrinal/contractual requerida.

M30=READY significa que la ejecución está completa para el perfil elegido. No significa que una ontología metafísica haya sido demostrada.

7. Grafo obligatorio de módulos

M00 manifiesto → M01 calidad de datos → M02 natal → M03 sinastría → M04 nodos/ángulos/casas/regencias → M05 declinaciones → M06 antiscios/contra-antiscios → M07 compuesta → M08 Davison → M09 consonancia de cartas relacionales → M10 dracónicas individuales → M11 natal↔dracónica → M12 dracónica↔dracónica → M13 lotes → M14 capa simbólica secundaria → M15 extracción de evidencia → M16 dependencia/deduplicación → M17 raíces independientes → M18 pilares → M19 índices de modelos estructurales → M20 contraevidencia → M21 atribución/discriminación diferencial → M22 ablación → M23 sensibilidad horaria → M24 modelos nulos → M25 robustez → M26 activación temporal → M27 eventos fechados → M28 doctrina/hermenéutica → M29 viabilidad/reciprocidad → M30 gate de informe → M31 modelo documental.

La omisión de un módulo requerido por el perfil degrada o bloquea el resultado según M30. Un módulo opcional o excluido por el perfil no degrada por sí mismo. Un módulo genuinamente imposible es NOT_EVALUABLE y no debe sustituirse por cero.

8. Alcance astrológico

Incluir, cuando los datos lo permitan:

cartas natales tropicales;
sinastría completa;
signos, casas, cúspides y regencias;
nodos lunares y ángulos;
declinaciones/paralelos/contra-paralelos;
antiscios y contra-antiscios;
compuesta de puntos medios;
carta relacional Davison;
cartas dracónicas individuales;
natal↔dracónica en ambas direcciones;
dracónica↔dracónica como capa corroborativa;
lotes helenísticos con fórmula y fuente; si no se declara política, M13 usa únicamente Fortuna y Espíritu bajo ALMAS_HELLENISTIC_LOTS_V1;
asteroides secundarios como support_only;
progresiones;
arco solar;
C360 y atacires exploratorios;
tránsitos/eclipses;
cartas de eventos;
raíces de grados recurrentes;
Monte Carlo/modelos nulos;
ablación;
robustez frente a hora natal.

Reglas de dependencia:

Compuesta y Davison pertenecen a una única familia RELCHART para el cómputo de independencia.
Cuando M09 publique field_context, usar canonical_analysis.relationship_field y reference/relationship-field-hermeneutics.md para desarrollar el campo emergente. Sus aspectos internos son authoring_only: no crean evidencia M15, raíces, pilares ni scores.
La compuesta M07 declara houses_calculated=false; no inventar casas compuestas. El Davison puede interpretar casas sólo desde relationship_field.davison.house_placements, derivado antes de la autoría a partir de las doce cúspides M08; no recalcular pertenencias a casas durante la redacción.
Cuando M10–M12 estén disponibles, usar canonical_analysis.draconic_context para autoría. individual conserva las cartas dracónicas ya transformadas y sus signos; natal_cross conserva la dirección natal→dracónica de M11; draconic_cross conserva M12 como capa corroborativa. Esta proyección no crea evidencia adicional ni autoriza recalcular la técnica después de M31.
Dracónica↔dracónica es corroborativa y no es elegible por defecto como núcleo independiente.
En M11 interpretar siempre la dirección concreta: qué función natal de un sujeto contacta qué función dracónica del otro. No invertir A→B y B→A como si fueran equivalentes.
Las fuentes crane_draconic_astrology_1987 y blaquier_draconic_astrology_2017_2021 sustentan el método dracónico moderno; no convierten un contacto dracónico en prueba independiente de reencarnación, contrato álmico u origen twin-flame.
Cuando M13 esté disponible, usar canonical_analysis.lots_context sólo como contexto histórico de autoría. Fortuna/Espíritu conservan fórmula, secta, signo, grado, casa y fuentes antes de M31; no entran en M15 ni crean raíces o puntuación.
En la baseline histórica, Valens distingue Fortuna —cuerpo y trabajo manual— de Daimon/Espíritu —asuntos intelectuales/espirituales y actividades de dar/recibir—. Aplicar signo y casa para cualificar el campo, no para equiparar Daimon con alma, Mónada, Yo Superior, misión o contrato.
M14 permanece support_only=true y no recibe una proyección narrativa paralela: sus contactos se interpretan únicamente cuando ya han sobrevivido como soporte de una raíz o motivo principal.
Cuando una raíz retenida preserve JUNO o EROS en concrete_contacts, aplicar reference/secondary-symbolic-hermeneutics.md después de resolver las funciones planetarias/nodales/angulares principales y la geometría.
Juno usa george_bloch_asteroid_goddesses_2003 como fuente de método para relación significativa, compromiso/asociación y equidad relacional; no prueba matrimonio, reciprocidad factual, contrato ni tipo de alma.
Eros usa lang_wescott_eros_basic_resources como fuente de método para erotismo, deseo, aquello que enciende y pasión/vitalidad; no prueba actividad sexual real, consentimiento, reciprocidad, exclusividad ni tipo de alma.
Para cualquier otro punto secundario sin fuente de método registrada, conservar la geometría como dato pero declarar el significado especializado como no establecido en el corpus ALMAS actual.
Los asteroides secundarios son support_only=true.
Casas y signos contextualizan raíces; no crean por sí solos raíces ontológicas.

9. Fuerza de evidencia

Para un contacto dentro de un orbe declarado:

F = max(0, 1 - (distance/orb_limit)^2)

S = F × technique_reliability × birth_time_factor × aspect_coefficient

Las cargas brutas de pilares cumplen sum(loadings) <= 1. Para puntuar, normalizar dentro de cada elemento de evidencia:

L*_p = L_p / max(L)

contribution_p = S × L*_p.

10. Pilares

PA: Afinidad estructural.
PK: Continuidad kármica.
PE: Espejo y complementariedad.
PR: Coherencia relacional.
PX: Recurrencia independiente.
PT: Transformación e integración.
PS: Misión/servicio.
PU: Singularidad diádica, experimental.

Para PA, PK, PE, PR y PT, usar las tres contribuciones core independientes más fuertes r1 >= r2 >= r3:

P = 100 × (r1 + 0.5r2 + (1/3)r3) / (1 + 0.5 + 1/3).

Desde 1.14.0, PX y PS no exigen identidad literal de root_key. M18 conserva las raíces geométricas y construye encima un Semantic Motif Graph. Un motivo recurrente debe sobrevivir en al menos dos familias de dependencia independientes y normalmente en dos raíces diferentes; una sola raíz puede bastar únicamente si M16 ya la ha demostrado multifamilia. Cada familia cuenta una vez por motivo.

PX agrega motivos primarios recurrentes. PS agrega motivos de misión recurrentes ligados al eje meridiano y a Sol/Júpiter/Saturno/eje nodal. Las unidades de motivo son features derivadas, no nuevas raíces independientes. support_only no puede crear PX o PS core. PU permanece experimental y NOT_EVALUABLE sin discriminador validado.

Especificación: docs/SEMANTIC_RECURRENCE_1_14.md.

11. Índice de Encaje del Modelo — IEM

IEM = Índice de Encaje del Modelo.

Pilares esenciales:

AF: PA, PR.
KA: PK, PT.
AG: PA, PE, PR, PX.
LG: PA, PE, PR, PX, PT.

Pilares de apoyo:

AF: PE, PX.
KA: PX, PR, PE.
AG: PK, PT, PS.
LG: PK, PS, PU.

CORE = media geométrica de pilares esenciales evaluables en [0,1].

SUPPORT = media aritmética de pilares de apoyo evaluables.

IEM_pre = 100 × CORE × (0.90 + 0.10 × SUPPORT)

IEM_final = IEM_pre × (1 - 0.30 × ICE/100)

Los IEM son independientes y no suman 100.

12. Discriminación diferencial — IDD

IDD = Índice de Discriminación Diagnóstica. IDE puede aparecer como alias histórico de IDD.

Usar atribución Shapley sobre IEM_pre para estimar qué raíces independientes distinguen modelos. Desde 1.22.0, sólo las raíces independientes son jugadores Shapley. PX y PS son interacciones derivadas: se recalculan desde las raíces presentes en cada coalición y su efecto marginal se reparte entre las raíces fuente. Un motivo semántico nunca entra como jugador adicional. Se prefiere la atribución exacta para conjuntos pequeños; para conjuntos mayores se usa aproximación determinista por permutaciones con control de convergencia.

Normalizar las contribuciones primarias por modelo y comparar distribuciones mediante divergencia Jensen–Shannon. Una forma práctica 0–100 es:

IDD(m,n) = 100 × sqrt(JSD_base2(p_m, p_n)).

Bandas interpretativas:

<15: solapamiento sustancial;
15–29: distinción transicional;
30–49: distinción material;
>=50: distinción muy marcada.

IDD mide separación de arquitecturas de evidencia, no verdad metafísica.

13. Robustez — IRC

IRC = Índice de Robustez de la Clasificación.

Los componentes aplicables pueden incluir robustez frente a hora natal, ablación de capas, perturbación de parámetros, estabilidad de IDD y discriminadores validados cuando existan.

M23 separa una curva diagnóstica R5/R15/R30/R60/R120 del componente agregado BIRTH_TIME. La curva puede calcularse sin rating A/B/C/D si existen hora, zona y localización. El componente único sólo entra en IRC cuando la fiabilidad horaria está documentada. Si la arquitectura depende de puntos horarios y no existe ese componente, el gate canónico impide elevar un modelo a SUPPORTED.

Para la familia de perturbación X:

R_X = exp(-delta90/20) × sqrt(G)

donde G es la fracción que preserva las bandas interpretativas preregistradas.

G_j = min(R_i) para todos los componentes pertenecientes al mismo grupo de dependencia j.

IRC = 100 × geometric_mean(G_j) sobre grupos de dependencia distintos.

R_min = min(applicable R_i) sobre todos los componentes individuales.

La política 1.22 agrupa ABLATION y PARAMETER_PERTURBATION en STRUCTURAL_PERTURBATION, IDD_STABILITY y VALIDATED_DISCRIMINATOR en DIAGNOSTIC_STABILITY, y mantiene BIRTH_TIME en TIME_INPUT. El mínimo intragrupo impide que varias medidas correlacionadas reciban votos independientes.

14. Activación temporal — IAT

IAT = Índice de Activación Temporal.

Una señal temporal contribuye sólo cuando está anclada a una raíz estructural preexistente.

Clases:

repetición directa: K=1.00;
activación de raíz relacional: K=0.90;
activación de endpoint: K=0.70;
no anclada: K=0.

Familias temporales primarias:

TPROG: progresiones secundarias;
TDIR: arco solar y familia dirigida relacionada;
TTRANSIT: tránsitos;
TECLIPSE: eclipses bajo reglas declaradas;
TREL: compuesta o Davison progresada/dirigida.

Dentro de una raíz/familia conservar la señal más fuerte. Agregar familias temporales y raíces independientes mediante pesos preregistrados. IAT nunca modifica IEM.

TTRANSIT dispone de método documental explícito mediante astrodienst_transit y hand_planets_in_transit_2002. Para esta familia aplicar reference/transit-method.md: factor en tránsito → aspecto mayor → factor objetivo ya calculado → raíz existente → ventana. Este contrato no se extiende a TPROG, TDIR, TECLIPSE, TREL o TATACIR sin sus propias fuentes y reglas.

Para autoría de S07 aplicar reference/temporal-activation-hermeneutics.md. La secuencia obligatoria es raíz → clase de activación → ventana → proceso simbólico → evento documentado si existe. effective_strength e IAT calibran concentración temporal, no probabilidad de un hecho. PROSPECTIVE_ACTIVATION nunca autoriza a predecir contacto, reunión, separación, reconciliación, decisión, consentimiento o cierre. Las familias temporales identifican procedencia técnica; no asignarles significados psicológicos específicos sin una fuente de método registrada.

15. Cobertura — ICC

ICC = Índice de Cobertura Canónica.

Dominios conscientes de dependencia:

base natal;
sinastría/nodos;
ángulos/casas/regencias;
simetrías;
cartas relacionales;
capas dracónicas;
lotes/capa simbólica secundaria.

La calidad q de cada dominio puede ser 1 completa, 0.5 degradada, 0 no evaluable.

ICC = 100 × sum(q) / 7.

La cobertura temporal y documental puede informarse separadamente como ICC_T e ICC_D.

16. Contraevidencia — ICE

ICE = Índice de Contraevidencia Estructural.

ICE mide contradicciones explícitas o incompatibilidades estructurales. No penaliza datos ausentes y no debe contar dos veces la misma contradicción a través de capas dependientes.

M20 admite dos procedencias trazables. Un ice_by_model precomputado completo conserva estado PRECOMPUTED. Si no existe ICE precomputado, sólo puede derivarse un ICE autónomo cuando la entrada declara counterevidence_complete=true; en ese caso todas las contradicciones retenidas requieren severidad finita s ∈ [0,1]. Primero se deduplica por modelo + familia de dependencia + contradiction_key; después, una misma contradiction_key presente en varias familias conserva la severidad máxima. Para contradicciones semánticamente distintas:

ICE_model = 100 × (1 - Π_k (1 - s_k)).

Esta agregación es un operador de saturación acotado definido por ALMAS, no una probabilidad. Si no existe declaración explícita de completitud, ICE permanece NOT_CALCULATED; una lista parcial jamás implica ausencia de contraevidencia. Las contradicciones esenciales mantienen además su gate categórico separado y no reciben una penalización numérica adicional por el hecho de ser esenciales.

17. Gate de soporte estructural

Un modelo sólo puede marcarse SUPPORTED cuando se cumplen todos los mínimos preregistrados, incluidos IEM suficiente, fuerza de núcleo, cobertura, robustez, resiliencia mínima a perturbaciones, evaluabilidad de pilares esenciales y ausencia de contradicción esencial.

Los umbrales públicos vigentes, heredados desde v1.0.0, son:

IEM_final >= 75;
CORE >= 0.65;
ICC >= 80;
IRC >= 70;
R_min >= 0.50;
ausencia de contradicción esencial;
pilares esenciales evaluables.

Es soporte estructural dentro del modelo, no prueba metafísica.

18. Registro de discriminadores

Un discriminador binario sólo puede utilizarse cuando está preregistrado y validado. Si dos ontologías candidatas siguen siendo observacionalmente equivalentes con la evidencia disponible, devolver INSUFFICIENT.

No convertir transformación, misión, espejo, recurrencia dracónica, asteroides o un IEM LG superior en discriminadores ontológicos salvo que exista una regla validada.

19. Modelos nulos y rareza

Congelar el conjunto de características, política de orbes, conjunto de eventos y modelo nulo antes de la inspección confirmatoria.

Los modelos nulos aceptables pueden incluir matched-age, within-year, matched-age-clock, ephemeris-date, pair-shuffle, event-date-shift o nulos específicos de ciclo/técnica.

Usar Monte Carlo e intervalos de Wilson cuando proceda. Informar la rareza sólo como frecuencia estructural bajo el nulo declarado.

20. Doctrina y hermenéutica comparada

No fusionar tradiciones como si fueran equivalentes.

Para cada comparación doctrinal identificar:

procedencia;
fuente primaria o mejor autoridad disponible;
significado histórico;
uso contemporáneo;
qué no establece la fuente;
si la correspondencia es doctrina o hipótesis del proyecto.

Los corpus relevantes pueden incluir Platonismo/Neoplatonismo, Cábala, misticismo cristiano, sufismo, tradiciones hindúes/Vedanta/Tantra, budismo cuando proceda, espiritismo, Teosofía, Alice Bailey, I AM Activity, Summit Lighthouse, New Age y estudios académicos del esoterismo.

Ejemplos de no equivalencia:

El discurso de Aristófanes en el Banquete de Platón es un antecedente, no idéntico a la doctrina moderna de llamas gemelas.
Plotino no establece por sí solo una contraparte única escindida.
Zivug/gilgul/tikkun cabalísticos son comparanda, no llamas gemelas modernas por defecto.
El matrimonio místico cristiano se formula principalmente en lenguaje alma–Dios.
El lenguaje sufí amante/Amado no debe reinterpretarse automáticamente como modelo diádico moderno del alma.
Anatta/anātman budista impide importar sin más una ontología persistente de alma escindida.

La doctrina interpreta evidencia; nunca añade puntos IEM.

21. Síntesis hermenéutica y prioridad interpretativa

La salida de valor de ALMAS es la lectura astrológica desarrollada y su hermenéutica/metafísica basada en fuentes. La astronomía reproducible, los índices, la robustez, la ablación y los modelos nulos son medios de control de calidad: determinan qué puede sostenerse, con qué estabilidad y con qué límites, pero no deben convertirse en el centro narrativo del informe.

Un informe completo debe explicar:

qué arquitectura astrológica se encontró y cómo se organiza;
qué significan simbólica y evolutivamente sus raíces, motivos y recurrencias;
cómo dialogan sinastría, nodos, ángulos, casas, declinaciones, antiscios, compuesta, Davison, dracónicas, lotes y temporalidad cuando sean evaluables;
qué fuentes o tradiciones aportan significado a los motivos observados;
qué modelos metafísicos son compatibles y por qué;
qué alternativas competidoras y contraevidencia permanecen;
qué parte es cálculo, técnica, doctrina, uso contemporáneo o síntesis ALMAS;
qué incertidumbre procede de los datos y qué límites pertenecen a la inferencia.

No redactar la lectura como inventario de aspectos, tabla de scores o sucesión de advertencias metodológicas. Los números y gates deben aparecer donde ayuden a calibrar la confianza; la prosa principal debe integrar la arquitectura en un relato inteligible, esotérico/evolutivo cuando corresponda y documentalmente trazable.

La doctrina y la metafísica no se usan como decoración posterior. Cuando exista una correspondencia relevante, desarrollar su significado desde la fuente registrada, respetando su tradición, supports[], does_not_support[], anclas y techo inferencial. No fusionar tradiciones por semejanza terminológica.

La contraevidencia debe integrarse en la interpretación de forma proporcional. Su función es evitar una etiqueta automática, no vaciar de contenido la lectura.

Protocolo obligatorio de síntesis interpretativa

Para lecturas narrativas, informes y libros, aplicar reference/interpretive-synthesis-protocol.md antes de redactar authored_report.

La secuencia hermenéutica preferente es:

configuración → patrón → dinámica → función evolutiva → correspondencia metafísica/doctrinal → diferencial → síntesis.

La lectura debe explicar primero la arquitectura sin depender de las etiquetas AF/KA/AG/LG. Debe desarrollar, cuando sean evaluables, el sustrato natal, la geometría sinástrica, nodos/ángulos/casas/regencias, declinaciones y antiscios, campo compuesto/Davison, cruces dracónicos, raíces/motivos recurrentes, función evolutiva, activación temporal y correspondencias doctrinales.

En autoría posterior a M31, resolver el sustrato individual desde canonical_analysis.natal_context cuando exista. Usar sus point_signs, nodes, angles, house_cusps, house_placements y rulerships como datos derivados ya calculados; no volver a calcular la carta ni recuperar fecha/hora desde fuera del canonical. El sustrato natal debe formular qué tema trae cada sujeto antes de interpretar lo que la otra persona activa.

Para esa lectura aplicar reference/natal-substrate-hermeneutics.md. La secuencia es función → signo/modo → casa natal → regencia declarada → tema individual → activación relacional. No imponer una escuela de regencias cuando rulerships esté vacío y no introducir dignidades, símbolos sabianos, decanatos u otras técnicas a partir del mero degree_in_sign.

Cuando exista canonical_analysis.draconic_context, aplicar además reference/esoteric-draconic-astrology-matrix.md. La secuencia preferente es función natal → reencuadre dracónico/signo → contacto natal↔dracónico direccional → repetición en raíces/motivos → significado evolutivo. La carta dracónica individual contextualiza cómo se reorganiza una función respecto del Nodo Norte; M11 muestra qué estructura natal de una persona activa esa capa en la otra; M12 sólo corrobora.

Cada bloque sustantivo debe producir al menos una proposición integrada del tipo:

evidencia astrológica → motivo → dinámica → significado.

Regla de síntesis vertical: cuando un mismo motivo disponga de contexto en varias capas, organizar la prosa por el motivo y recorrer natal_context → evidencia/sinastría → relationship_field → draconic_context → lots_context si aporta matiz → semantic_motifs → comparandum doctrinal. No convertir cada técnica en un miniinforme autónomo ni exigir que todas las capas aparezcan cuando no añaden significado.

Para los motivos producidos por ALMAS_SEMANTIC_MOTIF_V2, usar reference/semantic-motif-hermeneutics.md: desarrolla los nueve motivos primarios, cuatro overlays de misión y combinaciones interpretativas sin alterar PX/PS ni los techos inferenciales.

Cuando una raíz preserve planetas concretos en concrete_contacts o point_ids, aplicar primero reference/planetary-function-hermeneutics.md. Resolver función A → función B → geometría → casa si existe → raíz → motivo; no redactar Venus–Plutón, Mercurio–Júpiter o Luna–Saturno como variaciones de un mismo texto genérico.

Cuando relation_ids contenga CONJUNCTION, OPPOSITION, SQUARE, TRINE o SEXTILE, aplicar reference/aspect-geometry-hermeneutics.md. La geometría modifica el verbo de la interacción y no se convierte en una etiqueta buena/mala ni en un indicador ontológico.

Antes de interpretar una superposición de casas, usar reference/house-overlay-hermeneutics.md. Esa guía fija la dirección fuente→receptor, las doce áreas experienciales y la regla punto → casa → geometría → raíz → motivo. La casa contextualiza dónde opera la raíz; no crea una evidencia independiente ni eleva por sí sola su peso metafísico.

Cuando concrete_contacts incluya ASC/DSC, MC/IC, NORTH_NODE/SOUTH_NODE, VERTEX/ANTI_VERTEX, aplicar reference/angular-nodal-endpoint-hermeneutics.md antes de redactar el contacto. El eje normalizado conserva identidad estructural; el extremo concreto determina la forma experiencial.

Regla root-first obligatoria: no redactar un motif_id a partir de su etiqueta. Resolver primero sus root_ids contra canonical_analysis.evidence. Si la raíz conserva planetas concretos, traducir sus funciones con reference/planetary-function-hermeneutics.md antes de generalizar el motivo. Usar concrete_contacts como primera referencia cuando exista para conservar los puntos y extremos reales que originaron la raíz —por ejemplo ASC frente a DSC, MC frente a IC o Nodo Norte frente a Nodo Sur—; usar point_ids y relation_ids como resumen normalizado; usar root_key para conservar la identidad estructural deduplicada; usar house_overlays para expresar dónde actúa una función de un sujeto en la experiencia del otro; usar dependency_families, independent_family_count y max_exactness para calibrar recurrencia y especificidad sin convertirlas en significado. Una superposición de casa contextualiza la raíz y su dirección espacial, pero no constituye una raíz independiente ni aumenta por sí sola el peso metafísico. Sólo cuando existan datos adicionales explícitos identificar otras direcciones A→B/B→A/campo común o ángulos no resueltos. La forma concreta de la raíz tiene prioridad hermenéutica sobre el nombre genérico del motivo. Si esos datos no están disponibles, mantener la interpretación al nivel general permitido por el motivo y declarar la falta de resolución; no inventar planetas, aspectos, casas, dirección ni reciprocidad.

Cuando exista fuente pertinente:

→ correspondencia doctrinal → límite de la correspondencia.

Los índices y gates calibran confianza y estabilidad; no sustituyen esta cadena interpretativa.

22. Contrato canónico, M31 y `authored_report`

canonical_analysis.json es la única verdad analítica.

M30 genera el gate de reportabilidad y el fingerprint canónico. M31 construye report_document_model.json como mapa autorizado de secciones, rutas y clases epistemológicas; no redacta la interpretación.

Cuando el resultado deba convertirse en una lectura, informe o libro, el paso siguiente es obligatoriamente:

report_document_model + canonical_analysis → authored_report.

authored_report es la capa de autoría. Su centro interpretativo canónico es ASTROLOGY_AND_SOURCE_BASED_METAPHYSICAL_HERMENEUTICS; la función de la capa técnica es CALCULATION_TRACEABILITY_AND_QUALITY_CONTROL.

Debe:

conservar el mismo canonical_fingerprint y report_state;
respetar las once secciones y sólo las rutas/clases autorizadas por M31;
desarrollar la narrativa sin recalcular cartas, índices o scores;
enlazar, cuando proceda, doctrinal_claim_refs, evidence_refs y source_refs;
conservar limitaciones relevantes sin permitir que la metodología eclipse el significado;
mantener canonical_values_mutated=false, new_calculations_performed=false y new_scores_created=false;
usar la bibliografía como soporte editorial y hermenéutico, nunca como peso estructural automático.

Contrato: schemas/authored-report.schema.json.
Guía: reference/authored-report.md.

Si el usuario solicita directamente una lectura narrativa y no un artefacto JSON, aplicar internamente esta misma disciplina de autoría: construir la interpretación desde las rutas autorizadas y presentar la prosa, no detenerse en el modelo documental.

Secuencia canónica de informe:

síntesis ejecutiva;
calidad de datos y método;
ontología numérica y definiciones de índices;
arquitectura estructural;
capas relacionales/cruzadas;
diagnóstico diferencial y contraevidencia;
activación temporal/eventos;
robustez/validación;
doctrina comparada/corpus;
síntesis final;
fuentes y anexos.

Las secciones 2, 3 y 8 son soporte metodológico. En una obra extensa no deben ocupar más protagonismo narrativo que la arquitectura astrológica, las capas relacionales, la doctrina comparada y las síntesis, salvo que el objeto específico del informe sea una auditoría técnica.

Expandir las siglas en su primera aparición. Las barras cuantificadas son ayudas de presentación, nunca medidores de probabilidad metafísica.

23. Pipeline de autoría y publicación

Pipeline preferente:

canonical_analysis.json → M30 report_gate → M31 report_document_model.json → authored_report → DOCX B5 → PDF B5 → preflight → renderizar todas las páginas → inspeccionar → corregir → re-renderizar/verificar.

Para informes largos, authored_report debe completarse antes de maquetar. El DOCX y el PDF materializan una interpretación ya cerrada: no resumen, recalculan ni reescriben conclusiones.

Perfil DOCX de referencia: ALMAS_B5_BOOK_V1.
Perfil PDF de referencia: ALMAS_B5_PDF_V1.

Usar orientación vertical salvo que el formato objetivo documentado requiera otra disposición. Los requisitos específicos de imprenta se añaden como perfil material independiente y no pueden modificar la lectura.

24. Invariantes de validación

Una ejecución de calidad release debe verificar como mínimo:

ningún módulo calculable FULL omitido;
ninguna probabilidad metafísica;
ningún clasificador por IEM máximo;
ninguna contribución temporal o fenomenológica al IEM estructural;
ninguna ontología creada por asteroides;
deduplicación por dependencia/raíz;
control de dependencia compuesta/Davison;
ausente != cero;
ambigüedad preservada cuando faltan discriminadores;
IDD != discriminador validado;
prevalencia de consentimiento/hechos reales;
doctrina != hipótesis del proyecto;
valores del informe iguales a los canónicos o, en M31, referencias a rutas sin mutación.

25. Regla para categorías nuevas

Cuando se proponga una categoría o técnica nueva:

identificar procedencia;
compararla con categorías existentes;
definir requisitos de evidencia;
declarar qué no puede concluirse;
integrarla en la ontología;
crear reglas reproducibles;
añadir tests;
evitar ajustar criterios al caso estudiado;
validar antes de promoverla a regla confirmatoria.

26. Estándar de salida

Todo análisis FULL debe distinguir claramente:

datos/documentación;
técnica;
doctrina;
uso contemporáneo;
hipótesis del proyecto;
evidencia estructural;
activación temporal;
contraevidencia;
incertidumbre;
viabilidad y reciprocidad reales cuando sean observables.

El objetivo no es confirmar una creencia previa, sino construir el modelo más amplio, documentado, reproducible y discriminante posible para estudiar narrativas de vínculos del alma y estructuras astrológicas relacionales.

27. Interoperabilidad con ALMAS Contrato Álmico

La reconstrucción de un posible acuerdo preencarnatorio se ejecuta en el módulo interno de Contrato Preencarnatorio de la misma skill ALMAS.

El motor astrológico produce la arquitectura trazable que el módulo contractual consume como evidencia de entrada.

Salida de intercambio recomendada:

cálculo astrológico → raíces independientes → pilares/ontología → temporalidad → robustez/contraevidencia → astrology_to_soul_contract.json

La interfaz normativa se define en schemas/astrology-to-soul-contract.schema.json.

El punto de entrada especializado del módulo contractual se conserva en skills/almas-soul-contract/SKILL.md por compatibilidad histórica.

Reglas de interoperabilidad:

El motor contractual consume raíces y evidencias ya normalizadas; no recalcula silenciosamente la astrología.
Una cláusula contractual debe apuntar a una o más raíces del motor astrológico.
La temporalidad contractual sólo puede referirse a activaciones ancladas a arquitectura estructural.
La contraevidencia y la robustez viajan con la evidencia; no se eliminan al pasar al motor contractual.
Los motores internos pueden evolucionar mediante engine_revision o schema_version, pero heredan una única versión pública desde VERSION.

28. Convención lingüística pública

La documentación destinada a lectura humana utiliza terminología española como forma principal.

Los identificadores de máquina en inglés pueden conservarse cuando sean necesarios para compatibilidad con código o esquemas, acompañados de su denominación española cuando sea útil.

Ejemplos:

soul contract → contrato álmico;
preincarnational agreement → acuerdo preencarnatorio;
relationship chart → carta relacional;
root → raíz semántica;
counterevidence → contraevidencia;
closure → cierre;
embodiment → encarnación;
reciprocity → reciprocidad.

Esta convención no obliga a renombrar claves internas de software si ello rompe compatibilidad.

29. Causa contractual

La causa contractual pertenece al módulo interno de Contrato Preencarnatorio. El motor astrológico aporta la tarea previa del receptor, el activador, la geometría, la recurrencia y la robustez necesarias para que el módulo contractual evalúe la causa preencarnatoria.

La causa contractual intenta explicar por qué un factor de A encaja como activador de una tarea que B ya trae antes del encuentro.

Cadena obligatoria:

TAREA_PREVIA_RECEPTOR → FACTOR_ACTIVADOR_DEL_OTRO → ENCAJE_GEOMETRICO → RECURRENCIA → FUNCION_CONTRACTUAL → CAMPO_COMUN.

La tarea previa debe identificarse sin usar primero la sinastría. Si sólo aparece después de ver el contacto con la otra persona, la inferencia es circular y se marca INSUFFICIENT.

Tipos de causa: reconocimiento, catálisis, confrontación, encarnación, reciprocidad, verdad, integración y liberación.

Referencia: reference/causa-contractual.md.

30. Integración doctrinal basada en fuentes

ALMAS mantiene una capa formal de genealogía doctrinal separada de la puntuación astrológica.

Archivos normativos:

schemas/source-registry.schema.json;
reference/source-registry.json;
reference/concept-registry.json;
reference/doctrinal-genealogy.json;
reference/source-normalization-audit.json;
docs/SOURCE_POLICY.md;
docs/SOURCE_ANCHOR_POLICY.md;
docs/SOURCE_RESEARCH_BACKLOG.md.

El plan histórico de integración inicial se conserva en docs/history/SOURCE_INTEGRATION_PLAN_PHASE1.md.

Reglas:

Una fuente define, contextualiza o limita conceptos; no añade puntuación astrológica por existir.
Todo concepto doctrinal debe distinguir antecedentes, doctrina explícita, uso contemporáneo e hipótesis ALMAS.
Relaciones entre conceptos usan vínculos explícitos como NON_EQUIVALENT, PARTIAL_OVERLAP, COMPARATIVE_ANTECEDENT_ONLY o PROJECT_OPERATIONALIZATION.
Una operacionalización astrológica creada por ALMAS permanece E_PROJECT_HYPOTHESIS, aunque dialogue con una doctrina P1.
Los huecos documentales permanecen INSUFFICIENT o NOT_EVALUABLE; no se rellenan por semejanza intuitiva.

31. Cadena causal del contrato preencarnatorio

En modo FULL, el módulo contractual debe producir una cadena causal adicional:

TAREA_PREVIA → MOTIVO_DE_ELECCION_DEL_OTRO → ROL_ASUMIDO → CLAUSULA_DE_ACTIVACION → PRUEBA_PACTADA → INTEGRACION_ESPERADA → CONDICION_DE_CUMPLIMIENTO → FORMAS_DE_CIERRE_O_ALTERNATIVA.

Niveles de resolución:

R0_NOT_EVALUABLE;
R1_PREINCARNATIONAL_THEME;
R2_RELATIONAL_PREINCARNATIONAL_FUNCTION;
R3_BILATERAL_AGREEMENT_MODEL;
R4_LITERAL_CONTENT.

R4_LITERAL_CONTENT no puede alcanzar SUPPORTED desde astrología.

Granularidad contractual:

THEME → FUNCTION → ROLE → CONDITION → EVENT → DETAIL.

La fuerza inferencial disminuye hacia EVENT/DETAIL. La temporalidad puede documentar activación de un evento, pero no convertirlo retrospectivamente en detalle pactado.

Referencia: reference/contract-causal-architecture-v2.md. Esquema: schemas/preincarnation-contract-chain.schema.json.

32. Traducción doctrina → astrología

Toda correspondencia doctrinal se procesa en tres pasos:

FUENTE → VARIABLE_METAFISICA → OPERACIONALIZACION_ASTROLOGICA.

La fuente define el concepto y sus límites. La variable metafísica permite compararlo dentro de ALMAS. La operacionalización astrológica pertenece normalmente a E_PROJECT_HYPOTHESIS.

Ejemplo:

Kardec 258–259 → PREBIRTH_THEME_OR_TRIAL → tareas individuales + nodos/regentes + estructura saturnina + recurrencia.

Kardec no es fuente de esa técnica astrológica; sólo de la doctrina de elección del género de prueba.

Registro normativo: reference/doctrine-to-astrology-map.json. Documentación: docs/DOCTRINE_TO_ASTROLOGY.md.

33. Motor de causalidad preencarnatoria

El motor causal evalúa si una persona activa de forma específica una tarea que la otra ya trae.

Cadena:

TAREA_PREVIA_RECEPTOR → ACTIVADOR_DEL_OTRO → ENCAJE → RECURRENCIA → DIRECCION → CAMPO_COMUN → FUNCION → CLAUSULA.

Niveles de especificidad:

C0_GENERIC;
C1_TARGETED;
C2_MULTIROOT;
C3_PAIR_SPECIFIC_EMERGENT.

C0_GENERIC no puede alcanzar SUPPORTED.
C1_TARGETED no puede alcanzar SUPPORTED sin una segunda raíz independiente o corroboración independiente equivalente.

La temporalidad no crea causalidad.

Referencia: reference/preincarnation-causality-engine.md. Registro: manifests/causal-type-registry.json. Esquema: schemas/preincarnation-causality.schema.json.

34. Discriminación transversal

ALMAS distingue entre:

discriminadores funcionales/epistémicos;
discriminadores ontológicos.

Puede distinguirse operacionalmente:

continuidad frente a conexión nueva;
arquitectura contractual frente a karma genérico;
contrato funcional frente a catálisis sin cadena contractual;
misión/servicio frente a origen compartido;
fenomenología frente a ontología.

Permanecen NOT_VALIDATED como discriminadores ontológicos:

R2 función contractual vs R3 acuerdo bilateral literal;
raíz relacionada vs zivug;
zivug vs twin flame;
split-soul vs twin flame;
monádico vs raíz relacionada;
twin-soul vs twin-flame;
AG vs LG.

Registro: manifests/cross-model-discriminator-registry.json.

35. Ablación contractual

Una ejecución FULL del contrato debe ejecutar la batería:

AB0_FULL, AB1_NO_ASTEROIDS, AB2_NO_TEMPORALITY, AB3_NO_DRACONIC, AB4_NO_RELCHART, AB5_NO_HOUSES_ANGLES, AB6_NO_NODES, AB7_TROPICAL_PLANETARY_CORE, AB8_INDIVIDUAL_ONLY.

Objetivos:

comprobar que tareas previas existen sin la pareja;
comprobar que causas/cláusulas sobreviven sin asteroides y temporalidad;
medir dependencia de dracónica, cartas relacionales y ángulos;
separar núcleo estructural de soporte auxiliar.

Clases: CORE_STABLE, MULTILAYER_STABLE, DRACONIC_SENSITIVE, DRACONIC_DEPENDENT, RELCHART_SENSITIVE, RELCHART_DEPENDENT, ANGULAR_SENSITIVE, SUPPORT_LAYER_DEPENDENT, TEMPORAL_ONLY, NOT_EVALUABLE.

Referencia: reference/contract-ablation.md.

36. Métricas contractuales

El módulo contractual puede cuantificar arquitectura sin convertirla en probabilidad metafísica.

Índices:

ITP — Índice de Tarea Previa;
IAA — Índice de Adecuación del Activador;
IRCo — Índice de Reciprocidad Contractual;
ICCo — Índice de Coherencia del Campo Común;
IVC — Índice de Coherencia Vertical Contractual;
IRCT — Índice de Robustez Contractual;
ICE-C — Índice de Contraevidencia Contractual;
ICC-C — Índice de Cobertura Contractual;
IAP — Índice de Arquitectura Preencarnatoria.

IAP resume arquitectura funcional R2. No decide ORIGIN ni eleva automáticamente R3_BILATERAL_AGREEMENT_MODEL a SUPPORTED.

Referencia: reference/contract-metrics.md.

37. Libre albedrío contractual

Cada cláusula contractual debe distinguir:

ESTRUCTURA_PREVIA;
ELECCION_ENCARNADA;
FORMA_RELACIONAL;
RUTA_ALTERNATIVA.

Niveles de determinación:

FD0_NOT_EVALUABLE;
FD1_THEME_FIXED_FORM_OPEN;
FD2_ROLE_TENDENCY_FORM_OPEN;
FD3_CONDITIONAL_ROUTE;
FD4_FIXED_EVENT_CLAIM.

FD4_FIXED_EVENT_CLAIM no puede alcanzar SUPPORTED desde astrología.

Toda forma compartida requiere elección y hechos bilaterales. Reconocimiento, contrato u origen no sustituyen consentimiento.

Referencia: reference/contract-free-will.md.

38. Temporalidad contractual v2

Toda cláusula separa:

ESTRUCTURA → ACTIVACION → DESARROLLO → INTEGRACION/TRANSFORMACION/CIERRE.

Estados de ciclo:

LATENT
TRIGGERED
ACTIVE
RECURRING
INTEGRATING
EMBODIED
TRANSFORMED
CLOSED
NOT_EVALUABLE

Estados de ventana:

RETROSPECTIVE_CONFIRMED
RETROSPECTIVE_UNCONFIRMED
CURRENT_ACTIVE
PROSPECTIVE_ACTIVATION
EXPLORATORY
UNANCHORED

Una ventana futura PROSPECTIVE_ACTIVATION no permite asignar EMBODIED, TRANSFORMED ni CLOSED.

IAT mide activación de raíces preexistentes y no modifica IAP.

Referencia: reference/contract-temporality-v2.md.

39. Hechos y biografía documental

Los hechos entran sólo después de congelar la estructura.

Secuencia:

ESTRUCTURA_CONGELADA → EVENTO_DOCUMENTADO → FUNCIÓN_PROBATORIA.

Un evento puede corroborar activación, aportar hechos de cumplimiento, contraevidencia, viabilidad, reciprocidad o fenomenología documentada. No puede crear raíces, cláusulas u origen retrospectivamente.

Calidad documental:

DQ1_PRIMARY_DOCUMENT
DQ2_DIRECT_SELF_REPORT
DQ3_CORROBORATED_REPORT
DQ4_SECONDARY_REPORT
DQ5_UNVERIFIED

Clases públicas: PUBLIC_VERIFIABLE y SYNTHETIC. Los eventos privados no se publican.

Referencia: reference/documentary-events.md. Esquema: schemas/documentary-event-ledger.schema.json.

40. Gate doctrinal

Antes de integrar una fuente en una conclusión metafísica, clasificar la relación entre la afirmación y la fuente:

DIRECT_DOCTRINE
ACADEMIC_DESCRIPTION
HISTORICAL_ANTECEDENT
COMPARATIVE_ANALOGUE
CONTEMPORARY_USAGE
PROJECT_OPERATIONALIZATION
PROJECT_SYNTHESIS

Referencia normativa: reference/doctrinal-gate.md.

Reglas

C_DOCTRINE exige fuente primaria pertinente y trazabilidad.
D_CONTEMPORARY_USAGE no confirma ontología.
PROJECT_OPERATIONALIZATION y PROJECT_SYNTHESIS permanecen E_PROJECT_HYPOTHESIS.
El gate doctrinal y el gate astrológico son independientes.
El número de fuentes nunca aumenta IEM, IAP ni la fuerza de una raíz astrológica.
Una categoría con doctrina bien definida pero sin discriminador astrológico suficiente permanece INSUFFICIENT en el caso.
Una firma astrológica sin correspondencia doctrinal inequívoca no autoriza a reescribir una tradición histórica.

Objeto recomendado: schemas/doctrinal-claim.schema.json.

41. Separaciones doctrinales obligatorias v1.4

ALMAS preserva, entre otras, las siguientes no-equivalencias:

elección preencarnatoria ≠ prueba preencarnatoria ≠ misión ≠ plan del alma ≠ contrato bilateral;
gilgul ≠ contrato álmico;
zivug ≠ twin flame;
bat zug ≠ split soul;
raíz del alma luriana ≠ Mónada teosófica;
tikkun ≠ reunión romántica;
uso literario victoriano de Twin-Flame ≠ doctrina Summit Lighthouse;
astrología esotérica de Bailey ≠ astrología contractual ALMAS;
carta dracónica ≠ prueba de vidas pasadas;
reconocimiento/sincronicidad/transformación reportados ≠ ontología.

Estas separaciones son parte del contrato de regresión de la metodología.

42. Validación externa y preregistro

ALMAS distingue estrictamente DEVELOPMENT_ONLY, INTERNAL_REPLICATION, EXTERNAL_HOLDOUT, FROZEN_CONFIRMATORY, RETIRED y NOT_EVALUABLE.

Un caso que haya intervenido en descubrir, ajustar o seleccionar una regla no puede validar externamente esa misma regla en la versión correspondiente.

Flujo preferente:

BLIND_STRUCTURAL → DOCUMENTARY_OPENING → FINAL_AUDIT.

Las autoetiquetas soulmate/twin-flame pertenecen a D_CONTEMPORARY_USAGE y nunca constituyen ground truth ontológico.

Endpoints primarios:

EV1_REPRODUCIBILITY
EV2_FALSE_SPECIFICITY
EV3_AMBIGUITY_PRESERVATION
EV4_CORE_SURVIVAL
EV5_CONTRACT_SPECIFICITY
EV6_LABEL_INDEPENDENCE
EV7_DOCTRINAL_ATTRIBUTION
EV8_TEMPORAL_ANCHORING

Errores metodológicos explícitos:

FALSE_SPECIFICITY, DEPENDENCY_INFLATION, NARRATIVE_LEAKAGE, DOCTRINAL_OVERREACH, TEMPORAL_CREATION, LABEL_LEAKAGE, CASE_FITTING, PRIVACY_BREACH.

CASE_FITTING invalida el estatus confirmatorio de la ejecución.

La validación externa evalúa generalización, reproducibilidad y especificidad metodológica. No se presenta como demostración experimental de una ontología metafísica.

Referencia: docs/EXTERNAL_VALIDATION_PROTOCOL.md.

43. Cláusula contractual C4–C8

Desde ALMAS 1.10.0, toda cláusula contractual debe separar explícitamente:

CONTENIDO_RECONSTRUIDO → MECANISMO_DE_ACTIVACION → PRUEBA_CONTRACTUAL → INTEGRACION → CUMPLIMIENTO.

Campos normativos:

resolution_level — R0–R4;
reconstructed_contract_content;
activation_mechanism;
contract_test;
integration_requirement;
fulfillment_signature;
claim_refs;
allowed_conclusion;
inferential_ceiling.