Assurance Runtime

This is the canonical architecture reference for the Assurance layer. It is for engineers and architects implementing or extending Assurance packs; for the product-level entry point and claim-boundary wording, start at Assurance and Compliance Packs, and for the evidence-ownership boundary see the Assurance Scope Model.

The Assurance runtime is a product architecture layer over existing Stella Ops modules. It lets Stella expose regulatory or standards-specific capabilities as optional packs without turning the core product — a release control plane and DevOps vulnerability scanner — into a regional compliance suite.

Runtime Shape

Stella Core Evidence Platform
  Policy gates
  Evidence Locker records
  ExportCenter bundles
  Notify reporting timelines
  Graph asset inventory
  Authority tenant/operator profile
  Web and CLI surfaces

Assurance Runtime
  Pack discovery
  Pack enablement
  Setup prerequisite checks
  Control/evidence mapping
  Export profile discovery
  Reporting timeline registration
  Readiness and fail-closed reason codes
  Evidence scope and software-estate coverage

Optional Assurance Packs
  nis2
  dora
  cra.product-security
  cra.technical-documentation
  future packs

There is no strategic src/Europe module in this architecture. Regulation and standards support is represented as data, mappings, contracts, adapters, and operator surfaces over the owning modules.

Module Ownership

Pack Descriptor

Pack descriptors are defined by Assurance Pack v1. The descriptor catalog is currently shipped by the CLI: four descriptors are embedded as JSON resources in the StellaOps.Cli assembly under src/Cli/StellaOps.Cli/Commands/Assurance/Descriptors/ (nis2.json, dora.json, cra.product-security.json, cra.technical-documentation.json) and loaded by EmbeddedAssurancePackCatalog. The following abridged example shows the actual nis2.json discovery shape:

{
  "schemaVersion": "assurance-pack-v1",
  "packId": "nis2",
  "frameworkId": "nis2",
  "packVersion": "1.0.0",
  "displayName": "NIS2 Evidence Pack",
  "claimBoundary": "operator-support",
  "evidenceScopes": ["operator-observed-estate", "operator-supplied", "stella-supplier"],
  "evidenceSourceLanes": [
    { "scope": "operator-observed-estate", "label": "Stella-observed software estate", "requiredForConfiguredStatus": true },
    { "scope": "operator-supplied", "label": "Operator-supplied NIS2 governance evidence", "requiredForConfiguredStatus": true },
    { "scope": "stella-supplier", "label": "Stella supplier evidence", "requiredForConfiguredStatus": false }
  ],
  "coverageSummary": {
    "primaryScope": "operator-observed-estate",
    "coverageLabel": "Software-estate assurance for services Stella monitors or deploys for the operator.",
    "observedSoftwareKinds": ["container-images", "release-bundles", "services", "integrations", "plugins", "host-agents"],
    "operatorSuppliedGaps": [
      "legal-entity-and-sector-classification",
      "governance-policy-ownership",
      "business-continuity-processes",
      "physical-security-controls",
      "staff-training-and-awareness-records"
    ],
    "supplierEvidenceProfile": "stella.supplier-evidence"
  },
  "jurisdictions": ["EU"],
  "features": ["controls", "exports", "timelines", "dashboards", "standards-mapping"],
  "owners": [
    { "module": "Policy", "path": "src/Policy/", "responsibility": "control register" },
    { "module": "ExportCenter", "path": "src/ExportCenter/", "responsibility": "SoA export" },
    { "module": "Notify", "path": "src/Notify/", "responsibility": "incident timeline channels" }
  ],
  "setupPrerequisites": ["nis2.soa.live-export", "nis2.effectiveness.monthly-export"],
  "exports": ["nis2.statement-of-applicability", "nis2.effectiveness-report"],
  "reportingTimelines": ["nis2.article23.incident"],
  "controlMappings": ["nis2-control-register-v1"],
  "compatibilityRoutes": [
    "/compliance/nis2/control-register",
    "/api/policy/control-register/nis2",
    "stella export nis2-soa",
    "stella export nis2-effectiveness"
  ],
  "offlineMode": {
    "supported": true,
    "requiresLiveRegulatorEndpoint": false,
    "fixturePolicy": "local deterministic fixtures only"
  }
}

