DEV Community: Arvind Jolly

How We Turned Geomantic Doctrine into Deterministic Software

Arvind Jolly — Tue, 18 Aug 2026 12:27:51 +0000

What happens when you take a centuries-old symbolic decision system and try to implement it as software?

Not a chatbot that imitates its language.

Not an AI prompt that produces something that sounds traditional.

A system that actually executes the underlying rules.

That is the engineering problem behind SAGE — the School of Ancient Geomantic Education.

SAGE is building a growing portfolio of specialized decision tools based on Western Geomancy and Indian Ramal. The three newest additions are Temporal Engineering (Muhurta), Idea Validation (Prashna), and Venture Viability Oracle.

They are different modules for different problems, but they reveal a common architectural principle:

The deterministic engine calculates. The tradition constrains. AI explains.

This post looks at how that works.

The problem with asking an LLM to "do geomancy"

A large language model is remarkably good at producing plausible language.

That is also the problem.

Suppose you ask an LLM to perform a geomantic reading. It can generate figure names, describe planetary associations, interpret houses and produce a convincing narrative.

But convincing is not the same as canonical.

A model can accidentally mix Western geomancy with Indian Ramal. It can assign an incorrect planetary ruler to a figure. It can invent a relationship between houses. It can produce an elegant explanation of a calculation that was never actually performed.

For a system like SAGE, that is unacceptable.

The calculation therefore happens before the language model enters the process.

The AI receives a structured symbolic result and is instructed to interpret that result within the appropriate tradition.

The distinction is fundamental.

The basic pipeline

The architecture can be summarized as:

Real-world question
        ↓
Use-case-specific model
        ↓
Canonical geomantic calculation
        ↓
Structured judicial evaluation
        ↓
AI synthesis
        ↓
Human-readable guidance

The three latest modules demonstrate three different implementations of that pipeline.

Muhurta works backwards from a desired outcome.

Prashna converts an inquiry into a deterministic chart.

Venture Viability applies a Western judicial model to a proposed undertaking.

The underlying principle remains the same: the LLM is downstream of the calculation.

1. Muhurta: solving the chart backwards

Temporal Engineering is the most algorithmically unusual of the three.

A normal reading starts with a chart and interprets it.

An electional system asks a different question:

What configuration would be desirable for the event I want to perform?

SAGE therefore treats Muhurta as an inverse problem.

The implementation defines all four-bit binary figure patterns and enumerates their combinations, producing the complete 65,536-chart possibility space.

Instead of repeatedly constructing arbitrary charts, the system pre-indexes the results according to the desired H15 and H10 outcomes.

That makes it possible to search for charts satisfying a particular event objective.

The engine then applies additional structural filters.

It checks, for example, for an antagonistic elemental relationship between the 1st and 7th houses and for specified shield-breach conditions.

Only suitable candidates are retained.

The event itself becomes part of the model

The system does not treat every action as equivalent.

The event dictionary maps practical activities to different H10/H15 targets. Current mappings include business or project launches, housewarming, marriage, vehicle purchase, investment, travel, contract signing, professional consultation, wellness, property purchase, job changes, education, lawsuits and resignation.

That creates an important software pattern:

User describes an event
        ↓
Event classified
        ↓
Geomantic target selected
        ↓
Inverse search
        ↓
Candidate charts filtered
        ↓
Best configuration selected

The user sees a simple timing tool.

Underneath, the system is solving a constrained search problem across a finite symbolic state space.

The resulting candidate chart provides the required first-house figure, elemental context and planetary ruler.

Only then does the AI generate the natural-language explanation.

The prompt itself explicitly tells the model not to expose the internal matrix terminology and instead provide a practical timing prescription, including the relevant planetary hour and elemental guidance.

That is a useful general design pattern:

keep implementation complexity inside the engine; expose the useful result through the interface.

2. Prashna: making an open-ended inquiry deterministic

Prashna presents a different problem.

A user can ask almost anything.

How do you ensure that the same inputs lead through the same computational process?

SAGE creates a deterministic canonical signature.

The implementation normalizes the querent's name and event name, combines them with the supplied question, hashes the composite string and uses that result to create the seed for the Ramal chart.

