{
  "schemaVersion": "astro-compatibility-replay-v1",
  "observedAt": "2026-09-25",
  "scope": {
    "cases": 362,
    "description": "362 seeded synthetic chart pairs: 260 broadly random, plus deliberately engineered edge cases at/near every aspect's orb limit (both the declared and natalWidth tables, with and without the luminary allowance), house-cusp boundaries, zodiac-sign boundaries, an axis-relabeling trigger and a double-whammy trigger. Every case calls OpenFate's own buildAstroSynastryFacts and a separately written implementation (private verification implementation) configured to use the SAME declared orb table and body set, comparing every cross-chart contact, house overlay and the element blend. The two disputed conventions are analyzed separately below in conventionVariants, never blended into this headline count.",
    "seed": 20260925
  },
  "tolerances": {
    "description": "Exact equality is required on every contact, overlay and element-blend field for every case -- both sides are given the SAME input longitudes (no ephemeris involved), so there is no numeric tolerance to budget; any difference is an unexplained bug."
  },
  "comparedFields": [
    "primary×counterpart cross-aspect contacts: body pair, aspect type, orb, category, tight, key, doubleWhammy",
    "house overlays: guest planet → host Placidus-style house, guest sign, both directions",
    "element blend: each party’s element/modality/polarity counts, the combined element total, and complements"
  ],
  "results": {
    "cases": 362,
    "identical": 362,
    "withDifferences": 0,
    "byReason": {
      "engine-bug": 0,
      "replay-bug": 0
    },
    "byField": {}
  },
  "differences": [],
  "conventionVariants": [
    {
      "id": "natalWidth",
      "dimension": "orbVariant",
      "label": "natalWidth -- OpenFate's own NATAL orb table reused for synastry (no separate tightening)",
      "description": "A genuinely common alternative to OpenFate's tightened synastry orb table is to reuse an engine's ordinary NATAL orb widths for cross-chart contacts too, with no separate tightening. This measures how many of the sampled cases would gain or lose contacts under that wider table, relative to OpenFate's declared headline -- informational, a school decision for the product owner, never blended into results above.",
      "citations": [
        {
          "source": "internal implementation (ORBS)",
          "note": "OpenFate's own natal orb table (Conjunction/Opposition/Trine/Square 8 degrees, Sextile 6), reused here unmodified as the cited alternative."
        },
        {
          "source": "internal implementation (SYNASTRY_ORBS comment)",
          "note": "The declared synastry table’s own source comment states it is \"deliberately TIGHTER than the natal policy orbs (8/6)\" specifically because wide orbs flood a 12x12 point cross-chart with ~30 weak contacts -- i.e. OpenFate’s own code acknowledges the natural alternative this variant measures."
        }
      ],
      "impact": {
        "casesWithContactChange": 362,
        "casesWithOverlayChange": 0,
        "exampleCase": {
          "id": "case-001",
          "input": {
            "primaryBody": "Venus",
            "counterpartBody": "Mars",
            "changed": "+ Venus Trine Mars"
          }
        }
      }
    },
    {
      "id": "excludeOuters",
      "dimension": "bodySet",
      "label": "excludes Uranus/Neptune/Pluto (generational-planets convention)",
      "description": "A commonly cited synastry convention excludes the three slow \"generational\" outer planets (Uranus, Neptune, Pluto) from personal cross-chart contacts and house overlays, on the reasoning that a placement lasting years to decades says little about one specific pairing. This measures how many of the sampled cases would lose a contact or overlay if outers were excluded -- informational, never blended into results above. The element blend always uses all ten bodies regardless of this variant (excluding outers from an element COUNT is a much rarer position and is out of scope here).",
      "citations": [
        {
          "source": "internal implementation (COUNTING_BODIES / ASTRO_ENGINE_POLICY doc comment)",
          "note": "OpenFate's own policy already distinguishes the ten counted bodies from points, but declares no split within the ten between personal and generational planets for synastry purposes -- this variant tests the impact of drawing that line, a widely discussed distinction in synastry literature though not a single universally cited numeric source."
        }
      ],
      "impact": {
        "casesWithContactChange": 362,
        "casesWithOverlayChange": 362,
        "exampleCase": {
          "id": "case-001",
          "input": {
            "primaryBody": "Sun",
            "counterpartBody": "Pluto",
            "changed": "- Sun Trine Pluto"
          }
        }
      }
    }
  ],
  "knownIssues": [],
  "limitations": [
    "Inputs are hand-built ecliptic longitudes fed directly into a minimal AstroProfile, not real ephemeris-derived charts from birth data -- planet/cusp position ACCURACY is already independently checked by the single-chart replay (private verification implementation); this replay isolates the cross-chart pair-rule layer built on top.",
    "metadata.localIso is deliberately blank on every synthetic chart, so buildAstroSynastryFacts’s timingWindows (annual-profection timing) always comes back empty -- this replay does not cover timing windows, prose interpretation, or the birth-time honesty gates (every synthetic chart is always fully \"known\"), which are separate OpenFate synastry facts with their own coverage elsewhere.",
    "House cusps are a jittered near-Equal-House division (30 degrees apart plus small noise), not a real Placidus sweep across latitudes -- sufficient to exercise the wrap-aware house-lookup algorithm and its cusp boundaries, but not a house-SYSTEM accuracy check (that is the single-chart replay’s job).",
    "conventionVariants.*.impact is an aggregate + one example per variant, not a full second per-case table (which would roughly double this file’s size for a fact fully reproducible on demand from the published public script with --orb-variant=natalWidth or --body-set=excludeOuters against the same cases array)."
  ],
  "citations": [
    {
      "source": "internal implementation",
      "note": "The declared synastry orb table, luminary allowance, axis-relabeling and double-whammy conventions this replay independently re-implements (school decision locked 2026-07-08); not imported by the public script."
    },
    {
      "source": "internal implementation (ORBS) and internal implementation (COUNTING_BODIES, tightOrb)",
      "note": "OpenFate's own natal orb table and ten-body whitelist, cited as the source for the two disputed conventionVariants above and for the undisputed tight-orb threshold."
    }
  ],
  "title": "OpenFate astrology synastry (compatibility) verification summary",
  "publicationKind": "first-party-verification-summary",
  "claimBoundary": "OpenFate performed this comparison using a separately written implementation. This is a publisher-reported result, not independent certification, a public replay kit, or evidence of predictive accuracy. Full execution records and implementation remain private.",
  "receiptSha256": "ca7ef763072d5027d9e2352c763663d911a3bf5678f2c037756d2c15cbafca69"
}