Nouns, Verbs, and Permissions: The "Ontology Layer" in the Age of AI • Record reality Piece memory

Some time ago I watched an interview. Palantir’s CEO, Alex Karp, sat there talking about enterprise AI in a tone bordering on losing his composure, saying that something had gone completely wrong. What made the clip travel was his temper, along with his grievances against a few frontier model companies. But what actually caught me was a word he kept returning to: ontology.

He said that for large language models to be genuinely usable in enterprise settings, battlefield settings, or regulated settings, there has to be an “application layer,” and that they call theirs the ontology. He said this layer makes the model “safe and useful and precise.” He said everyone is copying it now.

I have no interest in his commercial claims. That part is a fairly crude inference, and this piece does not deal with it. I also do not intend to pass judgment on the labs he named. I should say plainly that I am a heavy user of AI myself, and the unease I am about to describe is my own. It is not an abstract industry question.

But the word stuck. A few months earlier, during a corporate internship, I had taken part in a discussion about an enterprise data model (EDM), and afterward I built an independent project that implemented, end to end, what I understood from it. When I went to look up what an ontology actually is, I found that I barely needed to learn anything. I was looking at something I had already built, with its consumer swapped out.

And that swap, it turns out, answers a question I had not been able to phrase for a long time: as we begin to use AI at scale, what happens to the sensitive things?

This is not a conclusive piece. It is a complete record of a process of thinking. I want to preserve the whole chain, from encountering a word to relocating a doubt, because several of the branches along the way deserve to be developed on their own.

If I have to state the destination up front, it is this:

Model capability can be bought with time and money, so it will keep getting stronger and keep getting cheaper. The contents of an ontology layer are not technology; they are your own business, and no vendor can buy them for you. What an enterprise really needs to notice is that this is a choice at all.

Here is how I got there.

1. What the Word Actually Means

A necessary clarification first, or everything below becomes a misunderstanding.

What Palantir means by ontology is not the philosophical study of being, and not knowledge representation in the OWL or description logic tradition. Its lineage is closer to a fusion of three things: the ubiquitous language of domain-driven design, knowledge graphs, and workflow engines. I will call it the ontology layer below, but please keep that qualification in mind throughout.

According to Palantir’s own documentation, the ontology layer is the “operational layer” of an organization. It sits on top of the data assets connected to the platform and links them to their real-world counterparts. It is composed of two sets of elements:

Semantic elements: object types, properties, link types. These are the enterprise’s nouns: which entities exist, what characteristics they have, and how they relate to one another.

Kinetic elements: action types, functions, dynamic security. These are the enterprise’s verbs: who may do what to an object, under what preconditions, with what side effects, written back to which system, and leaving what trace.

There is a line in their documentation that captures it precisely: the ontology layer describes not the data, but how the enterprise decides and acts.

Nouns, verbs, permissions. That is the whole thing. It sounds plain enough to be suspicious. But it was precisely that plainness that let me recognize it in ten minutes.

2. Why I Recognized It in Ten Minutes

From Local Maps to an Absolute Coordinate System

During that internship, I spent some time trying to understand the data flow among several internal systems: an intake system that received external submissions, a middle layer that moved things along, a system of record, an integration middleware layer that handled transformation and translation, and a number of downstream operational systems. Data moved among them constantly, with manual intervention and automated processes interleaved, the manual steps filling the seams where automation had not connected.

The longer I looked, the more a hypothesis formed, and I wrote it into an email at the time:

Although data flows continuously across multiple systems, the same business concept may not be expressed consistently across those systems, in naming, in structure, or even in meaning.

If that hypothesis holds, the consequence is not merely a few extra translations at integration time. The deeper issue is coupling: when you want to add a field or adjust a piece of logic, semantic and structural inconsistency forces a local change to fan out into a coordinated change across multiple systems. At small scale this is tolerable friction. As system and data complexity grow, it becomes a structural constraint that directly limits future extensibility.

