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.

~~~gherkin 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.

~~~gherkin 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.

~~~gherkin 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.

~~~gherkin 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.

~~~gherkin 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.

Those boundaries let the business inspect and audit how AI-generated work is used.