Mnemo Atlas

The project began with more than twenty field studies covering areas such as architecture, film, fashion, philosophy, technology, and political thought. Each study asked the same questions:

• What does the field catalog?
• Which relationships matter?
• Which identifiers and vocabularies already exist?
• Which facts can be structured?
• And where does interpretation begin?

The research showed that very different disciplines repeatedly rely on similar underlying ideas. Rather than invent a new vocabulary for every field, I looked for the smallest common structure that could still preserve meaningful differences.

That principle also shaped the sourcing model. Mnemo is not intended to replace resources such as Wikidata, Getty vocabularies, museums, libraries, or specialist publications. It uses those systems as references while adding a layer for comparing and connecting records across disciplines.

The central design decision is that a relationship is itself a record. A connection is not simply an edge drawn between two things; it can carry its own verb, direction, explanation, subtype, provenance, and evidence. This allows the database to preserve contested or competing claims rather than silently reducing them to one answer.

Every entity shares a small set of fields the application needs everywhere: name, description, dates, location, identifiers, and timestamps. A separate many-to-many type system records whether something is a person, building, product, movement, work, or one of sixteen supported record types. An entity can carry more than one type when necessary.

Facts that vary between types live in a flexible attributes field. A building might have height and floor count, while a vehicle might have horsepower and payload. Each entity type has its own Zod schema, so those attributes are validated before a record is written. The database remains flexible, while the application still enforces what valid data looks like.

This avoids two less useful extremes: maintaining a separate table for every type, which would make cross-field relationships difficult, or creating one enormous table containing hundreds of fields that apply only to a few records. With one shared entity ID, a building can connect directly to a film, person, product, or philosophy, and every visualization can query the same underlying records.

The relationship system follows the same principle. Research across twenty fields produced six core relationship families:

• Influence
• Part of
• Similarity
• Co-occurrence
• Opposition, and
• Cause.

They are families rather than the entire vocabulary. Mnemo currently supports fifteen relationship verbs, with more specific relationships such as created, derived from, named after, and discovered by being able to sit beneath broader categories.

The six remain separate because they behave differently.

• Influence and part-of are directional;
• similarity, co-occurrence, and opposition work in both directions;
• part-of can form hierarchies; and
• cause is directional and must also record whether its effect is positive or negative.

Not every verb is forced underneath a core family. Preceded by, for example, remains distinct because succession does not necessarily imply influence.

Keeping the core small makes cross-disciplinary questions possible. "What influenced this?" can return relevant relationships across architecture, film, technology, and philosophy without requiring the user to know each field’s preferred terminology.

Automation can suggest new records and connections, but generated content does not enter the catalog automatically. It goes through a human review queue where the evidence is checked before approval. Entity writes also pass through one validated path, with automated tests guarding against code that bypasses the model. That friction is intentional: the challenge is not collecting the largest number of records, but deciding whether the structure and evidence around each connection are strong enough to keep.

The underlying model currently includes:

• 16 entity types sharing one core record structure
• 15 relationship verbs organized around 6 core relationship families
• Source attribution for both individual facts and relationships
• PostgreSQL and PostGIS for relational and geographic data
• Zod schemas for type-specific validation
• Import and moderation tools for reviewing proposed records and connections
• Automated integrity checks around the database and write paths
• 21 research reports covering twenty subject areas
• A cross-field comparison matrix used to develop the ontology
• A growing set of written decision records documenting why the model works the way it does

The architecture is designed so that the system can grow mostly through data rather than code. A specific concept such as Brutalism can be added as a record or classification rather than becoming a new database type, while genuinely new structural requirements can be introduced deliberately when the existing model no longer holds.