Chronos
Sign inGet startedGGeett ssttaarrtteedd
Why ChronosFeaturesPricingCompareSecurityHow it worksSign inGet started
v1.0 · July 2026 · Public version. Our full internal policy set is available under mutual NDA via the security documentation package.
// Security policy

Change Management Policy

Mahlum Innovations LLC · Effective July 2026

Every change that reaches production is intentional, attributable, tested, reversible, and — for anything customer-visible — truthful. This policy covers the application (PHI-handling), the marketing site, infrastructure configuration, and secrets.

Chronos develops with AI-assisted engineering. Agent-authored changes follow the same gates as human-authored ones, and the founder is always the reviewer of record for production deploys, with automated gates (typecheck, test suite, preflight configuration diagnostics) doing the mechanical verification.

1. Standard change flow

Every production change passes through these steps in order:

Step 1: Scoping

The change is scoped in writing before work starts. Changes touching authentication or PHI-handling code paths require explicit founder scoping in advance.

Step 2: Implementation

Implementation happens in development environments with no PHI present. No real patient data or customer records exist in non-production systems.

Step 3: Automated gates

Typecheck and the full test suite must pass. Billing tests refuse live-mode payment keys — a live key in a test run is a hard failure.

Step 4: Attributable commits

Commits carry descriptive, attributable messages. Vague or undescribed commits are not permitted for production changes.

Step 5: Preflight deploy

Production deploys run through an audited deploy script whose preflight validates security-critical configuration (database TLS verification, fail-closed AI-gateway resolution) before anything ships. A deploy that fails preflight does not reach production.

Step 6: Post-deploy verification

Health checks and, for significant changes, manual smoke tests confirm the deploy is functioning correctly before it is considered complete.

2. Truthful-claims gate

Any change that adds or edits a compliance, security, certification, insurance, or legal claim on a public page must pass a truthfulness review before publication. Specifically:

  • No certification is named unless the report or certificate exists and is current.
  • The legal entity name (Mahlum Innovations LLC) must be correct everywhere, including structured data (JSON-LD).
  • Retention, backup, breach-notice, and insurance figures must match current contracts and verified infrastructure facts.
  • Approved wordings: 'SOC 2 readiness program' (not 'SOC 2 Type II certified'); 'HIPAA-aligned with a signed BAA' (not 'HIPAA-compliant').
  • Backup schedule is daily backups retained 30 days, monthly backups retained 12 months — no other figures may be published.
  • Breach notification commitment is 72 hours — no other figure may be published.

Published claims are re-verified against this gate on a weekly cadence. Regressions — false certification claims, wrong legal entity names, wrong retention figures — are treated as emergency changes and corrected immediately.

3. Emergency changes

For severe incidents (active data exposure, service-threatening defects, security vulnerabilities under active exploitation), the founder may ship a fix immediately, provided:

  • The change is committed to version control.
  • Preflight still runs — emergency does not bypass security configuration validation.
  • A retrospective note is recorded within 24 hours documenting what was changed and why.

4. Infrastructure and secrets

  • Infrastructure configuration changes are made only by the founder and recorded with what changed and why.
  • Secrets (API keys, credentials, database connection strings) rotate on offboarding, suspected exposure, or annually — whichever is first.
  • Database schema changes ship as versioned migrations.
  • Destructive migrations (column drops, table renames, data purges) require a verified fresh backup before execution.

5. Rollback

The platform retains prior releases for redeploy of the last known-good version. Database restores use point-in-time recovery only in a declared recovery event and include re-applying any customer deletions that post-date the restore point before service resumes. Serving customers a state that omits a deletion they requested is a contractual breach; the re-deletion step is non-negotiable.

6. Evidence and retention

Git history, deploy logs with preflight output, publish history, test output, and incident retrospectives are retained for at least 12 months.

At our current scale the version-control log is the change register. We disclose that plainly rather than describing a ticketing bureaucracy that does not exist.