The example above abridges each evidenceSourceLanes entry to scope/label/ requiredForConfiguredStatus; the shipped nis2.json lanes also carry a description. The evidenceSourceLanes and owners arrays are populated in the real descriptor (they are not empty); the runtime treats empty evidenceScopes or evidenceSourceLanes on a nis2/dora descriptor as a readiness blocker.

The descriptor is discovery metadata. It does not replace module-owned contracts such as NIS2 Control Register v1, NIS2 Statement of Applicability v1, DORA Major Incident Report v1, DORA Register of Information v1, DORA Info Sharing Event v1, TLPT Evidence Pack v1, CRA Technical File v1, or CRA Conformity Dossier v1.

Evidence Scope Runtime

Evidence scope is the runtime guardrail that prevents NIS2/DORA from becoming a generic compliance claim. The model is defined in Assurance Scope Model and uses four labels:

NIS2 and DORA descriptors must include both operator-observed-estate and operator-supplied. CLI status treats missing scope metadata as a readiness blocker. Web/setup surfaces must show the software estate coverage and the operator-supplied gaps rather than presenting a single compliance switch.

CLI Runtime Surface

The CLI exposes the runtime through generic Assurance commands:

• stella assurance packs list
• stella assurance pack inspect <packId>
• stella assurance pack status <packId> --tenant <tenant>
• stella assurance operator-config show
• stella assurance operator-config export
• stella assurance operator-config update

packs list and pack inspect read only embedded descriptors and are safe for offline discovery. pack status is live tenant readiness: it composes Authority pack enablement, ExportCenter export readiness, and Notify reporting timeline readiness. Missing APIs, disabled packs, signing/storage/trust-root gaps, and publication preflight blockers produce stable reason codes and non-zero exit status. The operator-config sub-group reads, exports a sanitized copy of, and updates tenant operator-owned Assurance settings. CLI output must not expose secret values, local secret paths, or failed service response bodies.

Pack-specific exports remain on the existing command surface, including stella export nis2-soa, stella export nis2-effectiveness, stella export dora-incident-report, stella export dora-roi, stella export dora-info-sharing, stella tlpt pack, stella export cra-tech-file, and stella export conformity-dossier.

Initial Pack Map

The “Primary owners” column above is the broad conceptual surface for each pack and is wider than the descriptor’s machine-readable owners[] field. The shipped descriptors declare a narrower technical-ownership list: nis2.json names Policy, ExportCenter, and Notify; dora.json names Telemetry, Notify, Findings, EvidenceLocker, and CLI; cra.product-security.json names Router and Notify; cra.technical-documentation.json names ExportCenter and CLI.

The cra.product-security pack covers Stella’s own manufacturer/supplier publication obligations. The cra.technical-documentation pack covers evidence assembly for customer products or Stella release dossiers.

The dora pack is exposed through generic Web/CLI Assurance discovery as an optional operator-support pack. The owning runtime pieces are registered: ExportCenter ships the dora.roi, dora.major-incident-report, dora.info-sharing, and dora.tlpt-evidence-pack export profiles in AssuranceExportProfileRegistry, and Notify registers the dora.article19.incident reporting timeline profile. Because the source-data, owner-approval, and schema-mapping prerequisites are unmet by default, these profiles report blocked (not configured) rather than unavailable; unavailable is reserved for the case where the ExportCenter or Notify API itself cannot be reached. stella assurance pack status dora and /assurance must not claim pack-level readiness until the owning services return configured readiness.

NIS2 and DORA coverage is intentionally limited to software Stella monitors or deploys for the operator: releases, services, container images, integrations, plugins, direct ICT software dependencies, runtime host agents, asset registry entries, policy gates, and evidence bundles. Legal entity facts, governance records, HR/training evidence, physical controls, contracts, subcontracting beyond direct integrations, risk tolerance decisions, and authority filings are operator-supplied.

