Regulatory asset intake lane

Document Version: 1.0.0 Effective: 2026-05-02 Owners: Compliance, Maintainer-of-Record, Legal Status: binding process

1. Why this lane exists

Stella Ops is offline/air-gap-first (CLAUDE.md §2.8). Every regulator-published or vendor-published evidence package that engineering needs at runtime (eIDAS QTSP/QSCD/TSL/LOTL fixtures, EBA DORA DPM/XBRL taxonomies, EBA RoI XSD packages, RFC 3161 TSA fixtures, OCSP/CRL snapshots) MUST be vendored into the repo under a stable local path with manifest SHA-256, license disposition, and notice attribution captured. Engineering cannot reach for these assets at build/test/runtime; the runtime never fetches.

The blocker on at least eight currently-BLOCKED tasks across sprints 018/019/112/121/122/123 is not engineering ambiguity — every fail-closed local-contract path is already implemented. The blocker is the absence of an intake lane: a deterministic process that takes a candidate package, clears it through legal/compliance, vendors it under the right path, and records the decision so future audits can replay it.

This document is the binding process. The associated decision-record template lives at docs/legal/templates/regulatory-asset-decision-record.md.

2. Roles and responsibilities

Out of scope for this lane: non-regulatory third-party dependencies (NuGet/npm/etc.) follow the existing THIRD-PARTY-DEPENDENCIES.md process. Use this lane only for regulator- or vendor-qualified evidence packages where deterministic, offline, content-addressed local copies are the contract.

3. Intake gates

A candidate package moves through five gates in order. Each gate either passes (record gains a signature row) or rejects with a reason. There is no “conditional pass”; if a gate cannot decide, the record sits in the gate’s queue until decided.

Gate 1 — Engineering candidacy

Engineering produces:

• The asset’s regulator/vendor source URL(s).
• Version pin string (e.g., eba-dora-roi-reporting-framework-4.0-taxo-package-4.0-errata5).
• SHA-256 of the candidate archive (computed locally; recorded in the decision record).
• Proposed local vendoring path under docs/contracts/schemas/eu/<regime>/<vendor>/<version>/.
• A short paragraph on why this asset is required (which sprint’s BLOCKED task it discharges).
• A short paragraph on what the runtime does with the asset (which validator code path consumes it; what fail-closed alternative is in place today).

Output: docs/legal/decisions/REG-<YYYYMMDD>-<short-id>.md from the template.

Gate 2 — Schema-governance review

Schema-governance reviewer verifies:

• The proposed local path matches the YAML inventory’s namespacing scheme; if a new top-level path is needed, the YAML is amended FIRST.
• The version pin is the canonical regulator string (no in-house abbreviations).
• The asset is the upstream-canonical package (not a derivative or a vendor-bundled redistribution unless the vendor is itself the authoritative source).
• All transitive references (CVSS schemas, etc.) are enumerated; partial vendoring is rejected.
• The SHA-256 in the decision record matches a freshly-recomputed digest (reviewer recomputes; does not trust engineering’s digest blindly).

Output: Schema-governance review row signed in the decision record.

Gate 3 — Legal review

Legal performs:

• BUSL-1.1 compatibility check of the distribution license (per docs/legal/LICENSE-COMPATIBILITY.md).
• Determination: approved-vendor, approved-with-notice, reference-only-no-vendoring, or rejected.
• For approved-with-notice and approved-vendor: composes the attribution text that will go into NOTICE.md and (if applicable) the file under third-party-licenses/.
• For reference-only-no-vendoring: documents the alternative (operator-supplied, runtime-loaded; engineering implements a registry/loader path instead of vendoring).

Output: Legal review row signed in the decision record.

Gate 4 — Compliance / Vendor Integration (vendor-qualified packs only)

Skip for regulator-only packages. Required for:

• eIDAS QTSP/QSCD-backed deployment packs (sprint 018).
• Vendor-bundled compliance evidence (rare; e.g., a partner-signed archive of a regulator-published taxonomy with the partner’s chain of trust).

Compliance verifies:

• Vendor agreement covers the intended use.
• Jurisdiction, profile, and expiry are recorded.
• Accepted/rejected verdict fixtures (the small set of inputs each validator must succeed/fail on) are present and digest-stable.

