DEV Community: AETHERCORE / Sora Attilas

Why This Astrology Feature Makes No New LLM Call: 386 Fixed Rules and a Separate Explanation Layer

AETHERCORE / Sora Attilas — Fri, 11 Sep 2026 09:39:01 +0000

The fastest way to build an AI astrology feature is obvious: send chart data to a language model and ask for a profile. The result may read well, but several engineering questions immediately become harder.

Can the same input reproduce the same judgment?
Can a sentence on screen be traced back to a calculated condition?
Can an editor repair an explanation without silently changing the matcher?
Can a model update change prose while leaving the product's labels untouched?

AETHERCORE operates GenesisCore, a product that calculates Western astrology and Jyotish as separate routes and presents the results on screen and in PDFs. On September 9, 2026, we added a detailed Five Paths view to both paid plans. The new surface includes a radar chart, matched conditions, interpretive notes, reference people, and a one-page PDF.

The Five Paths judgment itself makes no new LLM call. It uses fixed rules and a prepared explanation dictionary. Existing Western and Jyotish analysis still uses AI; the boundary is local to this feature.

The public pipeline

birth input
  -> Western / Jyotish chart computation
  -> fixed-rule matching
  -> path-group and detailed-rule IDs
  -> explanation and reference-data lookup
  -> result tabs and one-page PDF

This is a public behavior model, not a claim that every internal component has been open-sourced. Its purpose is to make the responsibility of each output layer visible.

Three kinds of information share one screen

The radar chart is easy to mistake for a personality or aptitude score. It is neither. The values compare the number of matched path-family types with a 420-person development reference. They are not ability ratings, career recommendations, or success probabilities. A zero means that no current fixed rule matched for that path; it does not mean the person lacks the corresponding ability.

The page keeps three data layers distinguishable:

Layer	Visible material	Responsibility
Judgment	placements, rule IDs, match conditions	what was calculated and matched
Interpretation	path names, meaning, rationale, practical contexts	how the symbolic structure is explained
Record	occupations, activities, comparison notes, sources	what was documented about reference people

That separation matters more than the chart design. It prevents a calculated match from quietly turning into a claim about ability or causation.

73 path groups are not 386 independent findings

The product dictionary currently covers 73 path groups and 386 detailed rules.

A path group is a reading unit that can contain several concrete routes. A detailed rule is the unit used to show which system, chart, position, or relation matched. Several rules may lead to the same social function, and one person may display several functions at once.

The interface preserves distinctions such as D1 versus D10 and the rule position versus a reference position. Display fields vary with the rule. The goal is a traceable answer to “why did this path appear?” rather than a decorative score alone.

The current dictionary size describes product coverage. It does not mean that all 386 detailed rules have been independently validated one by one.

Why split matching from explanation?

Reproducibility

With the same input, rule version, and dictionary version, the Five Paths result can follow the same route again. Sampling variation from an LLM does not enter the judgment layer.

Traceability

A label can be followed back to a path group, a detailed rule, and the calculated placement. When something is wrong, we can ask whether the defect belongs to computation, matching, wording, or reference data.

Editorial control

An unclear description or weak source can be corrected without rewriting the matcher. A rule change can be reviewed against the smaller set of affected explanations and screens.

Claim control

The product can show three different statements without merging them:

a condition matched;
the condition is interpreted in a particular way;
a documented person provides material for comparison.

Those statements have different evidential weight. The UI and the data model should respect that difference.

What does “509 records” count?

The reference-person layer contains 509 edited person-by-path records in Japanese and English. It is not a dataset of 509 unique people, and it is not 509 independent experiments. The same person may contribute material to more than one path.

This may sound like a small wording detail, but it is a data-contract issue. Once marketing copy calls a join-table row a unique subject, every later interpretation becomes unreliable.

What we tested—and what we did not

