Porutham vs Gun Milan: Why Rajju and Vedha Veto a Match

A matrimonial desk in Chennai and a matrimonial desk in Jaipur can read the same two horoscopes and reach opposite verdicts, and neither of them is wrong. The North reads the 36 point Ashtakoot Gun Milan sheet. The South reads ten poruthams, each a plain pass or fail, two of which are treated as outright vetoes. If your product computes only the 36 point score and ships it to a Tamil, Malayalam or Telugu speaking user, you are showing that user a number their family astrologer will overrule, and you will hear about it in a support ticket rather than in a test.

This post takes one real birth pair, runs it through all three sheets on RoxyAPI, and prints the actual responses. Every number below came off a live call, not from a worked example in a book.

Why does a 33 of 36 Gun Milan score still get rejected?

Because the 36 point sheet and the ten porutham sheet measure different things, and one of the poruthams is a veto that no score can outvote. The pair below scores 33 of 36 on Ashtakoot, carries no Nadi and no Bhakoot dosha, and returns isCompatible: true. The same two charts score 6 of 10 poruthams and come back verdict: "rejected", because both Moon nakshatras sit on the Paada limb of the Rajju body.

The couple: a groom born 23 January 1990 at 11:40 in Chennai, and a bride born 14 January 1990 at the same hour and place. The groom Moon falls in Jyeshtha pada 4 in Scorpio, the bride Moon in Magha pada 3 in Leo. Here is what POST /vedic-astrology/compatibility returns, abridged to the headline fields and the eight koota rows:

{
  "total": 33,
  "maxScore": 36,
  "percentage": 91.66666666666666,
  "isCompatible": true,
  "recommendation": "Union is recommended",
  "doshas": [],
  "doshaCancellations": [],
  "breakdown": [
    { "category": "Varna", "score": 1, "maxScore": 1, "person1": "Brahmin", "person2": "Kshatriya" },
    { "category": "Vashya", "score": 0, "maxScore": 2, "person1": "Keeta", "person2": "Vanacara" },
    { "category": "Tara", "score": 3, "maxScore": 3, "person1": "Parama Mitra", "person2": "Janma" },
    { "category": "Yoni", "score": 3, "maxScore": 4, "person1": "Hare", "person2": "Rat" },
    { "category": "Graha Maitri", "score": 5, "maxScore": 5, "person1": "Mars", "person2": "Sun" },
    { "category": "Gana", "score": 6, "maxScore": 6, "person1": "Rakshasa", "person2": "Rakshasa" },
    { "category": "Bhakoot", "score": 7, "maxScore": 7, "person1": "Scorpio", "person2": "Leo" },
    { "category": "Nadi", "score": 8, "maxScore": 8, "person1": "Adi", "person2": "Antya" }
  ]
}

Nadi, Bhakoot, Gana and Graha Maitri all land full marks. The only points lost are two on Vashya and one on Yoni. On any North Indian reading this is a very strong match.

Ready to build this? The Vedic Astrology API returns Ashtakoot, the ten poruthams and Papasamyam from one key and one request shape. See pricing.

What do Rajju and Vedha actually refuse?

Rajju maps the 27 nakshatras onto five parts of a body and refuses a couple whose two birth stars share a part. Vedha names thirteen nakshatra pairs held to obstruct each other and refuses those. Both are read off the Moon nakshatra alone, both are a plain pass or fail, and both are treated as disqualifying however many of the other eight poruthams matched.

POST /vedic-astrology/compatibility/dashakoot publishes each veto as its own object, so no caller has to scan the sheet to find the headline:

{
  "total": 6,
  "maxTotal": 10,
  "verdict": "rejected",
  "recommendation": "The union is refused on Rajju, which the tradition treats as disqualifying however the remaining poruthams read.",
  "rajju": {
    "active": true,
    "reason": "Both birth stars fall on the same Rajju limb, which the tradition treats as disqualifying whatever the rest of the sheet reads."
  },
  "vedha": { "active": false, "reason": "Neither birth star obstructs the other, so no Vedha applies." }
}

The five limbs and their membership, which is what makes the veto reproducible by hand:

Jyeshtha is 18 and Magha is 10. Both sit on Paada, so the veto fires and the breakdown row carries the limb for each person rather than burying it in a sentence.

Vedha never fires on its own, and that is arithmetic

Run every one of the 729 ordered birth star combinations through the two tables and the result is structural rather than coincidental. 153 of the 729 combinations share a Rajju limb. 26 of them are a Vedha pair. All 26 sit inside the 153. There is no star pair anywhere in the sheet that Vedha refuses and Rajju accepts.

