Public and synthetic only · unapproved · unmeasured.

Phase 1D · reliability before activation
A backup is useful only after a proven restore.
KIIRAAY separates availability, backup, restore, recovery, and incident response. The public plan shows controls without revealing server paths, accounts, secrets, on-call contacts, or exploitable operational detail.
Provisional objectives
A planning target is not a promise.
For the public site and synthetic scenarios only, the blueprint provisionally proposes a maximum 24-hour loss and four-hour service return. These values are neither approved nor measured. The future transactional platform needs separate objectives.
Public-service return target · unapproved · unmeasured.
No real objective activates before budget, architecture, ownership, and exercise.
Incident lifecycle
From detection to verified return.
Every step will require an owner, reliable time, a traceable decision, and proportionate communication.
- 01Detect
Measure a verifiable signal without logging personal content or secrets.
- 02Declare
Classify the incident, name approved command, and create an evidence reference.
- 03Preserve
Retain useful evidence with integrity, limited access, and chain of custody.
- 04Contain
Close a feature, revoke access, or isolate a component without expanding exposure.
- 05Restore
Return from controlled artifacts and backups in a clean environment.
- 06Verify
Compare counts, hashes, rules, and flags before progressive reopening.
- 07Learn
Document cause, decisions, impact, correction, and follow-up without blame.
Classification
Four levels, no invented commander.
Critical
Data exposure, compromise, election-integrity event, or critical nationwide unavailability.
Draft · owner unnamedMajor
Critical function failure, limited abuse, or contained integrity loss.
Draft · owner unnamedDegradation
Slow or partially unavailable service with a safe alternative.
Draft · owner unnamedAnomaly
Minor defect without immediate sensitive impact, to track and correct.
Draft · owner unnamedRestore evidence
The test starts from a clean environment.
A future restore must rebuild the application, database, controls, and keys through a separated procedure. It must never automatically reopen enrollment, messages, maps, identity, voice, or sessions.
Artifacts, configuration, migrations, database, objects, keys, and dependencies.
Hashes, encryption, dates, coverage, expiry, and job success.
Isolated environment, rotated secrets, and minimal access before data.
Counts, versions, withdrawals, revocations, audit, and closed flags.
Actual loss, duration, errors, decisions, and objective gaps.
Remove the test environment and retain only approved evidence.
Twelve controls
Eleven proofs remain.
The public probe exists. Every other item stays blocking until tested, assigned, and approved.
- PresentMinimized public health probe
- BlockingNamed service owner and backup
- BlockingApproved SLI, SLO, and error budget
- BlockingSensitive-data-free logs, metrics, and alerts
- BlockingIndependent external monitoring
- BlockingNamed on-call and escalation tree
- BlockingIncident command and evidence preservation
- BlockingApproved public and regulatory communications
- BlockingEncrypted isolated backups and key recovery
- BlockingClean-environment restore drill
- BlockingMeasured RPO/RTO evidence
- BlockingSensitive flags stay closed after restore
Safe public status
Operational detail stays private.
The public can verify general status, limits, and gates. Contacts, paths, accounts, backups, keys, incident evidence, and executable instructions remain in a protected register.