Common-mode dependencies across individually supportable cases

JADC2 Assurance Portfolio and Common-Mode Dependency Lab

Compare six fixed fictional Joint All-Domain Command and Control mission-thread assurance cases, expose what they share, and trace how one common change affects claims, evidence, verification, review, containment, and unresolved risk across the portfolio.

Research basis KW-RPT-007 KW-RPT-011 KW-RPT-013 KW-RPT-038 KW-RPT-041 KW-RPT-042 KW-RPT-043 KW-RPT-046 KW-RPT-047

Portfolio view, not portfolio approval

Several supported cases can still fail together.

JADC2 means Joint All-Domain Command and Control. CJADC2 means Combined Joint All-Domain Command and Control. A kill chain is one selected ordered mission process; a kill web is the changing graph of possible mission threads; JADC2 or CJADC2 is the wider joint or combined enterprise that enables, secures, governs, tests, and sustains those threads.

A portfolio is not resilient merely because it contains more nodes, more routes, or several passing case reviews. The same clock, schema, identity service, gateway, authority record, reviewer pool, update mechanism, supplier, or operating assumption can remain a common point of failure.

Governing definitions

Four levels that must not be collapsed

jadc2Joint All-Domain Command and Control
cjadc2Combined Joint All-Domain Command and Control
kill chainOne selected ordered mission process.
kill webThe changing graph of possible mission threads.
portfolioSeveral bounded cases viewed together with their common and case-specific dependencies.

Fifteen common-dependency classes

Counted redundancy is not necessarily diverse resilience.

Every dependency remains separately visible with its stable identifier, responsible shared service, and current state.

JAP-DEP-01

Shared identity and workload-trust service

Authenticates fictional services and workload state without proving that the underlying evidence is accurate.

Service: JAP-SVC-01

JAP-DEP-02

Shared trusted-time and synchronization source

Supplies fictional timing, freshness, expiry, and ordering assertions across several mission threads.

Service: JAP-SVC-02

JAP-DEP-03

Shared semantic schema and translation gateway

Defines fictional field meaning and translation behavior across otherwise different route labels.

Service: JAP-SVC-03

JAP-DEP-04

Shared data-product provenance service

Maintains fictional custody, derivation, source-artifact, and correction relationships.

Service: JAP-SVC-04

JAP-DEP-05

Shared software, model, and configuration lineage

Identifies the exact fictional artifacts used by translation, trust, path, assessment, and coordination services.

Service: JAP-SVC-05

JAP-DEP-06

Shared policy and permitted-purpose rule

Constrains fictional minimization, release, downstream use, expiry, and revocation.

Service: JAP-SVC-06

JAP-DEP-07

Shared authority and delegation record

Represents current fictional delegation, scope, expiry, revocation, and return-of-control conditions.

Service: JAP-SVC-07

JAP-DEP-08

Shared mission-partner release decision

Represents a fictional partner-specific disclosure and permitted-use decision used by selected combined cases.

Service: JAP-SVC-08

JAP-DEP-09

Shared communications and transport failure domain

Represents a common fictional gateway and dependency family beneath several differently named paths.

Service: JAP-SVC-09

JAP-DEP-10

Shared edge and regional compute capacity

Represents a bounded fictional compute and queue pool used by several analyses and reviews.

Service: JAP-SVC-10

JAP-DEP-11

Shared human-review role and workload pool

Represents fictional reviewers whose evidence access, time, competence, authority, and intervention capacity are finite.

Service: JAP-SVC-11

JAP-DEP-12

Shared assessment and reconciliation service

Compares fictional outcome records, divergent state, and return-of-control conditions across cases.

Service: JAP-SVC-12

JAP-DEP-13

Shared update and rollback mechanism

Distributes fictional software, schema, policy, and configuration updates and records rollback state.

Service: JAP-SVC-13

JAP-DEP-14

Shared supply-chain and dependency family

Represents fictional common libraries, build inputs, signing roots, and integration components.

