This document sets out the system architecture, the four build phases, the infrastructure required, and the reasoning behind each decision. It is written to be read in full before any commitment is made.
The rulebook is deterministic. Given a chart, a rule either fires or it does not, and it does so identically every time for every user. That property is the basis of the product's credibility and it must be preserved end to end.
A language model is probabilistic by design. If the rulebook is used as training data, the model will apply rules correctly most of the time and produce a plausible variant the rest of the time. For a paid advisory product this is not a rough edge, it is a failure of the core function. It also means the rulebook is embedded in model weights that cannot be selectively edited or withdrawn.
The architecture therefore separates the two completely. Astronomical calculation is code. Rule evaluation is code. Priority and conflict resolution is code. The language model performs one function: it converts an already resolved verdict list into readable prose in the correct language and register.
The narrator model never receives rule text, so it cannot reproduce rule text. This is a property of the architecture rather than a promise about prompt configuration. The rulebook, the priority tables and the verdict library remain on hardware the client controls, and the application never holds a copy.
Outputs reveal rules statistically. A determined party can register accounts, submit systematically varied birth data and map where verdicts change. Rate limiting, paraphrased narration, absence of rule identifiers in responses and anomaly detection on input patterns raise the cost of this substantially. They do not reduce it to zero. Contractual terms are the remaining protection.
Six steps. Five are deterministic. Only the last involves a language model, and by then every decision has already been made.
A birth chart never changes. Once calculated it is stored against the birth details that produced it and never fetched again. A report is stored against the chart identifier plus the rulebook version. When a rule changes, only reports touching that rule are regenerated.
At low volume this is a convenience. At scale it is the difference between a predictable operating cost and one that grows linearly with usage, because both the chart provider and the model provider bill per call.
Roughly four hundred rules fire for a given chart. The question of which rule acts on which part of a person's life is answered by the rule itself, not worked out at runtime.
Each rule carries metadata alongside its conditions. The conditions state when it fires. The metadata states what it acts on and how loudly. Four fields do the structural work.
| Field | Question it answers | Example value |
|---|---|---|
| domain | Which area of life this rule acts on. The engine groups by this field. | marriage |
| priority_tier | What it outranks and what outranks it. 1 is absolute, 4 is modifier only. | 2 |
| conflict_group | Which rules it contradicts. Inside a group only the highest tier survives. | marriage_timing_delay |
| strength | How loudly it speaks within its tier. Orders the survivors. | 7 |
Where the material says a placement indicates delay unless a particular aspect is present, that is two rules sharing one conflict group, with the second at a higher priority tier. When the second fires, the first is dropped before it reaches the report. Identifying these pairs is the substance of the conversion work, and it is the part that has never been written down.
If a model decides the ordering, two users with identical charts receive different reports. A complaint cannot be reproduced, a change cannot be tested, and no claim about consistency can be verified, including under technical due diligence during a funding round. Placing this logic in code makes the system auditable.
A user describes a difficulty in their own words. The system identifies which of their existing verdicts account for it, and returns causes and remedies.
Two design decisions make this safe. First, the query runs against verdicts already computed for that user, rather than triggering a fresh evaluation. The answer therefore cannot contradict the user's own report. Second, the list of recognised problems is closed. A complaint outside the taxonomy returns an empty result and the system says so, rather than producing an invented explanation.
The model performs classification, not interpretation. It converts free text into one code from a fixed list. Everything after that point is a database query.
Four phases. Each produces a working system rather than an internal milestone, and each is committed to separately.
The advisory product generates revenue from a single user. It has no network requirement. The matching product delivers no value until a population of profiles exists in each city, which means it cannot be tested meaningfully at launch.
Building the advisory side first produces a base of users who already hold complete verified chart profiles. Those users are the initial population for matching. This converts a cold start problem into an asset that has already been paid for.
Two to three weeks. Establishes whether the rulebook can be expressed as software before any application code is written.
Phase 1 development begins only after the 200 pilot rules pass validation. If 200 cannot be produced in the required form, 3,000 cannot either, and that is established at a cost of one phase rather than after an application has been built around an assumption.
Override logic is normally held intuitively rather than explicitly. A practitioner knows which rule wins without ever having recorded it. If extracting that ordering requires structured interviews rather than reading from existing documents, it will be scoped as a separate workstream at that point.
Lahiri, Raman and KP conventions place houses differently for the same birth details. If the chart provider uses one convention and the rules assume another, every verdict is subtly incorrect and the error is invisible for months. This is fixed in week one and asserted in automated tests thereafter.
| Phase 0 | Duration | Cost |
|---|---|---|
| Foundation | 2 to 3 weeks | $3,500 |
Eight to ten weeks. A complete paid advisory product with no matching features. Revenue begins at the end of this phase.
The rule engine reads rule records and evaluates them against a chart payload. It is indifferent to what any individual rule says. It is therefore built and tested entirely against synthetic rules written by WebEpex, and the client loads the production rulebook into the finished engine on their own server.
This removes the need for WebEpex to hold, transmit or store any part of the rulebook at any point during the engagement.
| Phase 1 | Duration | Cost |
|---|---|---|
| Astrology coreIncludes on site infrastructure setup and handover | 8 to 10 weeks | $25,000 |
Six to eight weeks. Compatibility scoring, discovery and messaging, built on the profile base created in Phase 1.
Compatibility is pairwise, so evaluation cost grows with the square of the user count. One thousand users produces half a million pairs, which is manageable. One hundred thousand users produces five billion pairs, which is not, and every one of those evaluations would run on the client rule server.
The system therefore filters before it scores. Structural filters reduce the candidate pool to a few hundred profiles before any rule is evaluated. Scores are cached against the rulebook version and recomputed only when a new user joins or a rule changes.
| Phase 2 | Duration | Cost |
|---|---|---|
| Matching | 6 to 8 weeks | $12,000 |
Eight to ten weeks. Features that increase revenue per account and reduce churn, plus the operational tooling required to run the product without developer involvement.
| Phase 3 | Duration | Cost |
|---|---|---|
| Expansion | 8 to 10 weeks | $20,000 |
Rule evaluation is comparison, lookup and sorting. It runs on ordinary CPU hardware. No graphics processing is involved in the rule layer at any point.
| Component | Owner | Cost |
|---|---|---|
| Rule serverOn premises machine or a VPS where the client holds sole root access. CPU only. | Client | $900 to $1,400 once or $80 to $150 monthly |
| On site installationTravel, installation, hardening, private link, backups, runbook handover. | WebEpex | Included in Phase 1 |
| Application backend and databaseManaged cloud, Mumbai region for latency and data residency. | WebEpex | $80 to $300 monthly |
| Object storage and CDNChart images, report files, audio files. | WebEpex | $10 to $50 monthly |
| Chart provider APIBilled per call, but each chart is purchased once and cached permanently. | Pass through | Usage based |
| Narrator model APIA small per report cost at current provider pricing. | Pass through | Usage based |
| Voice synthesisPhase 3 only. Billed per character. | Pass through | Usage based |
Local inference hardware is a reasonable choice where no user text may reach an external provider. It is a decision about inference sovereignty, not about training, since no model is being trained in this build.
Two points are worth noting before purchase. First, current desktop class AI systems link in pairs rather than into larger clusters, so additional units add capacity in parallel rather than combining into one larger machine. Second, these systems are optimised for development and privacy sensitive local inference; memory bandwidth, not raw compute, limits throughput when serving many concurrent users. For production serving at volume, a server with high bandwidth cards delivers more output per unit of spend.
This decision does not affect the build. The narrator sits behind an interface, and whether that interface points at an external API or at client owned hardware is a configuration change rather than a rebuild. It can therefore be made at any point without delaying Phase 0.
Placing the rule server physically on the client premises gives maximum control. It also makes the client's own internet connection a dependency of the product; if the line drops, report generation stops.
The recommendation is a hardened VPS in a Mumbai datacentre where the client holds the only root credentials and the only disk encryption keys, with a client controlled encrypted standby. This retains sole custody without taking on responsibility for uptime. If on premises hardware is preferred, it will be configured that way with a documented failover path.
No model is fine tuned in this build. Behaviour is controlled through configuration, structure and code, which keeps the rulebook out of model weights and makes changes reversible.
If tone still requires adjustment after this, a light fine tune on verdict to report pairs is possible later. Those pairs contain no rule text, so no intellectual property is exposed.
| Phase | Duration | Cost |
|---|---|---|
| Phase 0: FoundationSchema, contract, mock server, validator, wireframes | 2 to 3 weeks | $3,500 |
| Phase 1: Astrology coreComplete paid advisory product, both platforms, on site setup included | 8 to 10 weeks | $25,000 |
| Phase 2: MatchingCompatibility engine, discovery, messaging, safety tooling | 6 to 8 weeks | $12,000 |
| Phase 3: ExpansionFamily tree, timelines, voice, credits, admin console, hardening | 8 to 10 weeks | $20,000 |
Each phase is quoted and committed separately. No phase obliges the next.
Infrastructure and API usage are billed at cost and pass through separately. They are not absorbed into a support tier, so there is never an incentive to under provision the product.
| Tier | Scope | Monthly |
|---|---|---|
| Care | Monitoring, uptime, bug fixes, security patches, store compliance, backups. No new features.Approximately 12 to 20 engineering hours. | $500 |
| Build | All of Care, plus a monthly block of feature work, rule set expansion and iteration on live usage data. | $1,800 |
| Growth | All of Build, plus acquisition work run by the team that built the product: store optimisation, search, paid campaigns and reporting. | $3,200 |
| Risk | Mitigation | Owner |
|---|---|---|
| Rule conversion stallsOverride logic is held intuitively rather than documented. Highest probability failure mode. | Phase 0 gate. 200 validated rules and 20 conflict cases before Phase 1 begins. | Client |
| Rule correctnessThe engine executes rules faithfully. It cannot assess whether the rules are correct. | Reference readings and the evaluation harness detect drift from the intended output, not errors in doctrine. | Client |
| Chart convention mismatchWrong ayanamsa produces silently incorrect verdicts. | Convention fixed in Phase 0 and asserted in automated tests. | WebEpex |
| Chart provider dependencyOutage, price change or discontinuation. | Adapter interface from the first week, so providers can be swapped or calculation brought in house without wider changes. | WebEpex |
| Matching cold startEmpty feeds in low density cities reduce early retention. | Advisory user base seeds the matching pool. Threshold widens automatically when a pool is too small. | Shared |
| Rule extraction through outputsSystematic probing by outside parties. | Rate limits, paraphrased narration, no rule identifiers in output, anomaly detection, contractual terms. | Shared |
| App store rejectionAccuracy claims and dating safety requirements. | Claims reviewed before submission. Safety tooling built in Phase 2 rather than added afterwards. | WebEpex |
The source material contains diagrams for palm, nail and gemstone readings. These represent two separate problems and neither belongs in the phases above.
Converting the diagrams into rules is a knowledge task. The diagrams map to conditions and outcomes in the same way the written rules do, and this can be absorbed into a later rule set expansion at modest cost.
Reading a photograph of a user's palm is a computer vision problem. No general purpose model performs this reliably. It requires a large set of labelled images that does not currently exist, which means the work cannot begin until the product has an active user base generating that data. Including it in a fixed price build would consume the budget without producing a working feature.
The recommendation is to revisit this as a separate research engagement once the platform is live, at which point the user base is also the data source that makes it feasible.
WebEpex builds the engine, not the rules. The engine is content agnostic and is developed against synthetic rules. Authorship, correctness and maintenance of the rulebook remain with the client throughout.
Two to three weeks establishes whether the rulebook can be expressed as software, fixes the calculation convention, and produces the contract that lets both sides work in parallel from that point forward. Every decision after it is made with evidence rather than assumption.
If the answer turns out to be negative, it is established at the cost of one short phase rather than after an application has been built around it.