Skip to content
docs
UseBuildChangelog
Open Lumin

Examples

wellness-matcher

A single-page widget for a D2C Ayurvedic or personal-care brand. Birth details in, a Vata/Pitta/Kapha prakriti read and 4 catalog picks out, with reasoning grounded in the visitor's actual chart rather than a 12-question quiz.

Tool chain

Nine tools, all called on every request: set_birth_profile, get_full_chart, get_planets, get_house_cusps, get_nakshatra_details, get_aspects_and_strength, get_boundary_warnings, get_ayurvedic_constitution and get_shadbala.

get_ayurvedic_constitution is the primary signal: it maps planets to doshas (Saturn, Rahu and Mercury to Vata; Sun, Mars and Ketu to Pitta; Moon, Jupiter and Venus to Kapha), weights by house importance and lagna-element bonus, and returns a vata/pitta/kapha percentage triple that sums to 100. get_shadbala crosses against it to rank the constitution drivers: a dosha-carrying planet that is also strong by Shadbala is a firm driver, a weak one is a softer lean. get_boundary_warnings runs first as the Phase-1 credibility check, a CRITICAL flag (within 6 arc-minutes of a sub-lord boundary) tells the prompt a small correction could flip the sub-lord and invert the prakriti.

Inputs

  • name, optional, echoed back for reference only
  • birth_date (YYYY-MM-DD) and birth_time (HH:MM)
  • birth_time_known, boolean. When false the app defaults to 12:00 and the prompt skips ascendant and cusp logic, leaning on planet placements and Moon nakshatra alone
  • location_name, free text (e.g. "Colombo, Sri Lanka"), resolved to coordinates by the model itself
  • biological_sex, optional, defaults to unspecified

Birth-time fallback

Most visitors do not know their exact birth time. With birth_time_known: false the dosha triple still returns, but its lagna-element bonus and 1st-house weighting become unreliable, and the summary says so explicitly.

Call it

typescript
const result = await runLumin({
  allowedTools: ALLOWED_TOOLS, // the 9 tools above
  system: buildSystemPrompt(),
  user: buildUserPrompt(input),
  maxTokens: 16000,
  effort: "xhigh",
  signal: req.signal,
});

const parsed = ensureShape(
  parseJsonBlock<MatchResponse>(result.text),
  validateShape,
);

Wired against https://mcp.lumin.guru/mcp. The city-to-coordinates resolution runs inside the same model call, on the model's own geographic knowledge, so the demo needs no separate geocoding API; the resolved coordinates are returned so the visitor can verify the right city was used.

Response shape

json
{
  "resolved_location": {
    "latitude": 6.9271,
    "longitude": 79.8612,
    "utc_offset_minutes": 330,
    "note": "Colombo, Sri Lanka"
  },
  "prakriti": {
    "primary": "pitta",
    "secondary": "vata",
    "label": "Pitta-Vata"
  },
  "dosha_balance": { "vata": 34, "pitta": 46, "kapha": 20 },
  "constitution_drivers": [
    {
      "planet": "Mars",
      "dosha": "pitta",
      "strength": 78.4,
      "note": "Strong by Shadbala, in the 1st house. A firm driver."
    },
    {
      "planet": "Saturn",
      "dosha": "vata",
      "strength": 41.2,
      "note": "Below median strength. A softer lean, not a fixed trait."
    }
  ],
  "summary": "A Pitta-Vata constitution with a strong, well-placed Mars driving heat and intensity...",
  "matches": [
    {
      "id": "sp-cooling-facial-oil",
      "reason": "Pitta-pacifying, cooling potency counters the dominant Mars signature.",
      "name": "Cooling Sandalwood Facial Oil",
      "category": "skin",
      "pricing": { "lkr": 4200, "usd": 14 }
    }
  ]
}

Screens

  • A hero with a short pitch and the intake form entry point
  • A quiz-style form: name, date of birth, optional time with an "I don't know" toggle, birth city
  • A prakriti card with a Vata/Pitta/Kapha balance meter and the ranked constitution drivers
  • A 4-up product grid, each card carrying its own one-line reason

The interesting engineering detail

check_doshas is deliberately not on the allowlist here, and the name is a trap worth naming: it detects classical chart afflictions (Manglik, Kalsarpa, Sadhesati, Pitra Dosha), which is marriage-and-karma material, not Ayurveda. Wiring it into a constitution read would pull an unrelated life-area signal into a personal-care product. The allowlist is the enforcement mechanism, not a comment: a model cannot call a tool that is not in configs.

Where to next

  • Wellness and health use cases for the rest of the vertical, including the corporate cohort dashboard and the health-risk pattern this app's sibling implements.
  • products-matcher is the same pattern with a broader catalog and a personality read instead of a prakriti read.