At the time I reached for a metaphor to understand what an EDM is really trying to do:

Each system maintains its own “local map.” These maps work within their own boundaries, but they are built on their own relative coordinate systems. When you try to stitch them together, the absence of a shared coordinate system makes alignment extremely difficult. An EDM is like introducing a shared “absolute coordinate system” above these maps, so that different systems can align to the same spatial structure while retaining their own implementations.

I still think that metaphor is accurate. It captures what a semantic layer is: it does not replace the local systems; it gives them a common reference.

But it has a gap, and that gap is the hinge of this entire piece.

A coordinate system only answers “where.” It does not answer “what can be done.”

An absolute coordinate system can tell you that the case in system A and the file in system B refer to the same thing. It does not tell you who is allowed to move that thing from “pending” to “completed,” what must be true before the change, which systems need to be notified afterward, or what trace the change should leave behind.

What the ontology layer has that an EDM does not, is verbs.

My Own Project Had Already Grown Verbs

After that discussion, I realized that staying at the conceptual level would not be enough to internalize any of it, so I built an independent experimental project (Enterprise Integration Lab; the code and full documentation are in my portfolio). It is a deliberately industry-neutral simulation of enterprise integration: an intake portal, an event queue, a background worker, a normalized canonical semantic layer, a downstream operational workflow system, a document repository, and a set of semantic lineage and audit records.

When I went back and reread my own code in the vocabulary of the ontology layer, the correspondence was nearly one to one:

Ontology primitive	What it is in my project
Object types (nouns)	`canonical.business_objects`
Link types (relationships)	`canonical.lineage` records
Action types (verbs)	`PATCH /operational/cases/{id}/status` plus a whitelist of allowed status transitions plus `case_status_history`
Write-back and state propagation	`OperationalCaseStatusChanged` event plus a worker that syncs status back to the canonical layer
Auditability	`sync_logs` plus status change history
Dynamic security (object-level permissions)	Absent

I will come back to that last row. Look at the ones above it first.

The status transition design I wrote was this: the only legal transitions are open → in_progress, open → rejected, in_progress → completed, and in_progress → rejected, and everything else is rejected. Every change is required to record the previous status, the new status, who changed it, why, and when. After the change, an integration event is emitted, a worker asynchronously propagates the status back to the canonical layer, and a lineage record is written.

Structurally, that is an action type: a typed verb, with precondition checks, with declared side effects, with an audit trail, with asynchronous write-back. At the time I did not think I was doing anything special. I simply thought that people should not be able to move a completed case back to “not started.”

There is a second, sharper hit. Early in the project, I embedded the customer and agreement a user selected in the form directly into the free text of the request description. Functionally it worked fine. Later I extracted them into structured UUID foreign keys, and I wrote the lesson down in my project notes:

Text is not a substitute for relationships.

Looking back, that sentence is almost the defining move of an ontology layer: taking semantics that were implicit in natural language and promoting them into structured relationships that a machine can reference without ambiguity. I wrote it after stepping in the hole myself, not after reading it somewhere.

The Structure Did Not Change. The Consumer Did.

So my relationship to this concept is not “my project is a simplified version of it,” and not “it is an extension of my project.” The accurate statement is:

The structure is the same. The consumer changed.

My canonical layer was built for interoperability between systems. Its consumer was another system: a system with a fixed schema, with deterministic behavior, one that throws an exception when you pass it the wrong argument and does not improvise.

The ontology layer is the same skeleton, but its consumer is now an executor with no organizational memory, no tacit knowledge, and no entitlement to default trust.

The substitution looks light. What it changes is the entire trust model.

A human operator carries tacit semantics. An employee of five years knows that the case in the operational system and the file in the content repository are the same thing. He knows that a status stuck at a certain value means someone has to pick up the phone. He knows which field must not be touched at month end. This knowledge lives in people’s hands, not in any system, and it is supplied at runtime, on the spot, by a person.

