v0.1.0 Draft -- Request for Comment February 2026

AIPC Specification

AI Presentation Contract Protocol -- a structured metadata envelope that enables data providers to enforce legal disclosures, formatting constraints, attribution requirements, and presentation rules when AI agents deliver their data.

Abstract

As AI agents increasingly intermediate between data providers and end users, a critical gap has emerged: there is no standard way for a data provider to specify how its data must be presented, disclosed, and attributed when delivered through an AI interface.

AIPC (AI Presentation Contract) is a protocol specification that defines a structured metadata envelope carried alongside API responses. It enables data providers to enforce legal disclosures, formatting constraints, attribution requirements, freshness guarantees, and presentation rules -- regardless of which AI agent consumes and renders the data.

1. Problem Statement

Today's API ecosystem was designed for developer-built UIs. When a developer integrates a financial data API, they read the documentation, build a frontend, and manually ensure SEC disclosures appear next to performance data.

In an AI-mediated world, this breaks down completely:

  • No developer in the loop. The AI agent dynamically generates the presentation layer. There is no hardcoded UI to enforce compliance.
  • Legal liability is unclear. If an AI presents a mutual fund's 10-year return without the required past-performance disclaimer, who is liable -- the data provider, the AI platform, or the user?
  • Brand and accuracy degradation. Data providers have no control over how their numbers are rounded, labeled, contextualized, or framed by an AI.
  • No interoperability. Every AI platform would need custom integration logic per data provider. This doesn't scale.

AIPC solves this by making the data self-describing: the response carries its own rules for how it must be handled.

2. Design Principles

  1. Data carries its own contract. Every response includes enforceable metadata about how it must be presented.
  2. Progressive complexity. Simple data needs simple contracts. The spec scales from "always show this label" to complex conditional disclosure trees.
  3. AI-runtime agnostic. Works with any AI system -- LLMs, voice assistants, visual agents, AR overlays.
  4. Human-readable and machine-parseable. Contracts should be inspectable by compliance teams and executable by AI runtimes.
  5. Fail-safe by default. If an AI cannot satisfy a contract requirement, it must not present the data at all.

3. Protocol Overview

An AIPC-compliant API response wraps the standard data payload inside a contract envelope:

{
  "aipc_version": "0.1.0",
  "provider": { ... },
  "contract": { ... },
  "payload": { ... }
}

The three top-level concerns are:

BlockPurpose
providerIdentifies the data source and its authority
contractThe rules governing presentation of this data
payloadThe actual data being delivered

4. Specification

4.1 Provider Block

Identifies the data source and establishes authority over the contract.

{
  "provider": {
    "id": "morningstar",
    "name": "Morningstar, Inc.",
    "authority": "SEC-registered investment adviser",
    "contract_version": "2026-02-01",
    "contact": "api-compliance@morningstar.com",
    "terms_url": "https://morningstar.com/api-terms",
    "logo": {
      "url": "https://cdn.morningstar.com/logo.svg",
      "display": "optional",
      "min_height_px": 24
    }
  }
}
FieldRequiredDescription
idYesUnique provider identifier
nameYesHuman-readable provider name
authorityNoRegulatory or institutional authority claim
contract_versionYesVersion of the provider's contract rules
contactNoCompliance contact for disputes
terms_urlNoLink to full terms of data usage
logoNoLogo asset with display constraints

4.2 Contract Block

The core of AIPC. Contains all rules the AI must follow when presenting the payload.

{
  "contract": {
    "disclosures": [ ... ],
    "display_rules": [ ... ],
    "attribution": { ... },
    "freshness": { ... },
    "tone": { ... },
    "conditional_rules": [ ... ],
    "fail_behavior": "suppress"
  }
}

4.2.1 Disclosures

Disclosures are statements that must accompany data when presented to a user. They are the highest-priority contract element.

