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.
Further Reading
This article was adapted from a real architectural challenge encountered while building SAGE (School of Ancient Geomantic Education), an AI-powered platform for Western Geomancy and Indian Ramal.
For the original article and additional discussion, visit:
👉 https://www.dotsofdestiny.com/blog-post-conflict-resolution
You can also explore the broader project at:
Top comments (0)