Precisely because of this, enterprises could tolerate a semantic model that never left the documentation layer, because the executor was human.

A large language model has no such organizational memory. Hand it a raw schema and it will perform operations that are syntactically correct and semantically wrong, with great confidence.

And so the semantic layer stops being a design-time governance artifact and becomes a runtime execution interface. That is the real leap from EDM to ontology layer, and it is the technical substance of the “application layer” Karp keeps invoking.

3. It Broke My Unspeakable Unease into Three Answerable Questions

My unease used to be vague. It went roughly like this: if I bring AI into workflows at scale, what happens to all the sensitive material inside the company?

The reason that question was uncomfortable is that it could not be asked. It was too general. So general that it could not be worked on.

The greatest value of the ontology layer, for me, was not that it gave me an answer. It was that it let me break the question into three questions that can be answered separately:

One: what can the model see? Two: what can the model change? Three: where does this happen, and who runs it?

These three are not industry terminology, and they are not Karp’s framing. They are an analytical frame I built in order to take the concept apart. Their value is that each of the three has its own answer, and mixed together they have none.

What Can It See

The two ends of the answer are: at one end, hand the model the raw tables and schema; at the other, the model can only see objects and properties that have been resolved, trimmed, and authorized.

The ontology layer does real work here. What the model receives is not tables. It is objects. Sensitive properties can be excluded at the semantic layer so that they never enter the context at all. Not encrypted. Never present in the model’s field of view.

Karp’s very marketing-sounding line, “safe because it doesn’t touch your underlying data,” means exactly this.

Looking back at my own project, this was already physically implemented, for entirely different reasons. In the document repository, binary files went into object storage, and the relational database held only metadata: document ID, the submission it belonged to, the request it belonged to, file name, document type, storage key, upload timestamp. Business logic reads only metadata.

Translated into AI terms: an agent can route, classify, and decide based on document metadata without ever touching the file contents. My reason for that design at the time was simply “do not mix binaries into business tables.” The same design, under a new trust model, means something entirely different.

Then there is the reference layer. I constrained customers, agreements, request types, and teams into controlled reference data, so the form offers a dropdown and does not accept free text. My reason then was to stop users from entering values that do not exist in the upstream systems. In an AI context, it becomes something else: it constrains where the model’s output is allowed to land. The AI’s normalization result has to fall into a known, closed set, or it is rejected.

What Can It Change

The two ends of the answer are: at one end, give the model write access to the database (a disaster); at the other, give it a set of declarative verbs with precondition checks and audit trails.

This is what the ontology layer’s action types do. The model cannot perform arbitrary operations. It can only propose an action that has already been declared, with typed parameters, validated by deterministic code before execution.

Which means a hallucination cannot turn into an undeclared operation. The model may talk nonsense, but the product of that nonsense has to pass through a deterministic gate first.

This is exactly what the whitelist of status transitions in my project was doing. The gate I wrote for human operators can, unchanged, catch an agent.

Where It Happens, and Who Runs It

The two ends of the answer are: at one end, send the data to some SaaS API; at the other, a local deployment inside an air-gapped environment with model weights owned by the customer.

The ontology layer does nothing at all about this one.

It is outside its scope. It can only be resolved through deployment boundaries and contracts: zero-retention clauses, weight ownership, isolated environments.

The Palantir and NVIDIA partnership announced on June 29, 2026 addresses precisely this axis: bringing NVIDIA’s open-weight Nemotron models into air-gapped and classified environments, where the customer trains on its own data, on its own infrastructure, and retains full ownership of the resulting model, weights included.

Karp’s wording in that announcement is worth noting. He said the point was to remove the risk of proprietary insights migrating into the weights of closed models.

In other words, he concedes that what needs isolating is not only the data, but also the things that sink into the weights. I will return to this in section 5.

