A developer shows a matchmaking result. The score is 28 out of 36. Strong Graha Maitri, solid Gana compatibility, no Nadi dosha. By any standard reading of the Ashtakoota system, this pair scores well.
A practicing Jyotishi reviews the same pair and declines to proceed. The birth Nakshatras create a Rajju conflict. Both people belong to the same Rajju group. The classical tradition treats that as a condition prior to the score, not a penalty inside it. The Jyotishi is not overriding the score. The score was never the relevant question.
The developer's system returned a correct number by the rules it implemented. The rules were in the wrong layer.
What Rajju and Vedha Are
Each of the twenty-seven Nakshatras belongs to one of five Rajju groups, named for body parts: Siro (head), Kantha (neck), Udara (stomach and navel), Kati (waist), and Pada (feet). When two partners share the same Rajju group, their birth Moons occupy Nakshatras in the same group. Classical texts describe this as a structural incompatibility that operates regardless of the Guna Milan total. Classical South Indian matchmaking tradition does not describe Rajju as one factor among eight. It describes it as a condition to check before matching proceeds.
Vedha works on pairs. Specific Nakshatra pairs obstruct each other. Swati and Rohini are one such pair. When one partner's birth Moon is in Swati and the other's is in Rohini, the classical tradition treats this as mutual obstruction. Like Rajju, this is not a scoring factor. It is a prior condition.
The distinction matters because of what it implies for implementation. A scoring factor belongs inside the calculation that produces the total. A prior condition belongs in a separate layer that the score cannot override.
Where Most Implementations Put Them
The simplest way to implement Rajju dosha in a scoring system is to apply a penalty when the condition is detected. Score is 28, Rajju is present, deduct some amount, return a lower number. This is technically possible and architecturally wrong.
The deduction implies the score is still the governing decision. A high enough base score could still produce an acceptable result after the deduction. But classical texts do not describe Rajju as something strong compatibility can compensate. They describe it as something that makes the compatibility question irrelevant. A 28-point pair with Rajju dosha is not a 20-point pair. It is a pair where the score should not have been the conclusion.
An API that folds Rajju into the calculation produces one number. That number represents the result of the assessment. The developer who receives it cannot tell whether it reflects a clean match or a vetoed match that has been numerically adjusted. The information is in the system but collapsed into a form that hides what actually happened.
Why the Layer Matters in Practice
A developer who receives a single score cannot distinguish between these two outcomes without additional data. A family or practitioner who reviews the output will identify the difference in under a minute. The mismatch between what the software returns and what classical practice requires is not visible in the number. It is visible only to someone who knows to look for the veto separately.
This is a specific failure mode. The application functions correctly by its own logic. Its logic is structurally different from the classical tradition it implements. The error is not in the code. It is in the architecture.
There is also a secondary problem. To fold Rajju dosha into the score, a developer must choose a deduction value. How many of the 36 Guna Milan points does Rajju cost? Classical South Indian matchmaking tradition does not specify this. It specifies that Rajju makes the Guna Milan score irrelevant. Any deduction value is an invention, not an implementation of the classical text.
A compatibility score that has absorbed a Rajju veto into its calculation returns a number. A compatibility score accompanied by a separate veto object returns a number and a classification. The second structure is not more complex. It is more honest about what happened.
How We Structured the Separation
The Asterwise compatibility response has two independent sections that address the same pair. The total_score field carries the Guna Milan result: the sum of eight weighted kootas as the classical system defines them. Those eight kootas are Varna, Vashya, Tara, Yoni, Graha Maitri, Gana, Bhakoot, and Nadi. Rajju is not one of the eight. It has never been part of that calculation.
The classical_vetoes object is separate. It carries has_veto as a boolean, plus individual objects for rajju and vedha. Each carries a present flag, a description, and in the case of Rajju, a rajju_type that identifies which of the five body-part groups applies. When Rajju or Vedha is present, has_veto is true regardless of what total_score shows.
In a sample compatibility result for two charts used during development of this post, total_score is 14.5 out of 36 and classical_vetoes.has_veto is true simultaneously. Rajju type is Kantha. Vedha is present on the Nakshatra pair Swati and Rohini. The score and the veto are separate facts in the same response. Neither changes the other. Neither is derived from the other.
What This Design Forecloses
Building Rajju and Vedha as score modifiers would have produced a simpler-looking API. One number, one result. It would also have required choosing a deduction value with no classical basis, and it would have hidden the distinction between a low-scoring clean match and a high-scoring vetoed match.
The separate veto layer means the developer decides what to do with it. An application might show the score and the veto together. Another might suppress vetoed pairs before showing any score. A third might route them to practitioner review. The API does not make that choice. It provides the data in the structure the classical texts define: score and veto as separate results from separate questions.
The Guna Milan system asks how compatible two charts are across eight classical dimensions. Rajju and Vedha ask whether those charts should be matched at all. These are different questions. They belong in different parts of the response.