Peter Thiel's Zero to One asks a powerful question:
What can we build that does not yet exist?
But there is a question one level deeper:
What architectures determine what can exist in the first place?
This question is where I started developing Onturgy.
GitHub repository:
https://github.com/modarresi1913/Onturgy
Paper:
https://philpapers.org/rec/ALHPYC
From building things to building possibility
Software engineers already understand something philosophers often discuss only abstractly:
Architecture creates constraints.
An API determines what can be called.
A database schema determines what can be represented.
A protocol determines which interactions are possible.
An operating system determines which processes can run.
A platform determines which behaviors are rewarded.
The important point is that architecture doesn't simply enable actions.
It changes the space of possible actions.
Onturgy takes this observation seriously as a philosophical starting point.
Instead of asking only:
What does this system do?
we ask:
What does this architecture make possible, impossible, expensive, invisible, or irreversible?
The possibility graph
Consider a system as a graph:
G = (V, E, c, a)
Where:
- V = capabilities or states
- E = possible transitions
- c = cost of transitions
- a = distribution of access
Most software development assumes we are operating inside this graph.
Onturgy asks what happens when we modify the graph itself.
A new architecture can:
- add capabilities
- remove capabilities
- create new transitions
- eliminate existing transitions
- change transition costs
- redistribute who can access them
So instead of merely moving through:
A → B → C
we can change the underlying structure:
D
/ \
A ─── B ─── C
\ /
─── E ───
The philosophical question becomes:
Who gets to modify the graph?
Every architecture contains philosophy
An AI assistant is not philosophically neutral.
Suppose Architecture A has:
- proprietary memory
- irreversible delegation
- hidden optimization
- high switching costs
- centralized authority
Architecture B has:
- user-owned memory
- reversible delegation
- explicit authority boundaries
- portable state
- competing-model compatibility
Both may provide “AI assistance.”
But they construct radically different relationships between the human and the machine.
The difference is not merely UX.
It is philosophical.
The architecture has operationalized a theory of agency.
The Onturgic Kernel
Onturgy proposes a minimal constitutional layer around six dimensions:
Agency
Value
Authority
Memory
Exit
Contestability
These are not presented as universal metaphysical truths.
They are a minimal constitutional floor for architectures that claim to remain revisable by the people affected by them.
For example:
Agency
Who can initiate action?
Who can delegate?
Who can override the system?
Authority
Who makes the final decision?
Can an automated recommendation become an irreversible command?
Memory
Who owns the system's memory?
Can it be exported?
Can it be deleted?
Can it move to another architecture?
Exit
Can the user leave?
And what happens to their accumulated identity, history, relationships and capabilities when they do?
Contestability
Can the system's decisions be challenged?
More importantly:
Can the architecture itself be challenged?
From reversibility to reconstructability
This is where Onturgy goes beyond ordinary software reversibility.
There is a hierarchy:
Use
↓
Modify
↓
Exit
↓
Fork
↓
Reconstruct
A system may technically allow users to leave while making reconstruction practically impossible.
That distinction matters.
An architecture can be:
open enough to use,
but closed enough to replace.
Onturgy calls attention to this problem through concepts such as constructive lock-in and reconstructability.
The ultimate test is not:
Can you use the system?
It is:
Can you participate in rebuilding the conditions under which the system exists?
Why GitHub?
This is why the project lives on GitHub.
The repository is not merely a place to publish source code.
It is an experiment in open philosophical infrastructure.
The repository contains structures such as:
KERNEL.md
commitments/
architectures/
audits/
lineage/
stress/
results/
forks/
The idea is simple:
A philosophical commitment should be inspectable.
Its translation into architecture should be visible.
Its assumptions should be challengeable.
Its failures should be documented.
Its alternatives should be buildable.
And the framework itself should be forkable.
GitHub therefore becomes more than a distribution mechanism.
It becomes part of the philosophical method.
Philosophy as a build system
The deeper idea can be represented like this:
Philosophical Commitment
↓
Constraints
↓
Architecture
↓
Capabilities
↓
Possibility Space
But the process doesn't end there.
The resulting architecture encounters reality.
Commitment
↓
Architecture
↓
Reality
↓
Resistance
↓
Failure / Emergence
↓
Revision
↓
New Architecture
This is what I call ONTacture.
Construction is not proof.
Construction is philosophical exposure.
When an idea is forced into an architecture, hidden assumptions become visible.
The Thiel connection
This is also why I dedicated the paper to Peter Thiel.
Not because Onturgy is an extension of Thiel's philosophy.
Rather, I see a productive tension between two questions.
Thiel:
What can we build that does not yet exist?
Onturgy:
What architectures determine what can exist — and who gets to rebuild them?
Zero to One emphasizes technological and entrepreneurial creation.
Onturgy attempts to push the same creative impulse toward the level of architectural possibility.
The interesting frontier may not simply be creating another product.
It may be creating architectures that allow entirely new classes of products, institutions, and ways of organizing human–machine relationships to emerge.
That is a different kind of leverage.
The architect is part of the architecture
There is another problem.
We usually analyze the system.
We rarely analyze the person who designed it.
But every architect has a lineage:
Philosophy
↓
Thinker
↓
Builder
↓
Architecture
↓
Possibility
Books, mentors, institutions, technologies and philosophical traditions influence how builders perceive problems.
And now something new is entering this lineage:
AI.
AI can increasingly function not merely as a tool, but as an intellectual environment.
It can generate alternatives.
Challenge assumptions.
Combine philosophical traditions.
Suggest architectures.
Change what a builder considers possible.
The loop becomes:
Human
↓
AI
↓
Human
↓
Architecture
↓
New Possibilities
This creates a new question for the AI era:
What happens when the machine does not merely help build the architecture, but helps shape the architect?
The real alignment problem
This also changes how we might think about AI alignment.
Traditional alignment asks:
How do we align AI
with human values?
Onturgy asks an additional question:
How does AI participate
in shaping human values,
preferences,
institutions,
and possibility spaces?
Because:
Capability ≠ Authority
and
Prediction ≠ Legitimacy
An AI system can become extremely good at predicting what humans will choose without acquiring the right to determine what choices humans should have.
That distinction becomes increasingly important as AI systems move from tools toward agents, platforms, and cognitive infrastructure.
Don't just read it. Fork it.
Onturgy is deliberately not presented as a finished philosophical system.
The GitHub repository is an invitation to experiment.
You can:
- challenge the kernel
- propose a different kernel
- build rival architectures
- audit real systems
- test philosophical commitments
- document failures
- propose alternative encodings
- contribute new cases
- fork the framework entirely
The objective is not consensus.
The objective is generative disagreement.
A philosophy that cannot survive being forked is probably too close to doctrine.
A philosophy that can be forked, challenged, rebuilt and improved may become something more useful:
infrastructure for thinking.
The repository
ONTURGY — The Philosophical Kernel
GitHub:
https://github.com/modarresi1913/Onturgy
PhilPapers:
https://philpapers.org/rec/ALHPYC
The project is open.
Read the kernel.
Inspect the assumptions.
Break the architecture.
Build a better one.
Fork it.
Created by Seyed Alireza Alhosseini Almodarresieh
Top comments (0)