Critical Infrastructure Campaign Review, Cross-Site Recovery Baseline, and Resilience Authorization Board

Release

2.0.0-rc.41-WIP

Public route

/workbench/critical-infrastructure-defense-review

API root

/api/v2/critical-infrastructure-defense-review

Objective

The RC41 board consumes exact, customer-neutral critical-infrastructure campaign packages and determines what the evidence supports before any recovery-baseline proposal is represented.

It does not control a facility. It does not execute recovery. It does not activate a baseline. It does not shift load, shut down equipment, deploy software, migrate a database, restart Passenger, or promote an Evulgare release.

Governing sequence

PARENT CAMPAIGN PACKAGE
→ PACKAGE AND EVENT-CHAIN VERIFICATION
→ SITE MATRIX
→ EVIDENCE ROOTS AND CORRELATION
→ AUTHORITY / KEY / CONFIGURATION
→ CONTAINMENT AND MINIMUM CONTINUITY
→ COMMUNICATIONS AND RECONCILIATION
→ RECOVERY-BASELINE LINEAGE
→ CONTRADICTIONS AND DEFEATERS
→ REVIEWER INDEPENDENCE
→ BOUNDED REVIEW STATE
→ APPEND-ORIENTED HISTORY
→ SYNTHETIC_NULL_SINK

Parent campaign

The source campaign models six fictional estates and thirty bounded scenarios. All site identities, roles, gates, and outcomes are synthetic. The public system contains no real customer identity, facility layout, operating threshold, industrial-control protocol, reactor control, coordinate, target, weapon, vehicle command, or force-authorization path.

Exact source-package verification

Before review, RC41 verifies:

• published parent-package schema;
• source release and engine identity;
• package digest;
• campaign result digest;
• campaign event chain;
• individual scenario event chains;
• exact scenario membership;
• six-site matrix;
• evidence roots and correlation groups;
• customer-neutral public boundary;
• terminal state.

A package that parses successfully is evidence. It is not institutional approval.

Evidence dependence

The review board keeps record count separate from independent root-source count.

RECORD COUNT ≠ INDEPENDENT CORROBORATION

MULTIPLE DERIVATIVES FROM ONE ROOT
≠
MULTIPLE INDEPENDENT SOURCES

Every evidence family retains:

• site identity;
• root-source identity;
• correlation group;
• independence status;
• source outcome.

Twenty independent readiness dimensions

RC41 evaluates:

PACKAGE INTEGRITY
SCENARIO COVERAGE
WORKLOAD IDENTITY
DELEGATED AUTHORITY
SOFTWARE ATTESTATION
MODEL ATTESTATION
POLICY ATTESTATION
CONFIGURATION ATTESTATION
EVIDENCE FRESHNESS
EVIDENCE CONSISTENCY
EVIDENCE INDEPENDENCE
CONTAINMENT
MINIMUM CONTINUITY
COMMUNICATIONS
RECONCILIATION
KEY EPOCH
RECOVERY BASELINE
PROTECTED BOUNDARY
DEPLOYMENT EVIDENCE
INDEPENDENT REVIEW

States remain conservative:

SUPPORTED WITHIN DECLARED BOUNDS
SUPPORTED WITH QUALIFICATIONS
PARTIAL
BLOCKED
NOT ESTABLISHED

No composite readiness score is emitted.

Review states

ACKNOWLEDGED
MERITS REVIEW COMPLETE
ACCEPT WITHIN DECLARED BOUNDS
ACCEPT WITH QUALIFICATIONS
DEFER PENDING EVIDENCE
DENY RECOVERY AUTHORIZATION
SUSPEND CURRENT BASELINE
WITHDRAW CURRENT BASELINE
SUPERSEDE WITH CANDIDATE
ABSTAIN

These states are review records. They are not physical commands.

Reviewer modes

HUMAN CLICK
PROCEDURAL CONFIRMATION
MERITS REVIEW
DECLARED INDEPENDENT JUDGMENT
MACHINE REPORT
INDEPENDENT MACHINE REVIEW
ABSTAIN / DEFER

A click does not establish merits review. A primary machine report does not establish independent machine review. Independent review records implementation identity, implementation lineage, primary-evidence access, contrary-hypothesis review, and abstention capability.

Ten review profiles

The deterministic catalog includes:

1. Baseline continuity campaign.
2. Qualified cross-site recovery.
3. Correlated evidence roots.
4. Contradictory cross-site evidence.
5. Authority and key-epoch divergence.
6. Configuration reconciliation failure.
7. Partitioned authority envelope.
8. Invalid recovery baseline.
9. Protected-customer boundary failure.
10. All gates reviewed in the declared synthetic scope.

Contradictions and defeaters

Contradictory evidence is not normalized away. Unresolved defeaters remain first-class records and block recovery authorization where applicable.

Examples include:

AUTHENTICATED SITE RECORDS DISAGREE
CURRENT AUTHORITY NOT ESTABLISHED
CONFIGURATION DIGESTS DIVERGE
RECOVERY BASELINE DIGEST INVALID
PUBLIC / PRIVATE BOUNDARY FAILED
ACTUAL-HOST DEPLOYMENT EVIDENCE NOT ESTABLISHED

Recovery-baseline lineage

The review preserves:

• historical baseline ID;
• candidate baseline ID;
• candidate digest;
• parent baseline;
• source campaign digest;
• supersession state;
• activation state;
• unresolved defeaters.

A proposal cannot activate its own baseline.

Comparison and counterfactuals

The API supports baseline-versus-candidate comparison and isolated counterfactual branches.

Counterfactual records are labeled:

COUNTERFACTUAL REVIEW — NOT EXECUTED

They receive a separate digest and cannot mutate the parent review, source campaign, event history, active root, database, or production state.

API v2

GET  /api/v2/critical-infrastructure-defense-review
GET  /api/v2/critical-infrastructure-defense-review/catalog
GET  /api/v2/critical-infrastructure-defense-review/baseline
GET  /api/v2/critical-infrastructure-defense-review/proof
POST /api/v2/critical-infrastructure-defense-review/run
POST /api/v2/critical-infrastructure-defense-review/compare
POST /api/v2/critical-infrastructure-defense-review/branch
POST /api/v2/critical-infrastructure-defense-review/export
POST /api/v2/critical-infrastructure-defense-review/verify

Public operations are bounded, strict-field validated, same-origin, ephemeral, and non-persistent.

Public boundary

The public API rejects:

credentials
private keys
customer content
private topology
arbitrary files
arbitrary URLs
real coordinates
target data
weapon or payload commands
vehicle commands
force authorization
reactor control
industrial protocols
classified material
protected source material

Deterministic proof

The global proof verifies all published profiles for deterministic output, exact source-package verification, complete readiness dimensions, hash-linked review history, verified evidence packages, customer-neutral boundaries, deployment-evidence honesty, and non-execution.

Every result terminates at:

SYNTHETIC_NULL_SINK

What the workbench demonstrates

Within its declared synthetic scope, the workbench demonstrates:

• exact parent-package verification;
• cross-site evidence review;
• evidence-root and correlation control;
• separate authority, key, configuration, continuity, and recovery gates;
• contradiction and defeater preservation;
• reviewer-mode separation;
• append-oriented review lineage;
• deterministic comparison and branch isolation;
• reproducible evidence packages.

What the workbench does not establish

It does not establish:

• real facility readiness;
• nuclear safety or security accreditation;
• customer-system validation;
• physical recovery capability;
• certification;
• production deployment;
• legal authorization;
• procurement acceptance;
• operational effectiveness.