Intent Fidelity Protocol Specification  ·  v1.0  ·  Essays
An Open Standard for AI Integrity

The Intent Fidelity Protocol

A protocol for governing the integrity of intent as it travels from human instruction through machine generation to actionable output.

Integrity Intent Accountability
§ 1  ·  The Principle

Intent must survive generation.

Every interaction with a generative system involves a translation: a human formulates an intention, encodes it as a prompt, and a model produces an output. At each step, fidelity can be lost. Ambiguity creeps in. Context drops. Phrasing influences interpretation. Verification, when it happens at all, is performed on the output rather than on the integrity of the path that produced it.

The Intent Fidelity Protocol defines the obligations a system must meet for intent to survive that translation intact. It is not a security model. It is not an alignment framework. It is not a safety classifier. It is a governance protocol for a specific structural problem: the integrity of intent through generation.

This document specifies version 1.0 of the protocol.

§ 2  ·  What This Protocol Is Not

Boundaries against adjacent categories.

The Intent Fidelity Protocol exists alongside several established categories of AI governance work. It is structurally distinct from each. Implementers and reviewers should understand these boundaries before proceeding.

Not security

This protocol does not prevent unauthorized access, model exfiltration, prompt injection from external attackers, or any threat addressed by AI security tooling. Security and integrity are complementary disciplines that operate on different surfaces.

Not safety

This protocol does not classify harmful outputs, refuse dangerous requests, or enforce content policies. AI safety addresses what models should not produce. Intent integrity addresses whether what they produced reflects what was actually asked.

Not compliance

This protocol does not satisfy regulatory requirements, jurisdictional audit obligations, or industry-specific governance frameworks. Compliance regimes specify what records must be kept. Intent integrity specifies what conditions must hold during generation.

Not observability

This protocol does not measure model performance, token usage, latency, or operational telemetry. Observability tells operators what a system did. Intent integrity tells them whether what it did honored what was asked.

Not evaluation

This protocol does not benchmark model capability, accuracy, or quality on standardized tasks. Evaluation measures models. Intent integrity governs systems that route between models.

These boundaries are not hostile. The Intent Fidelity Protocol is designed to coexist with security, safety, compliance, observability, and evaluation tooling. It addresses a structural problem none of them target.

§ 3  ·  The Four Layers

Where intent integrity must be enforced.

The protocol identifies four layers at which intent can be lost between human and output. A conformant implementation must address all four.

L1
Restructure
The original instruction is analyzed for ambiguity, missing context, and structural defects before reaching any generative model. Defects are resolved or surfaced. The restructured instruction is preserved alongside the original.
L2
Route
The restructured instruction is matched to the engine, modality, and configuration most likely to produce a faithful response. Routing decisions are recorded. Routing is not a black box.
L3
Verify
The output is decomposed into atomic claims and grounded against independent sources. Verification queries do not contain the original response framing. Phrasing cannot influence truth.
L4
Account
Every step of the path is recorded in a form that can be inspected after the fact. The record is sufficient to answer the question: did the output honor the original intent, and how do we know.
§ 4  ·  The 24 Principles

Operational obligations of a conformant implementation.

Each principle expresses an obligation that must hold for the system to be considered conformant. Principles are organized by layer but apply across the protocol as a whole.

01Preserve original instruction
02Surface ambiguity before resolving it
03Restructure does not paraphrase
04Modality is detected, not assumed
05Routing decisions are recorded
06Engine selection is justified
07Verification is independent of generation
08Atomic claims, not whole responses
09Phrasing cannot influence truth
10Sources override engine claims on conflict
11Confidence is bounded, not asserted
12Disagreement between layers is surfaced
13Memory is cache, canon is truth
14Decisions update canon, not just memory
15Stale sources are flagged, not used
16Anchor before analysis
17Visual inputs are read in full
18Scope expansion is named, not silent
19Single-engine silent scope is a defect
20Multi-pass on consequential changes
21Final authority remains human
22Path is auditable end to end
23Failure modes are recorded as decisions
24Drift is corrected immediately, not deferred
§ 5  ·  Conformance Requirements

What it means to implement the protocol.

An implementation is considered conformant with Intent Fidelity Protocol v1.0 if and only if all of the following conditions are continuously met during operation.

Required Conditions

  1. The original instruction is preserved unaltered for the lifetime of the resulting record.
  2. A restructure step exists between the original instruction and any generative model invocation. The restructure step does not silently rewrite intent.
  3. Routing between engines, when present, produces a recorded decision with a stated reason.
  4. Verification of generated output uses sources that are independent of the generating engine.
  5. Verification queries are constructed from atomic claims and do not contain the original response framing.
  6. Conflicts between engine output and grounded sources are resolved in favor of sources, with the conflict recorded.
  7. The full path from instruction to output is recoverable from the record after the fact.
  8. The implementation publishes which principles it satisfies and which it does not.

Partial conformance is permitted and encouraged. An implementation may declare itself conformant with a subset of principles, provided the subset is published and the unimplemented principles are named explicitly.

§ 6  ·  Lexicon

Terms used in this specification.

Intent
The structured purpose a human is attempting to express through an instruction. Distinct from the literal text of the instruction.
Fidelity
The degree to which the path from instruction to output preserves the original intent without distortion, drift, or substitution.
Restructure
A transformation of an instruction that resolves ambiguity and supplies missing context without altering its underlying intent.
Atomic Claim
A single, source-checkable statement extracted from a larger response. The unit of independent verification.
Canon
The authoritative source of truth for a system's rules, decisions, and structural commitments. Distinct from cached memory.
Conformant Implementation
A system that continuously satisfies the conditions enumerated in §5 and publishes which principles it does and does not implement.
Reference Implementation
An implementation maintained by the protocol's publisher, used to validate the specification against working code. Not the only legitimate implementation.
§ 7  ·  Reference Implementation

DreamerOS.

DreamerOS is the reference implementation of the Intent Fidelity Protocol. It is a working system that satisfies all 24 principles and is operated continuously by the protocol's maintainer.

The reference implementation exists to demonstrate that the protocol is implementable in practice, to validate specification changes against working code before publication, and to provide a stable comparison point for third-party implementations.

DreamerOS is not the only legitimate way to implement the protocol. Any system that satisfies the conformance requirements in §5 may declare itself a conformant implementation. A registry of declared implementations is maintained as part of this specification.

§ 8  ·  Origin, Independence, Trademark

Provenance and rights.

Independence Disclosure

The Intent Fidelity Protocol is developed and maintained independently by DreamerAI Holdings LLC, a Wyoming limited liability company. It is not affiliated with, sponsored by, or endorsed by any other organization, employer, vendor, or research institution.

The protocol is published as an open standard. Any organization may implement it. Any implementation that satisfies the conformance requirements in §5 may declare itself conformant without licensing fees, royalties, or permission from the publisher.

Trademark

"Intent Fidelity Protocol" and "IFP" are trademarks of DreamerAI Holdings LLC. The trademarks may be used to describe a conformant implementation, to cite the specification, or for editorial and journalistic purposes. They may not be used to imply endorsement, sponsorship, or certification by the publisher absent a written agreement.

License

This specification is published for unrestricted reading, citation, and implementation. The specification text itself is made available under terms permitting reproduction with attribution. Implementers do not require a license to build conformant systems.

§ 9  ·  Version History

Specification revisions.

VersionDateNotes
v1.0 April 2026 Initial publication. Four layers, 24 principles, conformance requirements established.

The specification is versioned. Substantive changes to principles or conformance requirements increment the major version. Editorial revisions increment the minor version. Both are dated and recorded in this section.