Scope and priority
Critical assets, service priority, dependency restore order, backup owner, and business impact context must be recorded.
Restore Testing, Rollback, RTO/RPO, and Non-Claims
Backup, recovery, and cyber resilience
Latticra records backup, recovery, and resilience requirements before hosted services, mutating update lanes, production installers, production runtime, or recovery-service claims can promote. It does not create backups, store backups, restore systems, execute rollback, fail over, orchestrate recovery, or provide ransomware recovery.
Current Rule
Recovery evidence is not recovery authority.
The baseline names the evidence a future recovery-capable system would need: critical asset inventory, dependency restore order, RTO/RPO, backup scope, offline or immutable backup planning, integrity verification, restore tests, clean recovery environments, rollback plans, authorization, communications, incident handoff, and lessons learned.
RTO/RPO and backups
Recovery time, recovery point, backup scope, offline or immutable backup path, encryption, and access controls are required.
Restore and rollback
Integrity verification, restore-test result, clean recovery environment, golden-image or IaC restore path, and rollback plan must exist.
Recovery handoff
Recovery authorization, communications path, incident-response handoff, post-recovery validation, lessons learned, and exception expiry are required.
Current Snapshot
The baseline exists to keep recovery claims closed.
These fields describe requirements and blocked behavior. They are not evidence of backup services, restore execution, rollback execution, failover, disaster recovery, or continuity operations.
Recovery Gate
No recoverability wording can promote without tested recovery evidence.
Recovery claims sit next to mutation, update, incident, hosting, and operational continuity boundaries. A future recovery path needs explicit scope, tests, authority, communication, validation, and exception records before the public wording can change.
Present now
Baseline record, status record, guard script, high-assurance allocation, incident-response context, logging/monitoring context, supply-chain rollback context, OS-image readiness context, and metadata-only recovery path records.
Required before promotion
Critical asset inventory, dependency restore order, business impact or service priority, RTO, RPO, backup scope, backup owner, offline or immutable backup path, encryption and access control, integrity verification, restore-test result, clean recovery environment, golden-image or IaC restore path, rollback plan, recovery authorization, communications path, incident handoff, post-recovery validation, lessons learned, exception owner, exception expiration, and operator-visible non-claims.
Denied now
Production recovery, restore execution, rollback execution, failover, backup service claims, disaster-recovery claims, ransomware-recovery claims, hosted-service recovery claims, production update recovery claims, and continuity claims.
Latticra Boundary
Recovery-related records remain no-effect metadata.
Latticra can name recovery paths, rollback plans, and installer validation recovery flags as records. It does not store backup data, restore runtime state, fail over services, or grant recovery authority.
Recovery path
Recovery paths are planning records and source evidence, not executable recovery workflows.
Rollback plan
Rollback requirements can be recorded before mutation lanes without enabling rollback execution.
Install validation flags
Installer and OS-image readiness can carry recovery flags without claiming production recoverability.
Runtime recovery
No backup storage, restore runtime, failover runtime, disaster recovery, ransomware recovery, or recovery authority is added.
Local Commands
Validate recovery requirements without running recovery behavior.
These checks validate records and public alignment. They do not create backups, restore systems, roll back updates, fail over services, or write recovery artifacts.
Recovery baseline
sh scripts/test-backup-recovery-resilience-baseline.shHigh-assurance rollup
sh scripts/test-high-assurance-security-baseline.shIncident and logging context
sh scripts/test-cyber-incident-reporting-response-baseline.sh
sh scripts/test-security-logging-monitoring-baseline.shSource Records
Use exact records before repeating recovery wording.
Backup, recovery, and cyber resilience baselineBackup scope, restore testing, recovery prioritization, rollback planning, RTO/RPO, and no recovery-service claims.
Recovery baseline statusStatus fields and expected guard output for the backup, recovery, and resilience baseline.
High-assurance baselineSource-tracked security posture and future recovery/resilience control allocation.
Incident reporting baselineEvidence preservation, incident handoff, response gates, and closed recovery authority.
Security logging baselineIncident handoff path, event logging, retention, and monitoring non-claims.
Supply-chain baselineRollback or recovery contract context before release, updater, and production claims.
OS image release readinessRelease-readiness contract context for future image and recovery evidence.
Incident response boundaryReporting routes, evidence preservation, response gates, and incident-response non-claims.
Security logging and monitoringEvent-source inventory, audit events, redaction, retention, triage, and no detection-service claims.
Signed-updater delivery gateClosed update-delivery gate, rollback blockers, local-checkout updater lane, and no production update claims.
Secure configuration and change managementApproved changes, rollback planning, drift detection, exception ownership, and hardening non-claims.
Data classification and protectionBackup data protection, retention, disposal, redaction, DLP planning, and customer-data non-claims.
Installer readinessProduction installer gates, local artifact manifest fixture, and release non-claims.
Evidence modelPromotion levels, public claim boundaries, and exact source records.