Output: Compliance / Vendor row signed in the decision record.

Gate 5 — Vendoring + sprint update

After all prior gates pass:

• Engineering vendors the package at the approved local path.
• docs/contracts/schemas/eu/eu-schema-taxonomy-assets-v1.yaml is updated with the new entry: status flips from BLOCKED-pending-approved-asset-intake → present, the licenseStatus field is filled in, the notice field lists the new entries.
• NOTICE.md is updated with the attribution.
• For vendored license text: a file lands under third-party-licenses/.
• docs/legal/THIRD-PARTY-DEPENDENCIES.md “Regulator-vendored” section (added by this sprint) is updated.
• The originating sprint’s BLOCKED row(s) flip to TODO/DOING; the Execution Log entry references the decision record id.

Output: Final commit attaches the decision record id to the change.

4. Decision record schema

Every intake produces one Markdown record under docs/legal/decisions/REG-<YYYYMMDD>-<short-id>.md. The template is the binding shape. Required fields:

• Record id (filename matches a strict regex: REG-\d{8}-[a-z0-9-]+).
• Asset metadata: regime (eIDAS / DORA-IR / DORA-RoI / Other), vendor/regulator, version pin, source URLs, candidate SHA-256.
• Local vendoring path: under docs/contracts/schemas/eu/<regime>/....
• Runtime use: which sprint task this discharges; which validator code path; what the current fail-closed posture is.
• Gate signatures: one row per gate (engineering, schema-governance, legal, optional compliance, vendoring), each with date, signer identity, and outcome (pass / reject).
• Linked NOTICE/license artefacts: paths under third-party-licenses/ and NOTICE.md line numbers.
• Originating sprint: filename of the sprint that the intake discharges.

Records are append-only. If an intake decision needs to be revoked (license re-categorization, vendor agreement lapse), a new record is opened with Supersedes: REG-<id> and the old record gains a final Superseded by row; the original signatures remain.

5. Ledger schema (the YAML inventory)

The single source of truth for “what is vendored where” is docs/contracts/schemas/eu/eu-schema-taxonomy-assets-v1.yaml. Adding an asset means adding an entry under assets: with this shape (existing oasis-csaf-2.0 entry is the reference example):

- id: <kebab-case-short-id>
  regime: <eIDAS | DORA-IR | DORA-RoI | CRA | Other>
  artifact: <one-line description>
  source:
    name: <regulator-canonical name>
    version: <version pin>
    sourceDate: <YYYY-MM-DD>
    urls: [<canonical urls>]
    transitiveUrls: [<transitive references>]
  local:
    status: present | BLOCKED-pending-approved-asset-intake
    path: docs/contracts/schemas/eu/<regime>/<short-version>/
    files:
      - name: <relative path>
        sha256: sha256:<lowercase hex>
        bytes: <integer>
  licenseStatus: <approved-* | reference-only-no-vendoring | rejected>
  notice: [<NOTICE.md, third-party-licenses/...>]
  decisionRecord: REG-<YYYYMMDD>-<short-id>

The decisionRecord field is added by this lane; it is the back-pointer from inventory → audit trail.

6. Currently-BLOCKED packages

Tracking from the open-sprint blocker analysis originally captured at docs/implplan/_blocker_analysis_2026-05-02.md (Cluster A). The analysis dump was retired after its referencing sprints closed; the post-resolution outcomes for each row are captured under §6.1 “Status update 2026-05-02” below. Engineering has already drafted the fail-closed local-contract paths; the intake decision is what remains.

Status update 2026-05-02 (counsel response received)

External counsel returned the Gate 3 review for all three open EBA / eIDAS records on 2026-05-02. The originating response is preserved at docs/legal/decisions/response.md. Each row in the table below now carries the post-2026-05-02 state alongside the historical “Notes” wording.

