Stella Ops eIDAS / QTSP posture

Audience: Stella Ops PM, operators, compliance officers, auditors, buyers, external counsel, future engineers. Status: posture is binding internally per EXEC-20260504-eidas-reference-only-canonical-model.md. External-counsel review is closed — the canonical model was confirmed on 2026-08-23 (eidas-counsel-thread-canonical-model.md Round 3), and all seven production controls landed on 2026-08-23 (SPRINT_20260823_001 EIDAS-CTL-1…CTL-6), together with the exposure guard CTL-5. The deferred licence question is answered: counsel ruled that BUSL needs no eIDAS amendment, but requires a versioned, binding, affirmatively accepted operator instrument (question, reply). That choice is RULED (owner, 2026-08-25, Q-16): the full Customer Agreement is the instrument, drafted now, with no interim standalone addendum — no eIDAS release date requires one, and counsel recorded that the addendum alone would not cure the missing governing-law/liability/support-data terms. The eIDAS Operator Addendum content becomes a versioned schedule of that agreement. The agreement is ISSUED: CUSTOMER_AGREEMENT.md1.0.0, adopted for release by the manufacturer of record on 2026-09-16 (adoption record, SPRINT_20260825_016 LRS-3). It carries counsel’s eleven-section minimum content, the verbatim Operator Material schedule, the operator terms as Schedule 2 identified by version and digest, and a versioned acceptance record. Release rests on the owner’s ADOPTED decision rather than a signed opinion, which counsel confirmed is not a precondition to forming a B2B agreement; both review rounds are ASSESSED (see decisions/README.md). Issued is not accepted: it is not yet operative for any customer, and until a customer affirmatively accepts the issued version, support must not request customer logs/evidence without a documented confidentiality/data-protection basis. Authoritative records: see docs/legal/decisions/README.md for the full file-level audit trail. Runtime details: see docs/modules/cryptography/architecture.md§4.8 (“Runtime Loader And Claim Control”).

This document is the single-page narrative tying the eIDAS topic together. It is evergreen — read it first if you want to understand “what is Stella Ops’ eIDAS stance and how does the runtime back it up.” Underlying records (decisions, counsel correspondence, runtime contracts) are linked throughout.

1. The regulation in 60 seconds

eIDAS (Regulation 910/2014, as amended; “eIDAS 2” is the current implementing-act landscape) defines three categories that matter for Stella Ops:

• Trust services — creation, verification, and validation of electronic signatures, seals, or timestamps where provided as a service.
• Trust service providers (TSPs) — entities providing those services.
• Qualified trust service providers (QTSPs) — TSPs admitted to a Member State trusted list with explicit qualified status. The legal effect of a “qualified” trust service only attaches when the service is listed as qualified in the relevant trusted list at the relevant time.

Articles 33 / 34 / 40 govern qualified validation, qualified preservation, qualified electronic timestamping, and the application of those rules to qualified electronic seals.

ETSI TS 119 612 v2.4.1 (TLv6) is the technical format for trusted lists; it was enforced from 2026-04-28 22:00 UTC. Pre-v6 trusted-list snapshots are admissible only as labelled historical evidence.

2. Stella Ops’ three-role architecture

The legal architecture Stella Ops asks counsel to validate is:

Stella Ops      = on-prem technical software product
Operator        = party selecting QTSP, supplying evidence,
                  and making any workflow-level qualified-service representation
QTSP            = party providing any qualified trust service
Runtime states  = local claim-control vocabulary, NOT a qualified-service certificate

Stella Ops is not a TSP and is not a QTSP. Stella Ops ships software that locally processes operator-supplied trust material and per-transaction evidence. Stella Ops does not issue, validate-as-a-qualified-service, preserve-as-a-qualified-service, timestamp, certify, seal, or provide relying-party validation reports as a QTSP. If Stella Ops ever offers hosted/managed validation, the canonical model below reopens for review (see §6).