After release, the team checked 40 Japanese and English pages, eight paid-result variants, desktop and mobile rendering, public images, and consistency with the PDF sample. The PDF process included 1,522 layout inspections plus visual checks of representative outputs.

These checks support implementation, rendering, layout, and document consistency. They do not establish independent scientific replication, causation, personal ability, or future-prediction accuracy. A full production purchase run including paid AI generation and an actual customer email delivery has not yet been completed end to end.

A practical design rule

An AI product does not need to use generative AI at every layer. Use flexible generation where interpretation benefits from it. Keep deterministic rules where users need stable labels, traceable conditions, and reviewable changes.

For a domain in which calculation, tradition, interpretation, and personal meaning easily blur together, that boundary is part of the product.

When 359 Becomes 2 : Testing Boundary Sensitivity in Circular Features with Python

AETHERCORE / Sora Attilas — Wed, 09 Sep 2026 15:46:26 +0000

Suppose a feature changes from 359.060 degrees to 2.794 degrees.

A naive subtraction reports -356.266. The actual forward movement is +3.734 degrees. If those values are converted into 30-degree categories, the label changes as well—even though the underlying motion is smooth.

This boundary problem appears in headings, clock time, seasonal phase, hue, and any feature defined on a circle. I encountered it while testing how a ten-minute birth-time shift propagates through an astrological calculation pipeline.

The astrology context supplies a useful real example. The engineering problem is broader: how should a system preserve continuous circular data, categorical labels, and uncertainty at the same time?

The experiment

I held the synthetic date and public Tokyo coordinates constant and changed only local time.

date: 2000-01-01
timezone: Asia/Tokyo
latitude: 35.6762
longitude: 139.6503
times: 12:00, 12:10, 13:00, 14:00
sidereal mode: Lahiri
house system: Whole Sign

No personal birth data are involved.

The current GenesisCore calculation path produced these values:

Local time	Sun	Moon	Ascendant
12:00	256.130°	194.948°	359.060°
12:10	256.137°	195.032°	2.794°
13:00	256.172°	195.451°	20.340°
14:00	256.215°	195.954°	38.752°

The Sun moved about 0.085 degrees over two hours, the Moon about 1.006 degrees, and the Ascendant about 39.692 degrees around the circle.

Why ordinary subtraction fails

For values normalized to [0, 360), a forward angular difference can be calculated with modulo arithmetic:

def forward_delta(base: float, current: float) -> float:
    return (current - base) % 360.0


print(forward_delta(359.060, 2.794))
# 3.734

If direction can be positive or negative, use the shortest signed distance:

def signed_circular_delta(base: float, current: float) -> float:
    return ((current - base + 180.0) % 360.0) - 180.0

The right choice depends on the process. In this experiment, time only moves forward and the sampled Ascendant advances around the circle, so the forward delta is the relevant quantity.

Reproduce the source angles

The following function uses Swiss Ephemeris. It converts the local timestamp through an IANA timezone, calculates tropical Sun, Moon, and Ascendant values, and then applies Lahiri ayanāṃśa.

python -m pip install pyswisseph matplotlib

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

import swisseph as swe

LAT, LON = 35.6762, 139.6503
TZ = ZoneInfo("Asia/Tokyo")

swe.set_sid_mode(swe.SIDM_LAHIRI)


def sample(hour: int, minute: int) -> dict:
    local_dt = datetime(2000, 1, 1, hour, minute, tzinfo=TZ)
    utc_dt = local_dt.astimezone(timezone.utc)
    utc_hour = utc_dt.hour + utc_dt.minute / 60 + utc_dt.second / 3600
    jd = swe.julday(
        utc_dt.year, utc_dt.month, utc_dt.day, utc_hour, swe.GREG_CAL
    )

    sun = swe.calc_ut(jd, swe.SUN, swe.FLG_SPEED)[0][0]
    moon = swe.calc_ut(jd, swe.MOON, swe.FLG_SPEED)[0][0]
    ayanamsa = swe.get_ayanamsa(jd)
    _cusps, ascmc = swe.houses_ex(jd, LAT, LON, b"W", swe.FLG_SWIEPH)

    return {
        "minute": (hour - 12) * 60 + minute,
        "sun": (sun - ayanamsa) % 360.0,
        "moon": (moon - ayanamsa) % 360.0,
        "ascendant": (ascmc[0] - ayanamsa) % 360.0,
    }


