Use cases
Responsible use
Every use case on the previous seven pages carries a constraint. This page collects the constraints that repeat across verticals into one place: what a disclaimer has to say, which tools must never reach a consumer, and why birth data is not an ordinary form field.
Disclaimer requirements by vertical
The wording below is not a suggestion. It is the line every worked example in this repo enforces server-side and renders on every result, and it is the line a reviewer will look for.
| Vertical | Required framing |
|---|---|
| Health and telehealth | Supplementary lens, not diagnostic. No condition is ever asserted. Every elevated or high finding should route to a qualified physician, never replace one. |
| Longevity | Qualitative band only. SHORT / MIDDLE / LONG / INDETERMINATE. Never a date, never a number of years, in any surface, ever. This is absolute, not a default a product owner can override. |
| Career and HR | Coaching aid, never a hiring input. The person the chart is about is always the audience; a decision someone else makes about that person is never fed by this output, in either direction (screening in or screening out). |
| Weather and astrometeorology | An astrological lens, not a meteorological forecast. Pair with conventional weather services; never gate a safety decision (construction, marine, aviation) on this signal alone. |
| Matching and compatibility | One input among many. Never present a low score as a reason a relationship will fail, and never let a single-system score stand in for the disagreement between systems. |
| Electional (muhurta) | No score and no ranked top ten, by design. The corpus supports a hard-rejection stage and a stated reason for one moment, or up to three on a genuine tie, never a numeric or ordinal ranking. Building a score on top of the electional tools reintroduces a claim the source material does not make. |
Financial, legal and insurance framing
These three did not get their own row above because the rule is the same one word, repeated: not advice. Not financial advice, not legal advice, not an insurance pricing input, not investment advice, not immigration advice. Where a use case is explicitly research-only (insurance underwriting, historical mundane backtesting), ship it as a study a human reviews, not a feature a pricing engine reads.
Advisor-only tools that must never reach consumers
Three tools exist because a trained advisor sometimes needs to screen for a difficult finding on behalf of a client who has asked for it. None of the three belongs in a consumer-facing product, a self-serve flow, or an output a person receives about themselves with no advisor present to contextualize it.
| Tool | Why it is advisor-only |
|---|---|
| get_extramarital_signature | Reads a signature about a third party's conduct, never about a third party who has not consented. B2B advisor-only, never consumer-facing. |
| get_balarishta_panel | A child-longevity affliction panel. Never appears in a parent-facing product; the parent-facing shape is strengths only (get_nakshatra_details, get_d27_chart, get_yoga_karaka, get_relatives_karaka_panel). |
| get_marital_separation | Separation-risk screening. B2B advisor-only, paired with get_extramarital_signature in the one use case that calls it, and never shown to either party in the relationship being read. |
If your product has a birth-time-unknown lane
The onboarding-rescue pattern (find_birth_time, get_twin_divergence_score, rectify_birth_time, check_rule_of_origin, get_boundary_warnings) always shows the confidence alongside a rectified time. Never present a rectified time as certain, and never silently substitute noon and drop the caveat.
Birth data is personal data
Birth date, time and place are among the most identifying tuples a product can hold. Three pieces of data narrow a person to a level few other single form fields reach, and unlike an email address, birth data cannot be rotated if it leaks.
- Disclose it. A privacy notice that lists "usage data" and not "birth date, time and place" is incomplete. Say plainly that the product reads a birth chart and what that means.
- Do not resell it. A personalization API built on Lumin (see the B2B SaaS use cases) can pass the derived output to a consuming product; the raw birth data is a separate, higher-sensitivity asset that should not travel with it by default.
- The place-and-date and horary input classes exist precisely to avoid this. When a use case can be built on a location and a date, or a number and a moment, with no birth data at all, prefer it. Zero PII is not just lower legal risk, it is a lower-friction funnel.
- A large share of users do not know their exact birth time. A product that requires it with no fallback loses them at the door; see the birth-time-unknown lane above, or default to noon with the precision caveat the wellness and health examples use.
Where to next
- Use cases overview for the input-class table this page assumes.
- Recipes for the cross-system chip pattern and the chart-integrity confidence pill, both of which exist to make an uncertain output visibly uncertain rather than falsely confident.