3. The canonical model: reference-only-no-vendoring

Per EXEC-20260504-eidas-reference-only-canonical-model.md (PM-binding 2026-05-04):

Stella Ops vendors no QTSP trust-material pack, production timestamp token, OCSP/CRL evidence, archive timestamp, vendor credential, or QTSP-controlled production evidence in its repository or Offline Kit.

The in-repo sealed eIDAS fixture under src/Cryptography/__Tests/StellaOps.Cryptography.Tests/Eidas/Fixtures/sealed-pack/ is a first-party synthetic test pack. It may be used to exercise loader, CAdES, revocation, and future signer-certificate QES wiring, but it is not a QTSP pack and must not be shipped as production evidence. Real pack ingestion and replacement steps are documented in docs/modules/cryptography/eidas-qualified-provider-pack-ingestion.md.

Operator-signing program closeout (2026-06-10): production operator-QES qualification is abandoned for the operator-signed governance decisions program. That is a product/legal/supply-chain decision, not a missing implementation detail: no real QTSP/provider pack exists, no vendor-specific counsel decision exists, and treating the synthetic fixture as production qualified evidence would create a false qualified-service claim. Future re-entry must open a new sprint and follow the ingestion runbook plus REG-20260502-eidas-qualified-provider-pack.

Operators bring their own eIDAS trust material and evidence through two local loaders:

• Loader 1 — static offline trust-material pack, loaded at deploy/configuration time. Contents (operator-sourced from their QTSP arrangement): EU LOTL snapshot in TLv6 format, Member State TSL snapshots for the relevant jurisdictions, TSP/service metadata, public signing/TSA certificate chains and trust anchors, OCSP responses / CRL snapshots for the chains, service policy identifiers, CP/CPS references, and accepted/rejected test fixtures.
• Loader 2 — per-transaction evidence, loaded at the relevant release / signing / validation / evidence-embedding event, or from a local operator-controlled evidence store before use. RFC 3161 timestamp tokens are per-request artefacts (the token’s message imprint and TSA-unique serial number bind it to one specific signing event); OCSP responses and CAdES archive timestamps follow the same per-transaction model.

The runtime is implemented in src/Cryptography/StellaOps.Cryptography.Plugin.Eidas/Loading/:

• EidasTrustedListLoader.cs — Loader 1.
• EidasTransactionEvidenceLoader.cs — Loader 2.
• EidasRuntimeClaimState.cs — claim-state vocabulary (see §4 below).
• EidasClaimWording.cs — counsel-driven safer wording constants.
• EidasEvidenceNotProductionReadyException.cs — fail-closed exception with a typed reason enum.

Tests in src/Cryptography/__Tests/StellaOps.Cryptography.Tests/Eidas/ assert character-for-character equality with the counsel-supplied wording and verify all fail-closed branches.

4. The runtime claim-state vocabulary (counsel-settled and implemented 2026-08-23)

The rename landed 2026-08-23 (SPRINT_20260823_001 EIDAS-CTL-1). Counsel answered the carried question on 2026-08-23 (decisions/eidas-counsel-thread-canonical-model-reply.md; routed as Round 3 of decisions/eidas-counsel-thread-canonical-model.md) and disapproved claimed-against: for production use. The runtime now emits the approved strings, renders them from constants pinned character-for-character against this document and the counsel reply (EidasClaimWordingRecordTests), and refuses to let any emitted wire form or Doctor token carry a superseded expression. The other six controls and CTL-5 also landed on 2026-08-23; the completed evidence is in archived SPRINT_20260823_001.

This table is a machine-checked record. EidasClaimWordingRecordTests in src/Cryptography/__Tests/StellaOps.Cryptography.Tests/Eidas/ reads this file and asserts each of the six strings above appears in it character-for-character. Reformatting a token here — even the <qtsp-pack-version> placeholder — turns that suite red. That is intentional: the code and the record must not be able to drift apart silently.