The important part is not the hash itself.

It is the architectural separation between:

input → deterministic symbolic state → interpretation

The chart is then evaluated through predefined judicial dimensions.

The implementation extracts:

1st House — querent readiness
4th House — foundation and stability
7th House — external factors and opposition
9th House — auspiciousness
10th House — public outcome and career impact
11th House — realization, success and gains
15th House — Judge / final verdict

This turns a vague question into a structured diagnostic.

The output is similarly structured before AI synthesis begins.

For example, the system separately constructs explanations for the timing/auspiciousness dimension, readiness, foundation, success factors and final verdict.

The language model then receives those computed values and is explicitly told to preserve doctrinal purity and use only the Indian Ramal figure names.

Again:

the model does not calculate the chart.

It explains the chart.

3. Venture Viability: same architecture, different canon

The Venture Viability Oracle demonstrates another important software principle:

shared architecture does not require shared doctrine.

This module is explicitly Western-exclusive and uses the Agrippan Geomantic Judicial Canon.

Its input is transformed into a deterministic signature in the same general manner as Prashna, but the resulting chart is generated with:

generate_chart(mothers, tradition="western")

rather than the Ramal tradition.

The judicial dimensions are again explicit:

1st House — readiness
4th House — foundation
7th House — external factors
9th House — fortune and favour
10th House — public outcome
11th House — gains
15th House — Judge

The synthesis layer is then given the computed Western figures, elements and planetary rulers.

It is also explicitly instructed not to mix in Indian Ramal figure names.

This separation is deliberate.

A common software abstraction might tempt us to create one generic "geomancy" vocabulary and let the model fill in the differences.

We chose the opposite approach.

The architecture can be shared.
The canon cannot be casually merged.

Why deterministic computation matters

The word "AI" tends to make people assume that the entire system is probabilistic.

That does not have to be true.

In SAGE, the symbolic calculation can be deterministic even though the final narrative is generated by an AI model.

That creates an interesting hybrid architecture:

Deterministic layer
    ↓
Canonical figures
    ↓
Judicial structure
    ↓
Probabilistic language layer

The deterministic portion establishes what was calculated.

The language model determines how that result is communicated.

That division gives us several advantages.

Reproducibility

The underlying symbolic calculation follows an explicit computational pathway.

Doctrinal control

Figure properties and house meanings can come from structured canonical data rather than model memory.

Tradition separation

Western and Ramal calculations can use distinct datasets and generation rules.

Better AI behavior

The model receives a constrained symbolic state rather than being asked to invent one.

This is particularly visible in the prompts used by the new modules, which provide the model with the computed figure, element and planetary ruler information before requesting synthesis.

The broader SAGE architecture

These three modules are not the whole SAGE platform.

They are the latest additions to a much larger and growing portfolio of specialized decision tools.

That distinction matters.

The objective is not to build one giant geomantic engine that tries to answer every question.

It is to develop a reusable computational foundation and then build specialized modules around different categories of uncertainty.

That means a use case can determine:

which tradition is appropriate,
which inputs matter,
which houses deserve emphasis,
which judicial rules apply,
what constitutes the relevant outcome,
and how the final result should be translated into practical guidance.

The architecture therefore looks more like a platform than a single oracle:

                         SAGE
                          │
          ┌───────────────┼───────────────┐
          │               │               │
      Use Case A      Use Case B      Use Case C
          │               │               │
     Canon / Model    Canon / Model    Canon / Model
          │               │               │
     Deterministic    Deterministic    Deterministic
       Engine           Engine           Engine
          │               │               │
          └───────────────┼───────────────┘
                          │
                    AI Synthesis
                          │
                    User Guidance

The reusable part is the infrastructure.

The specialized part is the decision model.

That is how an ancient symbolic system can gradually become a modern software platform.

The engineering lesson

There is a broader software-engineering lesson here that goes beyond geomancy.

When a system contains domain-specific rules, it can be tempting to put those rules inside an LLM prompt.

That is often the fastest way to produce a demo.

It is not necessarily the best way to produce a dependable system.

A stronger pattern can be:

