PayCal Technologies Inc.

Verification and Governance Transparency

This page explains the controls PayCal uses to verify behavior and enforce operational guardrails in production.

Published: · Last updated:

What We Mean by Governance

For us, governance means policy encoded into code paths, limits, tests, and deployment checks. It is not a document-only promise.

The references below map to implementation points in this repository so claims can be independently verified.

Verification Metadata

Route metadata

  • Route: /transparency/verification-governance/
  • Last verified:
  • Next review due:
  • Verification scope: manual review of described gate implementations against current hooks, CI pipeline checks, and runtime control paths.
  • Previous version: Verification and Governance before the June 2026 tooling update

Known limitations

  • Gate descriptions are maintained manually; automated cross-reference between this page and hook/pipeline config is planned for quarterly close-out.
  • Runtime limit values reflect defaults; environment-specific overrides may differ on non-development instances.

This metadata is updated quarterly as part of the governance audit close-out.

Current Security Audit Status

As of 2026-03-24, PayCal remains in PASS status after the BRS-01 through BRS-05 expansion and follow-up release hygiene synchronization.

Public status details and evidence references are published at /transparency/security-audit/.

1) Local Policy Gates (Git Hooks)

Local hooks block unsafe merges before code reaches shared branches.

  • githooks/pre-commit runs PHPStan Level 9 on staged PHP files under html/.
  • githooks/pre-commit blocks baseline usage in phpstan.neon and blocks phpstan-baseline.neon.
  • githooks/pre-push runs full-repo PHPStan Level 9 and applies the same baseline-blocking policy.

These gates reduce the chance of policy drift and silent quality regressions.

2) CI Verification Pipeline

The CI workflow runs progressively deeper test layers from fast validation to stress-style verification.

For the current end-to-end CI/CD operating model, see CI/CD Tooling and Release Governance.

  • .github/workflows/phpunit.yml Stage 2: composer run test:all (unit + integration + contract).
  • .github/workflows/phpunit.yml Stage 3: composer run test:random (order-randomized).
  • .github/workflows/phpunit.yml Stage 3: composer run test:coverage.
  • .github/workflows/phpunit.yml Stage 4: mutation test job.

Representative contract/integration suites include html/tests/Integration/KekContractTest.php, html/tests/Integration/RedisContractTest.php, and contract tests under html/tests/Contract/.

3) Runtime Rate Limits and Input Governance

Operational endpoints are bounded by explicit request windows and payload validation rules.

  • html/src/Domain/RateLimiter.php defines per-minute endpoint and IP limits, including telemetry (90/minute).
  • html/src/Controllers/TelemetryController.php enforces authentication and telemetry rate limits before accepting events.
  • html/src/Controllers/TelemetryController.php bounds event type format with a strict regex to control key cardinality.
  • html/src/Controllers/EmailVerificationController.php applies retry windows with TTL-backed rate-limit keys.

These controls are intended to keep behavior predictable under both normal and abusive traffic patterns.

4) TTL and Security Limit Governance

Security-sensitive flow limits are centrally defined and bounded with min/max constraints.

  • html/src/system-limits-master.php includes enable_rate_limiting and account-recovery controls.
  • Account-recovery limits include code TTL, resend cooldowns, max verify attempts, replay windows, and hashed-IP block TTLs.
  • html/src/Domain/AccountRecoveryAbuseGuard.php records replay telemetry and applies automatic hashed-IP blocking when thresholds are exceeded.
  • html/src/Domain/AccountRecoveryTransaction.php enforces transaction/proof/bootstrap expiries from system limits.

This structure allows controlled policy updates without bypassing typed bounds.

5) CSP and Asset Delivery Controls

Public-facing pages are governed by explicit Content Security Policy and nonce-aware script/style rendering.

  • html/header.php builds and emits CSP directives including default-src 'none' and strict script-src/style-src policies.
  • html/header.php includes Trusted Types policy directives.
  • html/src/Domain/Render.php supports nonce-based module script rendering.

These controls constrain executable surfaces and are part of our baseline governance model.

How to Verify These Claims

Developers can reproduce verification signals directly in this repository:

# Static analysis gates
bash githooks/pre-commit
bash githooks/pre-push

# Test pipeline equivalents
cd html
composer run test:all
composer run test:random
composer run test:coverage

Last updated: June 22, 2026.