Why the rename. Counsel: “‘Claimed’ can reasonably be interpreted as Stella Ops making a product-side legal or conformance representation.” The negative state renames agreement → attestation because it describes the absence of an operator-controlled attestation file, not Stella Ops loading or interpreting the operator’s contract.

Mandatory disclaimer. Every external rendering of a positive state must carry the equivalent of counsel’s sentence, which is counsel-cleared wording and must not be paraphrased:

Local technical validation result. Stella Ops does not assert that it is providing a qualified validation service or that this result constitutes a QTSP-issued validation certificate.

Emission rule. Counsel: “The state must identify the exact pack version, trusted-list snapshot, validation policy and evidence set used. It must not be emitted merely because a pack is present. The runtime must distinguish at least present, absent, expired, revoked, rejected and historical-replay conditions.” Implemented 2026-08-23 (SPRINT_20260823_001 EIDAS-CTL-3) as a type, not a rule: EidasRuntimeClaimState has no public constructor, its public factory throws on a positive status, and the only route to a positive state is EidasClaimStateComposer.Compose, whose input record requires all four of counsel’s inputs plus the validation policy. FromLoaderState can no longer return a positive state at all — the PackLoaded arm that counsel ruled out has been removed. The six conditions live in EidasTrustCondition; note that counsel approved no wire token for “revoked” or “rejected”, so those two render the pack-not-loaded token and keep their distinction in the condition, the Doctor token and the audit diagnostic rather than in a vocabulary counsel never saw.

Acceptance conditions for the negative states. Counsel accepts them only if the state is defined as the absence of an operator-controlled attestation file; the workflow fails closed for qualified-service claims; neither the API nor the UI converts the state into a generic “valid” / “verified” / “eIDAS compliant” result; downstream consumers can distinguish cryptographic validity from qualified-service status; and the reason for withholding the claim stays in the audit record.

Current exposure. Verified 2026-08-23, before and after the EIDAS-CTL-1 rename: the claim state has no consumer outside the eIDAS plugin and its own tests — no API, report, export or UI renders it — so counsel’s production-exposure gate is not breached. The disapproved claimed-against: form is no longer emitted anywhere in src/Cryptography/; it survives only as a named entry in EidasClaimWording.SupersededExpressions, which exists so the absence guard can be shown finding one. The remaining tree-wide hits (StellaOps.Findings.DoraRoi, StellaOps.Evidence.TimestampAssurance) belong to other regulatory domains and are not in scope of counsel’s eIDAS ruling.

5. The operator attestation file

The runtime refuses to emit any positive eIDAS claim until the operator has supplied a local attestation file at the configured path. Counsel pinned the config key on 2026-08-23: Eidas:TrustedList:OperatorAgreementAttestationPath, which must be validated and pinned — “do not silently search for or infer an attestation.” Implemented 2026-08-23 (SPRINT_20260823_001 EIDAS-CTL-2) in EidasOperatorAttestationLoader, which holds the key name as EidasOperatorAttestationLoader.ConfigurationKey, reads it with no alias and no fallback, and gates EidasTrustedListLoader on the result. It stays distinct from Eidas:TrustedList:QtspAgreementPath, which is a QTSP agreement, not an operator attestation; that gate is unchanged and still fails with MissingAuthorisedQtspAgreement. The skeleton is at docs/legal/operator-attestations/eidas-operator-agreement-attestation.template.md.

How the gate behaves, and why the two failure shapes differ. An unset key means the attestation is absent: the loader returns operator-attestation-not-loaded and the runtime fails closed — an operator who never configured eIDAS must not get a startup crash. A set but unresolvable path throws (EidasEvidenceNotProductionReadyReason.UnresolvableOperatorAttestationPath) and never falls back to any other source, because degrading a named-but-missing custody artefact to “absent” is exactly the silent inference counsel prohibited; this is the same custody ordering CLAUDE.md §2.12 records for ReadSigningPrivateKeyPem. A file that is present but insufficient — unparseable, missing operatorId/attestedAt, dated in the future, or withholding any acknowledgement — fails closed to the negative state with the withholding reason carried in the diagnostic, which is counsel’s acceptance condition that “the reason for withholding the claim remains in the audit record”.