As for my own lab, it runs on a virtual machine I own, under Docker Compose, on a local network. That is one extreme answer to this axis.

Zero Trust, Displaced

If I have to give these three questions a theoretical anchor, the closest one is Zero Trust: assume no executor is trusted, grant least privilege one authorization at a time, and leave an auditable trace throughout.

What the ontology layer does is essentially move Zero Trust from the network layer to the semantic layer. Classical Zero Trust asks which machine and which identity a request came from. The ontology layer asks which objects an executor can see and which verbs it can call. The same principle, at a different level of abstraction.

The Thing I Left Out

Now back to the last row of the table.

In the “What This Project Is Not” section of my project, I explicitly excluded authentication and role-based authorization. My reasoning at the time was defensible: this was a demonstration project, and permissions were not what I was trying to show.

But once the executor changes from a system to an AI, permissions are the one layer that cannot be left out.

System to system, permissions can be backstopped by network boundaries, by deployment conventions, and by the premise that the other system will not improvise. Once the executor is something that does improvise, every one of those backstops fails. Permissions are the only thing left standing.

This is the most honest criticism I have of my own project. It is not a future improvement. It is a structural gap.

4. From Those Three Questions, a Judgment on the Enterprise Side

This is the part of the piece I consider most valuable.

First, the Vendor Side: Why the Model Layer Cannot Capture Outcome Value

Karp asks a sharp question in the interview: if this thing is really so valuable, if I could make you a billion dollars tomorrow, why would I not say “I will make you a billion and I want thirty percent”? Why are they charging for tokens?

The observation itself is correct. Per-token pricing is commodity pricing, isomorphic with electricity and cloud bandwidth: metered, substitutable, billed by consumption.

But the conclusion he draws from it is wrong. He concludes that the sellers themselves do not believe it is worth that much.

The real reasons are structural, and they have nothing to do with what the seller believes:

Attribution is impossible. To charge for outcomes, you must be able to prove you caused them. And a component that can be swapped out at any time cannot, in principle, be attributed. The same supply chain optimization might lose two percentage points of accuracy with a different model, while the value difference is absorbed by the application layer, by data quality, by process redesign. You cannot assign thirty percent of the alpha to a replaceable part.

Measurement is impossible. Tokens are the only quantity observable and auditable on the vendor’s side. How much value the enterprise created is invisible to the vendor, and the vendor has no right to look. To look, you would have to get inside the enterprise’s books, which is exactly what the enterprise least wants to hand over.

Marginal cost is real. Inference burns compute and electricity. Things with real marginal costs get billed by usage. That is standard.

So the conclusion is: whether you can capture outcome value depends on whether you are replaceable, not on how valuable you are. The model layer accepted commodity pricing not because it is not worth much, but because it accepted (or was forced to accept) replaceability.

This conclusion is harder than Karp’s, and it explains both his anger and why his anger is pointed in the wrong direction.

But That Is the Vendor’s View. The Enterprise’s View Is Different.

Everything above is seen from the seller’s position. What I care about is not who gets to collect the money. What I care about is where an enterprise should spend its effort.

Starting from the same “component” premise, the enterprise-side inference runs like this:

First, model capability can be bought with time and money. Compute and chips will be expensive, but they do not constitute a wall that cannot be climbed. Which means models will keep getting stronger and keep getting cheaper. Paying a premium for whichever model is strongest today, or spending your negotiating energy driving that premium down, is haggling over something that is guaranteed to depreciate.

Second, the contents of an ontology layer are not technology. They are your own business. Which object types exist in your enterprise, which properties, which relationships, which verbs, which state transitions are legal, who is allowed to do what: no external vendor can buy these for you, because they are not in the vendor’s hands to begin with. A smarter model can help you write the layer faster. It cannot decide the layer for you. That decision is where your agency lives.

Put the two together:

Whatever can be bought with time and money will get cheaper. Whatever can only be defined by you will not. Enterprises should put their resources into the latter.