formalize the domain → execute the rules deterministically → pass structured results to the LLM → constrain the narrative layer

The same architecture could be useful in many domains where rules are explicit but explanations are naturally expressed in human language.

The model becomes a communication layer rather than an authority on the underlying calculation.

That is the distinction we are trying to preserve at SAGE.

The ancient system is the specification

One of the most interesting consequences of this work is that implementation forces ambiguity into the open.

A manuscript may say something that sounds perfectly clear to a human reader.

A program cannot work with "something like this."

The software needs to know:

What is the input?

What is the transformation?

What are the legal states?

What is the relationship between positions?

What happens when a condition conflicts with another condition?

Which tradition does a figure belong to?

Which properties are authoritative?

What constitutes an impossible configuration?

In the Muhurta engine, for example, the software explicitly handles impossible H15/H10 combinations and refunds the transaction when no valid chart can satisfy the requested conditions.

Encoding the doctrine therefore becomes a form of doctrinal clarification.

The computer is unforgiving.

And that can be useful.

Building a Silicon Oracle

The phrase we use internally for this broader vision is the Silicon Oracle.

Not because silicon somehow replaces the ancient oracle.

Because the computer can perform the repetitive, formal and combinatorial work that would be difficult to execute manually, while preserving the symbolic logic of the original system.

The result is a new division of labor:

Ancient doctrine provides the model.

Software executes the model.

AI communicates the result.

And the user brings the actual decision.

That last part matters.

SAGE is not designed to remove human agency.

The purpose of the system is to create a structured perspective around uncertainty.

The final decision still belongs to the person asking the question.

Where this goes next

Muhurta, Prashna and Venture Viability are only the latest additions to SAGE.

The more ambitious project is the growing portfolio itself.

As additional decision categories are modeled, the same underlying principles can be reused:

identify the decision problem,

select the appropriate tradition and canon,

encode the relevant rules,

generate the symbolic state deterministically,

evaluate it through the appropriate judicial framework,

and let AI turn the structured result into understandable guidance.

That is the direction in which we are building SAGE.

Not a chatbot that pretends to know ancient divination.

Not a generic AI oracle.

But a growing collection of specialized decision tools built from ancient geomantic systems and engineered for modern questions.

Ancient systems.
Structured logic.
Modern engineering.

That is the experiment.

Explore the platform at dotsofdestiny.com.

I Found a Deterministic State Machine Hidden in a 1,000-Year-Old Indian Knowledge System

Arvind Jolly — Fri, 26 Jun 2026 05:42:35 +0000

Sometimes the most elegant software architecture was designed centuries before software existed.

When I began implementing Indian Ramal Shastra (an Indian adaptation of Arabic geomancy) as a Python application, I expected to spend most of my time translating historical rules into code.

Instead, I stumbled upon something I never expected.

Buried inside a thousand-year-old knowledge system was what every software engineer would immediately recognize as a deterministic finite state machine.

Not a metaphor.

An actual state machine.

The Discovery

One challenge in Ramal is determining the temporal behavior of an outcome.

Is an event approaching?

Is it moving away?

Will it remain stable?

Or is it inherently unstable?

Modern software engineers would probably model this using an enum.

The Ramal tradition did exactly that—long before programming languages existed.

Every one of its sixteen symbols belongs permanently to one of only four states.

class Gati(Enum):
    DAKHIL   = "Entering"
    KHARIJ   = "Exiting"
    SABIT    = "Stable"
    MUNQALEB = "Transforming"

That's it.

Every possible input maps to exactly one state.

No ambiguity.

No probability.

No fuzzy inference.

A Static Lookup Table

The implementation ended up looking surprisingly modern.

STATE_TABLE = {
    "1211": Gati.DAKHIL,
    "1121": Gati.KHARIJ,
    "2222": Gati.SABIT,
    "1111": Gati.MUNQALEB,
    # ...
}

The engine doesn't calculate the state.

It simply performs a lookup.

The state is immutable because tradition already assigned it centuries ago.

Once the state is known, downstream behavior becomes deterministic.

if state == Gati.DAKHIL:
    timing = "1–7 days"

