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