Why “Good Enough” Is a Viable Strategy

There is one more mechanism that makes this judgment hold economically: the ontology layer lowers how much intelligence a task demands of the model.

Give a model a pile of inconsistently named tables and a sentence like “handle this claim for me,” and it has to infer the semantics itself, guess the rules itself, and judge for itself which fields are trustworthy. That is a hard task. It requires a strong model, and it will still get things wrong.

Give a model a set of clearly defined objects, a list of legal verbs, and a closed set of permitted values, and the same business goal becomes an easy task. A weak model can complete it reliably.

What the ontology layer does is convert “semantics the model must reconstruct on its own” into “semantics the system supplies in advance.” The intelligence required for the same business goal is systematically lowered.

Two Paths, and the Asymmetry Between Them

So an enterprise faces two paths:

Path A: skip the ontology layer, and brute-force the mess with a stronger model. This also works, and that has to be conceded, or the argument is a straw man. The cost: paying a permanent premium for whatever is at the frontier; a capability ceiling set by how strong the model happens to be today; and outsourcing the hardest judgment to a black box you cannot audit.

Path B: build the ontology layer first, then choose a model that is exactly good enough for the actual difficulty of the task. The cost is the up-front modeling work.

Here is the asymmetry:

Path A’s cost is ongoing, escalating, and non-cumulative. Every model generation, you re-evaluate, re-procure, re-tune, and yesterday’s premium leaves you no asset.

Path B’s cost is one-time, cumulative, and cashed in repeatedly by every price drop. Your task difficulty has already been lowered; every time models get cheaper, you can move down another tier, while your semantic layer stays exactly where it is.

That is the rigorous reason for “obviously we would choose the second one.” It is not a value judgment. It is a cost structure.

But What Really Matters Is Noticing That This Is a Choice

This is the point I want to make.

An enterprise that has not noticed this problem exists will spend all of its effort on two things: picking a stronger model, and negotiating its price down. Neither is wrong. Both take place on the layer that is guaranteed to depreciate.

Noticing that the choice exists is itself the dividing line. Once you notice, you know where to push.

An Honest Counter-Case

The reasoning above is not universal. It has a clear failure condition:

When the business itself has not stabilized, Path B is wrong.

The ontology layer works by freezing business logic. If your business is torn down and rebuilt every quarter, what you freeze is noise. For early-stage companies and exploratory lines of business, being undetermined is itself valuable, and premature standardization will kill it. In that phase, brute-forcing the mess with a strong model is precisely the right call.

This qualification is not a patch. It reminds us that the ontology layer is infrastructure for organizations that already know what they are doing.

5. What It Does Not Solve, and Does Not Intend To

Up to this point the ontology layer looks extremely useful. But I have to draw its boundaries clearly, or this piece turns into a sales pitch.

Each of the three below could be an article of its own. Here I write only as much as each needs to stand.

Weights and Deployment: Outside Its Scope

I have said this already, so here I will add only one observation.

The more successful “what can it see” and “what can it change” become, the more they depend on “where does it run.”

Because the way you implement the first two is by organizing your most concentrated business logic into a clean, explicit, exportable layer. Once that layer exists, the question of whose machine it runs on, who can read it, and whether the vendor retains it gains enormous weight.

By building this layer you resolved the ambiguity of authorization, at the cost of manufacturing a single point of unprecedented value.

That, presumably, is why Palantir had to do the air-gap deal: the ontology layer is a thing that logically requires a deployment-side answer, or it becomes the largest leak surface in the building.

Confidentiality of the Logic Layer: No Technical Solution

This one is the hardest and the most interesting.

Start with a distinction: alpha is not one thing. It is two.

Data can be effectively protected. Air-gapped deployment, zero-retention clauses, property-level trimming, exposing metadata without exposing contents: that combination is reliable engineering.

What cannot be protected is the logic.