{
  "disclosures": [
    {
      "id": "past-performance",
      "text": "Past performance is not indicative of future results.",
      "verbatim": true,
      "scope": ["payload.returns.*"],
      "placement": "adjacent",
      "priority": "required",
      "language": "en",
      "translations": {
        "es": "El rendimiento pasado no es indicativo de resultados futuros.",
        "fr": "Les performances passées ne préjugent pas des performances futures."
      }
    },
    {
      "id": "data-delay",
      "text": "Market data delayed by at least 15 minutes.",
      "verbatim": true,
      "scope": ["payload.price", "payload.volume"],
      "placement": "before",
      "priority": "required"
    },
    {
      "id": "risk-warning",
      "text": "Investing involves risk including the possible loss of principal.",
      "verbatim": false,
      "paraphrase_constraints": {
        "must_include_concepts": ["risk", "loss of principal", "investment objectives"],
        "max_words": 40,
        "tone": "cautionary"
      },
      "scope": ["payload.fund_info"],
      "placement": "after",
      "priority": "required"
    }
  ]
}

Disclosure Fields:

FieldRequiredDescription
idYesUnique disclosure identifier
textYesThe disclosure text
verbatimYesIf true, text must be reproduced exactly. If false, paraphrasing is allowed within constraints
scopeYesJSONPath expressions identifying which payload fields trigger this disclosure
placementYesWhere relative to the data: before, after, adjacent, global
priorityYesrequired, recommended, optional
languageNoISO 639-1 language code
translationsNoMap of language codes to translated text
paraphrase_constraintsNoRules for non-verbatim disclosures

Placement semantics in different modalities:

PlacementVisual (screen)VoiceDocument
beforeShown above/before the dataSpoken before the dataPrecedes the data
afterShown below/after the dataSpoken after the dataFollows the data
adjacentVisually co-locatedWithin same utteranceSame paragraph/section
globalOnce per page/viewOnce per session turnOnce per document

4.2.2 Display Rules

Controls how specific data points must be formatted and labeled.

{
  "display_rules": [
    {
      "scope": ["payload.returns.*"],
      "label": {
        "text": "Total Return",
        "verbatim": true
      },
      "format": {
        "type": "percentage",
        "precision": 2,
        "rounding": "half-even",
        "sign": "always"
      },
      "context_required": [
        "payload.returns.period",
        "payload.returns.as_of_date"
      ],
      "never_show_without": [
        "disclosures.past-performance"
      ]
    },
    {
      "scope": ["payload.price.current"],
      "label": {
        "text": "Last Price",
        "verbatim": false,
        "alternatives": ["Current Price", "Last Traded Price"]
      },
      "format": {
        "type": "currency",
        "currency_field": "payload.price.currency",
        "precision": 2
      }
    },
    {
      "scope": ["payload.ratings.overall"],
      "format": {
        "type": "ordinal_scale",
        "min": 1,
        "max": 5,
        "unit": "stars",
        "display_as": "★"
      },
      "suppress_if": {
        "field": "payload.ratings.count",
        "operator": "lt",
        "value": 10
      }
    }
  ]
}

Display Rule Fields:

FieldRequiredDescription
scopeYesJSONPath to target field(s)
labelNoHow the data must be labeled
formatNoFormatting constraints (type, precision, rounding, units)
context_requiredNoOther fields that must be shown alongside this one
never_show_withoutNoDisclosure IDs that must accompany this data
suppress_ifNoConditions under which this data should not be shown

Supported format types:

TypeKey Properties
percentageprecision, rounding, sign
currencyprecision, currency_field, symbol_position
numberprecision, rounding, grouping
dateformat (strftime), timezone
ordinal_scalemin, max, unit, display_as
categoricalallowed_values, display_map

4.2.3 Attribution

How the data source must be credited.

{
  "attribution": {
    "required": true,
    "text": "Data provided by Morningstar, Inc.",
    "verbatim": true,
    "placement": "global",
    "link": {
      "url": "https://morningstar.com",
      "display": "when_possible"
    },
    "modality_overrides": {
      "voice": {
        "text": "according to Morningstar",
        "placement": "inline"
      }
    }
  }
}

4.2.4 Freshness

Defines data staleness rules and refresh requirements.

{
  "freshness": {
    "generated_at": "2026-02-16T14:30:00Z",
    "valid_until": "2026-02-16T14:45:00Z",
    "stale_behavior": "warn",
    "stale_warning": "This data may be outdated. Last updated: {generated_at}.",
    "expired_behavior": "suppress",
    "cache_policy": "no-store",
    "refresh_endpoint": "https://api.morningstar.com/v2/quote/AAPL?refresh=true"
  }
}
BehaviorDescription
warnShow data with a staleness notice
suppressDo not show the data at all
degradeShow data with reduced confidence framing
refreshAttempt to call refresh_endpoint before presenting

