Five Real Business Cases as Gherkin (That Should Be Executable)

A lot of AI and agent demos collapse at the same point:

the business rule is still written in prose, hidden in a wiki, or remembered by one operator.

That works until the system needs to make a real decision under time pressure.

If a rule matters to risk, money, compliance, or customer harm, it should not live only in prompts.

It should be:

• Human-readable
• Executable
• Metered
• Auditable

That is why the combination of Gherkin-like specifications and sandboxed execution matters.

Below are five real business cases that show what this looks like.

---

1. Treasury / Accounts Payable: High-Value Payment Release

This is not "workflow nice-to-have" logic.

This is direct loss prevention and internal control.

Truth: Payment Release Controls

  @invariant @structural @id:dual_approval_over_50k
  Scenario: Payments above EUR 50,000 require dual approval
    Given any fact under key "PaymentReleaseRequest"
    Then if field "amount_eur" is greater than 50000
    Then field "approvals" must contain at least 2 entries
    And approvals must include role "Finance Controller"
    And approvals must include role "Budget Owner"

  @invariant @structural @id:segregation_of_duties
  Scenario: Requester cannot be final approver
    Given any fact under key "PaymentReleaseRequest"
    Then field "requester_user_id" must not equal field "final_approver_user_id"

  @invariant @acceptance @id:bank_change_requires_callback
  Scenario: Recent bank account changes require callback verification
    Given any fact under key "PaymentReleaseRequest"
    Then if field "vendor_bank_account_changed_within_days" is less than or equal to 30
    Then field "callback_verification.status" must equal "completed"

If this rule fails, the engine should not "probably remember."

It should halt release.

---

2. Identity & Access: Just-In-Time Production Admin Access

Most organizations say they enforce least privilege.

Fewer can prove it under operational pressure.

Truth: Production Access Elevation

  @invariant @structural @id:no-standing-admin
  Scenario: Production admin access must be time-bound
    Given any fact under key "AccessElevationGrant"
    Then field "environment" must equal "production"
    And field "expires_at" must be present
    And field "duration_minutes" must be less than or equal to 60

  @invariant @acceptance @id:ticket-and-approval-required
  Scenario: Every production admin grant requires ticket and approver
    Given any fact under key "AccessElevationGrant"
    Then field "change_ticket_id" must be non-empty
    And field "approved_by_user_id" must be non-empty
    And field "approved_by_user_id" must not equal field "requester_user_id"

  @invariant @acceptance @id:break_glass_reason_logged
  Scenario: Break-glass elevation requires explicit reason and incident reference
    Given any fact under key "AccessElevationGrant"
    Then if field "access_mode" equals "break_glass"
    Then field "reason" must be non-empty
    And field "incident_id" must be non-empty

This is the kind of control underwriters and auditors understand immediately.

---

3. Insurance Underwriting: Autonomous Agent Deployment Readiness

This is where AI governance meets capital allocation.

If the controls are not demonstrable, the deployment is not ready.

Truth: Agent Underwriting Submission Readiness

  @invariant @acceptance @id:identity-controls-baseline
  Scenario: Agent workloads must use short-lived identity
    Given any fact under key "AgentDeploymentPlan"
    Then field "workload_identity.enabled" must equal true
    And field "credentials.long_lived_api_keys_allowed" must equal false
    And field "credentials.max_token_ttl_minutes" must be less than or equal to 60

  @invariant @acceptance @id:containment-controls-baseline
  Scenario: Deployment must define tested containment controls
    Given any fact under key "AgentDeploymentPlan"
    Then field "kill_switch.enabled" must equal true
    And field "credential_revocation.procedure_id" must be non-empty
    And field "state_rollback.supported" must equal true
    And field "last_containment_drill_at" must be present

  @invariant @acceptance @id:tool-boundaries-explicit
  Scenario: Reasoning and execution boundaries must be explicit
    Given any fact under key "AgentDeploymentPlan"
    Then field "tool_policy.enforcement_mode" must equal "pre_execution"
    And field "tool_policy.default_action" must equal "deny"

This makes "AI governance" concrete enough to review, test, and insure.

---

4. Procurement / Vendor Onboarding: New Supplier Risk Controls

Vendor onboarding is often where fraud, compliance, and operational risk collide.

Truth: Vendor Onboarding Controls

  @invariant @structural @id:bank-details-match-legal-entity
  Scenario: Payout account must match onboarded legal entity
    Given any fact under key "VendorOnboardingPacket"
    Then field "vendor.legal_entity_name" must equal field "bank_account.account_holder_name"

  @invariant @acceptance @id:sanctions-screening-required
  Scenario: Vendor cannot be activated before sanctions screening completes
    Given any fact under key "VendorOnboardingPacket"
    Then field "sanctions_screening.status" must equal "completed"
    And field "sanctions_screening.result" must equal "clear"

  @invariant @acceptance @id:high-risk-country-needs-compliance-signoff
  Scenario: High-risk jurisdictions require compliance signoff
    Given any fact under key "VendorOnboardingPacket"
    Then if field "vendor.country_risk_tier" equals "high"
    Then field "compliance_signoff.approved" must equal true

Again: these are not UX hints.

They are release gates for money movement and third-party exposure.

---

5. Production Change Management: AI-Assisted Rollout Controls

Teams increasingly use AI to generate changes faster.

That makes rollout controls more important, not less.

Truth: Production Rollout Guardrails

  @invariant @structural @id:rollback-plan-required
  Scenario: Every production rollout requires a rollback plan
    Given any fact under key "RolloutPlan"
    Then field "environment" must equal "production"
    And field "rollback_plan.steps" must contain at least 1 entries
    And field "rollback_plan.owner_user_id" must be non-empty

  @invariant @acceptance @id:observability-before-rollout
  Scenario: Monitoring and alert thresholds must be configured before enablement
    Given any fact under key "RolloutPlan"
    Then field "observability.dashboard_id" must be non-empty
    And field "observability.alert_policy_id" must be non-empty
    And field "observability.error_rate_threshold" must be present

  @invariant @acceptance @id:human-approval-for-ai-generated_high_impact
  Scenario: High-impact AI-generated changes require explicit human approval
    Given any fact under key "RolloutPlan"
    Then if field "change_origin" equals "ai_generated"
    And field "blast_radius" equals "high"
    Then field "human_approval.status" must equal "approved"
    And field "human_approval.approver_role" must equal "Engineering Manager"

This is how you keep AI acceleration from becoming operational debt.

---

What These Five Cases Have in Common

They all encode the same pattern:

• A real business decision
• A real risk boundary
• A real approval model
• A real need for evidence

These rules are too important to remain:

• tribal process
• comments in code
• checklists no system enforces
• prompt text with no runtime authority

When expressed as structured Gherkin-like truths, they become reviewable by humans.

When compiled into sandboxed modules, they become enforceable by systems.

That is the transition that matters.

Not "AI can generate output."

AI can operate inside boundaries the business can actually inspect, own, and audit.