For AI to do work inside your enterprise, you have to explain the background: which objects exist, how they relate, which actions are legal, and what may be done under which conditions. The sum of these things is that enterprise’s business logic. And the background relationships you have explained, even if the definitions are translated and abstracted, are logically transparent already.

Compare that with how things used to be. A veteran employee knows that “when this case stalls at a certain status, you have to call so-and-so,” but he cannot say why. That rule lives in his hands, not in any document. Its resistance to theft is not the result of protection. It is the result of being inexpressible.

The ontology layer requires you to write it down. Once written, it becomes, for the first time, something that can be understood outside the company that produced it.

So this is not a defect of the ontology layer. It is its condition of success. It has to make business logic explicit before AI can use it. Making it explicit and making it leakable are two sides of one action. There is no technical solution.

Note, in passing, that Karp’s phrasing in the NVIDIA announcement already concedes this. What he is worried about is proprietary insights migrating into weights. Insights are not data. Insights are the logic.

Which brings me to a much older structure: the consultant’s paradox.

You bring in a consultant to solve a problem, and you have to lay out how the company actually runs. There is no way to guard against him and be helped by him at the same time. Hiring consultants, hiring auditors, hiring outsourced developers: for centuries, all of it has been the same act. To be helped, you must be understood. To be understood is to have been read.

And human society’s solution to this problem has never been technical. It has been nondisclosure agreements, noncompete clauses, licensure and its revocation, reputation markets, professional norms. All institutional. Not one of them technical.

AI has only enlarged the old problem. The consultant reads slowly, remembers little, and eventually leaves. The model reads fast, remembers everything, and may end up written into weights.

One step further along this line (not developed here; worth its own piece): if the logic layer cannot be kept confidential, then purely logical advantages will depreciate faster. Moats of the form “we understand scheduling, or underwriting, or pricing, better than they do” get shallower. Meanwhile execution, relationships, licenses, assets, and accumulated data, none of which can be obtained by reading, rise in relative value.

Compositional Privilege Escalation: Syntax Cannot Constrain Intent

This is the most important thing I derived on my own in this entire process, and the one that unsettles me most.

What the ontology layer’s action types resolve is only the syntactic ambiguity of authorization. They can constrain which actions exist, what type each parameter is, and whether preconditions are met.

They cannot constrain whether this action should be taken right now.

An agent can, with every single step legal, arrive at a result that was never authorized, through a sequence of legal actions.

An example. An agent has the right to export a single record (legal), the right to run bulk queries (legal), and the right to send notification emails (legal). It has no “export the entire database and send it outside” action type. But loop those three legal actions ten thousand times and the result is equivalent to one.

No single-point check can catch this, because every step passed.

To catch it, you have to make a judgment at the level of the action sequence. And “what does this sequence of actions add up to intending” is a semantic question, not a syntactic one. The ontology layer is a syntax machine. It has no purchase here.

6. Repositioning

At this point I can answer the question I started with.

What the ontology layer does is standardize something that had never been standardized before. But the deepest, most central problem is still exactly where it was.

The structure is perfectly symmetric with the history of EDM. An EDM did not solve “why did the business grow up this way.” It only gave data exchange a shared coordinate system. The ontology layer does not solve “should AI be trusted.” It only gives authorization a shared syntax. Both are necessary infrastructure. Neither is an answer.

And my unease has not been eliminated. It has been moved.

Where it used to sit: I am using AI at scale, so will my data get eaten?

Where it sits now: a sequence of actions, every one of them legal, will add up to what?

That is not a solution. But it is progress, because a vague unease cannot be worked on, and a precise one can.

And This New Unease Is No Longer Just My Intuition

After finishing the reasoning above, I went to look at where this field currently stands. The result: what I was worried about is already being worked on this year, and it has already been demonstrated.