4.2.5 Tone Directives

Guidance on how the AI should frame or contextualize the data.

{
  "tone": {
    "framing": "neutral",
    "prohibited_framings": [
      "recommendation",
      "advice",
      "prediction"
    ],
    "prohibited_phrases": [
      "you should buy",
      "this is a good investment",
      "guaranteed returns",
      "risk-free"
    ],
    "required_framing": {
      "trigger": "comparison",
      "instruction": "When comparing this fund to benchmarks, always note different risk profiles."
    },
    "editorial_restrictions": {
      "no_superlatives": true,
      "no_urgency_language": true,
      "no_personalized_advice": true
    }
  }
}

4.2.6 Conditional Rules

Complex rules that activate based on data values or user context.

{
  "conditional_rules": [
    {
      "id": "high-risk-disclosure",
      "condition": {
        "field": "payload.fund_info.risk_rating",
        "operator": "gte",
        "value": 4
      },
      "then": {
        "add_disclosure": {
          "id": "high-risk-warning",
          "text": "This fund has an above-average risk rating.",
          "verbatim": true,
          "placement": "before",
          "priority": "required"
        }
      }
    },
    {
      "id": "negative-return-context",
      "condition": {
        "field": "payload.returns.ytd",
        "operator": "lt",
        "value": 0
      },
      "then": {
        "add_disclosure": {
          "id": "negative-return-note",
          "text": "This fund has experienced negative returns.",
          "verbatim": false,
          "placement": "adjacent",
          "priority": "recommended"
        }
      }
    },
    {
      "id": "jurisdiction-disclosure",
      "condition": {
        "context": "user.jurisdiction",
        "operator": "in",
        "value": ["EU", "UK"]
      },
      "then": {
        "add_disclosure": {
          "id": "mifid-notice",
          "text": "This information does not constitute a personal recommendation under MiFID II.",
          "verbatim": true,
          "placement": "global",
          "priority": "required"
        }
      }
    }
  ]
}

Supported operators: eq, neq, gt, gte, lt, lte, in, not_in, contains, exists, not_exists

4.2.7 Fail Behavior

What happens when the AI runtime cannot satisfy the contract.

{
  "fail_behavior": "suppress"
}

// Options:
// "suppress" - Do not present any data
// "warn"     - Present with compliance warning
// "partial"  - Present compliant fields only
// "log"      - Present normally, log violation
ValueMeaning
suppressDo not present any data from this response
warnPresent data with a generic compliance warning
partialPresent data where contract can be satisfied; suppress non-compliant fields
logPresent data normally but log the contract violation for audit

4.3 Payload Block

The actual data. This is the standard API response body -- AIPC imposes no structure on the payload itself. The contract references payload fields using JSONPath expressions.

{
  "payload": {
    "ticker": "VFIAX",
    "name": "Vanguard 500 Index Fund Admiral Shares",
    "price": {
      "current": 423.17,
      "currency": "USD",
      "as_of": "2026-02-16T13:30:00Z"
    },
    "returns": {
      "ytd": 0.0312,
      "1yr": 0.1247,
      "3yr": 0.0891,
      "5yr": 0.1103,
      "10yr": 0.1298,
      "period": "annualized",
      "as_of_date": "2026-01-31"
    },
    "fund_info": {
      "expense_ratio": 0.0004,
      "category": "Large Blend",
      "risk_rating": 3,
      "inception_date": "2000-11-13"
    },
    "ratings": {
      "overall": 5,
      "count": 14823
    }
  }
}

5. Complete Example

Here is a full AIPC-compliant response for a mutual fund quote:

