Compliance Levels

AIPC compliance operates on two independent axes: what the provider's contract requires, and what the consumer's runtime enforces. Understanding both axes is essential for building compliant integrations.

Two axes of compliance

A common misconception is that "compliance level" is a single number. In AIPC, compliance has two dimensions:

Provider Contract Levels — What the contract requires. Set by the data provider.
Consumer Enforcement Levels — What the runtime enforces. Determined by the consumer's implementation.

A contract may require L2 features (freshness, tone), but the consumer's runtime may enforce at L3 (post-generation validation). Or a contract may be L3, but the consumer enforces only at L1 (prompt-only). The provider can set a minimum enforcement requirement to prevent under-enforcement.

Provider Contract Levels

Provider Contract Levels define the complexity of the rules encoded in the contract. A higher level means the contract uses more advanced features:

Level	Name	What the contract includes
`L1`	Basic	Disclosures, display rules, attribution. The minimum viable contract.
`L2`	Standard	L1 plus freshness enforcement, tone restrictions, and conditional rules.
`L3`	Full	L2 plus modality overrides, signed contracts, and field-level suppression.

Consumer Enforcement Levels

Consumer Enforcement Levels define how the runtime enforces the contract. Higher levels provide stronger guarantees that the AI's output will comply:

Level	Name	How the runtime enforces
`L1`	Prompt-Only	The runtime generates prompt instructions from the contract. Compliance depends entirely on the LLM following those instructions. No deterministic guarantees.
`L2`	Deterministic Rendering	Compliance-critical blocks (disclosures, data values, attribution) are rendered by code, not by the LLM. The LLM generates only the narrative text. Deterministic elements are immutable.
`L3`	Full Enforcement	L2 plus post-generation validation. The LLM's narrative is checked against contract rules. Violations trigger redaction, retry, or suppression depending on severity.

The compliance matrix

The two axes combine into a matrix. Each cell represents a valid configuration:

	Consumer L1 (Prompt-Only)	Consumer L2 (Deterministic)	Consumer L3 (Full Enforcement)
Contract L1	Basic prompt instructions	Deterministic disclosures + data	Full validation (overkill but safe)
Contract L2	Tone/freshness in prompt only	Deterministic + tone in narrative context	Narrative validated for tone compliance
Contract L3	All rules in prompt (fragile)	Deterministic blocks + modality overrides	Full pipeline: render, validate, enforce

Minimum consumer enforcement

Providers can require a minimum enforcement level from consumers using the minimum_consumer_enforcement field in the contract:

{
  "contract": {
    "fail_behavior": "suppress",
    "minimum_consumer_enforcement": "L2",
    ...
  }
}

When this field is set, a consumer runtime that only supports L1 (prompt-only) enforcement must refuse to process the response, because the provider requires deterministic rendering at minimum. This prevents contracts with critical compliance requirements from being handled by prompt-only runtimes where the LLM could silently drop disclosures or reformat data.

Compliance handshake

When a consumer fetches an AIPC-wrapped response, it advertises its enforcement level via the AIPC-Enforcement-Level HTTP header:

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

The provider can use this header to:

Reject the request if the consumer's level is below the contract's minimum_consumer_enforcement
Return a simplified contract if the consumer only supports L1
Include additional L3-only fields (e.g., signed contract hashes) when the consumer supports full enforcement

If the header is absent, the provider should assume L1 and apply the minimum enforcement check against the contract's requirements.