Universal
Intent Protocol

This whitepaper is not a usage guide. It is an argument for why the world needs a standardized governance protocol to express human intent in a structured, executable, and safe form.

It is addressed to AI system architects, founders building on top of LLMs, investors seeking to understand the infrastructure layers still missing from the AI ecosystem, and any organization whose AI agents make autonomous decisions at high frequency.

{
  "spec":    "JSONFIRST",
  "version": "2.0",
  "execution_mode": "GUARDIAN_MODE",
  "jdons": [{
    "action":  { "normalized": "archive" },
    "object":  { "type": "email",
                 "filter": "age > 30d" },
    "constraints": { "scope": "inbox_only" }
  }],
  "execution": {
    "executable": false,
    "require_human_confirmation": true,
    "irreversible_check": true
  }
}

Large language models are, by nature, probabilistic. This property — the very one that makes them impressive in creative and general reasoning tasks — becomes a systemic flaw when deployed in production pipelines.

In 2025, a typical AI-powered application makes between 3 and 7 LLM calls to accomplish a single user task. Each call is an opportunity for structural drift: the model may interpret the same request differently based on context, temperature, prompt noise, or simply the stochastic variance inherent to its architecture.

The problem is not the LLMs' ability to understand natural language. It is the absence of a formal contract between human intent and machine action. When a user says "send an email to Marie to confirm Thursday's meeting," how many ways can an LLM interpret that? Dozens. The time? Implicit. The tone? Invented. The date? Inferred. Each of these inferences can be wrong, and in a production system, a wrong inference has a real cost.

This is the structural problem of LLMs in production: the absence of a formal intent specification layer. Developers currently compensate with prompt engineering — a craft-based discipline that is expensive, non-portable, and fundamentally fragile.

The unpredictability of LLMs in production has a cost that teams do not yet measure correctly, because it is diffuse, distributed across thousands of calls, and rarely attributed to its root cause.

There is an even deeper cost, rarely discussed: the cost of trust. An organization that cannot explain exactly why its AI agent made a specific decision cannot trust that system. And without trust, high-value use cases — medical, legal, financial, industrial — remain out of reach.

Prompt engineering is the industry's current answer to the unpredictability problem. It is a legitimate and useful discipline. But it has structural limitations that make it insufficient as a long-term solution.

First, prompts are not portable. A prompt optimized for GPT-4o can produce radically different results on Claude Sonnet, Gemini Pro, or any open-source model. There is no portability standard. Every model migration is a guaranteed partial regression.

Second, prompts are not meaningfully versionable. You can version a text file, but you cannot regression-test a prompt the way you regression-test an API. The absence of a formal output schema makes testing non-deterministic.

Third, prompts do not scale organizationally. When multiple teams work on the same AI system, prompt engineering conventions diverge. There is no "contract" between the AI frontend and backend — each team invents its own conventions.

The history of software engineering is a history of successive abstraction layers, each solving the unpredictability problem of the layer below it. Assembly resolved the unpredictability of manual binary. The operating system resolved the unpredictability of hardware access. TCP/IP resolved the unpredictability of network communication.

We are now at the emergence of a new layer: the intent layer. This is the interface between unstructured human thought and structured machine execution. This layer does not yet exist in standardized form. Every team implements it differently, locally, without interoperability.

A deterministic intent layer must satisfy four properties: portability (independence from the underlying model), auditability (every intent is traceable), validatability (one can formally verify that an intent is well-formed), and executability (the intent can be transmitted directly to an agent without further interpretation).

JSONFIRST is an open specification for the structured representation of human intentions. Its founding principle is simple: any intent expressed in natural language can be represented as a formally structured, validatable, and executable JSON object.

A JDON (JSON Data Object of Nature) is the atomic unit of the JSONFIRST protocol. A JDON captures exactly one intent, with its normalized action, object, domain, and constraints. Multiple JDONs can be combined to represent composite intents (sequential, parallel, conditional).

The protocol also defines 8 execution modes organized by sector profile, each encoding a specific governance contract:

The four sector-specific modes (Guardian, Finance, Ethical, Scope) represent JSONFIRST's evolution from a parsing protocol to a full governance layer for AI agents. They encode not just intent structure, but intent safety — the contract between human mandate and machine autonomy.

The JSONFIRST v3.0 architecture comprises three main components.

6.1 — The JDON Schema

Each JDON is a JSON object with the following fields: jdon_id (unique identifier), action (raw + normalized verb), object (action object + type + category), domain (primary and secondary domain), constraints (extracted parameters), and confidence (confidence score 0–1).

6.2 — The Autocorrect System

JSONFIRST integrates an autocorrection module that preserves the original raw text (raw_text) and produces a cleaned version (cleaned_text), with an explicit log of each correction applied. This traceability is critical for audit systems.

6.3 — The Execution System

The execution object encapsulates the pipeline state: parsable, executable, state (DRAFT → VALIDATED → EXECUTION_REQUESTED → EXECUTED_SUCCESS), and mode. This state machine is the foundation of JSONFIRST's auditability.

OpenAI, Anthropic, and Google all offer a "JSON mode" or "structured outputs" that forces the LLM to produce valid JSON. This is a useful improvement, but fundamentally different from JSONFIRST on several critical dimensions.

In summary: native JSON mode solves the problem of syntax (valid JSON). JSONFIRST solves the problem of semantics (formalized, portable, auditable intent). These are two different layers — JSONFIRST can in fact use native JSON mode as its implementation mechanism.

This whitepaper would be incomplete without an honest analysis of JSONFIRST's limitations and the risks inherent in its adoption.

9.1 — Technical Limitations

JSONFIRST is effective for intents that can be articulated in structured natural language. It is less suited to intrinsically ambiguous or creative intents (writing a novel, improvising a conversation), where formal structure may constrain the output counterproductively. The protocol is not a universal solution — it is a tool for a precise subset of use cases.

The quality of the JDON produced depends on the quality of the underlying parsing model. A poorly configured LLM can produce syntactically valid but semantically incorrect JDONs. The protocol provides validation tools, but does not guarantee the relevance of the extracted intent.

9.2 — Adoption Risks

The primary risk is fragmentation: if multiple actors propose incompatible variants of the protocol, the interoperability objective is compromised. This is why the JSONFIRST specification is public and versioned — to allow the community to contribute to its evolution while maintaining compatibility.

9.3 — Dependency Risks

Widespread adoption of JSONFIRST as a standard creates a dependency on the stability of the specification. An incompatible schema change in a major version can break production pipelines. A versioning policy and backward compatibility maintenance are commitments that JSONFIRST must honor to earn industry trust.

In five years, we estimate that the majority of AI applications in production will need a formalized intent layer. Here is why, and how we anticipate the ecosystem evolution.

The central thesis of this whitepaper can be summarized as follows: AI will only become reliably scalable at the industrial level when human intent is a first-class artifact in the technology stack — structured, versioned, auditable, and portable. JSONFIRST is a first serious proposal for this layer. It will not be the last.