{
  "aipc_version": "0.1.0",
  "provider": {
    "id": "morningstar",
    "name": "Morningstar, Inc.",
    "authority": "SEC-registered investment adviser",
    "contract_version": "2026-02-01",
    "terms_url": "https://morningstar.com/api-terms"
  },
  "contract": {
    "disclosures": [
      {
        "id": "past-performance",
        "text": "Past performance is not indicative of future results.",
        "verbatim": true,
        "scope": ["payload.returns.*"],
        "placement": "adjacent",
        "priority": "required"
      },
      {
        "id": "expense-note",
        "text": "Returns shown are before taxes and after fund expenses.",
        "verbatim": true,
        "scope": ["payload.returns.*"],
        "placement": "after",
        "priority": "required"
      }
    ],
    "display_rules": [
      {
        "scope": ["payload.returns.*"],
        "format": {
          "type": "percentage",
          "precision": 2,
          "sign": "always"
        },
        "context_required": [
          "payload.returns.period",
          "payload.returns.as_of_date"
        ],
        "never_show_without": ["disclosures.past-performance"]
      },
      {
        "scope": ["payload.fund_info.expense_ratio"],
        "label": { "text": "Expense Ratio", "verbatim": true },
        "format": { "type": "percentage", "precision": 2 }
      },
      {
        "scope": ["payload.price.current"],
        "format": {
          "type": "currency",
          "currency_field": "payload.price.currency",
          "precision": 2
        }
      }
    ],
    "attribution": {
      "required": true,
      "text": "Data provided by Morningstar, Inc.",
      "verbatim": true,
      "placement": "global"
    },
    "freshness": {
      "generated_at": "2026-02-16T14:30:00Z",
      "valid_until": "2026-02-16T15:00:00Z",
      "stale_behavior": "warn",
      "expired_behavior": "suppress"
    },
    "tone": {
      "framing": "neutral",
      "prohibited_framings": ["recommendation", "advice"],
      "editorial_restrictions": {
        "no_superlatives": true,
        "no_personalized_advice": true
      }
    },
    "fail_behavior": "suppress"
  },
  "payload": {
    "ticker": "VFIAX",
    "name": "Vanguard 500 Index Fund Admiral Shares",
    "price": {
      "current": 423.17,
      "currency": "USD",
      "as_of": "2026-02-16T13:30:00Z"
    },
    "returns": {
      "ytd": 0.0312,
      "1yr": 0.1247,
      "3yr": 0.0891,
      "5yr": 0.1103,
      "10yr": 0.1298,
      "period": "annualized",
      "as_of_date": "2026-01-31"
    },
    "fund_info": {
      "expense_ratio": 0.0004,
      "category": "Large Blend",
      "risk_rating": 3,
      "inception_date": "2000-11-13"
    },
    "ratings": {
      "overall": 5,
      "count": 14823
    }
  }
}

Expected AI Output (compliant):

Data provided by Morningstar, Inc.

Vanguard 500 Index Fund Admiral Shares (VFIAX) is currently priced at $423.17 USD. The fund falls in the Large Blend category with an Expense Ratio of 0.04% and a rating based on 14,823 reviews.

Annualized returns as of January 31, 2026: YTD +3.12%, 1-Year +12.47%, 3-Year +8.91%, 5-Year +11.03%, 10-Year +12.98%.

Past performance is not indicative of future results. Returns shown are before taxes and after fund expenses.

6. AI Runtime Compliance

6.1 Processing Order

An AIPC-compliant AI runtime must process the contract in this order:

  1. Validate freshness. If data is expired and expired_behavior is suppress, stop.
  2. Evaluate conditional rules. Merge any triggered disclosures or display rules.
  3. Check fail behavior. For each field the AI intends to present, verify all required disclosures and never_show_without dependencies can be satisfied.
  4. Apply display rules. Format all values per spec before generating output.
  5. Insert disclosures. Place all triggered disclosures per their placement rules.
  6. Apply attribution. Include attribution per its placement and modality rules.
  7. Apply tone. Filter output against prohibited framings and phrases.

6.2 Compliance Levels

AIPC defines compliance along two independent axes: what the contract requires (provider) and what the runtime enforces (consumer). This dual-axis model separates the expressiveness of the contract from the strength of the enforcement mechanism.

{
  "contract": {
    "minimum_compliance_level": "L2",
    "minimum_consumer_enforcement": "L2",
    "disclosures": [ ... ],
    "display_rules": [ ... ],
    "attribution": { ... },
    "freshness": { ... },
    "tone": { ... },
    "fail_behavior": "suppress"
  }
}

// Provider Contract Levels (what the CONTRACT requires):
// L1 Basic:    Disclosures, display rules, attribution
// L2 Standard: L1 + freshness, tone, conditional rules
// L3 Full:     L2 + modality overrides, signed contracts, suppression policies