Service: JAP-SVC-14

JAP-DEP-15

Shared operating-environment assumption

Represents fictional assumptions about communications, timing, load, evidence availability, and operating bounds.

Service: JAP-SVC-15

Eighteen abstract services and roles

Shared machinery and institutional responsibility stay visible.

JAP-SVC-01

Federated identity and workload-trust service

shared technical service

Dependency: identity-trust

JAP-SVC-02

Trusted-time and synchronization service

shared technical service

Dependency: trusted-time

JAP-SVC-03

Semantic registry and translation gateway

shared technical service

Dependency: semantic-schema

JAP-SVC-04

Evidence and provenance ledger

shared evidence service

Dependency: provenance

JAP-SVC-05

Software and configuration lineage registry

shared assurance service

Dependency: software-lineage

JAP-SVC-06

Purpose and policy decision service

shared governance service

Dependency: policy-purpose

JAP-SVC-07

Authority and delegation registry

shared governance service

Dependency: authority-record

JAP-SVC-08

Mission-partner release gate

shared partner service

Dependency: partner-release

JAP-SVC-09

Common transport and gateway family

shared infrastructure service

Dependency: transport-domain

JAP-SVC-10

Edge and regional compute pool

shared capacity service

Dependency: compute-capacity

JAP-SVC-11

Human merits-review workload pool

shared institutional role

Dependency: human-review-pool

JAP-SVC-12

Assessment and reconciliation service

shared recovery service

Dependency: assessment-reconciliation

JAP-SVC-13

Update, rollback, and recovery service

shared change-control service

Dependency: update-rollback

JAP-SVC-14

Common supply-chain dependency family

shared dependency family

Dependency: supply-chain

JAP-SVC-15

Operating-environment assumption registry

shared assurance assumption

Dependency: environment-assumption

JAP-ROLE-01

Portfolio assurance owner

institutional role

Maintains the portfolio map and current state without certifying it.

JAP-ROLE-02

Independent portfolio reviewer

institutional role

Reviews common-mode impact outside the original case and service teams.

JAP-ROLE-03

Containment and recovery coordinator

institutional role

Coordinates shared-service containment, rollback, state reconciliation, and return of control.

Fourteen distinctions

Do not promote a complete-looking portfolio into assurance theater.

Several supported casesPortfolio-wide assurance
Different path labelsIndependent failure domains
More nodesMore resilience
Redundant servicesDiverse implementations
Authenticated workloadTrustworthy evidence
Shared schemaShared interpretation
Available capacityAuthorized capacity
Shared reviewerIndependent review
Shared authority recordCurrent authority for every case
One passing testRepeated-condition resilience
Technical failoverEvidence or authority continuity
Restored serviceReconciled portfolio state
Contained component faultContained derived-product impact
Complete portfolio graphCertification or deployment approval

Six fixed fictional assurance cases

The portfolio references existing case, claim, evidence, and verification identifiers.

It does not copy a second competing assurance model. Each portfolio case links to the current fixed mission-thread assurance catalog through stable identifiers.

JAP-CASE-01 · JMA-1-CASE

Disaster-response information routing

A fictional multi-organization network routes infrastructure-damage observations to a bounded coordination service.

Domain
Joint emergency support
Shared dependency links
15
Case-specific dependencies
2

JAP-CASE-02 · JMA-2-CASE

Infrastructure-protection coordination

A fictional protective network coordinates sensor, maintenance, and service-continuity information without modeling force.

Domain
Critical infrastructure protection
Shared dependency links
14
Case-specific dependencies
2

JAP-CASE-03 · JMA-3-CASE

Mission-partner awareness and releasability

A fictional mission partner contributes a minimized awareness product under explicit releasability and purpose conditions.

Domain
Combined information sharing
Shared dependency links
15
Case-specific dependencies
2

JAP-CASE-04 · JMA-4-CASE

Logistics recovery after gateway loss

