Identity, action, artifact, and decision are being argued separately by different authors, and treating them separately is the failure. A substrate that handles identity but not decision is a directory service. A substrate that handles action but not identity is a logging product. A substrate that binds artifacts but does not model the social architecture of decisions is a metadata system. The missing layer is the integration of all four into a single substrate, with decision treated as a structural unit equal to the others, and with the substrate operating as a property of the system rather than as documentation produced about it. That layer is Provenance.
What follows is the case for naming it, the case against governance-as-wrapper, an honest engagement with the adjacent literature, and a description of what the layer integrates that no current proposal does.
Why governance-as-wrapper fails
Most enterprise AI deployment treats governance as a perimeter activity. Policies are written. Risk assessments are conducted. Compliance teams audit periodically. The AI system runs inside the resulting envelope, and the envelope is enforced through process: humans review outputs, sign off on decisions, document exceptions. When something goes wrong, an investigation reconstructs what happened from logs, interviews, and inference.
This model worked in a regime where AI was used as a tool by humans who remained the actors. It does not work in a regime where AI agents are themselves actors taking thousands of consequential actions per day. Each order of magnitude of agent activity widens the gap between what the wrapper documents and what the system actually did. By the time the gap is visible, the audit trail is missing the information needed to reconstruct what mattered.
August 2026 will make this visible at the regulatory level. EU AI Act Article 12 requires automatic logging over the lifetime of high-risk AI systems, with traceability sufficient to identify risk situations, support post-market monitoring, and enable operational oversight. Most enterprise governance platforms claiming to satisfy Article 12 are wrappers retrofitted to look like substrates. They will pass the first wave of audits and fail the second, because the logs they produce describe the system from the outside rather than from within it.
The failure mode is predictable. Policies are intact. Audits ran. Compliance teams did their work. And the question, "who or what made this decision, with what context, against what policy, and can we revoke or correct it," cannot be answered with the precision the regulation requires, because the data needed to answer it was never captured at the right layer.
Where the existing literature lands
Five active arguments are worth engaging directly, because the differentiated position only makes sense against them.
Arion Research's Agentic Identity argument (April 2026) is the closest published work on identity as a structural layer in enterprise AI. Their five characteristics overlap with the identity layer Provenance describes: federated identity, dynamic authorization, provenance tracking, cross-layer propagation, scale-aware design. Their framing is narrower than the integrated layer and stops at identity; it does not connect identity to decision-level legibility, and it does not address artifact binding.
ElixirData's Context Layer argument (March 2026) names six "decision-grade" properties an agent needs before executing: provenance, currency, authority, policy applicability, decision history, confidence. This is a sophisticated argument and it is positioned around a commercial product (Context OS). Context flows into the agent. Provenance, in their framing, is one of six properties of the context the agent receives, not a layer that captures what the agent does. The two arguments are complementary; neither is sufficient on its own.
SVRN's action provenance argument (April 2026) makes the precise distinction Provenance makes between model provenance, which is well-developed, and action provenance, which is not. SVRN is scoped to autonomous financial action authorization. The vocabulary aligns. The scope is narrower.
The CIO.com piece, "Beyond the hype: The enterprise AI architecture we actually need" (May 4, 2026), proposes a five-layer enterprise AI architecture and identifies a blockchain-based identity and audit layer as conspicuously absent from current enterprise AI discourse. Same regulatory frame, same observation that governance has to be built into the protocol rather than bolted on. Different proposed mechanism. The CIO author's layer is durable storage of audit events on a distributed ledger; the Provenance layer is a substrate that integrates identity, action, artifact, and decision and remains agnostic to the storage mechanism beneath it.
Horatio Morgan's Governance Control Stack (March 2026) is the most architecturally ambitious of the published work. Six layers: version governance, evidence-based verification, decision-time explainability logging, telemetry monitoring, drift detection, and governance escalation. Morgan's stack is comprehensive on the operational side and treats governance as continuous reproducibility. The Provenance four-layer model treats governance as a property of action and decision capture. The two stacks could coexist; Morgan's is closer to what governance teams operate, and Provenance is closer to what platform engineers build against.
Each of these arguments names a real gap. None of them names the integration as the layer.
What the four-layer model integrates
Identity establishes who or what is acting, under what delegation, with what scope. Every actor, human or agent, has a unique cryptographically verifiable identity. Service accounts shared between humans and agents are not permitted; the agent auditability literature is consistent that this is the most common failure mode. Authority is delegated explicitly, scoped narrowly, and time-bounded by default. Arion's argument lives here in most of its particulars.
Action records every meaningful event with its actor, timestamp, input lineage, model or rule version, governing policy, and reasoning trace. SVRN's action provenance argument lives here, generalized beyond financial authorization to cover the full range of agent and human action. Morgan's evidence-based verification and explainability logging map onto this layer too.
Artifact binds every produced thing (a document, a code commit, a generated image, a model output, a status report) to a tamper-evident manifest naming actors, sources, AI involvement, and edit history. C2PA's content provenance pattern lives here, extended beyond media to enterprise artifacts. ElixirData's provenance-as-context-property lives here when the artifact is being delivered into an agent's reasoning loop.
Decision records who shaped each decision, whose judgment was weighted, who was in the room, who was not, what alternatives were considered, and what policy framework governed the choice. This is the layer that distinguishes the substrate from sophisticated logging. None of the published work treats decision this way. This is the structural commitment to the equity argument: in an organization that runs on AI leverage, the social architecture of decision-making has to be legible rather than hidden, or the leverage compounds existing inequities.
The four layers operate as a single integrated requirement. A substrate that captures three of them is a different layer with a narrower scope, not a partial implementation of this one. Identity without decision is a directory service. Action without identity is logging. Artifact without action is metadata. The integration is the layer.
Where the framing is differentiated
Three places.
Decision as a structural layer is original. The published literature treats decision as something that gets logged (Morgan), as something that needs context to execute well (ElixirData), or as something that needs identity attribution (Arion). No one in the work surveyed here treats decision as a layer with the same architectural weight as identity, with the social architecture of decision-making as a structural commitment rather than a values statement. This is the part of the argument that connects most directly to organizational design in the AI era, and it is the part that is hardest to retrofit into a stack designed without it.
Integration is original. Each existing argument names one component of what the layer integrates. Naming the integration as the layer, and naming partial implementations as different layers with narrower scope, is a structural claim no one else has made.
Data sovereignty is differentiated. The CIO piece reaches for blockchain. Walrus is decentralized data infrastructure. ElixirData's Context OS aggregates context as a service. The enterprise governance platforms aggregate provenance as a service. No published work argues that the substrate has to operate on hashes and signatures wherever possible, with full content access requiring customer-held keys. The position is straightforward: data belongs to the organization that produced it, and a substrate that aggregates cleartext access to deliver its service has become a target rather than a substrate. This commitment is enforceable in the architecture rather than promised in the marketing.
How the layer interfaces with the others
A horizontal layer that intersects every other layer in the AI stack and provides four properties as a service the others can call. The substrate reads from each layer and writes to its own store. It does not modify the layers above or below it. It does not gate operation. It does not slow throughput through approval flows. The architectural commitment is that the substrate scales with the system rather than against it, which means its integration has to be a property of how the layers are built rather than a checkpoint they have to pass through.
Each layer publishes into the substrate at the events the substrate cares about. Models publish identity and version when invoked. Data systems publish dataset identity and access events. Orchestration systems publish agent identity, delegation, and tool-call events. Applications publish user identity, session context, and human-in-the-loop interactions. Agents publish reasoning traces and decision records. The substrate aggregates these, binds them through the identity layer, signs them for tamper-evidence, and exposes them through query interfaces that satisfy regulatory requirements (Article 12, the CoE Framework Convention's traceability principles, NIST AI RMF documentation actions) and operational requirements (incident reconstruction, post-market monitoring, decision auditing).
Crucially, the substrate does not own the data. Its integrity comes from cryptographic binding, not from aggregated storage. An implementation that requires aggregated cleartext access to function is not implementing the layer; it is implementing a governance product that calls itself the layer. This is a testable architectural commitment, and it is the commitment that keeps the layer from becoming the aggregation target the architecture is meant to prevent.
What the layer is, what it integrates, and what it leaves alone
Three boundary cases the architecture document will have to address explicitly, because the existing literature will read this framing as encroaching on adjacent categories.
A governance product operates on top of the layer the way an application operates on top of TCP/IP. Governance products use the substrate to enforce policies, run audits, generate reports, and demonstrate compliance. The substrate itself records what happened with sufficient fidelity that any party with appropriate authority can reconstruct what happened, attribute it correctly, and act on it. Enforcement belongs to the governance product. This separation matters; a substrate that enforces is a wrapper, and the field already has wrappers.
An observability stack records what systems do for the purpose of operating them. The Provenance substrate records what actors do for the purpose of attributing and reversing their actions. The two domains overlap technically (event capture and storage) and differ in what they record and why. Latency, throughput, and error rates are observability questions. Who decided what under which policy is a provenance question. The architecture document should engage observability seriously rather than dismissing it; the integration question is real and the boundary will not hold under technical review without precision.
The model layer does not generate provenance. Provenance is a property of the environment the model operates within, not a feature the model produces. The temptation, given how the layer interfaces with model and agent operations, is to treat Provenance as something AI systems produce as part of their output. The substrate is what the model operates inside, and the substrate's integrity does not depend on the model's cooperation.
What the framing changes
Provenance becomes infrastructure rather than governance. The audience shifts from compliance and risk leaders to platform engineers, infrastructure architects, and the standards community. The vocabulary shifts from policies and controls to interfaces and properties. The competitive landscape shifts from governance platforms, a crowded category getting more crowded by the month, to layer-defining infrastructure, a category that does not yet have established incumbents and is filling fast.
The category change matters because budget, ownership, and decision rights move with it. Governance is funded as a tax on the system. Infrastructure is funded as part of how the system works. A governance product is something an enterprise buys and a compliance team operates. An infrastructure layer is something an enterprise builds against and a platform team owns. The difference shows up in every downstream conversation: in procurement, in architectural review, in how the system gets specified, and in what gets cut when the budget tightens.
The product question, if there is one, follows from the category. A reference implementation of an open layer is positioned differently than a better governance tool. The reference implementation has to be implementable by parties other than its author, which means the layer has to be specified openly. That specification is the architecture document, and that document is what makes the position operational rather than rhetorical.
Where the framing is most vulnerable
Three places where the architecture document will have to do real work to defend the position.
The layering claim itself is the first vulnerability. The AI stack is contested, and arguing for a missing layer requires arguing for a stack model the field has not agreed on. The defense is that the argument does not depend on the exact layering; it depends on the observation that no current layering names a horizontal layer responsible for cross-layer attribution. That observation holds across every stack model in the literature reviewed here. The architecture document should make this defense in the opening, so readers who disagree about stack count do not dismiss the larger argument.
Observability is the second vulnerability. Observability vendors will say they already do most of what the layer describes. They are partly right, and the architectural distinction is subtle enough that hand-waving will not hold up under technical review. The actor-system distinction is real and important, and the document will need worked examples that make the distinction concrete. This is engineering work, not rhetorical work.
Agent-as-actor is the third vulnerability. The framing depends on agents being modeled as actors with identity and delegation rather than as outputs of systems. This is technically and philosophically contested, with an active argument in the AI safety community about whether autonomous agents should be granted that kind of structural status. The defense is that the practical question (can the substrate attribute an action to a specific agent under a specific delegation) does not require resolving the philosophical question (what kind of entity is the agent), and the substrate works either way. The document should acknowledge the contested ground rather than pretending it does not exist.
What is at stake
Provenance does not exist to give the field another governance product. The field is producing governance products at a rate that suggests the category has saturated. What it exists to address is a structural omission in the AI stack, an omission the existing categories are filling incompletely from different directions because no one has named the omission as the omission.
Decision as a structural layer is original to this argument. Integration of identity, action, artifact, and decision into a single substrate is original. Data sovereignty as an enforceable architectural commitment, rather than a marketing promise, is differentiated. The connection between the layer and the structural conditions for AI leverage at organizational scale is differentiated.
These are claims, not conclusions. The architecture document is what makes them implementable, and that document is in development. This piece exists to stake the position before the field converges on a less integrated version of it.
The August 2026 enforcement window for the EU AI Act will make the cost of getting this wrong visible. Most enterprise governance platforms claiming to satisfy Article 12 will pass first audits and fail second ones. That is a discoverable failure, and it is the failure the wrapper approach has been heading toward since governance teams started bolting compliance language onto AI deployments rather than asking what the deployments require structurally. Provenance is the answer to the structural question, and the question is not going away.
That layer needs a specification. The work is underway.
Nathan Kling writes on AI transformation, organizational design, and the human layer that determines whether transformations succeed or stall. More at thinkingmanagement.com. The architecture document referenced here and The Lattice, a foundational paper on organizational design in the intelligence abundance era, are sibling works in active development.