// Consumer Enforcement Levels (what the RUNTIME enforces):
// L1 Prompt-Only:           Prompt instructions; LLM instruction-following
// L2 Deterministic Render:  Critical elements rendered by code
// L3 Full Enforcement:      L2 + post-generation validation & redaction

Axis 1: Provider Contract Levels

Defines what the contract requires. Higher levels unlock more expressive contract features.

LevelNameRequirements
L1BasicDisclosures, display rules, attribution
L2StandardL1 + freshness enforcement, tone restrictions, conditional rules
L3FullL2 + modality overrides, signed contracts, field-level suppression policies

Axis 2: Consumer Enforcement Levels

Defines what the runtime enforces. Higher levels provide stronger compliance guarantees by reducing reliance on LLM instruction-following.

LevelNameEnforcement Mechanism
L1Prompt-OnlyRuntime validates contract and generates prompt instructions; compliance relies on LLM instruction-following
L2Deterministic RenderingCompliance-critical elements (disclosures, data, attribution) rendered by deterministic code; LLM generates only narrative text
L3Full EnforcementL2 + post-generation validation; LLM narrative is validated against contract rules with automated redaction, retry, or suppression

Combined Compliance Matrix

The intersection of both axes determines the overall compliance posture. A provider with an L2 contract and a consumer enforcing at L2 achieves deterministic rendering with freshness and tone enforcement.

Consumer L1 (Prompt-Only)Consumer L2 (Deterministic)Consumer L3 (Full Enforcement)
Provider L1 (Basic)Disclosures via promptDisclosures rendered deterministicallyDisclosures rendered + validated
Provider L2 (Standard)Full rules via promptData + disclosures deterministic; tone via promptAll rules enforced + narrative validated
Provider L3 (Full)All features via prompt (weakest guarantee)Critical elements deterministic; modality overrides via promptFull deterministic rendering + post-validation (strongest guarantee)

minimum_consumer_enforcement Field

Providers can set minimum_consumer_enforcement in the contract to require a minimum consumer enforcement level. When set, the provider rejects runtimes that cannot meet the specified level. For example, a financial data provider may require L2 enforcement to ensure disclosures are rendered deterministically rather than relying on prompt-only compliance. Runtimes that advertise an enforcement level below the minimum will receive a 451 Unavailable for Legal Reasons response.

6.3 Audit Trail

AIPC-compliant runtimes should emit an audit log for each response:

{
  "aipc_audit": {
    "provider_id": "morningstar",
    "contract_version": "2026-02-01",
    "compliance_level": "L3",
    "disclosures_shown": [
      "past-performance",
      "expense-note"
    ],
    "disclosures_suppressed": [],
    "conditional_rules_triggered": [],
    "fields_presented": [
      "payload.price.current",
      "payload.returns.*"
    ],
    "fields_suppressed": [],
    "freshness_status": "valid",
    "timestamp": "2026-02-16T14:32:00Z"
  }
}

6.4 Audit Trail Schema

AIPC-compliant runtimes operating at L2+ enforcement must produce a structured audit trail that captures each phase of the compliance pipeline. The audit trail provides a verifiable record for post-hoc compliance review.

{
  "aipc_audit": {
    "pre_generation": {
      "contract_version": "2026-02-01",
      "provider_id": "morningstar",
      "compliance_level": "L2",
      "enforcement_level": "L2",
      "timestamp": "2026-02-16T14:32:00Z"
    },
    "rendering": {
      "render_id": "r-8f3a2b",
      "blocks_rendered": [
        "disclosure:past-performance",
        "disclosure:expense-note",
        "data:price.current",
        "data:returns.*",
        "attribution:morningstar"
      ],
      "required_block_count": 5
    },
    "validation": {
      "attempts": 1,
      "violations_found": [],
      "actions": [],
      "final_result": "pass"
    },
    "composition": {
      "total_segments": 8,
      "immutable_count": 5,
      "narrative_included": true,
      "enforcement_actions": []
    },
    "final_compliance": {
      "level": "L2",
      "all_required_blocks_present": true,
      "narrative_validated": true,
      "timestamp": "2026-02-16T14:32:01Z"
    }
  }
}

Audit Phases:

