DEV Community: Arvind Jolly

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

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