Export Center Profiles

Currency check 2026-10-07: owner paths/source placement verified against 3238bd511a37e199ae99d4f17be2f13eabec8dd7. The supported boundary is /api/evidence/v1/evidence/capsules/tlpt-packs (src/Evidence/StellaOps.Evidence.WebService/Program.cs). Re-verify the host mount and owning endpoint extension together. This is source verification; deployment and broader audit coverage are separate evidence. Other dated findings retain their stated dates. Re-verify: rg -n "MapGroup|Map.*Endpoints|AddHostedService" src/Evidence/StellaOps.Evidence.WebService/Program.cs, then inspect the endpoint extension or library pointer cited at the operation.

Status: routes and paths re-checked against commit 942a18727c (2026-09-26); the export plane is served by offlinekit-web under /api/offlinekit/v1/**. The profile catalogue, field tables and JSON examples below were not re-verified; the request model the API accepts is CreateExportProfileRequest in src/OfflineKit/__Libraries/StellaOps.ExportCenter.Application/Api/ExportApiModels.cs (name, description, kind = ExportProfileKind AdHoc/Scheduled/EventDriven/Continuous/Mirror, scope, format = ExportFormatOptions, signing, schedule), which differs from the design-era shape in Common configuration fields.

Export Center profiles define what data is collected, how it is encoded, and which distribution paths are enabled for a run. Profiles are tenant-scoped and deterministic: identical selectors and source data produce identical bundles. This guide summarises built-in profiles, configuration fields, schema conventions, and compatibility notes.

Profile catalogue

Profiles can be cloned and customised; configuration is immutable per revision to keep runs reproducible.

Provisioning & CRUD model

The lists below name each route’s policy. Ordinary export and Assurance groups also apply export.viewer to every route; mutations add export.operator or export.admin as shown. Inherited, route-specific and configured resource-server default scope requirements apply together; a mutation policy does not replace Viewer.

There are two distinct profile classes, and they are provisioned differently. Conflating them is the source of the “export profiles have no CRUD” confusion — one class is fully CRUD-able, the other is intentionally read-only.

1. Tenant export profiles (ExportProfile entity) — full tenant CRUD, backed by Postgres and audited. These are the profiles operators create/clone/customise:

   • GET /api/offlinekit/v1/exports/profiles (scope ExportViewer) — list
   • GET /api/offlinekit/v1/exports/profiles/{profileId} (ExportViewer) — read one
   • POST /api/offlinekit/v1/exports/profiles (ExportOperator, audited create_profile) — create
   • PUT /api/offlinekit/v1/exports/profiles/{profileId} (ExportOperator, audited update_profile) — update
   • DELETE /api/offlinekit/v1/exports/profiles/{profileId} (ExportAdmin, audited delete_profile) — archive (soft-delete)
   • POST /api/offlinekit/v1/exports/profiles/{profileId}/runs (ExportOperator) — start a run

   The console currently wires only the read side (listProfiles); create/update/archive are available on the API and are the intended console follow-up. This is an FE-wiring gap, not a missing backend.

2. Assurance / compliance export profiles (NIS2 / DORA / CRA — the AssuranceExportProfileRegistry) are provisioned via offlinekit-web configuration (AssuranceExportOptions, Nis2SoaExportOptions; sections Export:Assurance and Export:Nis2Soa) and are read-only by design. They are discovery/readiness descriptors bound to signed adapters/routes; there is deliberately no create/update/delete surface. Change them by editing the offlinekit-web configuration and redeploying (see the Assurance export profile catalogue and OfflineKit architecture §7). Their read surface is /api/offlinekit/v1/exports/assurance/profiles.

Assurance export profile catalogue

The Assurance HTTP catalogue was verified against c5cc6723ce (PCD-281, 2026-10-04). Recheck all seven entries’ methods and templates with pwsh -NoProfile -File tools/scripts/test-targeted-xunit.ps1 -Project src/OfflineKit/__Tests/StellaOps.OfflineKit.WebService.Tests/StellaOps.OfflineKit.WebService.Tests.csproj -Class "*ExportSurfacingClientRouteTableTests" -BuildProjectReferences -Restore.

The generic Assurance registry uses dot-form profile ids and is exposed at /api/offlinekit/v1/exports/assurance/profiles. These descriptors are discovery/readiness records; execution uses the named typed export endpoints or registered CLI commands. The compatibilityRoutes JSON field lists these current entry points. Its HTTP entries include their method and complete /api/offlinekit/v1/exports path.

Every built-in Assurance profile sets signingRequired=true and supportsOfflineVerification=true. Readiness fails closed and reports stable reason codes without exposing secret/config values.

DORA route-owned profile targets

DORA RoI is a built-in fail-closed Assurance readiness descriptor and an HTTP-expressible source-supplied produce path. Web/CLI can render stable blocked readiness reasons instead of probing a missing route; when a request supplies a complete dora-roi.v1 register and ownerApprovalRef, ExportCenter materializes the signed RoI ZIP, validates the vendored EBA taxonomy package, and signs with operator-owned Export:Assurance:DoraRoi key material. The descriptor does not fetch workflow data, does not claim regulator submission, and never accepts signing key material from the request body. The ZIP wrapper uses the same DoraRoiBundleAssembler manifest/signature shape as stella export dora-roi --offline, so deterministic HMAC HTTP output can byte-match the CLI; HTTP-only approval/source refs remain request/readiness metadata instead of artifact fields. In deployed images, Export:Assurance:DoraRoi:TaxonomyPackagePath may point at a mounted read-only copy of the pinned EBA outer ZIP; readiness uses that same configured path before clearing dora-roi-schema-mapping-missing.

Other DORA handoff routes remain documented target profiles so Web/CLI can use stable ids. TLPT is HTTP-expressible only by delegating to EvidenceLocker. Major incident and information sharing are HTTP-expressible when the request supplies the Notify-owned source payloads and JSON-friendly Notify channel DTOs; ExportCenter maps those DTOs into the existing Notify contracts and does not invent workflow state.

dora.major-incident-report HTTP produce accepts { "doraMajorIncidentReport": { "report": <DoraMajorIncidentReportInput>, "channel": <AssuranceProduceNotifyChannelInput>, "producedAt": "..." } }, uses the Notify DORA major-incident encoder/outbound handoff, and signs with operator-owned Export:Assurance:DoraMajorIncidentReport HMAC material. Its wrapper media type is application/vnd.stellaops.dora-major-incident-report.http-bundle.v1+json.

dora.info-sharing HTTP produce accepts { "doraInfoSharing": { "request": <AssuranceProduceDoraInfoSharingExportRequest>, "subscriberApprovalRef": "..." } }, maps the request DTO into Notify DoraInfoSharingExportRequest, emits the Notify STIX/TAXII/DSSE artifacts, and signs with operator-owned Export:Assurance:DoraInfoSharing HMAC material. Its wrapper media type is application/vnd.stellaops.dora-info-sharing.http-bundle.v1+json.

dora.tlpt-evidence-pack HTTP produce accepts { "tlptEvidencePack": <CreateTlptEvidencePackRequest> } and delegates to EvidenceLocker POST /api/evidence/v1/evidence/capsules/tlpt-packs. ExportCenter persists the sealed EvidenceLocker response JSON as the Assurance run artifact; it does not assemble, sign, or mutate TLPT evidence locally. The delegated call still requires EvidenceLocker authorization/tenant context in deployed environments.

Common configuration fields

Selectors (time windows, tenants, products, SBOM subjects, ecosystems) are supplied per run, not stored in the profile.

JSON profiles

json:raw

• Content: Exports raw advisories, VEX statements, and SBOMs as newline-delimited JSON (.jsonl.zst).
• Schema: Follows canonical StellaOps schema with casing and timestamps normalised. Each record includes tenant, source, linkset, and content fields.
• Options:
  • include defaults to ["advisories", "vex", "sboms"].
  • compression defaults to zstd level 9.
  • maxRecordsPerFile (optional) splits outputs for large datasets.
• Compatibility: Intended for analytics platforms, data escrow, or feeding downstream normalisation pipelines.
• Sample manifest excerpt:

{
  "profile": { "kind": "json", "variant": "raw" },
  "outputs": [
    { "type": "advisories.jsonl.zst", "sha256": "...", "count": 15234 },
    { "type": "vex.jsonl.zst", "sha256": "...", "count": 3045 },
    { "type": "sboms.jsonl.zst", "sha256": "...", "count": 872 }
  ],
  "selectors": { "tenant": "acme", "products": ["registry.example/app"] }
}

json:policy

• Content: Everything from json:raw plus:
  • policy_snapshot.json (policy metadata, version, hash).
  • findings.policy.jsonl.zst (evaluated findings with decision, rationale, rule id, inputs hash).
• Determinism: Requires a policy snapshot id; runs fail if snapshot is missing or non-deterministic mode is active.
• Use cases: Compliance exports, auditor packages, policy attestation archives.
• Guardrails: AOC boundaries preserved: policy outputs are clearly partitioned from raw evidence.

Trivy profiles (retired)

⛔ RETIRED 2026-08-09 — owner ruling: Stella Ops does not support trivy-db. The trivy:db and trivy:java-db profiles, the TrivyDbAdapter / TrivyJavaDbAdapter, and the signed stellaops.exportcenter.trivy-db / …trivy-java-db bundles are severed; their sources moved to src/__Obsoleted/. No adapter declares either format in its SupportedFormats any more, so nothing can produce them. (Do not describe this as failing closed at adapter resolution — verified 2026-08-14, GetAdapterForFormat has no production call site, only test ones.) The ExportFormat.TrivyDb/TrivyJavaDb enum members are retained only so historical persisted plans deserialize.

Replacement: our own digest-attested compact offline vulnerability database — stella vuln-db export --from-hub <url>.

The historical adapter design is kept as a ⛔ FROZEN record in docs-archive/modules/export-center/trivy-adapter.md. Do not re-add these profiles.

Mirror profiles

mirror:full

• Bundle structure and delta strategy are covered in docs/modules/export-center/mirror-bundles.md.
• Content: Complete export with:
  • Raw advisories, VEX, SBOMs (/data/raw).
  • Policy overlays (/data/policy), including evaluated findings and policy snapshots.
  • Indexes for fast lookup (/indexes/advisories.pb, /indexes/sboms.pb).
  • Manifests and provenance (/manifests/export.json, /manifests/provenance.json).
• Layout: Deterministic directory structure with hashed filenames to reduce duplication.
• Encryption: Optional encryption block enables age/AES-GCM encryption of /data. strict=true encrypts everything except export.json.
• Use cases: Air-gap replication, disaster recovery drills, Offline Kit seeding.

mirror:delta

• See docs/modules/export-center/mirror-bundles.md for delta mechanics and application order.
• Content: Includes only changes relative to a base manifest (specified by baseExportId when running).
  • changed, added, removed lists in manifests/delta.json.
  • Incremental indexes capturing only updated subjects.
• Constraints: Requires the base manifest to exist in object storage or artifact registry accessible to the worker. Fails with ERR_EXPORT_BASE_MISSING otherwise.
• Workflow: Ideal for frequent updates to mirrored environments with limited bandwidth.

CRA profiles

cra:tech-file

• Content: Produces the deterministic cra-tech-file-v1 bundle described in docs/contracts/cra-tech-file-v1.md.
• Generic registry profile: cra.technical-file.
• Use cases: Annex VII technical documentation for Stella releases or customer products with immutable evidence refs.
• Signing: Local file-backed exports use HMAC DSSE for offline tamper checks. Production exports default to Signer/KMS-backed DSSE, can opt into cadenced DSSE+CAdES companion metadata, and record durable EvidenceLocker regulatory audit and ledger rows once the archive hash is known.
• Determinism: Uses canonical JSON and fixed tar/gzip metadata. Missing control-register inputs or production CAdES provider packs are recorded as blockers.

cra:conformity-dossier

• Content: Embeds tech-file/cra-tech-file.tar.gz and adds conformity-dossier-v1 overlays from docs/contracts/conformity-dossier-v1.md.
• Generic registry profile: cra.conformity-dossier.
• Module selection: Module A is the Stella default. B+C adds EU type-examination/test-certificate overlays. H adds full-QMS and ISO/IEC 27001 control-effectiveness overlays.
• Use cases: Self-assessment-ready Module A packages, notified-body evidence packs, and full-QMS customer-product dossiers.
• Determinism: Same inputs and selected module produce byte-identical bundles. Missing module evidence is represented by explicit blocked overlays rather than fabricated data.

Standards profiles

standards:mapping

• Content: Produces the deterministic standards-mapping-bundle-v1 archive described in docs/contracts/standards-mapping-v1.md.
• Targets: iso27001, iec62443-4-1, iec62443-4-2, en303645, and jrc-cra. All targets map to local YAML files under docs/europe/standards-mapping/; jrc-cra requires reviewed non-zero rows and no blocker state before publication.
• Use cases: Standards evidence crosswalks for NIS2 Article 21 control discussions, CRA standards evidence, procurement questionnaires, and auditor handoff.
• Determinism: Uses local files only, canonical JSON, fixed tar/gzip metadata, DSSE-signed index output, and explicit blockers for draft or pending review states.

NIS2 profiles

nis2:statement-of-applicability

• Content: Produces the deterministic nis2-soa-v1 signed bundle described in docs/contracts/nis2-soa-v1.md.
• Generic registry profile: nis2.statement-of-applicability.
• Inputs: Policy control-register snapshot, Authority tenant compliance profile, EvidenceLocker bundle ref, signing key/provider, storage root, and tenant export trust roots.
• Use cases: NIS2 Statement of Applicability handoff, auditor evidence review, and operator release/compliance records.
• Fail-closed behavior: Missing Authority profile access, storage root, signing key/provider, or tenant export trust roots blocks production export. Fixture data may be used for tests but must not be reported as live SoA evidence.

nis2:effectiveness-report

• Content: Produces the deterministic nis2-effectiveness-report-bundle-v1 JSON bundle described in docs/contracts/nis2-effectiveness-report-v1.md.
• Generic registry profile: nis2.effectiveness-report.
• Inputs: A local nis2-effectiveness-dashboard-v1 source report, a normalized yyyy-MM month, signing key material, and optional target document, Policy snapshot, and control-register snapshot references.
• HTTP produce (Sprint 20260616.003): POST /api/offlinekit/v1/exports/assurance/profiles/nis2.effectiveness-report/runs (inherited export.viewer plus route export.operator) materializes the signed monthly bundle by reusing Nis2EffectivenessExporter verbatim; the run-based response carries a bundleDownloadUrl (GET /api/offlinekit/v1/exports/assurance/runs/{runId}/bundle). The request body supplies the data inputs ({ nis2Effectiveness: { reportMonth, sourceReport, ...refs } }); the HMAC signing key is operator-owned config only (Export:Assurance:Nis2Effectiveness:SigningKeyFile, preferred key-custody file, or :SigningKey for lab/dev) — it is never accepted in the request body, and the path fails closed (409 effectiveness-signing-material-missing) when no key material is configured. The HTTP output is byte-identical to the CLI for the same frozen inputs.
• Use cases: Monthly NIS2 effectiveness evidence packs for offline audit review, including the 13 thematic areas, live KPI readings, target state, linked controls, and explicit blockers.
• Determinism: Canonical JSON, fixed manifest entry paths, report hash excluding its self-reference, and local HMAC DSSE output. Production CAdES/KMS signing is not claimed by the file-backed CLI path.
• Fail-closed behavior: The adapter rejects source reports that do not contain exactly 13 ordered NIS2 areas and records missing upstream hashes/refs as blockers instead of inventing target, control-register, or policy evidence.

Compatibility and guardrails

• Aggregation-Only Contract: All profiles respect AOC boundaries: raw evidence is never mutated. Policy outputs are appended separately with clear provenance.
• Tenant scoping + approvals: Profiles are tenant-specific. When selectors.tenants includes additional tenants or wildcards, approval.required=true plus approvedBy and ticket must be present (validated by verify-export-kit.sh and schema).
• Retriable runs: Re-running a profile with identical selectors yields matching manifests and hashes, facilitating verify-on-download workflows.
• Offline operation: JSON and mirror profiles function in offline mode without additional configuration.
• Quota integration and backpressure: Profiles declare limits.maxActiveRuns, limits.maxQueuedRuns, and backpressureMode (reject|defer|throttle). When limits trigger, exporters emit 429 with X-Stella-Quota-* plus Retry-After to keep retries deterministic.
• Advisory transport is not an export profile: Concelier is retired (ADR-039 D2), so there are no Concelier tactical exporters and no feedser-bundle/1.0 federation export to align with (export:trivy-db and the trivy:db profile were retired 2026-08-09). Advisory and VEX data reach an isolated estate as the Vulnerabilities hub mirror seed (docs/OFFLINE_KIT.md§2.4). The earlier Concelier/Export Center boundary is recorded in ADR-003, superseded 2026-09-27.

Example profile definition (CLI)

{
  "name": "daily-json-raw",
  "kind": "json",
  "variant": "raw",
  "include": ["advisories", "vex", "sboms"],
  "distribution": ["http", "object"],
  "compression": { "codec": "zstd", "level": 9 },
  "retention": { "mode": "days", "value": 14 }
}

Create through the API: POST /api/offlinekit/v1/exports/profiles (inherited export.viewer plus route export.operator). The CLI has no profile-create verb at this commit (stella export profiles offers list and show).

Verification workflow

• Download bundle via Console/CLI and extract export.json and provenance.json.
• Run cosign verify --key <tenant-key> export.json (for detatched signatures use --signature export.json.sig).
• For mirror bundles, run the verify-mirror.sh script shipped inside the bundle (see mirror-bundles.md).

Extending profiles

• Use API/CLI to clone an existing profile and adjust include, distribution, or retention policies.
• Adapter plug-ins can introduce new variants (e.g., json:raw-lite, mirror:policy-only). Plug-ins must be registered at service restart and documented under /docs/modules/export-center/profiles.md.
• Any new profile must append the imposed rule line and follow determinism and guardrail requirements.

Imposed rule: Work of this type or tasks of this type on this component must also be applied everywhere else it should be applied.