rows = [sample(*time) for time in [(12, 0), (12, 10), (13, 0), (14, 0)]]

Plot change, not wrapped position

Plotting the raw Ascendant values would draw a large downward line between 359 and 2 degrees. That line is a coordinate artifact. Convert each series to forward change from the baseline first.

import matplotlib.pyplot as plt


def forward_delta(base: float, current: float) -> float:
    return (current - base) % 360.0


minutes = [row["minute"] for row in rows]

for key, label in [
    ("sun", "Sun"),
    ("moon", "Moon"),
    ("ascendant", "Ascendant"),
]:
    baseline = rows[0][key]
    changes = [forward_delta(baseline, row[key]) for row in rows]
    plt.plot(minutes, changes, marker="o", label=label)

plt.xlabel("Minutes after 12:00")
plt.ylabel("Forward angular change (degrees)")
plt.title("Input-time sensitivity of calculated chart features")
plt.grid(alpha=0.25)
plt.legend()
plt.tight_layout()
plt.show()

This representation preserves the process being measured. It also makes the different sensitivities immediately visible.

Feature engineering near a circular boundary

The example suggests four design rules.

Preserve the original angle

A category such as a zodiac sign or compass sector loses distance information. Store the normalized angle beside the label. If later analysis uses only categories, that should be an explicit modeling choice.

Add distance to the nearest boundary

For 30-degree segments:

def boundary_distance(angle: float, width: float = 30.0) -> float:
    offset = angle % width
    return min(offset, width - offset)

This makes boundary sensitivity measurable. A label derived from an angle 0.1 degrees from a boundary should not carry the same stability assumption as one 15 degrees from it.

Consider sine/cosine encoding

Many statistical and machine-learning models will treat 359 and 2 as far apart. Circular encoding keeps neighboring angles close:

import math


def encode_angle(angle: float) -> tuple[float, float]:
    radians = math.radians(angle)
    return math.sin(radians), math.cos(radians)

This does not solve every domain question, but it removes the artificial discontinuity at zero.

Propagate input uncertainty

When the timestamp is uncertain, sample the defensible time interval. A result can then be labeled:

stable throughout the interval;
continuous but boundary-sensitive;
category-changing;
unavailable because the input is insufficient.

A precise-looking category should not hide an imprecise timestamp.

The role of astrology in this example

An astronomical position can be reproducible while an astrological interpretation remains unverified. Keeping those layers separate is central to the design.

AETHERCORE develops GenesisCore with separate Western and Jyotish calculation paths. Shared birth records pass through different declared coordinate and rule systems. The public route-research project then asks whether frozen chart-derived features are associated with documented social classifications.

The circular-data lesson affects that research directly. A sign-membership feature, a degree-based feature, and a boundary-distance feature are three different hypotheses. Reproduction requires the code and configuration to say which one was tested.

Project and source links

The next useful test is to apply the same stability labels to every time-sensitive output and show them directly in the result UI.

From 9,999 Sign Vectors to One maxT Threshold: Auditing GenesisCore v7

AETHERCORE / Sora Attilas — Sat, 29 Aug 2026 11:19:37 +0000

The line that matters most in our public reproduction script is not a p-value. It is the matrix multiplication that forces every estimable surface to face the same 9,999 person-level sign vectors.

Publisher: AETHERCORE. We build GenesisCore, a Western astrology and Jyotish analysis system, and publish the associated empirical research. This article inspects one narrow question in the current 420-person development result: how did the implementation control multiplicity across the declared evaluation package?