A fictional logistics thread reroutes status data after a gateway fails and later reconnects with divergent state.

Domain
Contested logistics support
Shared dependency links
14
Case-specific dependencies
2

JAP-CASE-05 · JMA-5-CASE

Cyber-defense interpretation with contradictory evidence

A fictional defensive system compares anomaly evidence and a benign explanation before recommending containment.

Domain
Defensive cyber coordination
Shared dependency links
13
Case-specific dependencies
2

JAP-CASE-06 · JMA-6-CASE

Time-critical protective support

A fictional protective thread operates under a short authority window and explicit human-review conditions.

Domain
Protective decision support
Shared dependency links
15
Case-specific dependencies
2

Eight conservative portfolio postures

Postures describe review state; they do not certify the portfolio.

qualifiedPortfolio supportable within declared bounds

Each fixed fictional case remains supportable only inside its own declared scope, versions, evidence, authority, review, and residual-risk bounds. Shared dependencies remain visible and do not create certification.

qualifiedShared dependency requires qualification

A common service or assumption is degraded or unavailable. Alternative paths require explicit diversity, capacity, and current-state review rather than a route-label substitution.

suspendedCommon-mode evidence lineage suspended

A shared provenance dependency can no longer support several cases. A generated rationale or surviving copy cannot replace the missing source lineage.

suspendedCommon-mode verification suspended

A shared schema, identity, software, configuration, or update dependency changed. Affected verification must be repeated for every dependent case and the portfolio-level interactions.

withdrawnAuthority or permitted-use portfolio hold

Expired authority or withdrawn permitted purpose prevents current use across every dependent case even when technical services remain available.

unresolvedHuman-review capacity hold

The shared review pool cannot provide timely, evidence-informed merits review for the affected cases. A nominal reviewer name does not cure workload or intervention limits.

suspendedPortfolio reconciliation required

Shared assessment or reconciliation state conflicts across several cases. Technical reconnection cannot silently choose which state becomes current.

withdrawnGovernance boundary exceeded

An unverified artifact entered a shared update path. Containment, rollback, provenance reconstruction, independent review, and complete re-verification are required before reliance can resume.

Bounded common-mode change

Stress the portfolio without rewriting its original state.

Synthetic only

Only allowlisted identifiers are accepted. No free text, upload, URL, real dependency, log, evidence, software artifact, authority instrument, target, or operational data is accepted.

Original portfolio qualified Portfolio supportable within declared bounds
Derived current view qualified Portfolio supportable within declared bounds

The six fixed fictional cases remain individually supportable only within declared bounds. Their shared dependency map remains an assurance warning, not a portfolio certification.

No composite JADC2, portfolio, independence, resilience, trust, evidence, authority, review, readiness, safety, legality, mission-success, or certification score is calculated.

Cases affected0
Common dependencies affected0
Claims affected0
Evidence records affected0
Verification activities affected0
Certification or deployment approvalNo

Containment and recovery

  • Maintain the standing bounded-monitoring posture.

Required actions

  • Monitor the shared dependency map, expiry, review workload, and invalidation triggers.

Warnings

  • Individually supportable cases still share common dependencies and are not certified.

Required portfolio reviewers

  • JAP-ROLE-01 Portfolio assurance owner — Maintains the portfolio map and current state without certifying it.
  • JAP-ROLE-02 Independent portfolio reviewer — Reviews common-mode impact outside the original case and service teams.

Residual unknowns

  • The fixed public catalog cannot establish real-system diversity, independence, or operational behavior.
  • The fixed public portfolio cannot establish real-system independence, certification, operational readiness, legal permission, or force authority.

Dependency ledger

Original and current common-dependency state