elif state == Gati.KHARIJ:
    timing = "2–4 weeks"

elif state == Gati.SABIT:
    timing = "2–6 months"

else:
    timing = "7–21 days"

If you've written protocol handlers, parsers, workflow engines, or embedded software, this pattern probably feels familiar.

What Makes It Interesting

The remarkable part isn't that ancient scholars classified symbolic figures.

Many traditions do that.

The remarkable part is how they classified them.

The system has several properties we still value in software architecture today:

Deterministic
Exhaustive
Immutable
Composable
Easy to verify
No undefined states

Every possible input is handled.

Every input produces exactly one state.

Nothing is left undefined.

Beyond the State Machine

While implementing the engine, I noticed something even more interesting.

The four movement states aren't the only classification.

Each figure also carries independent attributes describing its temperament and behavioral nature.

Instead of exploding into dozens of special cases, these independent dimensions compose cleanly into what is essentially a multidimensional domain model.

From a software design perspective, this is surprisingly elegant.

Ancient Domain-Driven Design?

One observation kept occurring to me while writing the engine.

The original practitioners obviously weren't thinking about enums, finite automata, or type systems.

Yet they arrived at a structure that maps naturally onto all of them.

The implementation required remarkably little interpretation because the underlying model was already highly structured.

Sometimes good architecture simply transcends technology.

Why I Wrote About It

This isn't really an article about divination.

It's an article about discovering computational thinking in an unexpected place.

As developers, we're accustomed to believing that formal state modeling belongs to modern computer science.

But occasionally history reminds us that people were building elegant rule-based systems long before computers existed.

And that's fascinating.

Read the Complete Technical Breakdown

The full article includes:

the complete 16-figure state table
the four canonical movement states
Python implementation details
timing engine logic
coherence scoring
structural invariants
why the model is effectively a deterministic finite state machine

You can read the complete article here:

https://dotsofdestiny.com/blog-post-ramal-state-machine.html

I'm curious whether you've encountered other historical systems whose architecture resembles modern software design. I'd love to hear your examples in the comments.

Building a High-Performance Progressive Web App Without React or Next.js

Arvind Jolly — Mon, 22 Jun 2026 11:13:19 +0000

Lessons learned from improving performance, caching, and user experience in a production web application.

The Problem

When we set out to build SAGE (School of Ancient Geomantic Education), our focus was not initially on Progressive Web Apps.

SAGE combines traditional systems such as Western Geomancy and Indian Ramal Shastra with modern web technologies, educational resources, interactive calculators, and AI-assisted interpretation.

As the platform evolved, performance, reliability, and user experience became increasingly important concerns.

Our users access the platform from a wide variety of devices and network conditions. Some use desktop computers with fast broadband connections. Others rely on mobile networks where latency and bandwidth can vary significantly.

We wanted the experience to feel fast, responsive, and dependable regardless of connection quality.

That led us to explore:

Service Workers
Intelligent caching strategies
Firebase Hosting optimizations
Progressive Web App technologies
Performance-focused UX design

The goal was not to create a fully offline oracle. AI-assisted readings continue to require backend services and network connectivity.

Instead, the objective was to improve performance, reduce unnecessary network requests, create a more resilient user experience, and make the platform feel more like a modern application than a traditional website.

This is the story of how we transformed a straightforward HTML + Firebase Hosting application into a faster, more polished Progressive Web App—without React, Next.js, or heavyweight build pipelines.

The Core Principle: Treat the Service Worker as a Router

Many PWA tutorials present caching strategies as isolated techniques:

Cache-first
Network-first
Stale-while-revalidate

In practice, a production application usually needs several of them simultaneously.

The most useful mental model we found was to think of the service worker as a routing layer.

Different content types receive different treatment.

Content	Strategy
Images, CSS, fonts, static JavaScript	Cache-first
HTML documents	Network-first
API requests	Pass-through
Configuration modules	Always fresh

The important question is not:

Which caching strategy should I use?

The important question is:

Which caching strategy should this particular resource use?

Once we adopted that mindset, the service worker became dramatically easier to reason about.

Public Content and Private Content Are Different Problems

