feat: add typed tier assurance guardrails

docs/PricingModelSchema.md

@@ -23,6 +23,7 @@ Each pricing model contains:
 - explicit charge components
 - commitments
 - tunable parameters
+- optional customer assurance claims with typed tenancy-posture minimums
 - eligibility and provider hints
 - free-form metadata for deployment-specific details
 
@@ -73,6 +74,25 @@ tunable_parameters:
     max_value: decimal | null
     options: []
 
+# Optional. Absence means the tier makes no assurance claim.
+assurance_claims:
+  - id: string
+    kind: isolation | availability | retention | performance
+    customer_wording: string
+    minimum_levels:
+      I: 0..3
+      A: 0..4
+      E: 0..4
+      P: 0..4
+      R: 0..4
+      V: 0..4
+    delivering_service: string
+    evidence_ref: string
+    maximum_erasure_horizon_days: integer | null
+    provider_contract_ref: string | null
+    resource_governor_ref: string | null
+    erasure_mechanism: row-deletion | key-destruction | null
+
 eligibility:
   - string
 
@@ -102,6 +122,18 @@ Current runtime validation enforces:
 - tunable parameter keys are unique
 - `customer_tunable` parameters declare bounds or enumerated options
 - commitment ids are unique
+- assurance claim ids are unique and each claim names a supported kind,
+  customer wording, typed in-range minimums, delivering service, and evidence
+- retention horizons are positive integers and erasure mechanisms use the
+  canonical vocabulary
+
+`assurance_claims` records the internal minimum that supports a customer-facing
+promise; it does not expose the framework ladder on a price page. The boundary
+engine checks coupled floors and wording, including E4/P3, retention horizons,
+resource-governed performance, and availability failure scope. Adding,
+changing, or removing a claim is assessed once at tier definition by
+`assess_tier_definition_assurance()`. An unchanged claim is not a per-campaign
+approval gate.
 
 ## Transitional Compatibility