Where NC2.5 Sits Relative to Enterprise Decision-Centric Architectures

A Structural Locating Between Operational Decision Orchestration and Architectural-Class Theorems on Long-Horizon Viability

PETRONUS Whitepaper · Foundation Series

Maksim Barziankou (MxBv)
May 2026 · Poznań
Contact: research@petronus.eu
License: CC BY-NC-ND 4.0
DOI: 10.17605/OSF.IO/D7V5G
NC2.5 v2.1 axiomatic core: 10.17605/OSF.IO/NHTC5
Attribution: petronus.eu

1. What This Paper Is and Is Not

This paper performs a structural locating. It is not a comparison, not a critique, not a competitive positioning. It identifies where Navigational Cybernetics 2.5 (NC2.5) sits relative to the class of enterprise decision-centric architectures currently in production deployment, of which the publicly described Palantir Ontology is the most visible mature reference point.

The two architectures address different problems at different levels of abstraction. They do not compete for the same engineering territory. They do not solve the same question. The structural relationship between them is not hierarchical and not adversarial. It is a relationship between an operational layer and an architectural-class layer, and the value of stating it explicitly is that the structural clarity protects both.

The paper is written for two audiences in parallel. The first audience is the architect or technical decision-maker evaluating decision-centric platforms for enterprise deployment, who needs to understand what such platforms address and what they do not. The second audience is the researcher or engineer working on long-horizon adaptive systems, who needs to understand why a decision-centric architecture, however mature, does not by itself answer the structural questions that arise once an adaptive system must remain itself across operational lifetime under sustained burden.

The locating is structural, not commercial. Both classes of work are real, both are useful, and the clarity offered here is intended to protect the integrity of both.

2. The Decision-Centric Architecture Class

Enterprise decision-centric architecture, as exemplified by the Palantir Ontology and described in Palantir's public materials on the Ontology and AIP architecture (April 2026), is a software architecture organized around the act of deciding rather than around the storage of data. Its structural commitment is that the four constituent elements of any operational decision - information, reasoning, execution, and governance - must be modeled together rather than treated as separate concerns. This is the move that distinguishes the class from classical data warehousing, conventional analytics platforms, and traditional workflow orchestration systems.

In the Palantir formulation, the four elements appear as data, logic, action, and security. Data is integrated as a full-fidelity semantic representation of the enterprise - operational systems, edge sources, unstructured repositories, and the decision data generated by users and agents during the act of deciding. Logic is the heterogeneous set of reasoning assets - business rules, statistical models, optimization algorithms, simulation processes - that determine when and how a given decision is evaluated. Action is the orchestration and execution of the chosen decision, including the writeback of decision outcomes to operational systems. Security is the runtime governance of every interaction, applied uniformly across data, logic, action, and tool invocations.

The architectural primitives that make this work in production are recognizable. Objects, properties, and links form the semantic backbone. Logic binding provides a uniform interface across heterogeneous reasoning assets. Scenarios stage proposed changes in a sandboxed subset of the ontology before commit. Decision lineage captures the end-to-end provenance of every decision. Granular access policies are computed dynamically at runtime for every interaction. Tools surface data, logic, and action as first-class operations callable by both humans and AI agents under uniform governance.

This is mature engineering. It addresses a real and load-bearing class of problems, at production scale, across more than fifty industrial sectors. The structural integrity of the approach has been demonstrated in commercial deployments, government deployments, and time-critical operational contexts. The class deserves to be named clearly and recognized for what it is.

3. What Decision-Centric Architecture Solves

The decision-centric class answers a specific architectural question: how does an enterprise execute the best possible decisions in real time, across a constantly changing operational reality, while maintaining governance, traceability, and the safe integration of AI agents alongside human decision-makers.