Wire format is a recorded assumption, not a settled question. The template proposes YAML and lists the format as pending counsel decision #4. The runtime parses JSON, matching every other eIDAS artefact it consumes and avoiding a new dependency through the BUSL licence gate. If counsel settles on YAML this is a parser swap, not a redesign.

Required acknowledgements (counsel-driven minimum content; per decisions/eidas-counsel-thread-canonical-model.md Round 1, Edit 4):

1. operator controls the QTSP relationship;
2. operator has rights to use the pack/evidence;
3. operator selected the QTSP/service;
4. operator accepts expiry/revocation duties;
5. operator will not claim Stella Ops is a QTSP;
6. operator is responsible for downstream qualified-service representations;
7. operator will preserve pack/evidence audit records.

Stella Ops never signs this file. The operator does. Stella Ops only consumes it, validates the seven acknowledgements, optionally validates an operator-side signature, and lets the runtime gate proceed.

6. Reversibility / triggers that reopen the canonical model

Per EXEC-20260504-...md “Reversibility” section + decisions/eidas-counsel-thread-canonical-model.md (Edit 5 in Round 2 + the optional hosted/managed-mode trigger), the canonical model must be reopened if any of the following changes:

• The law (eIDAS 2 implementing acts, Member State trusted-list rules, ETSI TS 119 612 versions).
• Stella Ops’ product claims, support model, or hosted/managed-service posture (e.g., Stella Ops later operates the eIDAS validation path on behalf of customers).
• The runtime claim-state vocabulary or loader behaviour.
• The operator attestation model.
• The third-party asset posture (e.g., partnering with a specific QTSP whose terms permit in-repo vendoring).

A reopening is performed by a new EXEC-YYYYMMDD-eidas-...md decision that supersedes EXEC-20260504. Until then, EXEC-20260504 is binding.

7. Counsel cycle status

The eIDAS lane has three counsel review threads of its own (a fourth, timestamp-specific one is noted below and is owned by the Evidence lane). All three had dispositive activity on 2026-08-23; each thread is a consolidated record covering its request, response, and applied disposition.

2026-08-23 thread activity:

• Canonical model — Round 3 (reply): “No material legal objection. Canonical model confirmed. Production emission of a positive claim state remains gated on the attestation implementation and claim-state correction.” Seven mandatory production controls; the claim-state rename in §4 above; the model is “not by itself a statutory safe harbour.” All seven controls landed on 2026-08-23 (SPRINT_20260823_001 EIDAS-CTL-1…CTL-6), plus the CTL-5 exposure guard. (Corrected 2026-08-23.) The thread’s “Pending implementation work” table records the pre-implementation measurement and carries a currency banner naming what has since landed.
• Vendor questionnaire — Round 4 (reply): questionnaire re-confirmed counsel-approved and held in reserve. This is approval of the document, not authorisation to engage a QTSP. “no legal action is currently pending. Product Management should leave the questionnaire and canonical implementation unchanged unless and until EXEC authorizes engagement with a named QTSP.”
• Licence text and customer agreement — ANSWERED 2026-08-23 (question, reply): counsel’s deferred licence question is now closed. No eIDAS amendment to the BUSL-1.1 body or its Additional Use Grant — BUSL is principally a copyright licence and obliges an adopter not to modify it in other ways, so an operator warranty or eIDAS indemnity is the wrong drafting mechanism there. But counsel did not clear the present arrangement: the operator-facing terms and Enclosure E do not, by themselves, create a sufficiently reliable contractual allocation, and the specified remedy is a versioned, binding eIDAS Operator Addendum incorporated into an instrument the customer affirmatively accepts. That addendum content is now drafted, inside the ruled instrument (Q-16, owner 2026-08-25): the full Customer Agreement exists as CUSTOMER_AGREEMENT.mdv0.1.0-draft (SPRINT_20260825_016 LRS-3) with the Operator Addendum content as Schedule 1 (counsel’s clause text verbatim) and the operator terms incorporated as Schedule 2; no interim standalone addendum is produced. The draft is pending counsel review. The contractual allocation remains UNSETTLED until a counsel-reviewed version of that agreement is affirmatively accepted — that is still the thing to read before telling anyone the eIDAS allocation is contractually settled. The separately-flagged licence defects (two inconsistent publications, Licensor identity, missing Change License) were all corrected 2026-08-23 and are guarded by licence-publications-verify.yml. Architecture confirmed legally supportable: the operator selects the QTSP, supplies the material, and Stella Ops distributes none of it.

