How PRISM’s chart engine
actually works.

Every chart PRISM produces is stamped with the engine version that produced it. Bumping the version invalidates the cache, and old charts can be re-computed on demand. The current version is ts-0.1.0.

PRISM uses the astronomy-engine library — an open-source pure-JavaScript port of Don Cross’s ephemeris algorithms (cosinekitty’s implementation). Position accuracy: better than 1 arcminute for Sun and Moon, a few arcminutes for outer planets.

Human Design’s tolerance is much wider than that — gate boundaries are 5.625° apart, lines are 0.9375° apart. The engine is far more precise than the framework requires, which means PRISM is never on the wrong side of a boundary because of astronomical imprecision.

Why not Swiss Ephemeris (the heavyweight standard)? Because deploying SwissEph on serverless infrastructure is fragile. astronomy-engine deploys cleanly and produces outputs within 0.01° of SwissEph for the bodies we use.

Human Design uses two snapshots: the Personality (conscious) chart at the moment of birth, and the Design (unconscious) chart at the moment when the Sun was 88° of ecliptic longitude earlier — roughly 88-89 days before birth.

PRISM finds the design moment by Newton iteration on the Sun’s longitude: start with a guess of ~88.7361 days back, compute the Sun’s longitude at that instant, compare to the target (personality longitude minus 88°), adjust by the difference divided by the Sun’s mean motion, repeat. Converges in under 10 steps to better than 1e-7 degrees.

Some calculators use a fixed 88-day offset. That introduces error of up to ~0.5° depending on Earth’s position in its orbit (the Sun moves faster near perihelion, slower at aphelion). PRISM iterates to the exact 88° arc instead.

The 360° ecliptic is divided into 64 gates of 5.625° each. Each gate is divided into 6 lines of 0.9375° each. Each line is divided into 6 colors of 0.15625° each. Each color is divided into 6 tones, and each tone into 5 bases. Total resolution:~0.00521°, or about 19 arcseconds.

PRISM’s pipeline:

1. Compute geocentric ecliptic longitude of the body.
2. Subtract the gate-start longitude (302.0°), modulo 360.
3. Divide by 5.625 to get the gate index, look up the canonical sequence (the I Ching wheel ordering).
4. Take the remainder, divide by 0.9375 to get the line (1-6).
5. Take the remainder, divide by 0.15625 to get the color (1-6).
6. Continue down through tone (1-6) and base (1-5).

The calculation is deterministic. Same inputs + same engine version always produce the same gate, line, color, tone, base.

The North and South Nodes can be computed two ways: the true node (oscillating, instantaneous geometry) or the mean node (averaged, smooth motion). Most Human Design calculators use the mean node; some use the true node; the difference can be up to ~1.5°, occasionally enough to shift the gate.

PRISM uses the mean lunar node, computed via the standard astrodynamic formula referenced from J2000. This is the more common Human Design convention and matches the Jovian Archive lineage. If you compare PRISM’s nodal activations against a calculator using true nodes, you may see disagreement on Color or Tone in a small percentage of charts.

Birth time matters. A 15-minute difference can shift gates and lines. PRISM accepts the IANA timezone identifier (America/Los_Angeles) as the canonical input, and resolves common abbreviations (PDT, EST, GMT, JST) as a fallback.

The local civil datetime is converted to UTC using JavaScript’s Intl machinery, which handles historical DST transitions correctly. We do not use fixed offsets — charts computed for births in 1962 in California correctly use PST/PDT as it existed in 1962.

PRISM ships with a vitest regression suite that runs four fixed birth fixtures through the engine on every commit and asserts:

• Determinism: same inputs twice → same chart id, type, authority, profile, gates, channels.
• Shape contract: 26 activations (13 bodies × 2 sides), all values within canonical ranges.
• Stability: the per-fixture (id, type, authority, profile, defined centers, channels, gate count) snapshot is committed and any drift triggers a failed test.

If we ever modify the engine in a way that changes outputs, the test fails loudly. We then either revert (regression) or bump the engine version (intentional). No silent drift is possible.

Every chart’s ID is sha256(inputs + engineVersion), truncated to 32 hex characters. Identical inputs produce identical IDs. The chart row in the database is keyed on this ID, so the same chart is never computed twice.

When the engine version is bumped, every chart’s ID changes automatically. Old charts remain valid for historical reference; new computations produce fresh rows. This is the same content-addressing pattern Git uses for commits.

PRISM treats birth date, time, and place as PII. They are stored encrypted in the database using envelope encryption: each tenant has its own data encryption key (DEK), wrapped by an active key encryption key (KEK). The chart output itself (gates, lines, channels, type, etc.) is not PII once computed and is stored unencrypted for query performance.

Every read of chart data is recorded in the audit log with tenant, actor, and IP address. PRISM users can export their full data as JSON or self-service-delete their entire account from Settings.