The answer, in the production form of the class, has four load-bearing properties. The architecture supports per-decision quality, by integrating data, reasoning, and execution into a single substrate that the decision-maker - human or agent - can navigate and act through. It supports access governance at runtime, with policies dynamically computed for every interaction across data, logic, and action. It supports agent-tool integration, where AI agents access the same underlying primitives as human users under the same security architecture. And it supports real-time deployment, where decisions are synchronized to operational systems with full lineage and the ability to audit, roll back, and learn from every action.

These are non-trivial achievements. The class makes possible the reliable use of AI agents inside operational workflows that previously required exclusive human steering. It compresses the time between data integration and operational impact from months to days. It provides a substrate against which heterogeneous reasoning assets - including non-deterministic LLM-driven reasoning - can be combined without losing governance integrity.

Enterprises that need this capability and adopt platforms in this class are making a correct architectural choice for the problem they have. The class is not a partial solution. For the problem space it addresses, it is a mature and architecturally coherent answer.

4. The Axis Decision-Centric Architecture Does Not Address

A decision-centric architecture is organized around the act of deciding. Each decision is a transactional unit. The architecture optimizes the quality of each decision, the governance of each decision, the lineage of each decision, and the learning that compounds across many decisions.

This is the per-decision axis. It is one axis along which an adaptive system can be evaluated.

There is another axis. It is the axis along which a system is evaluated not by the quality of any single decision but by what happens to the system itself over operational lifetime. This is the survival axis. It concerns whether the system remains itself across sufficiently long time, under sustained adaptive load, in the presence of accumulating structural burden that no single transaction registers but that compounds across the lifetime of the system.

The survival axis is where drift lives. It is where structural identity preservation lives. It is where the question of whether an autonomous system, deployed for months or years, can continue to be characterized as the same system it was at deployment time becomes load-bearing. None of these are per-decision questions. None of them are answered by per-decision quality, however sophisticated the per-decision optimization becomes.

A decision-centric architecture, as publicly described, does not claim to formalize the survival axis in the NC2.5 sense. It is not a deficiency that it does not - it is a different question. Per-decision quality and survival viability are orthogonal. A system can have excellent per-decision quality and fail along the survival axis. A system can survive the survival axis without optimizing per-decision quality at all. The two are separable, and conflating them produces architectural confusion that has shown up repeatedly in long-horizon agent deployments.

The structural cost of leaving the survival axis unaddressed is not visible in transactional metrics. It is visible in degradation patterns that emerge only over the operational lifetime of the system, after the per-decision metrics have been optimized to apparent saturation. Recent empirical work on long-horizon agent failures — including the HORIZON benchmark (Wang et al., 2026; arXiv:2604.11978; full structural reduction in NC2.5 Empirical Probes I) — is consistent with this concern: degradation appears most clearly when agents are exposed to extended operational horizons rather than isolated transactional tasks. A structural reduction of the HORIZON results through the NC2.5 formal apparatus has been performed in NC2.5 Empirical Probes I (petronus.eu/works), showing that every failure mode documented in the benchmark maps to a specific NC2.5 primitive — τ-exhaustion, Φ-accumulation, or admissibility boundary crossing — rather than requiring ad hoc explanation. Read through the NC2.5 lens, per-decision capability metrics do not exhaust the structural problem of long-horizon viability. The HORIZON results are not anomalies. They are the predicted behaviour of systems operating on the per-decision axis alone.

5. NC2.5 as Architectural-Class Theorem

Navigational Cybernetics 2.5 is a formal architectural theory. It is not a deployment platform. It is not a software product. It is not a feature set that competes with decision-centric architectures or any other class of operational system.

Its central objects are formal. The structural burden Φ is a monotone irreversible load functional that accumulates over the operational lifetime of an adaptive system. The viability budget τ = C − Φ is a Lyapunov-type scalar, bounded above by the system's structural capacity C and decreasing as Φ accumulates. The admissibility predicate is a non-causal structural gate that determines which realizations are permitted before optimization selects among them, without itself participating in optimization. The spin component is the non-potential divergence-free component of system motion that is structurally necessary for non-stagnant identity on bounded orbits. The non-reconstructibility bounds NR-ε and NR-LR formally prevent the admissibility layer from leaking into any causal or distributional channel of the agent.

