Why the software your astrologer uses changes the verdict

Most of the contested decisions on a matching report were made by whoever wrote the software, years before your chart existed, and printed as though they were arithmetic. Someone typed a date, a time and a place into three fields and pressed a button. The astrologer read out and interpreted what came back. The thing that came back was produced by a rule set nobody in the room chose, and on the printout it looks exactly like a calculation.

None of that is an argument against software. Sidereal positions are genuinely difficult to work out by hand, and a program does that part better than a person with an almanac and a pencil. The difficulty sits one layer up.

What did the program decide before it ever read your birth details?

Roughly a dozen questions on which the classical sources do not agree, all of them resolved once, at the time the program was written, for every report it will ever print. They are not exotic questions. They are the ordinary joints of the method, and each has more than one defensible answer in print.

Here is the list, in the order a program works through it. Which ayanamsa to subtract. Which historical time-zone offset applies to a birthplace on a date decades ago. Which houses count for Mangal dosha. Which points Mars is judged from. Whether friendship between two Moon lords has to be mutual or one-directional. Which of the circulating yoni tables to load. Whether the star distance is counted in one direction or both. Which cancellation rules exist at all, and which of them outrank which. Where the acceptance line sits. Whether a hard veto exists.

A program answers every one of those the same way for every user, forever. That is not a criticism; it is what a program is. But it means the report you are holding is the output of a configuration, and a configuration is a thing that can be listed, compared and disagreed with. The report almost never lists it.

The asymmetry is what stings. The astrologer can be questioned. The software cannot, because it is not present, and its choices arrive wearing the costume of a computed result.

Almost none of those dozen answers is recorded anywhere a reader can reach, which is the part that turns a reasonable engineering decision into a problem. A choice made once, at the time the code was written, does not announce itself afterwards. It becomes the way the program behaves, and behaviour reads as fact. A preset name is not a disclosure either: a menu offering North Indian and South Indian tells you that a switch exists without telling you which houses moved when it was flipped, or what else moved with them. So the document in your hand carries a dozen decisions and displays none, and the reader could not have known there was anything to ask about. That gap is what this page is for. Not that the choices are wrong — most of them are careful — but that they are made where nobody can see them and then printed where everybody can.

Two of the five readings run here are software defaults and not textual schools, which is why this is not a marginal complaint: for a very large number of families the configuration is the tradition they were judged by. Which two those are, what each of the other three descends from and where each is followed is the business of the field guide to the five readings. The business of this page is narrower: a setting nobody printed is still a setting, and it governs the verdict every bit as firmly as a verse would.

The setting nobody argues about is the one that moves the number

The one that gets argued about is the house list; the one that moves the rate far further is the reference point, and reports almost never state it. These are two separate settings and they are constantly collapsed into one.

The house list is the familiar dispute. Mangal dosha is raised when Mars occupies one of a named set of houses, and the sets differ: the northern one omits the 2nd house, the southern one omits the 1st, and each omission is a faithful reading of the verse its school descends from and not an oversight. Which school reads which text — the Manasagari lineage on one side and the Parashara one on the other — is a question of lineage, and the field guide answers it. What matters here is that a program has to load exactly one of these lists before it can compute anything, and then never says which.

The set most software ships is the union of the two. Keep every house either verse names and you have a list that appears in no classical text on its own. This one invites an argument. It is a perfectly reasonable engineering instinct — two sources conflict, so cover both — and it is also the only one of the circulating lists with no textual authority whatsoever, and it flags more people than either source does alone. It has been in use long enough to have acquired its own weight, which is a real argument, but it is a different argument from the one it is usually offered as.

Underneath that sits the setting nobody mentions. Some readings judge Mars from the ascendant only. Others judge it from the Moon and from Venus as well, raising the flag if Mars is badly placed relative to any of the three. That is not a stricter version of the same test.

It is three tests where there was one.

Put the narrowest and widest documented profiles side by side and the share of charts flagged runs from 11.7% under Astro-Vision (serious Kuja dosha only) to 73% under OP / SKU panchangas. Identical planetary positions in both cases. Across 2,000 computed charts, 61.4% come out manglik under one school and completely clean under another. You can see all five verdicts on one page in the manglik checker, which is the only way the spread stops being an abstraction.

The single most consequential line in most matching reports was set by a configuration the report does not disclose.

How much can a lookup table differ between two honest programs?

