On Building Software That Thinks About Time
We have built a world of software that fights against the nature of information.
Every enterprise runs on data. Yet the tools we've built to manage that data are fundamentally hostile to how information actually behaves. We force living, breathing business knowledge into frozen relational schemas. We pretend updates are atomic when business processes are continuous. We build systems that forget their past and then scramble to reconstruct it with audit tables and change data capture.
This is not an accident. It is the inevitable result of building on foundations that were never designed for the problems we now face.
The relational model gave us declarative queries over structured data. This was a triumph. But it came with assumptions baked so deep we forgot they were choices:
These assumptions served the computing constraints of 1970. They do not serve the business realities of today.
The past happened. It cannot unhappen.
When Alice's salary changed from $90,000 to $100,000, both facts are true. The first was true until Tuesday. The second has been true since. Any system that destroys the first fact to record the second has failed to represent reality.
We believe that append-only semantics are not an optimization—they are a fidelity requirement.
Every assertion in Open Ontology is timestamped and permanent. Retractions mark facts as no longer active; they do not erase them. Time travel is not a feature we added. It is a property that emerges from refusing to lie about the nature of information.
The world does not wait for your data model.
You do not know, on day one, every attribute a Customer will need. You cannot predict which relationships will matter. The traditional approach—define schema, write migrations, pray you got it right—is epistemologically backwards. It demands certainty before you have earned it.
We believe that schema should be discovered, not decreed.
In Open Ontology, adding a new attribute is as simple as asserting a new fact. There is no ALTER TABLE. There is no migration. There is no deployment. You learn something new about your domain; you record it. The schema is the set of attributes that exist, not the set of attributes someone predicted would exist.
This does not mean we reject structure. Object types exist. Validation exists. But they are lenses through which you view your data, not cages that constrain it. The map is not the territory.
A foreign key is a lie we tell ourselves for storage efficiency.
When we say Employee 42 works in Department 7, we are not describing a number in a column. We are describing a relationship—a first-class entity with its own semantics. When did it start? Who approved it? Is it the employee's primary department or a secondary assignment?
Relational databases cannot answer these questions because they do not believe the relationship is a thing. It is merely a value in a row.
We believe that relationships are entities, not attributes.
In Open Ontology, a link between two entities is itself an entity. It has a type. It has timestamps. It can have properties. You can query it, version it, reason about it. The graph is not simulated with JOINs—it is represented directly.
A function that might fail and a function that always succeeds are not the same type.
The exception model treats failures as supernatural events—control flow that transcends the call stack, invisible in type signatures, handled by whoever happens to catch them. This is not engineering. It is hope.
We believe that errors must be visible, composable, and inescapable.
Open Ontology is built on Effect. Every operation declares what can go wrong in its type. TripleStore.assert does not return Promise<Triple>—it returns Effect<Triple, WriteError>. The error is there, in the signature, demanding acknowledgment.
This is not bureaucracy. This is clarity. When you compose effects, the error types compose. When you handle errors, the compiler verifies completeness. The happy path and the sad path receive equal architectural respect.
The history of software is a graveyard of frameworks.
Every generation builds The Framework—the One True Way to structure applications. And every generation learns that frameworks are bet that the authors knew your problems better than you do. They did not.
We believe that composition of small, focused pieces beats configuration of large, opinionated systems.
Effect gives us this. Services are functions. Layers are transformations. The dependency graph is explicit, inspectable, testable. You do not configure Open Ontology—you compose it from pieces that each do one thing.
Want PostgreSQL instead of SQLite? That is a different layer, not a different application. Want custom validation? That is a middleware, not a fork. The system is not a monolith with extension points. It is a library of parts with connection surfaces.
SQL was a revolution in 1974. It is a compromise in 2024.
The relational algebra is beautiful for tables. It is awkward for graphs. JOINing five tables to traverse a relationship that should be a single hop is not power—it is penance for choosing the wrong abstraction.
We believe that Datalog is the right language for knowledge graphs.
In Datalog, you describe patterns. Variables that appear in multiple clauses create implicit joins. Recursion is natural, not bolted on with CTEs. Negation is expressible. The query says what you want; the engine decides how to get it.
And crucially, Datalog compiles to SQL. We do not abandon the relational model—we transcend it. The same SQLite that powers a billion mobile apps powers Open Ontology. The performance is real. The abstraction is higher.
Rich Hickey distinguishes between essential complexity—the inherent difficulty of the problem—and incidental complexity—the difficulty we create through poor choices. Our industry has normalized incidental complexity to the point where we mistake it for professionalism.
Consider what it takes, in a typical enterprise stack, to answer: "What was this customer's status last Tuesday?"
This is not essential complexity. There is nothing inherently hard about "what was true at time T." The difficulty is purely an artifact of systems that were not built with time as a first-class concept.
Open Ontology eliminates this entire category of incidental complexity by refusing to pretend that time does not exist.
Every fact knows when it became true. Every fact knows when it stopped being true. Querying the past is the same as querying the present—you just specify a timestamp. There are no triggers to maintain, no audit tables to synchronize, no temporal JOINs to fumble.
An ontology is a specification of a conceptualization.
This is not academic jargon. It is the most important sentence in enterprise software.
Your business has concepts: Customers, Orders, Employees, Contracts. It has relationships: Customers place Orders; Employees fulfill them; Contracts govern the terms. It has constraints: An Order cannot ship before it is paid; an Employee cannot approve their own expenses.
These concepts, relationships, and constraints exist whether or not you model them explicitly. They are your ontology. The question is not whether you have one—you do—but whether it is explicit, queryable, and shared.
Open Ontology makes the implicit explicit.
When you register an ObjectType, you are not creating a database table. You are documenting a concept that already exists in your business. When you define a ComplianceRule, you are not writing a stored procedure. You are encoding a constraint that humans already enforce manually.
The system becomes the single source of truth not by fiat but by faithfulness. It earns trust by accurately representing what your business actually believes.
Palantir was right about one thing: institutions are drowning in disconnected data.
Every department has its system. Every system has its model. Every model has its assumptions. And nobody has the complete picture. The CFO asks a question that spans sales, support, and engineering; three people export CSVs; someone reconciles them in Excel; the answer arrives two weeks later, probably wrong.
This is not a technology problem. It is an ontology problem.
We believe that a unified knowledge graph is not a luxury for Fortune 500s—it is a necessity for any organization that makes decisions.
Open Ontology is that graph. Import from Salesforce. Import from Stripe. Import from your legacy system with the schema nobody understands. Use namespaces to organize by source; use :same-as relationships to link entities across sources. Query across everything.
The question "which high-value customers have critical support issues and engineering escalations" is not a three-week project. It is a Datalog query. The answer is minutes away, not meetings away.
Enterprise software has historically been closed, expensive, and extractive.
This made sense when software was a capital expense and vendors needed to recoup R&D through licensing. It makes less sense when software is an operational expense and the value comes from network effects.
We believe that foundational infrastructure should be open.
Open Ontology is MIT licensed. You can run it on your laptop. You can run it on air-gapped servers. You can fork it and never contribute back. This is not altruism—it is strategy.
The value of a knowledge graph compounds with adoption. The more organizations model their domains in Open Ontology, the more patterns emerge, the more integrations get built, the more the ecosystem grows. Closed licensing is a local maximum that prevents reaching the global one.
We will build commercial products on top. Others will too. The commons benefits everyone.
Imagine an organization where:
New questions are cheap. A product manager wonders about the relationship between feature usage and contract renewals. The answer is a query, not a project.
History is navigable. When something goes wrong, you can see exactly what the state was at any point in time—not from logs, not from reconstructions, but from the actual data as it existed.
Schema evolves with understanding. Learning that you need to track customer sentiment does not require a migration, a deployment, or a sprint. It requires an assertion.
Compliance is continuous. Rules are defined declaratively. Violations are detected automatically. Tasks are created and assigned without human intervention. Auditors see the same system operators see.
Integrations are assertions. Connecting a new system means mapping its data to triples. There are no custom APIs to build, no ETL jobs to maintain. Facts flow in; queries flow out.
The org chart queries itself. "Who approved this expense?" is not a question for the finance team. It is a graph traversal.
This is not a product roadmap. It is a statement of values. Every design decision in Open Ontology is made in service of this vision. Features that move toward it are prioritized. Features that move away are rejected.
The pit of success should be deep and well-lit.
If developers have to fight the framework to do the right thing, they will do the wrong thing. The right thing must be the easy thing. Assert a fact—it gets a timestamp automatically. Query the past—the syntax is the same as querying the present. Handle an error—the type system shows you what's possible.
A little more thinking at the start saves a lot of debugging at the end.
Effect's learning curve is real. Datalog requires a shift in thinking. The EAV model is unfamiliar. We do not apologize for this. These are investments that pay dividends forever. The alternative—hiding complexity until it erupts in production—is not kindness. It is postponed suffering.
Code is written once and read many times.
We prefer explicit over implicit. We prefer verbose over clever. We prefer types that communicate intent. The reader—often your future self—deserves to understand what the code does without running it in their head.
If it compiles, it probably works.
Effect's type system is remarkably good at catching bugs before runtime. We lean into this. Errors are types. Dependencies are types. The absence of something is a type. When the compiler accepts your code, you have high confidence it does what you think it does.
The best code is code you can delete.
Tight coupling is debt. Global state is debt. Implicit dependencies are debt. We structure Open Ontology so that pieces can be removed as easily as they were added. Layers can be swapped. Services can be replaced. The system should be less than the sum of its parts, not more.
Magic that hides essential complexity. ORMs that pretend databases are object stores. Frameworks that auto-generate code you don't understand. Abstractions that leak at the worst possible times.
Ceremony without purpose. Configuration files for defaults. Factories that create factories. Boilerplate that exists because the framework demands it rather than because the problem requires it.
Premature abstraction. Interfaces for single implementations. Generics with one type argument. Flexibility we will never use.
Silent failures. Empty catch blocks. Errors logged and ignored. Functions that return null when they should throw.
Update-in-place semantics. Mutable state that erases history. Lost audit trails. The arrogance of believing the past doesn't matter.
This manifesto is not a sales pitch. It is a declaration of beliefs.
If you believe data should tell the truth about time—join us.
If you believe errors deserve respect—join us.
If you believe schema should emerge from understanding—join us.
If you believe the small organization deserves the same data infrastructure as the large—join us.
Open Ontology is not finished. It may never be finished. But it is principled. Every line of code is written in service of ideas larger than the code itself.
We are building software that thinks about time. Software that treats relationships as first-class. Software that composes rather than configures. Software that makes the right thing easy.
This is what we believe. This is what we build.
"Simple made easy." — Rich Hickey
"Clarity over cleverness." — DHH
"Make illegal states unrepresentable." — Yaron Minsky, via Scott Wlaschin
"The future of software is institutional." — Alex Karp
"Effects are values." — Effect
December 2024