Positive-state exposure and CTL-5 retirement rule (counsel reply §7E): before the CTL-5 exposure guard is narrowed or retired, every API, report, export, UI, or other external rendering that can carry a positive state must keep these three facts inseparable: counsel’s verbatim local validation disclaimer, the exact pack identifier, and the validation basis. The implementing sprint must record the new surface and prove by conformance test that no representation can emit the positive state while omitting any of the three. A consumer is not authorization to weaken the guard; it is the event that activates this replacement control.

A THIRD eIDAS-adjacent disposition landed the same day, owned by a different lane — read it before touching claim wording anywhere. decisions/timestamp-assurance-counsel-thread-claims-trust-and-retention-reply.md rules on RFC 3161 / eIDAS timestamp claims for the Evidence family (SPRINT_20260819_001 TA-6), not on this plugin. Two consequences reach across the boundary:

• It independently reaches the same conclusion as §4 above on the machine prefix: local-validation-against: approved, claimed-against: rejected by name, bare validated-against: also rejected. Two counsel threads disapprove the former string; this plugin now emits the approved vocabulary.
• It replaces, for Timestamp Assurance only, the REG-20260502 closed-gate sentence quoted in §4’s “Mandatory disclaimer”. That sentence remains this plugin’s counsel-cleared control under its own record — do not delete it here — but do not carry it into new timestamp surfaces.

The earlier rounds, closed 2026-05-04:

1. Canonical-model review — decisions/eidas-counsel-thread-canonical-model.md. Substantive review of the EXEC-20260504 reference-only canonical model. Two rounds; counsel affirmed the legal architecture (the four-role frame in §2 above). All counsel-driven edits applied. EXEC-20260504 header status is now APPROVED (restated 2026-09-15 by manufacturer-of-record instruction, SPRINT_20260825_016 LRS-19; the model is unchanged), previously APPROVED + COUNSEL-REVIEWED / LEGAL-MODEL-CONFIRMED. REG-20260502 wording block flipped to COUNSEL-APPROVED for the canonical-model wording only.
2. Vendor-questionnaire review — decisions/eidas-counsel-thread-vendor-questionnaire.md. Substantive review of VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md. Three rounds: vendor-independent Gate 3 → substantive reframe (which produced Loaders 1 + 2 in the runtime) → pre-forward sign-off. Counsel’s final verdict: “send it. No more substantive edits are needed.” The questionnaire is counsel-approved and held in reserve.

Conditional future counsel work (only fires under specific triggers; not currently pending):