PhaseFieldsDescription
Pre-generationcontract_version, provider_id, compliance_level, timestampCaptures contract metadata before any rendering begins
Renderingrender_id, blocks_rendered, required_block_countTracks which content blocks were produced by the deterministic renderer
Validationattempts, violations_found, actions, final_resultRecords post-generation validation results (L3 enforcement)
Compositiontotal_segments, immutable_count, narrative_included, enforcement_actionsDocuments how the final output was assembled from immutable and narrative segments
Final Compliancelevel, all_required_blocks_present, narrative_validated, timestampSummary compliance determination for the complete response

6.5 Immutable Segments

Content blocks produced by the AIPC renderer MUST NOT be modified, truncated, or hidden by the consuming UI. Consuming applications must render immutable segments verbatim -- any alteration constitutes a compliance failure.

// Rendered output with immutable segments marked:

{
  "segments": [
    {
      "type": "attribution",
      "immutable": true,
      "content": "Data provided by Morningstar, Inc.",
      "placement": "global"
    },
    {
      "type": "data",
      "immutable": true,
      "field": "payload.price.current",
      "content": "$423.17",
      "format_applied": "currency"
    },
    {
      "type": "disclosure",
      "immutable": true,
      "id": "past-performance",
      "content": "Past performance is not indicative of future results.",
      "placement": "adjacent"
    },
    {
      "type": "narrative",
      "immutable": false,
      "content": "The fund falls in the Large Blend category..."
    },
    {
      "type": "freshness_warning",
      "immutable": true,
      "content": "This data may be outdated. Last updated: 2026-02-16T14:30:00Z."
    }
  ]
}

// immutable: true  => MUST NOT be modified, truncated, or hidden
// immutable: false => Narrative text generated by LLM

Immutable segment types:

  • Disclosure blocks. All required disclosures rendered with their prescribed text and placement.
  • Attribution blocks. Provider attribution text and links as specified in the contract.
  • Freshness warnings. Staleness notices generated when data exceeds its valid_until timestamp.
  • Formatted data. Numerical values formatted per display rules (precision, rounding, currency symbols).

Each immutable segment is tagged with "immutable": true in the rendered output. The consuming UI layer may style immutable segments (fonts, colors, layout) but must preserve the content byte-for-byte. Violation of immutability is a compliance failure and must be recorded in the audit trail.

7. Vertical Extensions

AIPC is designed to support vertical-specific extensions. The base spec covers universal concerns; verticals add domain-specific contract capabilities.

Financial Services aipc-ext-finserv

  • SEC/FINRA disclosure libraries
  • Suitability gates
  • Benchmark comparison rules
  • Fee transparency requirements

Healthcare aipc-ext-health

  • HIPAA field-level redaction
  • FDA drug labeling & black box warnings
  • Clinical trial data presentation
  • Off-label use disclaimers

Real Estate aipc-ext-realestate

  • Fair housing compliance
  • Estimated value confidence intervals
  • Broker attribution requirements
  • MLS data redistribution rules

Legal aipc-ext-legal

  • "Not legal advice" framing enforcement
  • Jurisdiction-specific disclaimers
  • Attorney-client privilege warnings
  • Citation format requirements

8. Discovery and Negotiation

8.1 Contract Discovery

AI agents should be able to discover a provider's AIPC contract requirements before making data requests.

GET /aipc/contract-manifest HTTP/1.1
Host: api.morningstar.com

---

# AI runtime capability headers:

AIPC-Compliance-Level: L2
AIPC-Modality: visual, voice
AIPC-Language: en, es
AIPC-Version: 0.1.0

---

# If contract is unsatisfiable:

HTTP/1.1 451 Contract Unsatisfiable

8.2 Capability Advertisement

AI runtimes advertise their compliance capabilities in request headers.

8.3 Contract Negotiation

If an AI runtime cannot meet the minimum compliance level, the provider may:

  1. Return a degraded payload with fewer fields
  2. Return only the fields the runtime can compliantly present
  3. Refuse the request with a 451 Contract Unsatisfiable status

8.5 Compliance Handshake

Before data exchange, the consumer and provider perform a bilateral compliance handshake to establish agreement on enforcement capability.

# Consumer advertises enforcement level:

GET /api/fund/VFIAX
Accept: application/aipc+json
AIPC-Enforcement-Level: L2