Project and study recap
What enters the script
Why the family has 22 surfaces
The four lines that generate maxT
Adjusted p-values and simultaneous lower bounds
What M3 handles separately
Decoys, ablations, and failed history
Reproduce and review the code
Previous and next in this series

Project and study recap

GenesisCore converts linked astrological rules into testable data structures. The accompanying study asks whether frozen rule chains are associated with five documented social-expression functions: advocacy, authored symbolic production, collective realization, technology or product implementation, and competitive performance.

Version 7 uses 420 unique people in a development dataset. All five risk differences remained positive after adding birth era, evidence-measurement regime, and collection source. Earlier v3–v5 person-out tests remain non-positive. We therefore report v7 as a development-set result with measured-confound robustness, with an independently frozen person-out replication still open.

The multiplicity problem is concrete. The package contains several functions and more than one exposure surface per function. Reading five small p-values after searching freely across that structure would tell us very little. The code must preserve the declared family, preserve person-level dependence, and calculate the threshold from the maximum statistic in each draw.

What enters the script

The public matrix contains 420 anonymous rows. analysis_order fixes their order. Each row carries an opaque release_id, measured-factor groups, observed functions, and binary surface values.

The structure is approximately:

{
  "release_id": "opaque-id",
  "analysis_order": 1,
  "birth_era": "...",
  "source_evidence_regime": "...",
  "collection_source_group": "...",
  "observed_functions": ["..."],
  "surfaces": {
    "function-name": {
      "pp_both_system": 0,
      "any_tier_both_system": 1
    }
  }
}

The reproduction script sorts on analysis_order, asserts the exact 1–420 sequence, builds outcome arrays from observed_functions, and builds exposure arrays from surfaces. The order check matters because a person-level sign vector only has meaning when it is applied to the same fixed row order on every run.

Why the family has 22 surfaces

The five new outcomes are the primary reporting targets, while the multiplicity family spans 11 functions. Two frozen exposure surfaces are evaluated per function, giving 22 surfaces.

Eighteen surfaces are estimable. Four are structural zeros: their exposure column is constant, so a statistic cannot be estimated. The script records those four cases and asserts that exactly 18 influence vectors remain.

Dropping the four zeros silently and renaming the remaining 18 as the original family would make the family depend on what happened to be estimable. Keeping the 22-surface declaration visible makes that choice auditable.

For each estimable surface, the script calculates a null-score influence vector after residualizing against the M3 design. Stacking those vectors produces a 420-by-18 matrix.

The four lines that generate maxT

The implementation is short enough to inspect directly:

rng = np.random.default_rng(SEED)
signs = rng.integers(0, 2, size=(MAXT_DRAWS, 420), dtype=np.int8).astype(float) * 2.0 - 1.0
max_t = np.max(signs @ np.column_stack(influences), axis=1)
critical = float(np.quantile(max_t, 0.95))

signs has shape (9999, 420). One row is one draw; one column is one person. Multiplication by the 420-by-18 influence matrix gives an array of shape (9999, 18).

The key design choice is reuse. During a draw, a person's -1 or +1 sign is reused across all 18 estimable surfaces. If the same person contributes to several functions, that dependence is retained inside the draw. Each draw then contributes one value: the maximum statistic across the 18 columns.

The 95th percentile of those 9,999 maxima was approximately 2.59217.

Adjusted p-values and simultaneous lower bounds

For a primary surface, the script compares its observed t-statistic with the full max_t distribution:

adjusted_p = (1 + np.sum(max_t >= observed_t)) / (MAXT_DRAWS + 1)
lower = risk_difference - critical * hc3_standard_error

The five reported outcomes were:

