Vastu Consultation Workflow

The Vastu API provides deterministic geometric analysis — zone boundaries, Brahmasthan cell geometry, Vastu Purusha Mandala overlay, entrance direction classification and traditional rule evaluation — from polygon coordinates and bearing values. It does not perform physical inspection, structural assessment or prescribe remedies; that judgement belongs to the practitioner.

This workflow covers both apartment assessments (existing units, constrained structural changes) and plot assessments (new builds, proposed layouts). Detailed worked examples for each type are in separate guides — see Apartment Assessment and Plot Assessment.

Before any API call, establish:

• Property type: existing apartment, new-build plot, commercial premises, or a proposed floor plan the client has not yet built.
• Client consent: explain that the API analysis derives from coordinates and bearing values the practitioner supplies — results depend on measurement accuracy.
• Primary questions: health, prosperity, relationships, career, specific room purposes. These determine which rule findings are most relevant.
• Structural constraints: which walls, doors and rooms are fixed (load-bearing, legally constrained), and which offer practical scope for change.
• Occupancy timing: if a housewarming or ground-breaking ceremony is planned, collect the target date, latitude, longitude and time zone for muhurta computation.

Accurate coordinates are the foundation of accurate API results. The API's geometry engine requires:

• Boundary polygon: the outer boundary of the unit or plot in a consistent unit (metres or feet). Sketch the outline, place a coordinate origin at one corner (e.g. SW corner = (0,0)), and measure each vertex in turn.
• Room polygons: for apartment assessments, the internal polygon of each named room. Use the same origin and unit as the boundary polygon.
• Entrance bearing: the compass bearing (degrees clockwise from True North) of the main entrance door. Measure with a compass or surveying instrument from inside the property looking out through the main door. If you also pass a non-zero north_angle, send compass bearing − north_angle instead, because the API adds north_angle to every bearing.
• North reference (north_angle): if your coordinate system Y-axis does not point True North — for example if you traced the plan with the building's longest wall horizontal — pass the True North bearing of your plan's +Y (plan-up) axis, measured clockwise (90 if plan-up faces East), as north_angle.

A typical full consultation uses the following calls in order:

curl -X POST https://vedintelastroapi.com/api/v1/vastu/direction \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"bearing_deg": 45, "north_angle": 0}'

curl -X POST https://vedintelastroapi.com/api/v1/vastu/plan/analyze \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "plot": [ {"x":0,"y":0}, {"x":20,"y":0},
              {"x":20,"y":10}, {"x":0,"y":10} ],
    "rooms": [
      {"name": "Master Bedroom",
       "polygon": [{"x":0,"y":5},{"x":8,"y":5},
                   {"x":8,"y":10},{"x":0,"y":10}]}
    ],
    "entrance": {"bearing_deg": 45},
    "north_angle": 0
  }'

curl -X POST https://vedintelastroapi.com/api/v1/vastu/muhurta \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type": "griha_pravesh",
    "date": "15/01/2027",
    "lat": 12.9716,
    "lon": 77.5946,
    "tz": 5.5
  }'

Note: bhoomi_puja, griha_arambha, vastu_puja and griha_pravesh_renovation return HTTP 501 — not yet implemented.

The API returns two levels of output:

• rule_evaluation.findings[]: one entry for each of the 23 rules that fired for the submitted data; rules that do not apply are not listed. Each finding has rule_id, outcome (for example positive or negative), severity, source_type, source_text, source_verification_status, interpretive_confidence (high: straightforwardly derivable from the source; moderate: broadly consistent, with some interpretive inference), a description and the trigger that fired it.
• Counts: positive_count, negative_count, critical_count and informational_count summarise the findings, and rules_version identifies the rule corpus used.

When interpreting findings for a client, distinguish between:

• Non-structural options: furniture placement, colour, lighting, plants, symbolic objects — generally achievable in any tenancy or ownership.
• Minor structural options: door direction change, internal partition removal — may require landlord permission or building consent depending on jurisdiction.
• Major structural options: load-bearing wall changes, window additions — typically require architectural drawings and planning consent; outside the scope of a Vastu consultation alone.

The API does not know which walls are load-bearing, what the lease or planning restrictions are, or what the client's budget is. Recommendations must be calibrated to actual constraints established in intake.

A complete consultation report typically includes:

• Property description and coordinates used (with the note that results depend on measurement accuracy)
• Zone map and Brahmasthan finding (from API geometry output)
• Entrance direction and rule-triggered findings
• Room-by-zone assignments and relevant rules
• Griha pravesh muhurta windows, if requested
• Prioritised, feasible recommendations with the structural-constraint caveat
• Disclosure: traditional findings; not a guarantee of outcomes

The API returns structured JSON. Formatting, presentation and the interpretive layer are the practitioner's responsibility. Future API versions will include an AI narrative endpoint for Vastu findings; this is not available in Phase 1.