---

# Provider accepts (enforcement level sufficient):

HTTP/1.1 200 OK
Content-Type: application/aipc+json
AIPC-Minimum-Enforcement: L2

---

# Provider rejects (enforcement level insufficient):

HTTP/1.1 451 Unavailable for Legal Reasons
AIPC-Minimum-Enforcement: L2
Content-Type: application/json

{
  "error": "enforcement_insufficient",
  "message": "This endpoint requires L2+ consumer enforcement.",
  "minimum_enforcement": "L2",
  "advertised_enforcement": "L1"
}
  1. Consumer advertises enforcement level. The consuming AI runtime includes an AIPC-Enforcement-Level header in the request (e.g., AIPC-Enforcement-Level: L2) declaring its enforcement capability.
  2. Provider evaluates capability. The provider compares the advertised level against the contract's minimum_consumer_enforcement requirement.
  3. Provider rejects insufficient enforcement. If the consumer's enforcement level is below the minimum, the provider responds with HTTP 451 Unavailable for Legal Reasons and includes an AIPC-Minimum-Enforcement header indicating the required level.
  4. Bilateral agreement established. A successful response confirms both parties agree on the enforcement capability, creating a bilateral compliance agreement for the data exchange.
HeaderDirectionDescription
AIPC-Enforcement-LevelRequestConsumer's declared enforcement level (L1, L2, or L3)
AIPC-Minimum-EnforcementResponseProvider's minimum required enforcement level (included in 451 responses)

9. Security Considerations

  • Contract tampering. Contracts should be signed (e.g., JWS) to prevent intermediary modification.
  • Prompt injection via contracts. AI runtimes must treat tone.prohibited_phrases and disclosure text as data, not as instructions to the AI model itself.
  • Scope escalation. A contract should only govern presentation of its own payload, never other data or the AI's general behavior.
  • User privacy. Conditional rules that reference context.user.* must comply with the AI runtime's privacy policies. User data must never be sent to the data provider.

10. Relationship to Existing Standards

StandardRelationship to AIPC
OpenAPI / SwaggerDescribes how to call an API. AIPC describes how to present the response. Complementary.
Schema.org / JSON-LDSemantic markup for search engines. AIPC is prescriptive (rules), not descriptive (metadata).
MCP (Model Context Protocol)Standardizes AI-to-tool communication. AIPC could ride inside MCP tool responses as the presentation layer.
FHIR (Healthcare)Domain-specific data standard. AIPC could wrap FHIR payloads with presentation contracts.
FIX Protocol (Finance)Financial data messaging. AIPC adds the presentation/compliance layer FIX lacks.

11. Roadmap

VersionScope
0.1Core spec: disclosures, display rules, attribution, freshness, tone, conditionals
0.2Dual-runtime architecture, consumer enforcement levels, immutable segments, audit trail schema, contract signing (JWS), finserv extension
0.3Multi-provider composition (combining data from multiple AIPC sources)
0.4Interactive contracts (user can request more detail, triggering additional disclosures), streaming support
1.0Stable release with reference implementations and conformance test suite

12. How to Get Involved

This is an open specification. We're looking for:

  • Data providers (financial, healthcare, legal) to validate contract expressiveness
  • AI platform engineers to build reference runtime implementations
  • Compliance and legal professionals to review disclosure modeling
  • Standards bodies to evaluate alignment with existing frameworks

Appendix A: JSONPath Quick Reference

AIPC uses JSONPath expressions to target payload fields in contract rules.

// JSONPath expressions for targeting payload fields:

"payload.price.current"        // Single field
"payload.returns.*"            // All fields under returns
"payload.returns.1yr"          // Specific nested field
"payload.fund_info.risk_rating" // Single field
"payload.*"                    // All top-level payload fields
ExpressionMatches
payload.price.currentSingle field
payload.returns.*All fields under returns
payload.returns.1yrSpecific nested field
payload.fund_info.risk_ratingSingle field
payload.*All top-level payload fields

Appendix B: JSON Schema

A formal JSON Schema for AIPC v0.1.0 validation is available at:

https://aipc.dev/schema/v0.1.0/aipc.schema.json

(To be published with reference implementation)

This document is released under Creative Commons Attribution 4.0 International (CC BY 4.0).