These are not deployment primitives. They are architectural-class objects. The theory states what any bounded adaptive system that must preserve structural identity across long time is required to satisfy at the foundation of its architecture, regardless of the specific deployment form. NC2.5 sits in the same line as classical results on architectural impossibility. CAP states what a distributed coordination system cannot achieve along the consistency-availability axis under partition. FLP states what an asynchronous consensus system cannot achieve along the deterministic-termination axis under failure. RINA states what a network organization cannot achieve along the recursive-uniformity axis under conventional layering. NC2.5 states what a long-horizon adaptive system cannot achieve along the survival axis if causal optimization is the only structural mechanism. The comparison is by architectural role, not by historical status, adoption, or maturity of proof tradition. The analogy is functional: each result marks a structural impossibility frontier for a declared system class.

The result is class-relative. It does not claim to apply to every adaptive system, only to systems within the declared architectural class - bounded τ, non-stagnant identity preserved across operational lifetime, sustained adaptive load. For systems outside this class, NC2.5 makes no architectural claim. The point of class-relativity is that the result becomes falsifiable at the level of implementation: an architecture in the declared class either satisfies the structural conditions or violates them, and the violation is observable.

6. The Two Levels

The decision-centric class operates at the deployment level. It addresses the engineering question of how an enterprise constructs an operational substrate in which decisions are made, executed, governed, and learned from. The unit of concern is the decision and the workflow.

NC2.5 operates at the architectural-class level. It addresses the structural question of what any system within a particular class is required to satisfy at the foundation of its architecture, before any deployment is built. The unit of concern is the architectural class itself - the family of all systems that share certain structural commitments, regardless of how they are deployed.

These are different levels of abstraction. They do not compete because they do not address the same question. A decision-centric platform answers what to deploy and how to operate it. An architectural-class theorem answers what any deployment within a particular class is required to satisfy if it is to remain coherent across operational lifetime.

The relationship between the two levels is not hierarchical in the sense that one is above the other. It is hierarchical in the sense that an architectural-class theorem constrains the space of possible deployments, and a deployment platform inhabits some specific point in that space. A given deployment platform either satisfies a given architectural-class theorem or does not. The theorem does not tell the platform how to be built. The platform does not contradict the theorem unless it explicitly violates the structural conditions the theorem states.

A decision-centric architecture, as currently formulated in the class exemplified by the Palantir Ontology, does not publicly specify the structural commitments required by NC2.5 for survival-axis conformance. Runtime governance, lineage, rollback, monitoring, and audit can preserve operational control across decisions; they do not, by themselves, constitute a monotone structural-burden model of system survival across operational lifetime. This is not a violation of NC2.5. It is a different commitment, made at a different level, addressing a different problem. The two architectures are not in conflict.

7. Where the Two Levels Could Meet

A decision-centric architecture could, in principle, be constructed to be NC2.5-conformant. The structural conditions are specifiable. The architecture would need a substrate-level admissibility predicate gating realization before optimization. It would need an explicit accounting of the structural burden Φ accumulating over the system's operational lifetime, distinct from the per-decision lineage already captured. It would need a viability budget τ tracked at the substrate level, not at the per-decision level. It would need the non-reconstructibility bounds to hold at the boundary between the admissibility layer and the rest of the system. It would need the spin component to be architecturally present, not an emergent property of the optimization layer.

None of these conditions is structurally incompatible with the existing primitives of decision-centric architecture. Objects, links, scenarios, decision lineage, and runtime governance can coexist with the NC2.5 substrate. What changes is what sits underneath them. The decision-centric primitives become the deployment expression of an architecture whose foundation includes the survival axis as a first-class concern.

