Cloud Capable Convergence And Publication Strategy

Status: Canonical strategy note

Cloud Capable is a Governed Digital Capability Environment.

This document explains why the explanatory surfaces are converging and how that convergence should be published without collapsing doctrine, specifications, implementations, and evidence into one mixed category.

Root Observation

The source observation came before the technology:

Governance that depends on spreadsheets, meetings, and after-the-fact audits is happening too late.

Everything downstream is an operationalization of that observation.

The doctrine, architecture, products, crosswalks, and proof packages converge because they were not invented as separate narratives. They are expressions of the same root claim discovered in sequence.

The Evolution of Abstraction

NovaStore represents the third major evolution in cloud scalability, moving the unit of value from infrastructure to platform, and finally to complete governed capabilities:

The NovaStore Hierarchy

Instead of distributing raw software, NovaStore acts as a marketplace for complete, deployable operational capabilities. The hierarchy of assets is structured as follows:

• Capability Packs (What customers buy): The complete, deployable business capability containing all governance, operational, and verification assets.
• PlayBooks (Governance specifications): Rules defining what should happen (e.g., Secret Manager access bounds, allowed regions, policy invariants).
• RunBooks (Operational procedures): Instructions defining how it executes (e.g., deploy adapters, configure registries, publish evidence).
• ERI Registries (Decision logic): The deterministic pre-execution admissibility rules.
• Connectors & Adapters: Integrations with existing cloud services (Vertex AI, Key Vault, BigQuery).
• Verification Packages: Deterministic test suites to prove compliance bounds.
• Evidence Templates: Cryptographically signed receipts emitted on every commit and refusal.

Definition Boundary

Carl's refinement is the right one:

Cloud Capable is the operating environment.
The Secure Digital Convention Center is the spatial mental model.

That distinction must remain stable.

A mental model can change without changing Cloud Capable itself. The convention center is the map. Cloud Capable is the governed operating environment in which digital capability can safely occur.

This is why ERI-CFM uses architectural location rather than convention-center location as the required field. The metaphor helps people navigate, but the architecture must remain independent of any one metaphor.

Closed Stack

The complete stack is:

Comphyology
-> Cyber-Safety
-> Cloud Capable
-> Governed Execution Environment
-> Proof Runs
-> Evidence Packages
-> Trust Anchor
-> Crosswalks
-> External Standards

The Trust Anchor belongs between Evidence Packages and Crosswalks.

Without a trust anchor, a crosswalk points to artifacts that a reviewer may still have to accept as internal claims. With a trust anchor, the reviewer can begin from a hardware-rooted or otherwise independently verifiable basis and recompute the rest of the evidence chain.

For confidential execution, the trust anchor is the hardware attestation chain, such as Intel TDX or AMD SEV-SNP, verified through the hardware manufacturer's public certificate chain and tooling.

The credibility posture is:

Do not trust our dashboard.
Verify the package.

One Responsibility Per Layer

The maturity principle is one responsibility per layer.

The Crosswalk does not govern. The Proof Run does not certify. The Trust Anchor does not explain the doctrine. Each layer does one job.

That is why the system is becoming legible.

Three-Book Architecture

The publication architecture should separate three books or living works:

Book 3 should not explain NovaFuse as a product catalog.

It should explain how to think while designing and operating a governed digital capability environment.

Cloud Capable then becomes the reference implementation of that discipline, not the entire discipline itself.

Four Artifact Classes

The publication strategy has four artifact classes:

Each artifact class creates demand for the next.

Doctrine reader
-> specification evaluator
-> reference implementation reviewer
-> proof-run buyer

That is the distribution engine.

What This Changes

The story should no longer be told as:

GRC tool -> products

The stronger and more accurate sequence is:

Observation -> discipline -> primitives -> operating environment -> proof artifacts -> external review

This lets Cloud Capable be understood as a governed environment rather than a bundle of software components.

Immediate Next Moves

1. Build a filled synthetic Proof Run for an AI factory scenario with representative data and real computed hashes.
2. Put ERI-CFM-SOC2-001, especially CC7.2 and CC8.1, in front of a working SOC 2 practitioner.
3. Draft the Book 3 operator-manual outline for Governed Digital Capability Environments.
4. Prepare the public ERI Registry path so specifications can be inspected without exposing private operational material.

Canonical Positioning

Cloud Capable is the reference operating environment for governed digital capability: consequential actions are evaluated before effect, bounded during execution, rooted in verifiable trust where possible, evidenced at runtime, and mapped outward for review without claiming conformance by assertion.