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

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.