One mistake I see frequently in PWA discussions is treating all pages equally.

They aren't.

Some pages are:

Public
Anonymous
Safe to cache

Others are:

User-specific
Session-aware
Privacy-sensitive

The boundary matters.

For example, serving a stale public calculator page is usually harmless.

Serving cached user-specific content to the wrong session is not.

Our solution was simple:

Public pages can be pre-cached.
Session-dependent pages are excluded from pre-caching.
Sensitive content is always fetched fresh.

The result is a much safer offline experience.

Never Cache the Service Worker

If there is one rule worth remembering, it is this:

Do not aggressively cache your service worker.

The service worker controls your entire update mechanism.

If the browser becomes stuck with an old service worker, every future deployment becomes harder.

Static assets can be immutable.

The service worker cannot.

Treat it as the control plane for your application.

Build an Escape Hatch

Eventually, every production application encounters one of these:

A bad deployment
Corrupted cache state
An update bug
A broken service worker

When that happens, users should not need to clear browser data manually.

We implemented a simple versioning mechanism that can:

Detect an application version change
Unregister outdated service workers
Trigger a clean reload

Think of it as an emergency recovery procedure.

You may never need it.

When you do need it, you'll be glad it exists.

Why We Chose localStorage Instead of IndexedDB

This decision often surprises developers.

IndexedDB is usually presented as the "correct" storage solution for PWAs.

For large datasets, that's true.

For our use case, it wasn't.

The application only needed to store:

Small pieces of user state
Temporary workflow data
Lightweight JSON payloads

Each payload was only a few kilobytes.

The benefits of localStorage were compelling:

Simplicity
Synchronous access
No schema management
Minimal implementation complexity

Could IndexedDB have worked?

Absolutely.

Would it have improved the user experience?

Not meaningfully.

Sometimes the simplest solution is the right solution.

The Most Overlooked Performance Problem: Fonts

Many performance discussions focus on JavaScript bundles.

In our case, fonts were the bigger challenge.

The application supports multiple writing systems, including:

Latin
Devanagari
Arabic
Japanese
Chinese

Without careful loading strategies, typography can easily become the largest source of perceived latency.

Three techniques made the difference:

Using display=swap
Adding preconnect hints
Caching font resources after the first visit

After the initial load, typography effectively became free.

Offline UX Is More Important Than Offline Technology

Most developers focus on the technical side of offline support.

Users don't care about your caching strategy.

They care about what happens when connectivity disappears.

When a page isn't available offline, users should never encounter a browser error screen.

Instead, provide:

A branded fallback page
Clear messaging
A recovery path
Consistent visual identity

The goal is not merely functionality.

The goal is preserving trust.

Fast Applications Need Feedback

An unexpected challenge emerged once everything was cached.

The application became extremely fast.

Page transitions often completed in under 100 milliseconds.

Users interpreted this as abrupt rather than responsive.

The solution wasn't optimization.

The solution was intentional motion.

Subtle micro-interactions:

Entry animations
State indicators
Ambient visual feedback

made the interface feel more polished despite adding virtually no latency.

This was a reminder that perceived performance and measured performance are not always the same thing.

What We Learned

After deploying and maintaining the application, a few principles stood out:

1. Service workers are routing infrastructure

Treat them like routers rather than cache containers.

2. Not everything belongs in IndexedDB

Simple state often benefits more from simplicity than scalability.

3. Offline experiences are UX problems first

Caching is only the implementation detail.

4. Every PWA needs a recovery mechanism

Eventually something will go wrong.

Plan for it.

5. Fast interfaces still need visual feedback

Perceived quality matters as much as measured speed.

6. Simplicity scales surprisingly far

For many applications, a lightweight architecture can outperform a far more complex framework-based stack.

Final Thoughts

The modern web platform already provides most of the tools needed to build capable offline applications.

Service Workers, Cache Storage, localStorage, and modern browser APIs are remarkably powerful when combined thoughtfully.

The biggest lesson wasn't technical.

It was architectural.

Offline support works best when it is treated as a product requirement from the beginning rather than an enhancement added later.

When that happens, the result feels less like a website and more like an application that simply happens to run on the web.