• Vendor-specific Gate 3 review — fires only IF Stella Ops later partners with a specific QTSP. The QTSP would return terms (jurisdiction, profile, expiry/renewal, redistribution, confidentiality, no-mark-use, etc.); those terms come back to counsel for vendor-specific review before any vendor relationship lands. A new thread file decisions/eidas-counsel-thread-vendor-terms.md would be created at that time. Under EXEC-20260504 reference-only-no-vendoring, no QTSP is engaged, so this review is not currently pending. A new EXEC decision would be required to engage a QTSP.
• Reopened canonical-model review — fires only IF the law, product claims, support model, hosted/managed-service posture, runtime claim-state vocabulary, loader behaviour, operator attestation model, or third-party asset posture changes (see §6 reversibility triggers).

8. Engaging a candidate QTSP — how it works

Forwarding a vendor questionnaire / RFP / RFI to one or several candidate QTSPs is normal pre-sales activity. No contract, NDA, license, or payment is required for the act of forwarding or for receiving the candidate’s proposal:

• Compliance / Vendor Integration takes the counsel-approved decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md and sends it to one or several candidate QTSPs as cold outreach.
• The candidate returns a proposal: pricing, jurisdiction coverage, profile (RFC 3161 / CAdES-LTA / etc.), expiry/renewal cadence, redistribution model (Options A–D from the questionnaire), confidentiality requirements, marketing materials.
• An NDA may fire at this point if the candidate sends proprietary/confidential information that Stella Ops would ingest. NDAs are bilateral confidentiality, not licensing.
• Receiving multiple proposals lets Stella Ops compare candidates without committing to any.
• License / payment fires only when Stella Ops or an operator actually uses the QTSP’s qualified service in production.
• When Stella Ops decides to engage a specific candidate, that decision is itself a new EXEC under docs/legal/regulatory-asset-intake.md. The candidate’s terms then come back to counsel under the conditional vendor-specific Gate 3 review (§7 above).

In short: cold-emailing the questionnaire to three candidate QTSPs tomorrow is fine. Picking one and signing terms is what triggers the next legal cycle.

9. When a QTSP is selected — what engineering work follows

When (and only when) a future EXEC engages a specific QTSP, the engineering work that follows lands inside the existing crypto plugin tree, not as a new top-level plugin. Specifically:

• Trust-material wiring (most of the work) — operators receive the QTSP’s pack and configure it via Eidas:TrustedList:OfflineTrustMaterialPackPath. This is operator-side work; Stella Ops does not vendor the pack. The runtime (EidasTrustedListLoader.cs) consumes it.
• HSM / PKCS#11 wiring (if the QTSP uses an HSM) — the existing HSM plugin (StellaOps.Cryptography.Plugin.Hsm) consumes any compliant PKCS#11 module. PKCS#11 is the industry-standard interface; every credible QTSP HSM (Thales Luna, YubiHSM 2, AWS CloudHSM, SoftHSM2 for test, nCipher, Utimaco, Sansec / Yunsec for SM regions, CryptoPro / Rutoken for GOST regions) exposes it. Stella Ops does not need a per-vendor sub-plugin for the cryptographic operations — the existing HSM plugin works against any PKCS#11 module the operator points it at.
• Vendor-specific quirks (rare) — only if the QTSP has non-standard PKCS#11 extensions or proprietary protocols. These land as targeted code paths inside the eIDAS plugin (StellaOps.Cryptography.Plugin.Eidas), not as a new plugin.
• A truly new plugin is justified only if the QTSP uses a non-PKCS#11 protocol (proprietary REST API, custom appliance, vendor SDK that bypasses PKCS#11). Most serious QTSPs are PKCS#11-compliant; a new plugin is the exception, not the default.

This means: vendor selection does not bottleneck on per-vendor engineering. The expensive engineering — Loaders 1 + 2, the claim-state vocabulary, the fail-closed gates — is already done and is vendor-agnostic. What’s QTSP-specific is trust material, not crypto operations.

