Onturgy: What If Philosophy Shipped Code?

Onturgy: What If Philosophy Shipped Code?

A new paper argues that the most important philosophy of our time is already compiled into the systems we build — and it's almost never written down.

I want to tell you about a paper that made me stop and rethink what I do as a developer.

It's called "ONTURGY: The Philosophical Kernel" by Seyed Alireza Alhosseini Almodarresieh. It's open-source, forkable, and it has kill criteria — observable conditions under which its own claims fail.

That last part is what got me. A philosophy paper that says "here's how I could be wrong" and means it.

Let me explain why this matters to anyone who writes code.

The Problem: Your Stack Has a Philosophy (And It's Not Written Down)

Every consequential architecture carries philosophy. What counts as relevant, valuable, owned, an agent, an error. That philosophy is almost never declared. It's compiled into the system and then treated as neutral.

You've seen this. The platform that says "we empower users" while optimizing for attention extraction. The assistant that says "convenience" while implementing "delegation should replace deliberation."

The paper calls this gap Dark Ontology — the set of ontological, normative, epistemic, and political assumptions a system operationalizes without declaring them.

And here's the kicker: the gap is testable.

Write the declared commitments as explicit claims. Derive what each predicts under stress (user refusal, conflicting incentives, degraded conditions). Compare to observed behavior. The size and direction of the discrepancy is the declared-operational gap.

"Declared philosophy ≠ Operational philosophy"

This isn't just critique. It's a measurable claim.

The Possibility Graph: A Model You Can Actually Compute

Here's where it gets interesting for engineers.

The paper proposes a formal model:

G_t = (V, E, c, a)

• V: capabilities or states an actor can occupy
• E: transitions between them
• c(e): the cost of a transition (money, time, expertise, coordination)
• a(e): who can traverse it (access distribution over actors)

The footprint of a construction is:

ΔG = G_{t+1} - G_t

Nodes and edges added or removed. Costs changed. Access redistributed.

This turns "this platform is extractive" into something you can measure:

And exit cost splits into two components, only one of which is the target:

ExitCost = NaturalLoss + ArchitecturalBarrier

Natural loss is value that can't be moved because the relation itself constitutes it (the people in a network, the benefit of a good service). Architectural barrier is cost produced by design: non-portable formats, undocumented interfaces, contractual penalties, deliberate friction.

A rising exit cost isn't automatically coercion. Value accumulates legitimately. What's suspect is a rising architectural barrier.

This is a language for talking about lock-in that doesn't collapse into either "everything is fine" or "everything is coercion."

The Kernel: Six Questions Every Architecture Must Answer

The paper derives a kernel from an explicit criterion:

What must an architecture make explicit if it is to remain revisable by those it affects?

Six dimensions:

Plus a Capacity layer (Materiality: who owns infrastructure, who can block, who pays, who maintains; Labor: who performs the hidden work) and an Evaluation layer (Legitimacy: why is this architecture entitled to constrain alternatives; Reconstructability: can a different version be built?).

The kernel is not neutral. Exit and Contestability are values. A distribution that denies those below it any exit or any route to challenge its rules is excluded by the kernel. The paper calls this "a minimal constitutional-liberal floor, not a value-free substrate."

That's honest. Most frameworks pretend to be neutral. This one doesn't.

ONTacture: Testing Philosophy by Building

Here's the method:

Claim → Compile → Build rival architectures → Stress → 
Attribute failure → Assess negative horizon → Revise → Rebuild

Compile is the step that translates commitments into constraints. It's where philosophy becomes architecture, and where it can be distorted.

Failures get classified:

The Negative Horizon Rule: a theory-faithful implementation produces a consequence that's reproducible across independent implementations and can't be eliminated within the pre-registered search budget without changing a constitutive commitment.

Results are always reported relative to the search budget. The rule yields a candidate for revision, never an absolute refutation.

And then: revision. Name the commitment that changed. Judge it progressive (predicts a new consequence that's then tested) or degenerating (only absorbs the anomaly).

This is Lakatosian research programmes applied to software architecture. If that sentence excites you, you're the target audience.

The Second Level: Who Built the Builder?

The paper doesn't stop at architectures. It asks: what shaped the people who built them?

"Every architecture has an architect. Every architect has a lineage."

Lineage is defined as a dependency graph:

L = (N, U)

• N: concepts, commitments, sources, artifacts
• U: documented uptake edges (adopted, adapted, or rejected a concept, with evidence)

Evidence is graded: self-report, documentary, behavioral. The grade is recorded for every edge.

The testable claim: differences in documented lineage predict differences in the architectures builders produce, beyond what field, market, and resource constraints explain.

And then AI enters the lineage.

AI in the Lineage: When Does an AI "Own" Your Possibility Space?

Four properties distinguish AI from earlier lineage sources:

1. Responsiveness — adapts to the individual and the moment
2. Breadth — draws on many traditions at once
3. Weak provenance — outputs have no stable author or citable chain
4. Common cause — many builders may consult the same system

Each creates a risk: provenance laundering, dependence, homogenization, sycophancy.

The paper defines AI-owned configuration operationally. A human-AI system is in an AI-owned configuration when the human cannot do one or more of these at acceptable cost:

1. Reconstruct the reasoning behind a commitment without the AI.
2. Override the AI's suggestion (cost, expertise required).
3. Exit: continue the work with a different AI, or none, without losing the reasoning record.
4. Attribute: say which commitments originated with the AI and which with the human.

"Each is a measurement, not a feeling."

This is the part that hit me hardest. I've been using AI assistants for years. Have I been tracking which commitments originated with me and which with the model? No. Could I reconstruct my own reasoning without the AI? Honestly? Sometimes no.

The paper proposes a lineage log — every change to a commitment carries an origin tag:

change: C-AGENCY-01 revised
origin: human | ai_suggested | co_developed
ai:
  system: "provider and model, version if known"
  role: "critique | alternative | wording | none"
human_decision: accepted | modified | rejected
reconstructable_without_ai: yes | no

And a prediction: if many builders use the same AI as a mentor, the diversity of their commitments and architectures should fall relative to builders with varied mentors. Testable. Can fail.

The Repository: Philosophy You Can Fork

The paper proposes a concrete repository structure:

ontology/
|-- KERNEL.md          # six dimensions, criterion, exclusions
|-- commitments/       # one file per commitment
|-- encodings/         # compiled constraints + proponent-audit log
|-- architectures/     # one implementation per rival
|-- stress/            # pre-registered interventions, bridge principle
|-- audits/            # Onturgic audits with independent-auditor records
|-- lineage/           # lineage graph and lineage log
|-- results/           # observations, failure classes, graph footprints
|-- forks/             # divergences, each with its commitment diff
|-- CHANGELOG.md       # which commitment changed, why, and its origin tag

A commitment file:

id: C-AGENCY-01
statement: "Human agency requires meaningful alternatives."
status: constitutive
rivals: [C-OPT-01]
encoding: encodings/agency-01.md
audit:
  proponent: "<named defender of the theory>"
  verdict: signed_off | objections_recorded
bridge:
  observable: "task performance after system removal"
  direction: "higher retention supports C-AGENCY-01"
search_budget:
  implementation_checks: [...]
  re_encodings: 2
  parameter_ranges: {...}
origin: human | ai_suggested | co_developed

Generative depth: for a commitment C, the number of encodings, architectures, and results that change when C changes. A commitment with large depth is load-bearing. One with depth near zero makes no difference to anything — and the program should ask whether it's doing philosophical work at all.

This is dependency analysis for ideas.

Kill Criteria: How Onturgy Could Be Wrong

A program that can't name its own failure conditions hasn't earned the word "constructive."

1. Generativity fails if philosophically distinct commitments rarely yield non-trivial architectural divergence.
2. Measurability fails if graph footprints can't be estimated reliably outside a narrow class of software systems.
3. Forking fails as comparison if forks almost always turn out incomparable.
4. Translation fails if proponent audits routinely reject encodings as unfaithful.
5. Attribution fails if independent teams assign the same anomaly to different failure classes.
6. The kernel fails under ablation: if a dimension is never uniquely needed, it's redundant; if many failures are undetectable, the kernel is insufficient.
7. The audit fails if independent auditors can't agree on indicator classification.
8. Lineage fails if documented lineage explains no variance beyond field, market, and resources.
9. Homogenization prediction fails if shared AI mentors show no reduction in commitment diversity.
10. Provenance fails if origin tags can't be recorded reliably.

Each is testable. The first project of the program should be to test them.

Why This Matters for Developers

We are building systems that shape what people can do, be, and become. We're doing it at scale. And most of us are doing it without a language for the philosophy we're compiling.

Onturgy offers:

• A measurable model of practical possibility and construction's footprint
• A kernel derived from an explicit criterion, with exclusions stated
• An audit that detects the gap between declared and operational philosophy
• A method (ONTacture) for testing commitments by building rivals
• Fork semantics that separate philosophical disagreement from encoding and engineering variation
• A lineage graph and origin-tagged log that make AI influence inspectable
• Kill criteria — observable conditions under which the program's own claims fail

It's not a finished product. It's a research program. It's meant to be forked.

"Do not build a philosophy of the future. Build the kernel from which philosophies of the future can be built, and keep it forkable."

The Call

For the kernel: write a commitment as a file. Compile it. Build the rival. Fix the observable before you look. Stress both. Classify every failure before you interpret it. Audit a real system and compare your audit with someone else's. Tag where every idea came from — including the ones a machine gave you. Test whether you could rebuild your own reasoning without it.

"The world is not obliged to execute our philosophy. When it refuses, that is the philosophy being tested."

The paper: ONTURGY: The Philosophical Kernel by Seyed Alireza Alhosseini Almodarresieh (4 October 2026)

PhilPapers record: https://philpapers.org/rec/ALHPYC