Q-16 settlement record — how the Customer Agreement came to exist
Audience: anyone who needs the provenance of
CUSTOMER_AGREEMENT.mdwithout reading a sprint ledger — customers’ advisers, auditors, future engineers, and the Licensor’s own support and sales. Status: live and citable. This document is the durable receipt for the Q-16 settlement.Why it exists rather than a link to the sprint. The work was executed in a sprint ledger, and sprint ledgers are archived once their rows close. A released, digest-pinned contract cannot cite a path that later moves, and product documentation should not send a reader into a frozen archive to find out why the instrument they are being asked to accept exists. So the substance lives here, in
docs/, and this file does not move.
What was ruled, and by whom
Q-16 (owner ruling, 2026-08-25): full-customer-agreement-now. The commercial instrument is a single versioned Customer Agreement that a customer affirmatively accepts — covering governing law, disputes, liability, withdrawal, merchant-of-record, confidentiality and support-data terms — with the eIDAS operator terms incorporated as a versioned schedule. No interim standalone addendum was produced, because no eIDAS release date required one and counsel had recorded that an addendum alone would not cure the missing governing-law, liability and support-data terms.
Q-17 (owner ruling, 2026-08-25): remove-until-instrument-exists. Until the instrument existed, no public surface could state that a “Stella Ops Commercial Licence/EULA” exists. That prohibition survives the instrument’s issue, because what issued is the Customer Agreement — no document by the prohibited name exists now either. What changed is that surfaces may name the Customer Agreement.
Both rulings came from the manufacturer of record. The eIDAS model they sit on top of (reference-only-no-vendoring) was settled separately and is unaffected by anything here.
What the instrument is
CUSTOMER_AGREEMENT.md, issued at 1.0.0 on 2026-09-16 by the manufacturer of record (adoption record).
- Counsel’s eleven-section minimum contractual content.
- Counsel’s Operator Material clauses, carried character-for-character, as Schedule 1.
- The eIDAS operator terms as Schedule 2, identified inside the Agreement by version and full SHA-256, so the second half of the package cannot change after acceptance without the identification failing loudly.
- A per-version, SHA-256-anchored affirmative acceptance record (§11).
Issued versions and both halves’ digests are recorded in customer-agreement-versions.sha256, and the released copy is retained byte-identically in the release bundle. An automated gate asserts both, and inverts its assertions for draft versions so it is load-bearing before and after issue rather than dormant.
Review provenance, in the terms this repository defines
The labels have defined meanings in decisions/README.md, and they are used strictly here because they were once used loosely.
| What happened | |
|---|---|
ASSESSED | Two substantive review rounds of the complete operative text, 2026-09-15. Round 2 found the principal architecture sound and the liability-cap defect cured, while declining to issue the then-current draft. Every finding it raised was applied. |
COUNSEL-REVIEWED | Not claimed. No named, identified legal professional has reviewed the operative text, and the round-1 reviewer expressly declined to be recorded as satisfying that criterion. |
ADOPTED | The manufacturer of record approved 1.0.0 for release on its own authority, 2026-09-16. |
A precondition this repository invented and then withdrew. Release was treated for two weeks as requiring a signed opinion of a qualified Bulgarian advocate. That came from misreading a reviewer’s note about what their own document was as a rule about what the agreement needs. Counsel corrected it: “My earlier statement that I was not providing a signed advocate’s opinion did not mean that such an opinion is generally a statutory precondition to forming an ordinary B2B software agreement.” The general lesson — a provenance caveat is not a legal precondition — is recorded in decisions/README.md, and professional-signoff governance is kept out of the instrument as an internal choice.
Owner decisions inside the instrument
Counsel left these to the owner rather than deciding them. Each is recorded in the adoption record with its reasoning and residual risk.
- §7.2(d) is mutual, not Licensor-only. An earlier asymmetric draft was withdrawn before issue: an asymmetric limitation in a B2B instrument is the most challengeable shape available, and it widened the Customer’s exposure under an indemnity counsel already described as broad.
- §7.2(e) preserves loss of profit that is a direct consequence of breach, so §7.2(d) is not a blanket lost-profits exclusion.
- §7.2(f) keeps the Schedule 1 clause 9 indemnity uncut by §7.2(d) — an indemnity is a primary obligation to meet defined third-party claims, not a damages claim between the parties.
- §7.2(b) counts separately priced support toward the liability cap’s fee base, so a support-paying customer is not left with a cap of zero.
- §7.2© states the zero-cap case expressly for free and evaluation use, keyed to the fee base, subject always to §7.3 and mandatory law.
- §12.2 notices are receipt-based on counsel’s recommendation, with §12.3 defining two narrow anti-avoidance exceptions.
What is deliberately not settled by this instrument
- Copies already distributed. §2.1a states that nothing in the Agreement determines which licence governed a copy of the Licensed Work delivered before acceptance. That question is handled separately, on its own evidence, and no recipient is recorded as having accepted anything by having pulled an image.
- Acceptance mechanics in a checkout or merchant flow. The model is settled; the implementation and its evidence are a separate body of work, and it must produce merchant-agnostic obligations templates rather than anything scoped to one payment provider.
- Issue is not acceptance. 1.0.0 may be presented to a customer; it becomes operative against that customer only on affirmative acceptance under §11. Until a customer accepts, support must not request customer logs or evidence without a separately documented confidentiality or data-protection basis (§8.2).
Where the underlying records live
All of these are live documents in docs/legal/:
decisions/README.md— the file-level audit trail and the label definitions.decisions/EXEC-20260916-customer-agreement-1-0-0-adoption.md— the adoption decision, its reasoning and its residual risks.decisions/customer-agreement-counsel-thread-draft-review-reply.mdand round 2 — the two review rounds.decisions/eidas-counsel-thread-licence-text-and-customer-agreement-reply.md— the section plan and the Operator Material clauses that became Schedule 1.eidas-qtsp-posture.md— the eIDAS narrative and its dated history.eidas-operator-terms-internal-record.md— the review provenance behind Schedule 2, kept out of the incorporated contract on counsel’s instruction.