Sync from Staging: Remove provider compliance declarations

assets/provider-monitor-schema-v2.openapi.json

@@ -136,9 +136,6 @@
           "deployment_region": {
             "type": "string",
             "minLength": 1
-          },
-          "compliance": {
-            "$ref": "#/components/schemas/Compliance"
           }
         },
         "required": [
@@ -2289,20 +2286,6 @@
           "country_code"
         ],
         "additionalProperties": false
-      },
-      "Compliance": {
-        "type": "object",
-        "properties": {
-          "zdr": {
-            "type": "boolean"
-          },
-          "hipaa": {
-            "type": "boolean"
-          }
-        },
-        "additionalProperties": {
-          "type": "boolean"
-        }
       }
     }
   }

guides/community/for-providers.mdx

@@ -133,8 +133,7 @@
         "slug": "anthropic/claude-sonnet-4"
       },
       "datacenters": [{ "country_code": "US", "region": "us-east-1" }],
-      "deployment_region": "US",
-      "compliance": { "zdr": true, "hipaa": false }
+      "deployment_region": "US"
     }
   ]
 }
@@ -246,7 +245,7 @@
 | `capacity` | No | Declared throughput limits for this input (see [Capacity](#4-capacity)) |
 | `passthrough_parameters` | No | Provider-specific parameters scoped to this input (see [Passthrough Parameters](#5-passthrough-parameters)) |
 
 The `supported_inputs` object uses the same [capability descriptor](#capability-descriptors) grammar as output `supported_parameters`, with closed enums for every known value domain:
 
 | Modality | Constraint fields |
 |---|---|
@@ -417,7 +416,7 @@
 | `range` | `{ "type": "range", "min": 0, "max": 1 }` | Any number in `[min, max]` is valid |
 | `integer` | `{ "type": "integer", "min": 1, "max": 128000, "unit": "token" }` | Any integer in `[min, max]` is valid |
 | `boolean` | `{ "type": "boolean" }` | Supported (present) or unsupported (absent) |
 | `enum` | `{ "type": "enum", "values": ["standard", "priority"] }` | Discrete allowlist of accepted values |
 | `array` | `{ "type": "array", "items": { ... }, "max_items": 4 }` | List of values described by `items` |
 | `object` | `{ "type": "object", "properties": { ... } }` | Nested object with per-key descriptors |
 | `unknown` | `{ "type": "unknown" }` | Accepted, but the value domain is not machine-described |
@@ -436,7 +435,7 @@
 { "type": "completion", "unit": "megapixel", "cost_usd": "0.015" }
 ```
 
 A document that validates is a valid declaration, not a guarantee that every declared SKU is billed today: OpenRouter bills the SKUs its pipeline supports and records the rest, and billing for newly declared SKU shapes lands as support for them does. Declare what you charge; do not tailor the document to what OpenRouter currently bills.
 
 **Input pricing types** (on input modality entries):
 
@@ -460,11 +459,11 @@
 | `request` | Flat cost per request |
 | `web_search` | Cost per web search performed |
 
 Do not zero-stuff prices: omit pricing entries for SKUs you don't bill. A genuinely free SKU exposed as a distinct billable line may use `"0"`. A modality with no `pricing` array is simply unpriced.
 
 #### Conditional pricing with `overrides`
 
 Conditional pricing (e.g. long-context tiers) attaches declaratively to the individual pricing entry it modifies, using a `when` predicate:
 
 ```json lines
 {
@@ -515,13 +514,13 @@
 
 #### Cache pricing
 
 Cache prices are first-class SKUs in a modality's `pricing` array. Multiple entries may have the same `type` when their qualifier fields differ. The effective identity of an entry is its `type` together with its qualifiers, so two `cache_write` entries with different TTLs are separate SKUs. Two entries with the same effective identity are invalid.
 
 `ttl_seconds` is the cache lifetime the price applies to. It is a qualifier field, not part of the `type` string, so providers can add lifetimes without expanding the pricing type enum. `implicit` marks provider-initiated caching that the request does not ask for and defaults to `false`. Explicit and implicit cache modes can coexist on one model.
 
 Cache pricing is input-side. Prompt caching stores and re-reads input tokens, so cache entries belong on input modality entries and never on outputs. The word `write` describes writing to the prompt cache, not generated output.
 
 Cache prices are base entries, not overrides. Overrides remain reserved for request-conditional pricing on generation parameters. Cache SKUs are enumerable so billing and product surfaces can display them directly. A provider may take TTL as a request parameter and the price is still modeled as a cache SKU rather than an override. A cache entry may itself carry overrides for genuinely request-conditional pricing, such as a long-context tier raising the cache write rate, but never for TTL differences.
 
 Cache pricing is per modality, so an image input modality can carry its own cache entries at its own rates. A text input modality offering two explicit write lifetimes alongside provider-initiated caching looks like this:
 
@@ -559,7 +558,7 @@
 }
 ```
 
 Time windows are accepted on input and output pricing entries. Like `ttl_seconds`, the window is part of the entry's effective identity, so entries with different windows are separate SKUs and two entries with the same window are invalid.
 
 **Weekly schedules** add the optional `utc_days` qualifier — a non-empty array of UTC weekday names (`"monday"`, `"tuesday"`, `"wednesday"`, `"thursday"`, `"friday"`, `"saturday"`, `"sunday"`, no repeats), evaluated at the request instant in UTC. With a `utc_start`/`utc_end` window it scopes the window to those days; without one it covers the listed whole days. `utc_days` joins the entry's effective identity alongside the window. A peak window that applies only on weekdays:
 
@@ -608,7 +607,7 @@
 
 Limits declared in different scopes are independent buckets that all apply simultaneously: a per-modality token limit and a root request limit each constrain traffic on their own dimension, and a request is admitted only when every declared limit it consumes against has headroom. Declaring a limit in one scope does not relax or replace a limit in another.
 
 This reuse distinguishes prompt, cached prompt, and output capacity without adding separate fields for each dimension. Capacity and pricing remain separate sibling arrays because a modality may declare limits without prices, or prices without declared limits. Units are constrained per scope, exactly as pricing units are: an entry accepts any unit its scope (input, output, or root) can bill in, so image capacity is expressed as images per minute (or megapixels per minute for resolution-scaled throughput), video capacity as output seconds per minute, and a mismatched pairing (such as a `prompt` capacity per `search`) is rejected at validation time. Validation is not narrowed to the owning modality's own billing unit, which is why an image output modality may carry a `concurrency` entry in `request` units.
 
 Here is a capacity declaration covering text input, text output, image output, and request scope:
 
@@ -681,29 +680,23 @@
 }
 ```
 
-### 6. Datacenters, deployment region, and compliance
+### 6. Datacenters and deployment region
 
-Declare where each endpoint physically serves from and its data-handling posture:
+Declare where each endpoint physically serves from:
 
 ```json lines
 {
   "datacenters": [
     { "country_code": "US", "region": "us-east-1" },
     { "country_code": "DE" }
   ],
-  "deployment_region": "US",
-  "compliance": {
-    "zdr": true,
-    "hipaa": false
-  }
+  "deployment_region": "US"
 }
 ```
 
 - `datacenters[].country_code`: ISO 3166-1 alpha-2 country code.
 - `datacenters[].region`: provider-scoped region identifier (e.g. `us-east-1`).
 - `deployment_region`: optional provider-scoped label for the model deployment's region or scope (e.g. `US`, `global`). Use it when the same underlying model is deployed to more than one region under distinct model `id`s, so each document declares which regional deployment it describes. It complements `datacenters`, which lists the physical serving locations. This is a display-only label today: OpenRouter does not route or bill on it, so use consistent values across your documents and coordinate the vocabulary with us before publishing.
-- `compliance.zdr`, zero data retention: no prompt retention and no training on prompts.
-- `compliance.hipaa`: HIPAA compliance. Additional boolean certification flags (SOC 2, GDPR, FedRAMP, ...) may be added over time.
 
 ### 7. Operational fields
 
@@ -787,7 +780,7 @@
 Behavior:
 
 - OpenRouter creates a separate endpoint for each tier document, using that document's own pricing, context length, limits, and capabilities. A priority tier with a shorter context window, or a flex tier with fewer supported parameters, declares those differences in its own document.
 - A tier document is staged only once OpenRouter serves the default tier of the same `id`. Publish the default document first, or alongside the tier documents. Tier endpoints then go through the standard staging, baseline test, and unhide flow.
 - Tier endpoints appear to users as [service tier endpoints](/guides/features/service-tiers): they are reachable through the `service_tier` request parameter, the `:nitro` and `:floor` variants, and tier-suffixed provider slugs, and they stay out of default routing.
 - `service_tier` is OpenRouter's vocabulary, not your API's. If your API names a tier differently, for example `standby` for a discounted tier, still publish it as `flex` here. The mapping to your wire format lives in OpenRouter's integration for your API.
 - A document cannot combine `is_free: true` with `service_tier`. Free endpoints are a separate variant of the default tier.