OpenCompliance treats certificates as revocable state, not static PDFs. The lifecycle layer maps source changes to impacted controls, plans a delta recheck, and either marks trust stale or revokes it before anyone can compose that stale result into a larger artifact.
The current public lifecycle pack starts from the issued ExampleCo corridor and applies a normalized source-change event: the scheduled cloud-logging export is missing in the next sync window. That one change maps cleanly to the logging control, one proof claim, and the issued certificate that depended on it.
The same source change can be expressed in two policy modes. A cautious mode marks the certificate re_verification_required. A fail-closed mode revokes it immediately. In both cases, the child certificate is blocked from further composition until trust is restored.
issued certificate
-> normalized source-change event
-> impacted controls and claims
-> delta recheck plan
-> re-verification-required or revoked
-> composition blocked until trust is restoredThe lifecycle artifact records the exact impacted control refs and impacted claims. In the current pack, only oc.log-01 and EX-CLAIM-202 move, so the recheck plan does not pretend the whole corridor changed.
The lifecycle event keeps a list of recheckClaims and a separate list of reusedClaims. That makes the “continuous” part legible: only the impacted claim should be rerun first.
The lifecycle record keeps the original certificate issuance entry and the later stale or revoked state in one lineage trail. Silent mutation is not acceptable; state transitions have to be artifacts too.
The public pack also includes two synthetic issued component certificates and a composed higher-level certificate. The rule is strict: composition only works while every child remains issued and aligned on organisation and framework intent.
re_verification_required and revoked policies.