Enough to move a total by a point or two, which near the acceptance line is the whole verdict. The 36-point score looks like arithmetic, and arithmetic looks like the sort of thing that cannot vary. It varies, because each of the eight kootas is computed from a table and several of those tables exist in more than one documented version.

Yoni sorts each birth star into an animal group and two circulating tables place some stars in different groups. Tara counts the distance between two birth stars, and one convention counts in a single direction while another counts both ways and takes the better result. Graha maitri scores the friendship between two Moon lords, and the schools split on whether that friendship has to be mutual or whether one-directional friendship is enough — a difference that turns out to have two entirely separate conventions behind it and not a sloppy implementation.

None of those is an error and each has a source. A program picks one per table, and then it stops mentioning the pick. The picks are individually small and they do not stay small, because the totals cluster: an enormous number of couples sit within a point or two of the conventional line, so one differing table is the entire distance between accept and refuse for them.

The cancellation rules are the worst case of this, and they get almost no attention. A dosha is raised, and then a set of conditions may set it aside. How many conditions? That depends entirely on the program. Some implement three or four of the famous ones. The registry this engine runs holds dozens, drawn from named printed sources, along with the precedence between them, because several cancellations contradict each other and the order they fire in changes the outcome. Two programs can agree on every koota table, agree that nadi dosha is present, and still print opposite verdicts because one of them checked a condition the other has never heard of. The list of conditions checked is the most informative table a report could print and is the one most often omitted entirely.

Notice what none of this requires. Nobody had to be careless, no corner had to be cut, and no source had to be misread. Every step is a competent person following a documented rule. The divergence is structural, which is also why it is stable enough to be measured.

Run every one of the 11,664 possible ordered birth-star pairings under five readings — the whole population and not a sample drawn from it — and 56.4% trigger a tested difference or veto across the combined census checks. Meanwhile the headline rates barely move: about 66.7% of all pairings clear the conventional line whichever reading you use, and the mean total sits at 20.1 out of 36. A configuration barely shifts the population and reliably shifts the particular couple, and a family only ever meets the particular couple.

One pair of birth records, five documents

The couple in the published sample report are Priya, born in Pune with her Moon in Ashwini, and Arjun, born in Chennai with his in Purva Bhadrapada. Their two birth records went through all five readings. The totals landed between 13.5 and 17 out of 36, two readings accepted them and three refused, and the groom was manglik under three of the five and clean under the rest.

Look closely at the spread in the score, because it is not dramatic and that is the point. A gap of a few points sounds like rounding. It is not rounding: it is the accumulated effect of four or five table choices, and it straddles the acceptance line, so the readings that scored the couple lowest are among the ones that accepted them. The score and the verdict do not move together, because the readings do not all draw the line in the same place or treat the same components as fatal.

The manglik line moves for a different reason again. The groom’s Mars sits in the same house in every one of the five documents — the astronomy is not in dispute anywhere — and whether that house is on the list, and whether the list is applied from the ascendant alone or from the Moon and Venus too, is the entire difference between three documents saying manglik and two saying clean.

Read the five documents in sequence and the experience is disorienting in a specific way. Nothing in any of them is hedged. Each states its verdict plainly, each is internally consistent, and each would be perfectly convincing on its own. It is only the fifth one, laid beside the first, that makes the first one look like a position rather than a finding.

The sample report cites the text each rule came from, which is the only reason any of this is legible instead of a heap of contradictory verdicts. 19 rules fired across the five readings for that one couple, and every one of them names its source on the page where it fires. A report that does not do that leaves the reader with the difference and none of the reasons for it.

Does any of this mean one of the programs has a bug?

Almost never. Each program is computing exactly what it was told to compute, from a rule set that traces to a printed source, and it does so consistently across every chart. That is what correct software looks like. The problem is not defective computation; it is that the rule set is invisible on the output.

The astronomy underneath is not where the disagreement lives either. Every serious implementation resolves planetary positions to a small fraction of a degree, and the arithmetic is checkable against the JPL DE440 ephemeris published by NASA. Nobody in this argument disputes where Mars was. They dispute which houses to count it in, which is a question no ephemeris has an opinion about.

It also does not follow that a family running a software default is being unreasonable. That default may line up exactly with what their community has followed for generations, and a match between the two is not a coincidence to be cynical about: the developers were mostly trying to reproduce a practice, not invent one.

What does follow is narrower. “The computer said” is not a more objective authority standing behind the astrologer. It is one more reading, with a house list and a set of tables and a starting assumption, all of which have names. The thing to be wary of is a report that presents its output as the only arithmetic available.