This is not a recommendation that any particular enterprise platform be built this way. It is a structural observation that the conditions are specifiable, and that NC2.5 provides the formal language in which the specification can be written. Whether any specific platform team chooses to take the survival axis as a load-bearing concern is a product decision, not an architectural one. NC2.5 only states what is required if such a decision is made.

The publicly described Palantir Ontology does not claim NC2.5 conformance, and nothing in the public description requires such conformance. This is not a criticism. It addresses a different problem class. The locating offered here does not change that. What it does is make explicit the structural conditions under which a decision-centric architecture would also be a long-horizon-survival architecture. That clarity is useful in both directions.

8. What This Means in Practice

For organizations deploying enterprise systems where the decision is the unit of value - supply chain operations, customer service, real-time analytics, AI-augmented workflows that turn over within transactional time horizons - the decision-centric class is the correct architectural choice. The survival axis is not load-bearing at the relevant transactional time scale. The system is not expected to remain itself across years of sustained adaptive load. The system is expected to make excellent decisions, governed and traceable, and to be retrained or replaced when its decision quality degrades. For this problem space, decision-centric architecture is the mature answer.

For organizations building long-horizon adaptive systems where the unit of value is the system itself sustained across operational lifetime - autonomous agents deployed for months or years, scientific instruments running unattended adaptation cycles, governance systems where the integrity of the governing function is a load-bearing concern - the decision-centric class does not provide architectural foundation. It provides excellent infrastructure for individual decisions inside such a system, but the question of whether the system as a whole survives the operational lifetime sits at a different level. For that question, NC2.5 provides the formal language in which a foundation can be specified. The implementation is a separate concern, but the architectural language exists.

The dividing line between the two cases is not the size of the deployment, the importance of the customer, or the sophistication of the AI. The dividing line is the time horizon over which the system is expected to remain itself, and whether that horizon is long enough for the survival axis to become load-bearing. Many enterprise deployments today are below that horizon. The deployments where the horizon matters are growing, and they are the systems for which NC2.5 is built.

9. A Brief Note in the First Person

This is the only place in this paper where I will speak in the first person, and I will keep it short.

The reason I formalized NC2.5 is that I watched, over years, a particular architectural mistake recur across systems built by serious people in serious contexts. The mistake is to treat survival as an emergent property of decision quality. It is not. They are different axes, and the conflation between them is what produces the cliff-like long-horizon failures that recent empirical work has now begun to document independently. Decision-centric architecture is not the source of this mistake. The mistake predates decision-centric architecture by decades. But decision-centric architecture, however mature, does not by itself correct the mistake, because it does not by design address the axis along which the mistake compounds.

The Navigational Cybernetics school is being built around exactly this distinction. It is a school, not a platform. Its purpose is to formalize the architectural conditions for systems that must remain themselves across long time, to build the body of work in which those conditions are stated precisely enough that they become falsifiable and implementable, and to make the foundation available so that engineers building real systems do not have to rediscover, separately and painfully, what the survival axis requires. Navigational Cybernetics 2.5 is the foundation. The Engineered Vitality Systems class, defined in the Synthetic Conscience series of November 2025, is the positive engineering class that NC2.5 formalizes — artificial adaptive systems capable of independently maintaining coherence of behavioural form and structural identity under entropy, without an external controller. The Synthetic Conscience series is the next layer built on that foundation. Every subsequent work points back to the same structural commitment: that survival, in the architectural sense, is not a side effect of optimization, and that any system that needs to survive must be built on a foundation that addresses survival as its own axis.

This whitepaper is part of that work. It is a locating piece, not a polemic. The clarity it offers is meant to protect what the decision-centric class achieves, and to mark where the foundation that sits beneath the survival axis begins.

10. The Architectural Stack

The locating performed in the preceding sections is one section of a larger constructed system. To make the scope of that system visible — and to clarify what level of abstraction this whitepaper actually addresses — it is necessary to show the stack as a stack: a multi-layer architecture in which each layer has a distinct structural role, and the layers compose into a single coherent body of work.