Lifecycle

Readiness must fail closed. Missing prerequisites should produce stable reason codes and human-readable summaries without exposing secrets.

The table above is the conceptual lifecycle. The CLI pack status runtime currently composes a coarser set of states: AssurancePackStatusResult.Compose (in AssurancePackCommandGroup.cs) emits only configured, disabled, unavailable, or blocked, and stella assurance pack status returns a success exit code only when the composed state is configured (otherwise it returns the service-not-configured exit code). The finer-grained available, enabled, export-ready, handoff-ready, and publication-ready states are the target model; today they map onto Authority pack-enablement modes (evidence-only, signed-export, regulator-handoff, public-publication) and the per-line readiness booleans (signedExportReady, livePublicationReady, operatorHandoffReady, autoSubmitReady) rather than a single emitted pack state.

Readiness Examples

NIS2 Statement of Applicability

The NIS2 SoA export can be enabled only when the tenant has live Policy control register data and ExportCenter can produce a signed bundle. Readiness checks include:

• Authority tenant compliance profile endpoint is configured and reachable by ExportCenter.
• ExportCenter NIS2 SoA storage root is configured.
• Signing key/provider is configured.
• Tenant export trust roots are configured.

If any item is missing, Web and CLI should show the export as unavailable with a specific reason code. They must not substitute fixture data as successful export evidence.

CRA Product Security Publication

The CRA Product Security Pack has two separate readiness lines:

• local signed evidence/export readiness;
• live public publication readiness.

Live public publication remains blocked until the product-security mailbox has delivery/access verification and a non-expired encryption-capable intake key or subkey certified by the website key lineage is published. That gate must not block local CRA technical-file generation.

DORA RoI Local-Contract Export

The DORA RoI path is operator-support, not regulator submission. The local export can be produced only when tenant profile data, asset/integration source snapshots, retention policy resolution, and local schema/taxonomy status are available. Official EBA XSD validation remains blocked until the selected RoI taxonomy package is approved and copied into the offline schema path.

Generic Assurance readiness must show this distinction. The named two-line model below is the target framing; the shipped DORA RoI readiness check exposes a single signedExportReady boolean plus blocking reason codes rather than two separate named readiness flags:

• local-contract-export-ready (target) can be true when deterministic local XML, manifest, signature, retention, and prior-year hash checks pass;

• official-schema-validation-ready (target) stays false until the exact pinned EBA taxonomy package is locally available and covered by offline tests.

  Today this gate is enforced by AssuranceExportProfileRegistry.AddDoraRoiReadinessReasons, which emits the blocking reason code dora-roi-schema-mapping-missing until IDoraRoiTaxonomyPin.IsPinned() confirms the SHA-256-pinned EBA package (taxo_package_4.0_errata5) is vendored and validates offline. The same check also blocks on dora-roi-register-source-missing and dora-roi-owner-approval-missing until the owning workflow supplies register rows and owner approval.

Copy Rules

Use pack/support language:

• “NIS2 Evidence Pack”
• “CRA Technical Documentation Pack”
• “Export readiness”
• “Publication preflight”
• “Operator-owned configuration”

Avoid certification language unless an explicit attestation exists:

• “NIS2 compliant”
• “DORA compliant mode”
• “CRA compliant mode”
• “EU compliance product”

Migration Rule

Existing NIS2 and CRA routes, contracts, and CLI commands should remain compatible while new generic discovery/readiness surfaces are added. Migrate in this order:

1. Document the architecture and generic contracts.
2. Add pack descriptors and docs.
3. Add Authority pack enablement and readiness.
4. Generalize Policy and ExportCenter discovery without breaking typed NIS2/CRA routes.
5. Reframe Web and CLI surfaces.
6. Retire duplicated or Europe-centric labels only after compatibility tests are green.