Operator Compliance Configuration v1

Contract: tenant-operator-compliance-settings.v1 Owner: Authority Status: Initial Authority implementation Audience: Authority service owners, Console/CLI Assurance integrators, and compliance owners configuring tenant Assurance settings.

Purpose

This contract defines the tenant-persisted operator settings for Assurance and compliance workflows. Its job is to keep customer- and operator-controlled choices (approvers, pack enablement, retention, distribution channels) cleanly separated from sealed deployment posture and secret material — the two MUST NOT mix (see Sealed Or Environment Settings).

Authority stores this document under the authority.tenants.settings key operatorCompliance. The tenant compliance profile remains under the tenant metadata key complianceProfile until a dedicated tenant-catalog column lands.

Related contracts: Tenant Compliance Profile v1 (the tenant-compliance-profile.v1 document this contract reads regime state from) · Assurance Pack v1 · Assurance Setup Prerequisites v1.

Sealed Or Environment Settings

These values must not be stored in operatorCompliance:

Authority validation rejects any unknown operator-setting key (anything not part of tenant-operator-compliance-settings.v1 is reported as not part of the schema). Keys that look like secret material or deployment posture are rejected with a distinct “cannot be stored as tenant operator settings” message. The explicit forbidden-key set includes secret, secrets, secretRef, signingKey, signingKeyPem, privateKey, privateKeyRef, privateKeyPem, signingProvider, signingProviderMode, publicBaseUrl, canonicalPublicBaseUrl, trustRoots, trustRoot, trustRootBundle, schemaAssetRoot, schemaHashAllowlist, endpointSecret, endpointFailClosedMode, routerFailClosedMode, failClosedMode, sealedMode, networkEgressPolicy, publicationEnabled, deploymentPosture, mailboxCredential, smtpSecret, providerSecret, storageRoot, and credentialSecretRef. In addition, any key containing the fragments secret, apikey/api_key, password, credential, token, signingkey/signing_key, privatekey/private_key, deployment, endpointsecret/endpoint_secret, mailboxcredential/mailbox_credential, or trustroot/trust_root is rejected. The CLI update command applies the same fragment-based scan client-side and refuses to send a document containing such fields.

Tenant-Persisted Settings

The persisted document is tenant-operator-compliance-settings.v1 (the top-level schemaVersion). It may contain:

Identifier fields (approverId, packId, channelId, kpiKey, providerId) are lower-cased and must match ^[a-z0-9](?:[a-z0-9._-]{0,126}[a-z0-9])?$. Approvers, packs, channels, and providers are de-duplicated and emitted in a deterministic order (the subcontracting list is ordered by rank then providerId).

Assurance Pack Enablement

Authority stores only operator-owned pack enablement state. It does not store sealed deployment readiness facts, signing key material, trust roots, storage roots, public endpoint posture, mailbox credentials, or provider secrets.

Supported pack modes are:

Supported claim boundaries are:

Example:

{
  "assurancePacks": [
    {
      "packId": "nis2",
      "enabled": true,
      "mode": "signed-export",
      "claimBoundary": "operator-support",
      "ownerRole": "compliance-owner",
      "enabledBy": "setup-wizard",
      "enabledAt": "2026-05-01T09:00:00Z",
      "lastReviewedAt": "2026-05-01T09:00:00Z",
      "configRevision": 1
    },
    {
      "packId": "cra.product-security",
      "enabled": true,
      "mode": "public-publication",
      "claimBoundary": "manufacturer-self",
      "ownerRole": "product-security-owner",
      "enabledBy": "setup-wizard",
      "enabledAt": "2026-05-01T09:00:00Z",
      "lastReviewedAt": "2026-05-01T09:00:00Z",
      "configRevision": 1
    }
  ]
}

The Authority readiness API itself only emits the three deterministic booleans described under “Assurance Pack Readiness Gates” and their three reason codes (authority-profile-missing, operator-approver-missing, retention-policy-unreviewed). Higher-level readiness is composed downstream: NIS2 SoA live-export readiness is derived from Authority profile state, operator approver state, and downstream sealed readiness checks. CRA product publication readiness is derived from the CRA Product Security Pack state plus external publication preflight checks for mailbox/key/route readiness. Those preflight facts are reason codes, not tenant-stored secrets.

Retention Rules

Authority normalizes an absent DORA RoI policy to 7 years. DORA RoI, DORA incident-report, and standards-mapping evidence overrides are accepted between 5 and 10 years. TLPT pack retention has a 10-year minimum. Any non-default override requires reason and approvedBy. Shortening a previously committed period requires shorteningApprovedBy.

EvidenceLocker remains the durable retention ledger owner. Downstream writers use the Authority-normalized effective policy to populate evidence_locker.regulatory_retention_records with the same retention years, policy reason/approval refs, and shortening approval ref. Authority emits local operator config hashes; EvidenceLocker records the durable artifact-specific retention ledger row when a regulatory artifact is generated or exported.