The body of work referenced as "the Navigational Cybernetics school" is not a single paper, not a single domain, and not a single product line. It is a thirteen-layer stack in which behavioural-architecture foundations stand under formal mathematics, formal mathematics stands under ontological extensions, ontological extensions stand under an engineering class, the engineering class is approached through discursive series and standalone companion works, the architectural functions are realized through a protocol layer, the protocols support concrete operator instances, and the operator instances meet at a network platform. Each layer is load-bearing for the layers above and below it; none of the layers is decorative.

The full stack is given in Table 10.1.

Table 10.1 — The Navigational Cybernetics architectural stack

Three observations are visible only when the stack is read as a whole.

The first is that layers 3a, 3b, and 5 form a derivation chain: behavioural architecture → mathematical formalization → engineering class. The chain runs from prior conceptual identification to formal apparatus to positive engineering target. NC2.5 is not a free-standing axiom set in search of an application; it is the formalization of an architectural object that was identified earlier, and the engineering target it formalizes the conditions for is named explicitly in the corpus.

The second is that the layers labelled 6 through 9 (Extremes series, Synthetic Conscience series, Essay layer, Companion works) are not redundant. Each is a distinct register in which the architecture is expressed. Extremes diagnoses the limits where the architecture is tested. Synthetic Conscience works through the philosophical implications. The essay layer reports the architecture from inside the operator's seat. Companion works close specific structural gaps the series do not address. A reader who picks up only one register receives only one face of the architecture; the architecture itself is the conjunction of the registers.

The third is that the architecture has both technical infrastructure (the Protocol layer, layer 10) and a positive engineering target (EVS, layer 5). Layer 5 says what should exist; layer 10 says how it is realized; layer 11 says what has been instantiated. Together, layers 5–11 form the central spine of the stack. Layers 1–4 are the foundation; layer 12 is the distribution mechanism for the central spine across multiple operators.

The structural relationship to decision-centric architecture, which the rest of this whitepaper has located, is now legible at a different scale. A decision-centric platform inhabits a specific point in the deployment-space of layer-11-style operator instances built on a particular configuration of layer-10-style protocols. NC2.5, the discipline at layer 2, addresses what is structurally required of any such configuration if the system that uses it is to remain itself across long operational time. Different scopes, different layers, different problems — and now, at last, a complete picture of the stack the survival axis requires.

11. Closing

The publicly described Palantir Ontology is a mature, production-class decision-centric architecture. It addresses per-decision quality, governance, agent integration, and operational deployment at enterprise scale, across more than fifty industrial sectors. It does what it sets out to do, and it does it well.

NC2.5 is a formal architectural-class theorem on long-horizon viability. It states what any bounded adaptive system within its declared class is required to satisfy at the foundation of its architecture if it is to remain itself across sustained adaptive load. It does not compete with decision-centric architectures, and decision-centric architectures do not compete with it. They sit at different levels of abstraction, addressing different axes of the same engineering reality.

The Navigational Cybernetics school is the body of work in which the architectural foundation for long-horizon adaptive systems is being formalized. The foundation begins with the Engineered Vitality Systems class and NC2.5, and extends through the Synthetic Conscience series and the works that will follow. The purpose of the school is not to replace the decision-centric class or any other class of operational system. The purpose is to provide the architectural foundation that the survival axis requires, so that systems built to remain themselves across long time have the structural conditions stated precisely enough to build against.

Both kinds of work are real. Both are useful. The structural clarity offered here is meant to keep them properly distinguished, so that neither is mistaken for the other and neither is asked to do the other's job.

PETRONUS Whitepaper · Foundation Series, May 2026.
NC2.5 v2.1 axiomatic core DOI: 10.17605/OSF.IO/NHTC5
This whitepaper DOI: 10.17605/OSF.IO/D7V5G
petronus.eu · CC BY-NC-ND 4.0
Copyright © 2026 Maksim Barziankou. All rights reserved.