Function	M3 difference	maxT adjusted p	Simultaneous one-sided 95% lower bound
Advocacy / public cause	+33.60 pp	0.0001	+18.48 pp
Authored symbolic production	+39.08 pp	0.0001	+27.79 pp
Collective realization	+27.95 pp	0.0001	+16.01 pp
Technology / product	+32.49 pp	0.0008	+9.64 pp
Competitive performance	+32.14 pp	0.0047	+6.93 pp

All five simultaneous lower bounds remained above zero. That is the selection-aware result we want reviewers to inspect. A single attractive raw p-value is not carrying the claim.

What M3 handles separately

The maxT layer controls multiplicity across the fixed family. It does not make historical records comparable by itself. The model sequence handles measured differences in the data:

M0: no added blocks;
M1: birth era, five levels;
M2: evidence-measurement regime, three levels;
M3: collection source, six levels.

The main table reports M3 risk differences. Additional checks include within-era and within-source permutations, raw strata summaries, leave-one-source-out fits, and separate opportunity-data adjustments for 311 and 109 people.

These checks address recorded factors. Unmeasured confounding remains possible, which is one reason the next external dataset matters.

Decoys, ablations, and failed history

The repository also contains 7,634 adversarial-decoy rows representing 708 unique exposure sets. They were constructed after outcome information was available. Their purpose is to attack specificity: does an observed surface exceed the 95th percentile of these necessary-condition alternatives?

They are not a random null distribution. The chance-control statement comes from maxT. Decoy performance answers a different question.

Western-only, Jyotish-only, and full-system exposures are also refit. Those ablations describe which rule family may carry a result under the present specification. No Western-by-Jyotish interaction test has been run, so the ablations do not establish synergy.

Finally, the non-positive v3–v5 person-out results remain in the repository. v7 adds robustness inside the development set; it does not turn the earlier external tests into successes.

Reproduce and review the code

git clone https://github.com/AETHER-CORE1219/Genesis-Core-route-research-public.git
cd Genesis-Core-route-research-public
python3 -m pip install -r independent_social_expression_v7/requirements.txt
PYTHONDONTWRITEBYTECODE=1 python3 independent_social_expression_v7/scripts/reproduce_v7.py
PYTHONDONTWRITEBYTECODE=1 python3 independent_social_expression_v7/scripts/validate_public_v7_privacy.py
(cd independent_social_expression_v7 && sha256sum -c CHECKSUMS.sha256)

A focused review can start with six questions:

Does analysis_order lock the same opaque 420 rows?
Is the 18-column influence matrix derived from the declared 22-surface family correctly?
Are person-level signs shared across every estimable surface in a draw?
Is axis=1 taking the intended per-draw maximum?
Do the critical value, adjusted p-values, and lower bounds match RESULTS.json?
Do the privacy validator and checksums pass?

AETHERCORE develops and operates GenesisCore, which provides free results, paid detailed analysis interfaces, and emailed PDF reports. The commercial relationship is disclosed here because it is relevant context; the research code and result files can be reviewed without using the service.

Previous and next in this series

The previous article introduced AETHERCORE, the GenesisCore product, the v1–v7 history, and the public package. This article followed the maxT implementation from the anonymous matrix to the simultaneous bounds. Next, we will inspect analysis_order, the privacy validator, and the checksum chain that make the package reproducible without publishing identities.

If you find a flaw in the fixed family, influence calculation, sign reuse, or adjusted-bound calculation, please include the code path and the result produced by the alternative specification.

Who We Are, What GenesisCore Builds, and Why Our Astrology Research Is Open

AETHERCORE / Sora Attilas — Tue, 25 Aug 2026 15:34:54 +0000

Publisher: AETHERCORE, the research and business organization behind GenesisCore.

What we build: an analysis system combining Western astrology, Jyotish, AI-assisted interpretation, numerical processing, interactive results, and PDF reports.

What we will publish here: data structures, reproducible code, statistical design, failed tests, product boundaries, and new research results.

Hello. We are AETHERCORE.

Our main project is GenesisCore. It is both an astrology-analysis product and a research program. Users can receive a free result, explore a paid detailed analysis interface, and obtain an extended PDF report by email.