Do the ayanamsa and the time zone vary between programs too?

Yes, and both of them run before any matching rule does, which makes them the two settings with the longest reach. Everything in the report is computed from a birth star and a set of house positions. Those come from a longitude, and a longitude comes from an instant and a convention.

The ayanamsa is the offset a program subtracts to convert a tropical longitude into the sidereal one an Indian chart is drawn from. Published values differ by more than a degree, which is a meaningful fraction of the width of a nakshatra, so a Moon near a boundary lands in one star under one value and in the next star under another. Everything downstream is then recomputed from a different starting point. That has a whole page of its own, because it affects every reading on this site equally.

The time zone is the setting nobody thinks about at all, and it is the most quietly interesting one. India has not always run at a single offset. The IANA time-zone database, which is the historical record most software builds on, records an hour’s wartime advance in the 1940s and a pre-1906 offset for eastern India that is not +5:30 at all. A program that applies a flat +5:30 to every Indian birth in every year will be an hour out on some of them. An hour moves the ascendant by roughly half a sign, which moves the house each planet occupies, which moves the manglik verdict.

The national ephemeris that Indian panchangas are computed from is produced by the Positional Astronomy Centre in Kolkata, and it is useful to know that such an office exists, because it is the closest thing to an official answer on the ayanamsa question in India. It is not a referee on the matching rules. Nobody is.

Why does a program never print the settings it used?

Because printing them would make the report look uncertain, and the market rewards reports that look certain. That is a commercial observation and not a technical one, and it explains the design better than any technical account does.

A page that says “36 points, 17 scored, not recommended” reads as a fact. The same page, honestly annotated — “under this house list, from these reference points, on this ayanamsa, with these two cancellations checked and neither met” — reads as an argument. An argument invites a second opinion. A fact does not.

There is a gentler explanation too, and it is probably the true one for most software. The settings were chosen so long ago, by someone reproducing the practice they knew, that nobody involved experiences them as settings. They are simply how matching is done. It takes running several rule sets side by side over a whole population before the choices stop being invisible, and almost nobody has a reason to do that.

There is also a genuine design problem hiding behind the commercial one. Disclosing everything would produce a page of configuration that most readers would skip, and a setting buried on page thirty of an appendix is barely more visible than a setting nobody printed. The useful version is not a dump of parameters. It is the small number of settings that actually changed the verdict for this particular couple, printed where the verdict is, with the alternative shown next to it. That is a harder thing to build than a configuration page, which is probably the other reason it is rare.

What should you ask the person who ran the report?

Four things, all of them factual, none of them a challenge to anyone’s competence. Which program produced this, and which preset was it on. Which houses were counted for Mangal dosha, and from which reference points. Which ayanamsa was set. And what birth time was entered, to the minute.

A practitioner who knows their tools answers all four without difficulty, and the good ones volunteer what the answer would have been on a different setting, because they have watched it change. If the reply is that the software does not show that, you have still learned something useful: the verdict you were handed is a default, and defaults can be listed and compared and put in front of both families at once.

The birth-time question is the one people skip and it is often the cheapest. In the published sample the bride’s ascendant moves from one sign to the next with a shift of 3 minutes in the recorded time. Three minutes. For a chart like that, arguing about house lists before establishing the birth time is arguing about the second decimal place.

The narrow thing a comparison can do

It establishes whether a refusal is unanimous across the documented readings or particular to one of them. Which rule set your two households should follow is a question about lineage and practice, and no amount of computation touches it.

Where two verses genuinely conflict, running both does not adjudicate between them. It tells you that a conflict exists, names both sides, and shows which one produced the sentence you were given. That is a smaller result than people want and a much larger one than a bare verdict, because it converts “the kundli did not match” into “this was refused under a reading that judges Mars from Venus”. The second sentence can be taken to a second astrologer, or to a text, or to the other family. The first one cannot be taken anywhere.

Our own position is deliberately narrow. We do not think one of the five is correct, and we would not be able to demonstrate it if we did. We think a report should say which one it ran, print the alternatives beside it, and cite the text each rule came from, so that the disagreement is visible instead of absorbed into a single number. The matching tool is built to that specification: each rule it fires prints the setting that decided it and the text that setting came from, so a disagreement arrives with its cause attached instead of as a bare number to be trusted or refused. If you want the measurement behind all of this rather than the argument, the divergence census sets out how it was run and what it does not cover.