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
- Data carries its own contract. Every response includes enforceable metadata about how it must be presented.
- Progressive complexity. Simple data needs simple contracts. The spec scales from "always show this label" to complex conditional disclosure trees.
- AI-runtime agnostic. Works with any AI system -- LLMs, voice assistants, visual agents, AR overlays.
- Human-readable and machine-parseable. Contracts should be inspectable by compliance teams and executable by AI runtimes.
- 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:
| Block | Purpose |
|---|---|
provider | Identifies the data source and its authority |
contract | The rules governing presentation of this data |
payload | The 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
}
}
}| Field | Required | Description |
|---|---|---|
id | Yes | Unique provider identifier |
name | Yes | Human-readable provider name |
authority | No | Regulatory or institutional authority claim |
contract_version | Yes | Version of the provider's contract rules |
contact | No | Compliance contact for disputes |
terms_url | No | Link to full terms of data usage |
logo | No | Logo 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:
| Field | Required | Description |
|---|---|---|
id | Yes | Unique disclosure identifier |
text | Yes | The disclosure text |
verbatim | Yes | If true, text must be reproduced exactly. If false, paraphrasing is allowed within
constraints |
scope | Yes | JSONPath expressions identifying which payload fields trigger this disclosure |
placement | Yes | Where relative to the data: before, after, adjacent, global |
priority | Yes | required, recommended, optional |
language | No | ISO 639-1 language code |
translations | No | Map of language codes to translated text |
paraphrase_constraints | No | Rules for non-verbatim disclosures |
Placement semantics in different modalities:
| Placement | Visual (screen) | Voice | Document |
|---|---|---|---|
before | Shown above/before the data | Spoken before the data | Precedes the data |
after | Shown below/after the data | Spoken after the data | Follows the data |
adjacent | Visually co-located | Within same utterance | Same paragraph/section |
global | Once per page/view | Once per session turn | Once 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:
| Field | Required | Description |
|---|---|---|
scope | Yes | JSONPath to target field(s) |
label | No | How the data must be labeled |
format | No | Formatting constraints (type, precision, rounding, units) |
context_required | No | Other fields that must be shown alongside this one |
never_show_without | No | Disclosure IDs that must accompany this data |
suppress_if | No | Conditions under which this data should not be shown |
Supported format types:
| Type | Key Properties |
|---|---|
percentage | precision, rounding, sign |
currency | precision, currency_field, symbol_position |
number | precision, rounding, grouping |
date | format (strftime), timezone |
ordinal_scale | min, max, unit, display_as |
categorical | allowed_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"
}
}| Behavior | Description |
|---|---|
warn | Show data with a staleness notice |
suppress | Do not show the data at all |
degrade | Show data with reduced confidence framing |
refresh | Attempt 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| Value | Meaning |
|---|---|
suppress | Do not present any data from this response |
warn | Present data with a generic compliance warning |
partial | Present data where contract can be satisfied; suppress non-compliant fields |
log | Present 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:
- Validate freshness. If data is expired and
expired_behaviorissuppress, stop. - Evaluate conditional rules. Merge any triggered disclosures or display rules.
- Check fail behavior. For each field the AI
intends to present, verify all
requireddisclosures andnever_show_withoutdependencies can be satisfied. - Apply display rules. Format all values per spec before generating output.
- Insert disclosures. Place all triggered disclosures
per their
placementrules. - Apply attribution. Include attribution per its placement and modality rules.
- 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 & redactionAxis 1: Provider Contract Levels
Defines what the contract requires. Higher levels unlock more expressive contract features.
| Level | Name | Requirements |
|---|---|---|
| L1 | Basic | Disclosures, display rules, attribution |
| L2 | Standard | L1 + freshness enforcement, tone restrictions, conditional rules |
| L3 | Full | L2 + 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.
| Level | Name | Enforcement Mechanism |
|---|---|---|
| L1 | Prompt-Only | Runtime validates contract and generates prompt instructions; compliance relies on LLM instruction-following |
| L2 | Deterministic Rendering | Compliance-critical elements (disclosures, data, attribution) rendered by deterministic code; LLM generates only narrative text |
| L3 | Full Enforcement | L2 + 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 prompt | Disclosures rendered deterministically | Disclosures rendered + validated |
| Provider L2 (Standard) | Full rules via prompt | Data + disclosures deterministic; tone via prompt | All rules enforced + narrative validated |
| Provider L3 (Full) | All features via prompt (weakest guarantee) | Critical elements deterministic; modality overrides via prompt | Full 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:
| Phase | Fields | Description |
|---|---|---|
| Pre-generation | contract_version, provider_id, compliance_level, timestamp | Captures contract metadata before any rendering begins |
| Rendering | render_id, blocks_rendered, required_block_count | Tracks which content blocks were produced by the deterministic renderer |
| Validation | attempts, violations_found, actions, final_result | Records post-generation validation results (L3 enforcement) |
| Composition | total_segments, immutable_count, narrative_included, enforcement_actions | Documents how the final output was assembled from immutable and narrative segments |
| Final Compliance | level, all_required_blocks_present, narrative_validated, timestamp | Summary 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 LLMImmutable 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_untiltimestamp. - 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:
- Return a degraded payload with fewer fields
- Return only the fields the runtime can compliantly present
- Refuse the request with a
451 Contract Unsatisfiablestatus
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"
}- Consumer advertises enforcement level. The consuming AI runtime includes an
AIPC-Enforcement-Levelheader in the request (e.g.,AIPC-Enforcement-Level: L2) declaring its enforcement capability. - Provider evaluates capability. The provider compares the advertised level against the contract's
minimum_consumer_enforcementrequirement. - Provider rejects insufficient enforcement. If the consumer's enforcement level is below the minimum, the provider responds with HTTP
451 Unavailable for Legal Reasonsand includes anAIPC-Minimum-Enforcementheader indicating the required level. - Bilateral agreement established. A successful response confirms both parties agree on the enforcement capability, creating a bilateral compliance agreement for the data exchange.
| Header | Direction | Description |
|---|---|---|
AIPC-Enforcement-Level | Request | Consumer's declared enforcement level (L1, L2, or L3) |
AIPC-Minimum-Enforcement | Response | Provider'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_phrasesand 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
| Standard | Relationship to AIPC |
|---|---|
| OpenAPI / Swagger | Describes how to call an API. AIPC describes how to present the response. Complementary. |
| Schema.org / JSON-LD | Semantic 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
| Version | Scope |
|---|---|
| 0.1 | Core spec: disclosures, display rules, attribution, freshness, tone, conditionals |
| 0.2 | Dual-runtime architecture, consumer enforcement levels, immutable segments, audit trail schema, contract signing (JWS), finserv extension |
| 0.3 | Multi-provider composition (combining data from multiple AIPC sources) |
| 0.4 | Interactive contracts (user can request more detail, triggering additional disclosures), streaming support |
| 1.0 | Stable 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
| Expression | Matches |
|---|---|
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 |
Appendix B: JSON Schema
A formal JSON Schema for AIPC v0.1.0 validation is available at:
(To be published with reference implementation)
This document is released under Creative Commons Attribution 4.0 International (CC BY 4.0).