The subject is astrology. The work we want to discuss with the developer community is broader: how to turn a large symbolic rule system into structured data, how to connect it to auditable real-world records, how to limit researcher freedom, and how to release a result that another person can recalculate.

This first post introduces the organization, the product, the reason for the research, the failed steps from v1 through v5, and the new v7 result. Later posts will examine the implementation in detail.

What GenesisCore provides
Why developers may care
What we mean by a route
From a chart to a public matrix row
How the research reached v7
The question and result in plain language
How M0, M3, and maxT differ
What is in the public package
How the result can enter the product
What we will publish next

What GenesisCore provides

GenesisCore calculates Western and Jyotish structures from birth date, birth time, and birthplace. It then organizes many interacting rules into explanations, scores, graphs, timelines, and thematic analyses.

The current user-facing surfaces are:

a free result interface;
a paid detailed analysis interface;
a long-form PDF report delivered by email.

The image below shows verified GenesisCore product surfaces. It is not a generated product mockup.

Why developers may care

A large symbolic system creates a technical and epistemic problem. When hundreds of rules can apply to one person, it is easy to select a convincing interpretation after seeing the outcome.

This is a familiar engineering problem in an unusual domain: a flexible rule engine can produce plausible outputs while making its own error rate hard to measure. We therefore separate two activities.

The product calculates and explains a chart. The research layer asks whether a frozen group of astrological chains has a measurable relationship with documented activity across people.

The questions include:

Do different chart expressions converge on the same real-world function?
Can one function be reached through several mechanisms?
Does a result persist after accounting for era and data-collection differences?
Does it survive correction across a declared family of tests?
What should happen when a selected route fails on unused people?

What we mean by a route

A route is not a single placement-to-job lookup. It is a structured chain of chart factors that can converge on a documented social function.

chart factors
  -> frozen relationship pattern
  -> route surface (present / absent)
  -> documented social function (present / absent)
  -> person-level analysis row

The current research focuses on five non-exclusive functions:

advocacy or public-cause action;
authored symbolic production;
organized collective realization;
technology or product implementation;
embodied competitive performance.

A person may express several functions. We code documented activity, not an occupation label inferred from a chart.

From a chart to a public matrix row

The public package reduces each person to an anonymous row. observed_functions records the real-world side from fixed evidence. surfaces records whether the frozen chart-side chains were present. This is an abridged public row:

{
  "analysis_order": 14,
  "release_id": "R0001",
  "birth_era": "BEFORE_1900",
  "observed_functions": [
    "AUTHORED_SYMBOLIC_PRODUCTION",
    "KNOWLEDGE_OR_DISCOVERY_PRODUCTION",
    "ORGANIZED_COLLECTIVE_REALIZATION"
  ],
  "surfaces": {
    "AUTHORED_SYMBOLIC_PRODUCTION": {
      "any_tier_jyotish": true,
      "any_tier_western": false,
      "primary_jyotish": true,
      "primary_western": false
    }
  }
}

The release ID and analysis order replace a personal name. The public package contains no identity lookup table.

How the research reached v7

The history matters because v7 was not our first attempt.

v1: the first measurement method failed

A 12-person pilot tested whether real-world activity could be labelled consistently from public evidence. It did not meet the predefined standard, so we stopped before chart comparison and recorded the failure.

v2: five functions in 420 people

We built an anonymous, duplicate-free development set of 420 people. Five social functions and related astrological candidates were organized into a person-level matrix.

v3–v5: selected candidates did not reproduce on separated people

We tested selected authorship, collective-realization, and competitive-performance candidates on people who were not used to select them. None produced a clear positive result. Those results remain public.

v6: multiple paths and failed tests were integrated

We integrated five functions, 136 groups of related meanings, person-level paths, and the v3–v5 results. This made room for several mechanisms leading toward the same function while preserving the failed tests.