Assurance Pack Readiness Gates

GET /api/v1/tenants/{tenantId}/assurance-packs returns, per enabled pack, three Authority-owned readiness booleans and a stable, sorted reasonCodes array. Each boolean is computed deterministically from tenant configuration:

Framework → required retention evidence class mapping (v1):

FrameworkRequired retention evidence class
doradora-roi (Authority always normalizes an absent dora-roi to a 7-year floor, so DORA is covered once the regime is active)
nis2dora-incident-report
crastandards-mapping-evidence

An unknown/unmapped pack framework treats any positive-period retention policy as reviewed.

Approval And Fresh Auth

Approver assignments require at least one identity selector: email, subjectId, or roleRef. submit and autoSubmitApproval actions are normalized with freshAuthRequired=true. The Console admin endpoints enforcing these writes are fresh-auth-gated.

Write audit events include:

The settings-replace path (authority.admin.operator_config.update) also emits roll-up counters (operator_config.approvers.count, operator_config.assurance_packs.count, operator_config.channels.count, and operator_config.retention.dora_roi.years), and the read path (authority.admin.operator_config.read) emits the same property shape with action=read.

Approver assignment (authority.admin.operator_config.approver.assign) and revocation (authority.admin.operator_config.approver.revoke) events also include approver.id, approver.active, approver.actions, approver.scopes, approver.regimes, and approver.fresh_auth_required.

Pack enablement, disablement, and mode-change deltas use authority.admin.operator_config.pack.enable, authority.admin.operator_config.pack.disable, and authority.admin.operator_config.pack.mode_change event types and include assurance_pack.id, assurance_pack.enabled, assurance_pack.mode, assurance_pack.prior_mode, assurance_pack.claim_boundary, assurance_pack.owner_role, assurance_pack.config_revision, operator_config.prior_hash, operator_config.new_hash, and the Authority audit correlation id. Retention-period changes emit authority.admin.operator_config.retention.change with retention.evidence_class, retention.years, retention.approved_by, and retention.shortening_approved_by. These delta events are derived during the settings-replace flow and are in addition to the single authority.admin.operator_config.update event.

Authority Endpoints

The Authority surface is split between Console admin (mutation) routes under /console/admin/tenants and runtime-safe read routes under /api/v1/tenants:

Console admin (mutation) routes:

Runtime-safe read routes:

The whole /console/admin group requires the ui.admin scope plus a tenant header (X-Tenant-Id) and fresh auth. Each operator-compliance route additionally requires authority:tenants.read (the GET read route) or authority:tenants.write (the PUT, approver POST, and approver DELETE write routes); the write routes are additionally fresh-auth-gated. The /api/v1/tenants read group requires authority:tenants.read and enforces that the resolved tenant header matches the path tenant.

The Console admin GET .../operator-compliance route returns the full tenant-operator-compliance-settings.v1 document together with tenantId and the canonical settings hash (sha256: hex). The PUT, approver POST, and approver DELETE routes echo back the normalized settings (or normalized approver) plus priorHash and hash.

The /api/v1/tenants/{tenantId}/assurance-packs read route returns tenant-assurance-pack-readiness.v1 with a top-level status (disabled when no packs are enabled, configured when every enabled pack is ready, blocked when any enabled pack has reason codes), the enabledPacks array, and a readiness array of Authority-owned booleans (authorityProfileConfigured, operatorApproverConfigured, retentionPolicyReviewed) plus a stable, sorted reasonCodes array per pack.

The /api/v1/tenants/{tenantId}/submission-authorizations read route returns tenant-submission-authorization.v1 for a purpose (and optional channelId). The response carries the resolved regime, the canonical settingsHash, the maximum settingsRevision across the regime’s packs, autoSubmitEnabled, approvalRequired, freshAuthRequired, an activeApprovers array (runtime-safe approver projection — never private keys or secrets), and a sorted reasonCodes array (purpose-unsupported, submission-channel-missing, purpose-channel-mismatch, channel-disabled, auto-submit-disabled, approver-missing). It performs no writes and stores no secrets.

The runtime-safe compliance-profile read route returns tenant-compliance-profile.v1 (the nullable Authority-owned tenant compliance profile carrying LEI, jurisdiction code, responsibility locus, regulated regimes, and the per-regime dora/nis2/cra sub-profiles).

Operator Surfaces

The generic Assurance CLI exposes this contract without introducing a jurisdiction-specific command namespace:

CLI output uses operator-compliance-config.v1, includes the Authority settings hash, and computes effective retention rows from the normalized settings. An absent dora-roi policy is shown as a 7-year Authority default. The CLI redacts secret-like fields in read/export output and refuses update input containing secret material or deployment posture.

The Console Assurance shell (/assurance) is the UI entry point for the same operator-owned settings. It may display effective retention, approver, Assurance pack, and channel counts next to live readiness, but it must not label the product as European compliance or present the settings as legal certification.