• EBA DORA RoI Reporting Framework 4.0 errata5 — Gate 3 cleared approved-with-notice (REG-20260502-eba-dora-roi-4-0-errata5). NOTICE.md attribution mounted; YAML inventory carries licenseStatus: approved-with-notice and a decisionRecord back-pointer; third-party-licenses/ placeholder file landed. Sprints 121 / 122 / 123 stay BLOCKED with narrower remaining scope: Gate 2 (engineer downloads from eba.europa.eu and recomputes SHA-256 + verifies no package-specific notice override and no uncleared third-party material) and Gate 5 (vendoring + YAML local.status flip + replacement of the placeholder third-party-licenses/ file with the actual EBA Legal Notice text).
• EBA DORA Incident-Reporting Framework 4.3 — Gate 3 provisionally cleared approved-with-notice (same EBA Legal Notice posture as RoI) but with a hard counsel-flagged asset-scope re-verification gate (REG-20260502-eba-dora-incident-framework-4-3). Engineering must confirm whether “EBA Reporting Framework 4.3” is the correct machine-validation package for the DORA RTS encoder, or whether the actual ESA/EBA DORA incident template/schema package should replace it. Counsel cannot answer that. NOTICE.md / YAML inventory NOT updated — vendoring waits on the asset-scope re-verification AND a Gate 3 re-confirm against the actual published 4.3 package notice page. Sprint 112 D1-112-1 stays BLOCKED with the new asset-scope re-verification gate.
• eIDAS qualified provider pack — Gate 3 vendor-independent half cleared (REG-20260502-eidas-qualified-provider-pack); default engineering fallback is reference-only-no-vendoring with a fail-closed runtime-loader path. Final Gate 3 determination still pending Gate 4 (Compliance / Vendor Integration must select a QTSP and attach the agreement); TLv6 / ETSI TS 119 612 v2.4.1 compatibility is binding on any pack chosen after 2026-04-28; eIDAS Articles 33 / 34 / 40 claim-control wording is binding on runtime output paths. Gate 4 work tracked in SPRINT_20260502_005_Cryptography_eidas_qtsp_vendor_intake.md. Sprint 018 EIDAS-EVIDENCE-018-01 stays BLOCKED with narrower remaining scope.

7. Engineering responsibilities BEFORE the lane

Engineering does NOT have to wait on this lane to ship the consuming code path. Every consumer must be implemented as fail-closed:

• The validator/encoder runs the local-contract checks on whatever in-repo fixtures already exist (golden fixtures the team controls).
• The validator/encoder refuses to claim regulator-conformance until the vendored package is present and its licenseStatus is approved.
• The validator/encoder is gated behind a configuration setting (e.g., Eidas:TrustedList:FixturePackManifestPath) whose default points at the not-yet-vendored path; missing path = clean fail-closed (Healthy + airGapSealed=true for Doctor checks; documented quarantine for ingest paths; no false claim of regulator-conformance).

This is already the pattern across the BLOCKED sprints (see sprint 018 EIDAS-EVIDENCE-018-00, sprint 030 DOCTOR-AIRGAP-030-04). New consumers must follow the same pattern.

8. What this lane is NOT

• Not a fast-track for one-off intake. Every package goes through every applicable gate. There is no “emergency intake” path; that’s exactly the kind of shortcut that destroys the offline-first guarantee.
• Not a license-laundering channel. Legal cannot retroactively approve a package after vendoring; Gate 3 must precede Gate 5.
• Not a replacement for THIRD-PARTY-DEPENDENCIES.md. That document remains the canonical inventory for non-regulatory NuGet/npm/etc. dependencies.
• Not a place engineering autonomously vendors regulator content. Even when engineering knows the answer, the gates exist so the decision is auditable and replayable. A future audit reads the decision record, not the engineer’s memory.

9. Audit & replay

Every regulator-vendored asset must be reachable through:

1. The YAML inventory entry (machine-readable).
2. The REG-... decision record (human-readable; gates + signatures).
3. The vendored files under docs/contracts/schemas/eu/<regime>/<version>/ (the artefacts themselves, with bytes-on-disk matching the recorded SHA-256).
4. The NOTICE.md attribution and any third-party-licenses/<package> text.
5. The sprint Execution Log entry that consumed the intake.

If any of these five is missing for a package that runtime treats as authoritative, the package is in violation of this lane and must be quarantined: the YAML status flips back to BLOCKED-pending-approved-asset-intake, the runtime reverts to fail-closed posture, and a new decision record opens.

10. Change log