The structure I derived, every step legal and the composition an escalation, now has a name in this year’s research and has been shown empirically. One line of work states plainly that today’s mainstream multi-agent frameworks all rest on an assumption that has never been systematically tested: if every subtask is individually safe, the plan as a whole is safe. The assumption is false. In the attack chains the researchers constructed, every individual step passed every deployed safety classifier, and the composed result violated enterprise policy. Another line of empirical work shows that chaining individually harmless tools into a sequence can yield attack success rates above ninety percent.

The institutional side is moving too, and the way it is moving is itself the point.

NIST launched its AI Agent Standards Initiative on February 17, 2026. The accompanying concept paper names two classes of vulnerability as most urgent: prompt injection, and accountability gaps in autonomous action chains, where an agent’s downstream actions cannot be traced back through the delegation chain to a responsible human. The second one is the thing I derived on my own. It has already been written into a government document.

Singapore published the world’s first governance framework aimed specifically at agentic AI on January 22, 2026. Among its recommended technical controls is limiting an agent’s access to whitelisted services, which is the same move as the whitelist of status transitions I wrote for human operators in my own project. And what it states repeatedly is that humans remain ultimately accountable. Compliance with the framework is voluntary. An organization’s legal accountability for its agents’ behavior is not.

The European Union is the most interesting case. The AI Act’s high-risk obligations, including the human oversight duty in Article 14, were originally set to apply on August 2, 2026. On June 29, 2026, the Council gave final approval to a simplification package that pushes those obligations to December 2, 2027. The stated reason for the delay is that the necessary technical standards and compliance tools are not ready.

That fact is a footnote to this entire piece. Rules can be written first. The technical foundation that would make the rules executable does not yet exist.

And one thing did not change, and it happens to bring this piece back to its center: the human oversight duty falls on the deployer, not on the model vendor.

This cannot be outsourced. That is a legal fact, not a claim of mine.

An Honest Rebuttal, and Its Turn

There is also a body of new technical work attempting to formalize intent itself: verifying an entire plan as a unit, binding actions to a user’s intent token, applying formal methods to oversight. Which is to say, the field is trying to turn intent into something that syntax can constrain after all.

So my judgment that syntax cannot constrain intent may be temporary. I cannot pretend not to see that.

But even if that road works, one link cannot be bypassed: to formalize intent, someone has to say first which intents are permitted.

And “what this company allows, what it forbids, and which combinations of actions are absurd for this business,” no vendor can answer for you.

So the human position has not disappeared. It has moved from execution to definition.

Which is structurally identical to the logic of the ontology layer itself: whatever can be automated will be automated, and the part that remains, remains precisely because it has to be decided by someone who genuinely understands the business.

There is a long road ahead. And I at least know now what it is I am worried about.

References

Center for AI Standards and Innovation. (2026, February 17). Announcing the “AI Agent Standards Initiative” for interoperable and secure innovation. National Institute of Standards and Technology. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure

Council of the European Union. (2026, June 29). Artificial intelligence: Council gives final green light to simplify and streamline rules [Press release].

European Union. (2024). Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.

Infocomm Media Development Authority. (2026, January 22). Model AI governance framework for agentic AI. Government of Singapore. https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai

NVIDIA. (2026, June 29). Open models, closed environments: Palantir brings secure AI to US agencies with NVIDIA Nemotron. NVIDIA Blog. https://blogs.nvidia.com/blog/palantir-secure-ai-us-agencies-nemotron-open-models/

Palantir Technologies. (n.d.). Ontology overview. Palantir Documentation. https://www.palantir.com/docs/foundry/ontology/overview

Palantir Technologies. (2026, June 29). Palantir launches engine for deploying NVIDIA Nemotron open models in sovereign environments [Press release]. https://investors.palantir.com/news-details/2026/Palantir-Launches-Engine-for-Deploying-NVIDIA-Nemotron-Open-Models-in-Sovereign-Environments/

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Wang, C. (2026). Enterprise Integration Lab [Portfolio project]. https://nortant.com/portfolio/enterprise-integration-lab/