Skip to content

Certification Lifecycle

Trust in code should never be permanent.

Every certification in Certify has an expiration date. When that date passes, the certification lapses and the code must be re-evaluated against current standards.

┌──────────┐
┌──────────▶│ Certified │◀─── recertification
│ └─────┬────┘
│ │ time passes
│ ┌─────▼────┐
│ │ Expired │
│ └─────┬────┘
│ │ re-evaluate
passes│ ┌─────▼────────┐
policy│ ┌─────│ Evaluating │─────┐
│ │ └──────────────┘ │ fails
│ │ │ policy
│ ▼ ▼
└─────┘ ┌──────────────┐
│ Decertified │
└──────────────┘
StatusWhat it meansWhat happens next
CertifiedUnit meets all policiesValid until expiration
Certified with ObservationsPasses but has warningsValid, but watch items noted
ProbationaryBelow threshold, grace periodMust improve before next evaluation
ExpiredCertification window elapsedMust be re-evaluated
DecertifiedFails required policiesNeeds remediation
ExemptExcluded by human overrideNot evaluated

Each certification has a time window — by default, 90 days.

The window adjusts based on risk factors:

FactorEffect
High git churnShorter window
Many recent authorsShorter window
Low complexity, stable codeLonger window
High test coverageLonger window

Configurable bounds:

  • Minimum: 7 days
  • Maximum: 365 days

When certification expires, the unit enters the queue for re-evaluation on the next certify certify run. The process is automatic — expired units are rediscovered, re-evaluated with fresh evidence, and assigned new certification status.

The recommended workflow:

  1. PR — Certify changed files before merge
  2. Nightly — Sweep for expired certifications
  3. Weekly — Full recertification run + report card update

This ensures certification state stays current without manual effort.