One Protocol, Multiple Subjects

The question ontoref asks of a software project is precise: What are you? What principles define you? What tensions are you actively managing? What decisions have you made with lasting consequences? Where are you versus where you intend to be?

This turns out to be the same question that infrastructure environments need answered. And a body of authored work. And individuals.

The subject changes. The question is identical.

What They All Have in Common

Any system with identity and intent shares the same structural problem:

• Identity — what it is, what principles define it
• Active tensions — trade-offs that don’t resolve, they’re managed
• Durable decisions — choices with lasting consequences that constrain the future
• Observable state — where it is versus where it intends to be
• Drift — the distance between intention and reality, growing silently with time
• Operations — the actions that reduce that drift

Software projects have all of these. So do infrastructure environments. So does a body of authored work. So do people.

And they all benefit from the same architecture: an ontological layer that captures what IS, and a reflection layer that captures what BECOMES and operates to keep those two aligned.

Infrastructure

Infrastructure already uses DAGs — Terraform, Pulumi, Ansible. All of them describe how the system is provisioned. None of them capture why it exists as it does.

The why is where knowledge lives:

Service "auth"       --tension-->    Principle "stateless"
    reason: needs session state, but the principle forbids it

Constraint "zero-downtime"  --enforces-->  Practice "blue-green"
    reason: ADR-infra-003, after the 2025 deploy incident

This information is not in the Terraform plan. It’s in the memory of the engineer who was there, in a Slack thread from eight months ago, or nowhere at all. When that engineer leaves, the infrastructure loses its own history — it knows what it is, not why.

Infrastructure ontoref captures the architectural decisions of the infrastructure itself, with the same ADR formalism as software projects. It tracks state dimensions — which environments are stable, which are in active migration, what’s blocked and why. The FSM doesn’t track deployment status; it tracks epistemic status — how well the infrastructure understands itself.

Federation via NATS means each environment (dev, staging, prod) describes itself and can be queried from the projects that depend on it. Sovereign GitOps: the infrastructure knowledge lives with the infrastructure code, not in a vendor’s database.

Authoring — the Work

This is the subject ontoref reached last, and the one where the drift is most visible to the reader.

A Work — a book, a course, a documented method, a research corpus — is an authored coherent whole. It has a thesis, an architecture, and decisions that constrain every later edition. It faces the identical structural problem:

Chapter "field notes"   --tension-->   Thesis "method over recipe"
    the chapter earns its place only if it serves the whole

Decision "restructured Part II"  --constraint-->  every translation and adaptation
    with the same architectural weight as ADR-001

State "draft"   --blocker-->   "second edition"
    a dimension of the Work's FSM, not a task in a backlog

The drift here has a name authors already feel: the Work is disseminated as fragments — a post, a talk, an excerpt, a thread — and each fragment travels without the whole. Over time the fragments say things the Work no longer means, or the Work moves and the fragments stay behind. The reader meets the fragment, never the governed whole.

Authoring ontoref treats the Work as the subject and every fragment as a provenanced edge back to it. The ontological layer holds what the Work is — its thesis, its structure, the decisions that bind future editions. The reflection layer operates the dissemination: which fragments are live, which have drifted, which edition they belong to. The book is the archetype, not the boundary; dissemination is an effect of the Work, never its essence. The door says it in one line: diffuse the whole Work, not loose fragments.

Personal

This is the most radical application. But it follows directly from the same logic.

A person with values, roles, and long-term intentions faces exactly the same structural problem as a software project:

Value "depth"       --tension-->  Role "parent"
    reason: time is finite and both demand it fully

Decision "left company X"  --constraint-->  Future career choices
    with the same architectural weight as ADR-001

State "learning Rust"      --blocker-->     "contribute to ontoref-core"
    a personal FSM dimension, not a task list item

The knowledge graph here is not a productivity system. It’s not a second brain of notes. It’s a graph of commitments — typed, provenanced, with active tensions named rather than suppressed.

The drift problem is identical: who you are becoming versus who you intended to be. Reflection modes for a person might be weekly reviews, annual state assessments, or triggered reviews when a major decision introduces new constraints. The operational loop is the same — observe, detect drift, execute, record.

The Same Stack, Different Subject

Every one of these domains runs on the same infrastructure:

Sovereign storage: Knowledge lives alongside its subject — in the project repo, in the infrastructure code, in the author’s repository of the Work, in a personal vault. No vendor holds it. No platform dependency. NCL files versioned with the same discipline as code.

Multi-surface access:

VCS alignment: jj’s model — where the working copy is always a commit — aligns naturally with ontoref’s approach to continuous state capture. There is no “dirty state”; every moment is capturable. Radicle as transport makes the whole stack sovereign and P2P — code collaboration without a central platform.

Federation: Projects querying each other’s knowledge graphs without a central broker. Infrastructure environments exposing their self-knowledge to the projects that depend on them. Authors whose Work exposes its structure so every citation and excerpt resolves back to the whole. Individuals whose personal knowledge graph informs their contributions to the projects they work on.

Why Scale Matters

The smallest unit that can adopt ontoref is a person. One developer, one project, one infrastructure environment, one author with one Work. No team required. No budget conversation.

The largest unit is an ecosystem of federated, self-describing projects that can query each other’s knowledge without any of them being the authoritative central source.

That range — individual to ecosystem — is possible because the protocol is the same at every scale. The ontological DAG and the reflection DAG don’t change shape based on the size of the subject. They change in density and depth, not in structure.

The organizations that Talisman argues should invest in knowledge infrastructure are trying to build this top-down, with dedicated teams and multi-year programs. Ontoref makes it available bottom-up — starting with a single project, a single environment, a single Work, a single person, each describing themselves in the same language.

Ontoref is open source. The protocol specification, Nushell automation, and Rust crates are at repo.jesusperez.pro/ontoref/ontoref.