A vendor may also distribute their own SDK (typically wrapping their PKCS#11 module). Operators can use the vendor SDK directly if they prefer — Stella Ops will still consume the same PKCS#11 interface underneath, so the SDK choice is invisible to Stella Ops as long as PKCS#11 is exposed.

10. Operator workflow (when an operator deploys Stella Ops with eIDAS)

1. Operator selects a QTSP and signs a vendor agreement covering: jurisdiction, profile, expiry/renewal cadence, redistribution, confidentiality, no-claim-of-QTSP-endorsement, no-use-of-QTSP-marks.
2. Operator obtains the static trust-material pack from their QTSP and places it at the path configured by Eidas:TrustedList:OfflineTrustMaterialPackPath.
3. Operator authors their local attestation file based on docs/legal/operator-attestations/eidas-operator-agreement-attestation.template.md, populating the seven acknowledgements and (if counsel requires) an operator-side signature. Places it at Eidas:TrustedList:OperatorAgreementAttestationPath.
4. Operator wires the per-transaction evidence supply path: either (a) operator obtains timestamp / OCSP / archive evidence directly from the QTSP per release; (b) vendor supplies an operator-local appliance or batch channel; © vendor supplies periodic evidence bundles; or (d) operator validates only and embeds evidence already supplied locally. Path configured by Eidas:TransactionEvidence:RootPath.
5. Operator restarts the service. Runtime emits local-validation-against:<qtsp-pack-version> (or :historical-validation for the labelled historical-replay carve-out), together with counsel’s verbatim disclaimer, once all gates open. If any gate is shut, runtime emits the corresponding not-claimed:<reason> and the operator’s downstream consumers see no qualified-service claim attached to the output.
6. Operator’s own legal counsel reviews the attestation file and the workflow before any qualified-service claim is made to downstream parties. Stella Ops is not a substitute for that operator-side legal review.

11. What this posture does NOT cover

• Hosted, SaaS, managed-service, or Stella-Ops-operated validation / preservation / timestamping workflows. If Stella Ops later operates the eIDAS path on behalf of customers, EXEC-20260504 reopens (see §6 trigger).
• Non-eIDAS regulatory regimes (DORA, EBA, FIPS, GOST, SM) — tracked in their own intake records under docs/legal/decisions/.
• Vendor selection, QTSP commercial suitability, or specific vendor agreement terms — those land under future lawyer-request<N> cycles after a candidate QTSP returns terms.
• Stella Ops becoming or partnering as a QTSP. That would require a new EXEC decision plus a fresh counsel cycle.

12. Cross-references

• Customer-facing deployment flow (sales / customer success / customer’s IT-ops / customer’s compliance officer): dora-eidas-customer-deployment-flow.md— what’s per-customer (configuration), what’s per-product (counsel cycles, code), what’s almost never (per-vendor modules), common misconceptions, sales talking points.
• Binding decision: decisions/EXEC-20260504-eidas-reference-only-canonical-model.md
• Regulatory asset record: decisions/REG-20260502-eidas-qualified-provider-pack.md
• Real-pack ingestion runbook and synthetic-fixture guardrails: docs/modules/cryptography/eidas-qualified-provider-pack-ingestion.md
• Vendor questionnaire: decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md
• Operator attestation template: operator-attestations/eidas-operator-agreement-attestation.template.md
• Operator-facing terms (counsel control #7, the instrument that allocates responsibility to the operator): eidas-operator-terms.md— provider boundary, limitations, asset rights, operator responsibility, and the prohibition on representing Stella Ops as a QTSP.
• Answered counsel question on the licence text: decisions/eidas-counsel-thread-licence-text-and-customer-agreement.md — no eIDAS amendment belongs in BUSL; a versioned, binding, affirmatively accepted operator instrument remains required.
• Counsel cycle index: decisions/README.md §D
• Runtime architecture: docs/modules/cryptography/architecture.md§4.8
• Simulator/hardware separation (cross-cutting): docs/operations/simulator-and-hardware-test-separation.md§1.4
• Regulatory asset intake process: docs/legal/regulatory-asset-intake.md

Append-only history