The reason is that both tables have the same nine star period. Every Vedha pair sums to 19, 28 or 37, each of which leaves a remainder of 1 when divided by 9, and the Rajju zigzag climbs and descends the five limbs on that same nine star cycle, so the limb map is symmetric about exactly the axis the Vedha sums pick out. The arithmetic variant of Vedha that some desks prefer, which refuses any pair summing to 19, 28 or 37 rather than the thirteen printed pairs, is a strict superset and every one of its pairs shares a limb too. Practical consequence for anyone implementing this: if you only have room for one veto, implement Rajju. Vedha will never reject a pair that Rajju has not already rejected.

Why does swapping the two people change the answer?

Because five of the ten poruthams are directional. Dina, Mahendra, Stree Deergha, Rasi and Vasya all count from the bride toward the groom, and the Papasamyam comparison is an inequality in one direction, so the two people are not interchangeable arguments. Send them the wrong way round and you get a different, wrong sheet with a 200 and no warning. On RoxyAPI person1 is the groom and person2 is the bride.

Here is the same couple with person1 and person2 exchanged, same request shape, same city, same frame:

Stree Deergha means the long life and prosperity of the woman, and it passes when the groom star sits far enough ahead of the bride star. Reverse the two people and the distance is measured backwards, which is how a failing porutham silently becomes a passing one. Papasamyam is starker still: the same swap turns verdict: "balanced" into verdict: "unbalanced" on the identical two charts, because the rule asks whether the bride carries no more affliction than the groom and never the reverse.

How does Papasamyam measure malefic balance between two charts?

Papasamyam counts malefic affliction in each chart and compares the two totals. It counts Mars, Saturn, Sun and Rahu sitting in the six afflicting bhavas 1, 2, 4, 7, 8 and 12, read from three reference points in turn. It is never a verdict on one person: the doctrine is that like cancels like, so a heavily afflicted native matched with a comparably afflicted one is held to be safe.

The three points carry different weights, and POST /vedic-astrology/compatibility/papasamyam publishes the weight beside each one rather than assuming it, because schools genuinely disagree here:

For our couple the groom carries 2 points and the bride 1.25, so the bride is the lighter chart and the verdict is balanced. What makes a total like 1.25 auditable is that every point names the graha and the bhava it came from:

{
  "person2": {
    "total": 1.25,
    "byReference": [
      { "reference": "Lagna", "weight": 1, "afflictions": [] },
      { "reference": "Moon", "weight": 0.5, "afflictions": [{ "graha": "Mars", "house": 4 }] },
      { "reference": "Venus", "weight": 0.25, "afflictions": [
        { "graha": "Saturn", "house": 12 },
        { "graha": "Sun", "house": 1 },
        { "graha": "Rahu", "house": 1 }
      ] }
    ]
  },
  "verdict": "balanced",
  "recommendation": "The bride carries 1.25 papa points against 2 for the groom, so the affliction is balanced and the match is not refused on this count."
}

One affliction from the Moon at half a point plus three from Venus at a quarter each is 1.25, and a reader can redo that sum in their head. Note the house numbers are counted from the reference on that row, not from the Lagna, which is why Saturn shows as the 12th from Venus.

Why do the three sheets disagree, and which one does your product need?

They disagree by design, because they are three different questions rather than three views of one answer. Ashtakoot weights eight kootas across 36 points. The ten poruthams are equal pass or fail rows with two hard vetoes. Papasamyam is not a score at all, it is a comparison between two counts. Reconciling them into one number throws away what each one carries.

Now the honest part, because it decides how you present the result. No classical text publishes either the porutham tables or a papa point table. Checked live on 20 September 2026: two published ten porutham sheets name Vasya as the tenth row while a third drops it and substitutes Nadi, and a widely read practitioner answering a reader states plainly that papasamyam has no maximum and no minimum point total at all, because the scoring schemes in circulation are not comparable to each other. Tamil and Kerala practice differ again on the Stree Deergha threshold.

So RoxyAPI names the convention it ships where a caller can see it, publishes the three papa weights on the response instead of assuming them, and leaves the classification for each person on its own row. If your desk reads Stree Deergha differently or weights the three reference points equally, both totals and every underlying point are already in the response and the comparison is yours to make.

How to run all three sheets from one location lookup

