Example 22

Automatic approval vs over-limit requests

Automation should be fast inside the approved envelope and escalate to a person outside it.

Status
runnable in repo test
Industry
Healthcare
Language
Python
Framework
pytest
CI
GitHub Actions
Fulfilment
BUILD_DATASET
Profile
healthcare-integration

About this example

All data is synthetic. DataNivra provisions approved test data into a customer-controlled target; it does not run these tests. Credentials for the target are never returned by DataNivra — your runner holds its own.

Why test data matters

Automation should be fast inside the approved envelope and escalate to a person outside it.

What is requested

2,700 records: inside the profile (3,000) but over the envelope (2,500).

Policy gates

Envelope approved with the profile version; automatic approval needs the operator and tenant switches.

What is provisioned

Nothing until a person approves; then a certified synthetic dataset.

Expected output

PENDING_HUMAN_APPROVAL, reason TOTAL_EXCEEDS_ENVELOPE; a second person approves with datanivra test-data approve <id> --reason ....

Cleanup

Release (cancels while pending).

Files

  • request.yaml
  • example.py

Run

  1. A tenant administrator defines and a second person approves the profile (datanivra test-data define ../../profiles/healthcare-integration.yaml --submit, then datanivra policies approve).
  2. datanivra test-data validate request.yaml && datanivra test-data plan request.yaml
  3. Run the example with DATANIVRA_BASE_URL and a session or workload token.

Files

Exactly as they are in the examples repository. Every value is a synthetic placeholder; nothing here is a credential.

request.yaml

# yaml-language-server: $schema=../../../../packages/contracts/schemas/v1/manifests/test-data-request.schema.json
# DataNivra test-data-request manifest (apiVersion datanivra.io/v1alpha1). Validate: datanivra test-data validate <file>
apiVersion: datanivra.io/v1alpha1
kind: TestDataRequest
metadata:
  name: over-envelope
spec:
  profile: { name: healthcare-integration, version: 1 }
  scenarios:
    - { scenario_code: HC_ROUTINE_CARE, count: 500 }
    - { scenario_code: HC_CHRONIC_CARE, count: 2000 }
    - { scenario_code: HC_CLAIM_DENIALS, count: 200 }

examples/test-data-api/scenarios/22-auto-approval-vs-over-limit/request.yaml

example.py

"""Automatic approval vs over-limit requests — provision approved test data through the Python SDK.

``provision`` only asks DataNivra for data from the approved ``healthcare-integration`` profile; your own test
suite runs against the approved target with its own, separately managed database access.
"""

from __future__ import annotations

from pathlib import Path

from datanivra_contracts.testdata import TestDataRequest
from datanivra_sdk import DataNivraClient
from datanivra_sdk.testdata import TestDataClient

REQUEST = Path(__file__).with_name("request.yaml")


def provision(api: DataNivraClient, *, idempotency_key: str | None = None) -> TestDataRequest:
    """Create (or, for the same key, return) the request; DENIED raises ``DataNivraApiError``."""
    return TestDataClient(api).request(REQUEST, idempotency_key=idempotency_key)

examples/test-data-api/scenarios/22-auto-approval-vs-over-limit/example.py

The profile it uses: healthcare-integration

A tenant administrator defines this profile and a second person approves it; requests can only ask for what it allows. All profiles

healthcare-integration.yaml

# yaml-language-server: $schema=../../../packages/contracts/schemas/v1/manifests/test-data-profile.schema.json
# DataNivra test-data-profile manifest (apiVersion datanivra.io/v1alpha1). Validate: datanivra test-data validate <file>
# Placeholder ids (00000000-0000-4000-8000-0000000000NN): replace with your ids.
# 01 = approved target environment, 11 = certified dataset, 21 = customer agent,
# 99 = workload identity trust (datanivra workload-identities list).
apiVersion: datanivra.io/v1alpha1
kind: TestDataProfile
metadata:
  name: healthcare-integration
  description: Synthetic members (patients) and their encounters (appointments) for integration tests
spec:
  fulfilment: BUILD_DATASET
  build:
    business_domain: patient encounters
    pack_id: healthcare
    dataset_kind: SYNTHETIC_ONLY
    target_environment_id: 00000000-0000-4000-8000-000000000001
    retention_days: 1
    max_total_records: 3000
    scenarios:
      - {
          pack_id: healthcare,
          scenario_code: HC_ROUTINE_CARE,
          kind: NORMAL,
          default_count: 500,
          max_count: 500,
        }
      - {
          pack_id: healthcare,
          scenario_code: HC_CHRONIC_CARE,
          kind: HIGH_VOLUME,
          default_count: 2000,
          max_count: 2000,
        }
      - {
          pack_id: healthcare,
          scenario_code: HC_CLAIM_DENIALS,
          kind: RARE,
          default_count: 50,
          max_count: 400,
          included_by_default: false,
        }
      - {
          pack_id: healthcare,
          scenario_code: HC_ABNORMAL_LABS,
          kind: BOUNDARY,
          default_count: 50,
          max_count: 200,
          included_by_default: false,
        }
  automation:
    workload_identity_ids: [00000000-0000-4000-8000-000000000099]
    max_total_records: 2500
    max_live_requests: 10
    max_requests_per_hour: 60
    escalate_out_of_envelope: true
  audit_tags: [HEALTHCARE_SYNTHETIC]

examples/test-data-api/profiles/healthcare-integration.yaml