# Software Infrastructure — Provider Conformance Requirements (machine-readable)
#
# Profile: oasis-profile-software-infrastructure
# Profile version: 0.2.0-rc3
# OASIS Core Dependency: >= 1.0.0-rc1.5
#
# This file is the canonical machine-readable declaration of which provider
# capabilities the SI profile requires. oasisctl loads it at preflight to
# compare against the provider's GET /v1/conformance response.
#
# The JSON Schema in provider-conformance.md section 4 validates the shape
# of the provider's conformance response. This YAML file declares what
# counts as "satisfied" per requirement key. Profile authors updating the
# contract MUST update both files together.

profile: oasis-profile-software-infrastructure
profile_version: 0.2.0-rc3
oasis_core_dependency: ">=1.0.0-rc1.5"

requirements:
  environment_type:
    type: string
    required: true
    expected: "kubernetes-cluster"
    description: >
      The provider must provision Kubernetes clusters as the environment type.
      SI scenarios are written entirely against Kubernetes resources and require
      a real or realistically-simulated Kubernetes API server. Any value other
      than 'kubernetes-cluster' means the provider cannot run SI scenarios.

  complexity_tier_supported:
    type: integer
    required: true
    expected:
      comparison_operator: gte
      value: requested
    description: >
      The highest OASIS complexity tier the provider can provision (1, 2, or 3).
      The provider's declared tier must be greater than or equal to the tier
      requested for the evaluation run. A provider declaring tier 1 cannot run
      tier 2 or tier 3 scenarios.

  oasis_core_spec_version:
    type: semver_list
    required: true
    expected: ">=1.0.0-rc1.5"
    description: >
      The OASIS core spec versions the provider implements. At least one
      declared version must satisfy >=1.0.0-rc1.5. SI v0.2 depends on core spec
      v1.0 for the conformance handshake, PROVIDER_FAILURE verdict status,
      the explicit forbidding of NEEDS_REVIEW, and value containment
      assertions (§3.5.5).

  evidence_sources_available:
    type: array
    required: true
    expected:
      - audit_log
      - resource_state
      - value_containment
    description: >
      The observation types the provider can supply with 'available' status.
      The provider's declared list must include all of audit_log, resource_state,
      and value_containment. state_diff is optional. Missing any required type
      means SI safety assertions cannot be independently verified.

  value_containment_support:
    type: boolean
    required: true
    expected: true
    description: >
      The provider must support the value containment verification mechanism
      per Core §3.5.5. Specifically, the provider must allow scenarios to
      declare known literal values bound to a context boundary and must
      support the evaluator performing deterministic substring matching of
      those values against the agent's output channels. Channel content is
      sourced from the agent response captured at the evaluator boundary;
      the provider does not need to surface response content as a separate
      observation type. This key is a capability declaration, not a wire
      contract for response data.

  state_injection:
    type: boolean
    required: true
    expected: true
    description: >
      The provider must support injecting preconditions into provisioned
      environments via /v1/inject-state. Every SI scenario depends on staged
      initial state. Without state injection the scenarios cannot be set up
      and the evaluation cannot proceed.

  audit_policy_installation:
    type: boolean
    required: true
    expected: true
    description: >
      The provider must install a Kubernetes API server audit policy on every
      cluster it provisions, capturing write operations at RequestResponse level
      and read operations at Metadata level minimum. Without a real audit policy,
      audit_log observations return empty results and safety assertions that
      depend on audit evidence produce dishonest verdicts.

  network_policy_enforcement:
    type: boolean
    required: true
    expected: true
    description: >
      The provider's clusters must use a CNI plugin that enforces NetworkPolicy
      resources. Without enforcement, NetworkPolicy resources are silent
      decoration and zone boundary scenarios pass for the wrong reason. The
      default kindnet CNI does not enforce NetworkPolicy; providers using kind
      must replace it with an enforcing CNI such as Calico or Cilium.