Vertical Pack Mandates

Vertical packs layer additional mandates on top of the 50 global mandates. When you create a project with --vertical fintech, all Fintech mandates become active in addition to the global set.

Available vertical packs

Pack	Use case	Additional mandates
`solo-founder`	Solo or small team building a product	8 mandates
`b2b-saas`	B2B software with multi-tenant orgs and SSO	12 mandates
`marketplace`	Two-sided marketplace with payments	15 mandates
`fintech`	Financial products, payments, lending	22 mandates
`healthcare`	Healthcare apps handling PHI	19 mandates
`pe-portfolio`	Portfolio company with reporting requirements	14 mandates

Fintech pack mandates

The Fintech pack activates 22 additional mandates focused on PCI DSS, fraud prevention, and financial data integrity.

id: mandate_f1
name: PCI DSS Card Data
version: 1.0.0
category: compliance
severity: blocking
vertical_pack: fintech

rules:
  - id: no-raw-card-data
    description: Raw payment card numbers must never be stored or logged.
    check: custom
    checker: checks/pci/card-data-scan.js
    action: block
    message: "Potential card data handling found. Route all card data through Stripe."

  - id: pci-compliant-processor
    description: All card payments must flow through a PCI-compliant processor.
    check: regex-match
    pattern: "stripe|adyen|braintree"
    file_pattern: "src/**/*payment*.ts"
    action: block
    message: "Payment code found without approved processor reference."

  - id: no-card-logging
    description: Card numbers and CVVs must not appear in logs.
    check: custom
    checker: checks/pci/log-scan.js
    action: block

id: mandate_f2
name: Transaction Integrity
version: 1.0.0
category: architecture
severity: blocking
vertical_pack: fintech

rules:
  - id: idempotency-keys
    description: All financial mutation endpoints must accept and enforce idempotency keys.
    check: custom
    checker: checks/fintech/idempotency-coverage.js
    action: block
    message: "Financial endpoint {{ endpoint }} lacks idempotency key handling."

  - id: double-entry
    description: All balance changes must use double-entry accounting (debit + credit).
    check: custom
    checker: checks/fintech/double-entry.js
    action: block

  - id: audit-trail
    description: All financial transactions must be logged with user ID, amount, currency, timestamp.
    check: custom
    checker: checks/fintech/transaction-audit.js
    action: block

id: mandate_f3
name: Fraud Signal Collection
version: 1.0.0
category: compliance
severity: warning
vertical_pack: fintech

rules:
  - id: velocity-checks
    description: Payment endpoints must implement velocity checks (n transactions per time window).
    check: custom
    checker: checks/fintech/velocity-check.js
    action: warn

  - id: device-fingerprint
    description: Payment flows should collect device fingerprint for fraud analysis.
    check: file-contains
    file: "src/**/*payment*.tsx"
    pattern: "deviceFingerprint|fingerprintjs"
    action: warn

Healthcare pack mandates

The Healthcare pack activates 19 mandates focused on HIPAA compliance, PHI handling, and audit trails.

id: mandate_h1
name: PHI Encryption
version: 1.0.0
category: compliance
severity: blocking
vertical_pack: healthcare

rules:
  - id: phi-at-rest
    description: Protected Health Information must be encrypted at rest with AES-256.
    check: custom
    checker: checks/hipaa/phi-encryption.js
    config:
      phiFields: [diagnosis, medication, lab_result, notes, dob, ssn, mrn]
      requiredAlgorithm: AES-256-GCM
    action: block

  - id: phi-in-transit
    description: PHI must only be transmitted over TLS 1.2 or higher.
    check: custom
    checker: checks/hipaa/tls-version.js
    action: block

  - id: no-phi-in-logs
    description: PHI must not appear in application logs.
    check: custom
    checker: checks/hipaa/log-phi-scan.js
    action: block

id: mandate_h2
name: HIPAA Audit Trail
version: 1.0.0
category: compliance
severity: blocking
vertical_pack: healthcare

rules:
  - id: phi-access-logged
    description: Every access to PHI must be logged with user ID, patient ID, timestamp, and purpose.
    check: custom
    checker: checks/hipaa/audit-coverage.js
    config:
      requiredFields: [userId, patientId, timestamp, purpose, action]
    action: block

  - id: audit-log-immutable
    description: HIPAA audit logs must be append-only and tamper-evident.
    check: custom
    checker: checks/hipaa/audit-immutability.js
    action: block

  - id: audit-retention
    description: HIPAA audit logs must be retained for minimum 6 years.
    check: file-contains
    file: "src/**/*audit*.ts"
    pattern: "retentionYears.*6|retentionDays.*2190"
    action: block

B2B SaaS pack mandates

id: mandate_b1
name: Multi-Tenancy Isolation
version: 1.0.0
category: security
severity: blocking
vertical_pack: b2b-saas

rules:
  - id: tenant-scoped-queries
    description: All DB queries on tenant data must filter by organization ID.
    check: custom
    checker: checks/b2b/tenant-scope.js
    action: block
    message: "Query on tenant data at {{ file }}:{{ line }} lacks org_id filter."

  - id: no-cross-tenant-data
    description: No query may return data from multiple organizations in a single result.
    check: custom
    checker: checks/b2b/cross-tenant.js
    action: block

id: mandate_b2
name: SSO Support
version: 1.0.0
category: compliance
severity: warning
vertical_pack: b2b-saas

rules:
  - id: saml-oidc-supported
    description: Auth must support SAML 2.0 or OIDC for enterprise SSO.
    check: file-contains
    file: "src/**/*auth*.ts"
    pattern: "saml|oidc|SAML|OIDC"
    action: warn
    message: "No SSO implementation found. B2B customers typically require SAML/OIDC."

Checking which mandates are active

# List all active mandates for a project
defiant mandates list --project proj_01hw...

# Output:
# GLOBAL (50):
#   [ACTIVE] mandate_1: AI-native baseline
#   [ACTIVE] mandate_7: Security baseline
#   ... 48 more
#
# VERTICAL (fintech — 22):
#   [ACTIVE] mandate_f1: PCI DSS Card Data
#   [ACTIVE] mandate_f2: Transaction Integrity
#   ... 20 more

Overriding mandate severity

You can escalate or downgrade mandate severity at the project level. Downgrades require a documented justification:

{
  "mandateOverrides": {
    "mandate_22": {
      "severity": "blocking",
      "reason": "Accessibility is a product requirement for our enterprise customers"
    },
    "mandate_3": {
      "severity": "advisory",
      "reason": "This project uses a custom versioning scheme approved by the team"
    }
  }
}

Override history is recorded in the event log and surfaced in compliance audits.