v7: a different question

v7 does not rerun the failed person-out tests with new thresholds. It asks whether the five development-set results survive measured external factors and a declared multiple-testing family.

The question and result in plain language

The core question is:

Among people whose charts contained the corresponding frozen chains, was the documented social function more common than among people whose charts did not? Did the difference remain after adding birth era, measurement regime, and collection source? Did it remain when 22 testing surfaces were evaluated together?

M0 is the raw difference between the two rates. M3 is the adjusted difference after adding birth era, evidence-measurement regime, and collection source.

Function	Chains present	Chains absent	M0	M3	maxT p	Simultaneous 95% lower
Advocacy / public cause	74.65% (71)	37.82% (349)	+36.83	+33.60	0.0001	+18.48
Authored symbolic production	89.41% (85)	50.45% (335)	+38.96	+39.08	0.0001	+27.79
Collective realization	82.50% (120)	55.00% (300)	+27.50	+27.95	0.0001	+16.01
Technology / product	64.71% (34)	27.46% (386)	+37.24	+32.49	0.0008	+9.64
Competitive performance	64.00% (25)	18.48% (395)	+45.52	+32.14	0.0047	+6.93

The primary multiplicity control used 9,999 person-package maxT draws across a fixed 22-surface family. All five simultaneous lower bounds remained above zero.

The result is strong inside the defined development study. It is not an independent person-out replication. It does not establish causality, universal validity, or deterministic career and future prediction.

How M0, M3, and maxT differ

M0 through M3 add measured factors in stages:

M0: chain presence only;
M1: add birth era;
M2: add evidence-measurement regime;
M3: add collection source.

Multiple-testing control is a separate layer. The fixed 22 surfaces share the same person-level sign flips in each draw, preserving dependence among surfaces. The following is a shortened version of the public implementation's core idea:

import numpy as np

rng = np.random.default_rng(20260821)
shared_signs = rng.choice((-1.0, 1.0), size=(9_999, len(rows)))

influence_matrix = np.column_stack(surface_influences)
null_max_t = np.max(shared_signs @ influence_matrix, axis=1)

critical_95 = np.quantile(null_max_t, 0.95)
adjusted_p = (1 + np.sum(null_max_t >= observed_t)) / 10_000

Using a shared 420-person sign package for every surface keeps cross-surface dependence in the null distribution. The complete calculation, including studentization and simultaneous bounds, is in scripts/reproduce_v7.py.

What is in the public package

The repository contains more than a narrative README:

methods and function definitions;
an anonymous 420-person analysis matrix;
machine-readable RESULTS.json;
a machine-readable claim boundary;
failure and limitation history;
a reproduction script;
a public-privacy validator;
SHA-256 checksums.

From the repository root:

python3 -m pip install -r independent_social_expression_v7/requirements.txt
PYTHONDONTWRITEBYTECODE=1 python3 independent_social_expression_v7/scripts/reproduce_v7.py
PYTHONDONTWRITEBYTECODE=1 python3 independent_social_expression_v7/scripts/validate_public_v7_privacy.py
(cd independent_social_expression_v7 && sha256sum -c CHECKSUMS.sha256)

How the result can enter the product

AETHERCORE operates both the research and the GenesisCore service. We disclose that commercial relationship.

v7 can support explanation, hypothesis formation, and dialogue. It cannot currently serve as a validated predictor of occupation, behavior, or future events. Product UI must display the research status and the open replication boundary.

Readers can evaluate the public package without using or purchasing the product.

What we will publish next

The next DEV post will explain the shared-sign person-package maxT design and why multiplicity and measured-confound adjustment are separate layers.

Later posts will cover:

public-data privacy and anonymous reproducibility;
the v3–v5 failed person-out tests;
Western-only and Jyotish-only ablations;
the claim boundary between research output and product UI.
GenesisCore v7 primary page
Full public research repository
See the actual GenesisCore product