Lifecycle Type

Lifecycle Type

Definition

Closed enumeration of how a content item ages and decays. Drives freshness policy: evergreen content does not expire on calendar; date_bound has an explicit validity window; regulation follows regulatory effective dates; bid_discovered was extracted from a bid response and inherits the bid’s validity context.

Synonyms / Acronyms

None.

Baseline values

key	label	provenance
evergreen	Evergreen	core
date_bound	Date-bound	core
regulation	Regulation	core
bid_discovered	Bid-discovered	core

Relationships

• record_lifecycle.lifecycle_type — text DEFAULT 'evergreen', still no DB CHECK (Liam ruling S236’s “ADD CHECK” migration never landed against content_items and the ratification is unresolved in the new home too). Re-homed off content_items.lifecycle_type at ID-131 M1a (20260628190000_id131_record_lifecycle_facet); content_items itself was DROPPED at ID-131 M6 (S450 GO).
• Source-document-only axis (D7). lifecycle_type is part of record_lifecycle’s freshness/expiry/review-cadence axis, which is owner_kind='source_document'-ONLY: the record_lifecycle_freshness_axis_chk CHECK forces lifecycle_type IS NULL (with freshness, expiry_date, etc.) on every owner_kind='q_a_pair' row. Q&A pairs carry no lifecycle_type value at all — q_a_pairs have no freshness clock (D7).
• Bound to freshness (CV 08) and governance_review_status (CV 09) on the same record_lifecycle facet row: per-lifecycle freshness decay rates live in governance_config.freshness_decay_* per WP-ONTO-R1 §6.2.
• Adjacent to record_lifecycle.expiry_date (used by date_bound lifecycle_type) — same facet table, same source-document-only axis.
• Layer 2 (administrative metadata): lifecycle_type drives the governance subsystem.

Consumers

• lib/freshness.ts:22-128 — calculateFreshness() branches on lifecycle_type for evergreen / date_bound / regulation / bid_discovered rules.
• lib/quality/quality-score.ts, lib/quality/quality-actions.ts — freshness scoring.
• lib/notifications.ts, lib/dashboard.ts, lib/dashboard-signals.ts — surfaces lifecycle-driven freshness signals.
• Governance review schedulers — escalation cadence depends on lifecycle_type.
• lib/mcp/tools/governance.ts, lib/mcp/tools/quality.ts — MCP filter/scoring inputs.
• Filter UI: “show only evergreen” / “show only date-bound expiring soon” (planned).

Notes

• regulation vs date_bound — Ratified-S237 regulation-as-specialisation rule. Liam ratified S237: regulation = externally-set effective dates (e.g. ICO regulation X effective from Y; GDPR effective 25/05/2018) — the date is published by a regulator; date_bound = internally-set validity windows (e.g. “valid for FY26”, contract term, internal policy review window) — the date is set by the organisation. Both lifecycles get freshness decay; regulation additionally tracks regulator-published effective/sunset dates when those metadata land. Industry-aligned with the DCAT-AP regulatory-metadata pattern. Implementable in lib/freshness.ts branch rules + docs/reference/classification-prompt.md update; no schema change required for the rule itself.
• No DB CHECK on record_lifecycle.lifecycle_type today — soft-CV, unchanged by the M1a re-home. CHECK migration will be added per Liam ruling (S236: “ADD CHECK”) to harden the 4 documented values, against the record_lifecycle home. The migration itself is out of WP6 scope (informational ratification only); when it lands, editable_via stays database_migration.
• Freshness THRESHOLDS are client-tunable per governance_config, but the lifecycle_type vocabulary itself is closed.
• Prod-data observation (verified 14/05/2026): regulation 8 rows, date_bound 4 rows; evergreen and bid_discovered row counts not listed because they have not yet been observed in prod.