DependencyShared serviceCasesOriginalCurrentReason
JAP-DEP-01
Shared identity and workload-trust service
JAP-SVC-016currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-02
Shared trusted-time and synchronization source
JAP-SVC-026currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-03
Shared semantic schema and translation gateway
JAP-SVC-036currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-04
Shared data-product provenance service
JAP-SVC-046currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-05
Shared software, model, and configuration lineage
JAP-SVC-056currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-06
Shared policy and permitted-purpose rule
JAP-SVC-066currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-07
Shared authority and delegation record
JAP-SVC-076currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-08
Shared mission-partner release decision
JAP-SVC-083currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-09
Shared communications and transport failure domain
JAP-SVC-095currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-10
Shared edge and regional compute capacity
JAP-SVC-106currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-11
Shared human-review role and workload pool
JAP-SVC-116currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-12
Shared assessment and reconciliation service
JAP-SVC-126currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-13
Shared update and rollback mechanism
JAP-SVC-136currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-14
Shared supply-chain and dependency family
JAP-SVC-146currentcurrentNo selected common-mode change affects this dependency.
JAP-DEP-15
Shared operating-environment assumption
JAP-SVC-156currentcurrentNo selected common-mode change affects this dependency.

Transitive case impact

Dependency → case → claim → evidence → verification

CaseAssurance caseOriginalCurrentAffected dependenciesAffected claimsEvidenceVerification
JAP-CASE-01
Disaster-response information routing
JMA-1-CASEqualifiedqualified0000
JAP-CASE-02
Infrastructure-protection coordination
JMA-2-CASEqualifiedqualified0000
JAP-CASE-03
Mission-partner awareness and releasability
JMA-3-CASEqualifiedqualified0000
JAP-CASE-04
Logistics recovery after gateway loss
JMA-4-CASEqualifiedqualified0000
JAP-CASE-05
Cyber-defense interpretation with contradictory evidence
JMA-5-CASEqualifiedqualified0000
JAP-CASE-06
Time-critical protective support
JMA-6-CASEqualifiedqualified0000

Affected claims

  • No claim is changed in the selected baseline state.

Invalidated or changed evidence

  • No evidence record is changed in the selected baseline state.

Verification to repeat

  • No additional verification is required in the selected baseline state.

JADC2 assurance portfolio loaded.

Direct answers

What portfolio assurance can and cannot establish

What is a JADC2 assurance portfolio?

It is a bounded view of several fixed fictional Joint All-Domain Command and Control mission-thread assurance cases and the identity, timing, semantics, provenance, software, policy, authority, transport, review, assessment, update, supply-chain, and environmental dependencies they share.

Why are several supported cases not the same as portfolio assurance?

Each case may be supportable within its own declared bounds while several cases still rely on one shared gateway, schema, clock, identity service, authority record, reviewer pool, update mechanism, or operating assumption. One common-mode failure can therefore invalidate several cases at once.

Do different route labels prove independent resilience?

No. Two paths may have different names while sharing the same transport gateway, power source, timing service, software lineage, identity provider, management plane, reviewer pool, or supply-chain dependency.

Does technical failover preserve evidence and authority?

Not automatically. A successful failover can restore reachability while evidence lineage, permitted purpose, current authority, human-review quality, and state reconciliation remain missing or invalid.

Does this lab calculate portfolio readiness or certify JADC2?

No. It calculates no composite score and makes no safety, readiness, legality, command-authority, accreditation, certification, deployment, targeting, weapon, or force determination.

Can the portfolio lab accept real dependencies, logs, evidence, or an Evulgare handoff?

No. It accepts only one allowlisted fictional common-mode change, performs no upload or external request, and creates no real-system evidence project, account, transfer, authority, or deployment state.

Public synthetic boundary

The output is a dependency and review posture—not operational assurance.

The lab cannot optimize a real portfolio, accept real evidence, infer classified dependencies, select targets, assign weapons, recommend engagement, allocate force, calculate mission success, authorize force, determine legality, certify safety, approve deployment, or create an Evulgare evidence project.

No composite score is calculated. A complete portfolio graph makes declared common dependencies visible; it does not prove that a real system has no undeclared common modes.