A Note on Offline Functionality

The techniques discussed in this article focus primarily on performance optimization, caching, installability, and user experience improvements.

While certain assets and resources benefit from browser caching, AI-assisted readings and other server-dependent functionality continue to require network connectivity and backend processing.

The goal was to build a faster and more resilient web experience rather than a fully offline application.

What has been your biggest challenge building PWAs in production? I'd be interested to hear what strategies have worked (or failed) for you.

About the Project

SAGE (School of Ancient Geomantic Education) is a modern geomancy platform that combines traditional Western Geomancy and Indian Ramal Shastra with contemporary software engineering.

The platform provides:

Free geomantic calculators and educational tools
Daily oracle readings
Premium AI-assisted geomantic consultations
Support for multiple languages
Offline-capable Progressive Web App functionality

Explore the project at dotsofdestiny.com and learn more about how ancient symbolic systems can be implemented using modern web technologies.

How We Modeled Conflicting Historical Knowledge Without Breaking Our Database

Arvind Jolly — Thu, 18 Jun 2026 12:37:54 +0000

How building an AI-powered geomancy platform forced us to rethink data modeling

Most software systems assume that there is a single source of truth.

A user has one email address.

A product has one price.

An order has one status.

Databases, APIs, and validation layers are typically designed around this assumption.

But what happens when your domain contains multiple valid truths?

This was a problem we encountered while building SAGE, an AI-powered geomantic platform that supports multiple historical traditions, including Western Geomancy and Indian Ramal.

Unexpectedly, the hardest challenge wasn't AI.

It was data modeling.

The Problem

Geomancy is built around sixteen foundational figures.

Each figure carries various attributes:

Element
Planetary ruler
Zodiac association
Interpretive meanings
Dignities and conditions

The complication?

Different historical traditions don't always agree.

For example, a figure may have one set of correspondences in a Western lineage and a different set in an Indo-Persian Ramal lineage.

From a historical perspective, this is normal.

From a software perspective, it creates an immediate design problem.

A naïve schema might look like this:

CREATE TABLE figures (
    id VARCHAR PRIMARY KEY,
    name VARCHAR,
    element VARCHAR,
    planet VARCHAR,
    zodiac VARCHAR
);

Looks fine.

Until two legitimate traditions assign different values to the same figure.

Now the database is asking a question that historians have debated for centuries:

Which version is correct?

The Wrong Solution

Many systems solve this by choosing one authority.

In effect:

One Figure
↓
One Interpretation
↓
One Truth

This simplifies implementation.

It also destroys historical fidelity.

As soon as we hardcode one interpretation, every other lineage becomes "wrong" according to the software.

That wasn't acceptable.

The Shift: Truth as Context

The breakthrough came when we stopped treating interpretations as facts.

Instead, we treated them as context.

The identity of a figure remains constant.

Its attributes become lineage-dependent.

{
  "figure": "puer",
  "binary_signature": "1101",
  "lineages": {
    "agrippa_western": {
      "element": "fire",
      "planet": "mars"
    },
    "ramal_traditional": {
      "element": "air",
      "planet": "mars"
    }
  }
}

Now the question becomes:

What is the element of Puer
within this lineage?

instead of

What is the element of Puer?

This distinction changed the entire architecture.

The Registry Pattern

Duplicating complete datasets for every tradition would quickly become unmaintainable.

Most lineages agree on the majority of attributes.

Only a small percentage differ.

To solve this, we implemented a layered registry pattern.

class FigureRegistry:

    def get_attribute(
        self,
        figure_id,
        attribute,
        lineage
    ):
        if lineage_override_exists():
            return override

        return baseline

Resolution order:

Lineage Override
        ↓
Tradition Baseline
        ↓
Default Registry

This gave us:

Smaller datasets
Easier maintenance
Cleaner onboarding of new traditions
Reduced duplication

Most importantly, it allowed the system to grow without rewriting existing data.

Why Snapshots Matter

The next challenge was versioning.

Suppose a reading is generated today.

Six months later, historical research leads us to revise part of a lineage definition.

Should old readings change?

Absolutely not.

A reading should remain reproducible forever.

