Operations: Compaction, Diagnostics & Bootstrap#

The operations subsystem manages storage lifecycle, system diagnostics, and the bootstrap initialization flow.

Compaction#

• The system must maintain three storage tiers: Hot Graph (last 30 days), Ancestry Index (forever metadata), and Cold Packs (heavy blobs)
• Compaction must never delete: node headers, provenance edges, approvals, or signatures
• Compaction must be triggered by: size threshold exceeded, pipeline upgrade accepted, or time-based fallback
• Each compaction must produce a CompactionEvent meta-node in the provenance graph
• PolicyBot must announce every compaction event

Diagnostics & Severity Model#

• Every status item must include: severity (error, warning, or info), category, subject, message, and recommended_actions
• Status items must be grouped by severity in display output
• The diagnostics system is the primary user experience surface for Phoenix
• phoenix status must always be explainable, conservative, and correct-enough to rely on
• Diagnostic messages must never be ambiguous about what action the developer should take

Bootstrap Flow#

• The bootstrap command must execute in order: cold pass, canonicalization, warm pass, generate Trust Dashboard, set system state to WARMING
• D-rate alarms must be suppressed during the BOOTSTRAP_COLD phase
• Severity must be downgraded during the BOOTSTRAP_WARMING phase
• After stabilization, the system must transition to STEADY_STATE
• Bootstrap must be resumable: if interrupted, it must pick up from the last completed phase
• The system must never transition to STEADY_STATE until the D-rate is within acceptable bounds