Every chart endpoint needs coordinates and a timezone, so the first call is always the city. Pass the IANA timezone string rather than the numeric offset, since the calculation resolves the offset that was actually in force on the birth date.

curl -s "https://roxyapi.com/api/v2/location/search?q=Chennai" \
  -H "X-API-Key: YOUR_KEY"

{
  "total": 1,
  "cities": [
    {
      "city": "Chennai",
      "province": "Tamil Nadu",
      "country": "India",
      "iso2": "IN",
      "latitude": 13.0878,
      "longitude": 80.2785,
      "timezone": "Asia/Kolkata",
      "utcOffset": 5.5,
      "population": 4681087
    }
  ]
}

Feed latitude, longitude and timezone straight into the match. The same body works on all three endpoints, so a platform that already sends Gun Milan gets the other two sheets for the cost of changing the path:

curl -s -X POST "https://roxyapi.com/api/v2/vedic-astrology/compatibility/dashakoot" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{
    "person1": { "date": "1990-01-23", "time": "11:40:00", "latitude": 13.0878, "longitude": 80.2785, "timezone": "Asia/Kolkata" },
    "person2": { "date": "1990-01-14", "time": "11:40:00", "latitude": 13.0878, "longitude": 80.2785, "timezone": "Asia/Kolkata" }
  }'

Swap the final path segment for papasamyam and the same body returns the malefic balance, or drop it entirely for the 36 point sheet. Add ?lang=hi and every note, reason and recommendation comes back in Hindi while verdict, name and the classification labels stay canonical English, so you can render a translated sentence and still switch on the machine value, across 10+ languages on one key.

All three sheets are also live as tools on the Remote MCP server for this domain, so an agent can call them over Streamable HTTP with no local setup and no glue code. Full request and response schemas, runnable in the browser with no signup and no key, are on POST /vedic-astrology/compatibility/dashakoot in the API reference.

FAQ

What is porutham in marriage matching?

Porutham is the South Indian method of checking marriage compatibility from the two birth stars, usually as ten pass or fail agreements called Dasa Porutham: Dina, Gana, Mahendra, Stree Deergha, Yoni, Rasi, Rasyadhipati, Vasya, Rajju and Vedha. RoxyAPI returns all ten with a note explaining each verdict from POST /vedic-astrology/compatibility/dashakoot. It is a different system from the 36 point Ashtakoot Gun Milan sheet and the two are never reconciled.

Can a high Gun Milan score still be a bad match?

Yes, and it is not a rare corner. 153 of the 729 possible birth star combinations put both people on the same Rajju limb, and Rajju is treated as disqualifying however many other poruthams matched, so a pair can score 33 of 36 on Ashtakoot and still come back rejected on the ten porutham sheet. RoxyAPI publishes Rajju and Vedha as explicit top level objects with an active flag, so a matrimonial product can surface the veto instead of surfacing a score that a family astrologer will overrule.

Does it matter which person I send first?

It matters a great deal. Five of the ten poruthams count from the bride toward the groom, and the Papasamyam balance is a one way inequality, so swapping the two people returns a different answer with no error at all. On RoxyAPI person1 is the groom and person2 is the bride on every matching endpoint, and the same couple moves from 6 of 10 to 7 of 10 when the order is reversed.

What is Papasamyam and how is it different from a Manglik check?

A Manglik check asks a yes or no question about Mars in one chart. Papasamyam asks whether two charts carry comparable affliction, counting Mars, Saturn, Sun and Rahu in the six bhavas 1, 2, 4, 7, 8 and 12 read from the Lagna, the Moon and Venus, then comparing the totals. RoxyAPI returns the graha and the bhava behind every point from POST /vedic-astrology/compatibility/papasamyam, so the total can be audited rather than trusted.

Is there an API for South Indian porutham matching?

Yes. RoxyAPI returns the ten porutham sheet, the 36 point Ashtakoot Gun Milan sheet and the Papasamyam malefic balance from three endpoints that take the identical request body, on one API key that also covers 258+ endpoints across 18+ insight domains. Responses are typed, localized into 10+ languages, and the underlying charts run against 11,000+ automated tests on every deploy, 2,800+ of them locked to named external references.

Conclusion

A matrimonial product that ships only the 36 point number is not wrong so much as incomplete, and the gap shows up precisely where the stakes are highest, in front of a South Indian family reading the sheet they actually use. Run all three, show the veto when it fires, and show the working behind the papa total so a sceptical reader can check it. The Vedic Astrology API returns every sheet above from one key, one request shape and one verified chart engine.