The solution was to store a resolved snapshot with every generated reading.

{
  "reading_id": "rdg_892347",
  "tradition": "western_agrippa",
  "schema_version": "v1.2.0",
  "resolved_attributes": {
    "puer": {
      "element": "fire",
      "planet": "mars"
    }
  }
}

This gives us:

Auditability
Reproducibility
Historical consistency
Easier debugging

Every reading becomes self-contained.

The Broader Pattern

Although this project involved geomancy, the underlying problem appears everywhere.

Examples:

Legal Systems

Different jurisdictions interpret regulations differently.

Medicine

Clinical guidelines change over time.

Finance

Accounting standards vary across countries.

Taxation

Rules differ by region and version.

Historical Archives

Sources often contradict each other.

The common challenge is this:

Multiple valid interpretations must coexist inside a single system.

Traditional CRUD thinking doesn't solve that elegantly.

Context-aware architectures do.

What We Learned

The most valuable lesson wasn't about AI.

It was about knowledge representation.

Many domains don't contain a single source of truth.

They contain multiple authoritative perspectives.

The job of software architecture isn't always to eliminate disagreement.

Sometimes it's to model disagreement cleanly.

Once we accepted that idea, the architecture became significantly simpler.

Instead of forcing competing traditions into a single schema, we designed a system that allows multiple traditions to coexist while sharing a common framework.

In hindsight, that turned out to be a much more scalable solution than trying to determine which historical authority was "correct."

Final Thought

If your domain contains:

competing authorities
evolving standards
multiple jurisdictions
historical interpretations
configurable business rules

you may not have a data problem.

You may have a context problem.

And context is often easier to model than truth.

Originally inspired by architectural challenges encountered while building SAGE, an AI-powered platform for Western Geomancy and Indian Ramal traditions.

I'm the founder of SAGE (School of Ancient Geomantic Education), where we're building AI-powered systems for Western Geomancy and Indian Ramal. I write about software architecture, knowledge modeling, and the challenges of digitizing historical systems.

DEV Community: Arvind Jolly

How We Turned Geomantic Doctrine into Deterministic Software

The problem with asking an LLM to "do geomancy"

The basic pipeline

1. Muhurta: solving the chart backwards

The event itself becomes part of the model

2. Prashna: making an open-ended inquiry deterministic

3. Venture Viability: same architecture, different canon

Why deterministic computation matters

Reproducibility

Doctrinal control

Tradition separation

Better AI behavior

This is particularly visible in the prompts used by the new modules, which provide the model with the computed figure, element and planetary ruler information before requesting synthesis.

The broader SAGE architecture

The engineering lesson

The ancient system is the specification

Building a Silicon Oracle

Where this goes next

I Found a Deterministic State Machine Hidden in a 1,000-Year-Old Indian Knowledge System

The Discovery

A Static Lookup Table

What Makes It Interesting

Beyond the State Machine

Ancient Domain-Driven Design?

Why I Wrote About It

Read the Complete Technical Breakdown

Building a High-Performance Progressive Web App Without React or Next.js

The Problem

The Core Principle: Treat the Service Worker as a Router

Public Content and Private Content Are Different Problems

Never Cache the Service Worker

Build an Escape Hatch

Why We Chose localStorage Instead of IndexedDB

The Most Overlooked Performance Problem: Fonts

Offline UX Is More Important Than Offline Technology

Fast Applications Need Feedback

What We Learned

1. Service workers are routing infrastructure

2. Not everything belongs in IndexedDB

3. Offline experiences are UX problems first

4. Every PWA needs a recovery mechanism

5. Fast interfaces still need visual feedback

6. Simplicity scales surprisingly far

Final Thoughts

A Note on Offline Functionality

About the Project

How We Modeled Conflicting Historical Knowledge Without Breaking Our Database

How building an AI-powered geomancy platform forced us to rethink data modeling

The Problem

The Wrong Solution

The Shift: Truth as Context

The Registry Pattern

Why Snapshots Matter

The Broader Pattern

Legal Systems

Medicine

Finance

Taxation

Historical Archives

What We Learned

Final Thought

Further Reading