Tables, variables, and referenced artifacts

This generalizes something already in the design: the fixings block WAS this pattern’s special case. An SCB index series is just an externally published lookup table with a trusted publisher. Promote the mechanism:

5.1 The artifact model

• Variable: a named, typed value (hourly rate, index cap, payment-days). Lives inline or resolves from a table.
• Lookup table: a keyed artifact - rate table (role -> rate), price list (article -> price), tier table (volume -> discount), calendar (working days - cadence and due within silently depend on one!), attest table (attestordning), index series (SCB). One mechanism for all of them.
• Reference, don’t inline: the contract binds art:kb-it-rates-2027 by content hash (git/IPFS-style addressing). Artifact versions are append-only, effective-dated, and resolve exactly like contract versions: every event evaluates against the artifact version in force at its effective date. Replay stays sacred.
• Binding modes: pin v2 (updates reach THIS contract only via amendment) or track latest-approved (updates flow automatically IF they passed the artifact’s own update rules AND the referencing contract’s declared bounds).

5.2 Self-governing updates (the “self-referencing thing”)

The refinement that makes it sound: an artifact carries its own update contract. Its header declares who may propose, who approves, the cadence (at-most 1 per year, window January), and the bounds (within index-clause cap). Which means an artifact IS a minimal mechanical contract whose single port is update.publish - same signatures, same receipts, same cadence machinery, same replay. Self-referencing, but bounded: artifact headers do not reference further artifacts’ governance (one level of turtles; boring wins).

The payoff of governed updates: an update that violates cadence or bounds cannot become a version - it is rejected with a receipt like any other malformed event. “The supplier quietly raised the rate table in March” stops being a forensics finding (the drift thesis: an update-time rejection instead of an invoice-time one) and becomes a door that does not open.

5.3 Shared artifacts - the network effect in data form

One rate table referenced by MANY contracts is the Adda reality: a national ramavtal’s prisbilaga as ONE artifact, referenced by hundreds of kommuners’ call-off contracts. The center updates it once, under its declared governance; every referencing contract picks up the version per its own binding mode and bounds. The Adda-corpus moat becomes literal shared infrastructure - and whoever hosts the artifact registry sits at the middle of it.

5.4 Prior art (grounded against existing sources)

• Legal: incorporation by reference is ancient practice - standardavtal (AB 04), the ISDA Definitions booklets (versioned external artifacts entire markets reference), every prisbilaga ever attached. Contracts have always referenced external tables; none carry a hash, none govern their own updates at runtime.
• Swedish e-commerce: SFTI’s original- och ersättningsprislista + Peppol Catalogue - electronic price-list updates are already standardized here. The gap is exact: catalogues update the buyer’s ERP, not the agreement - nothing machine-checks an incoming price update against what the contract permits (cadence, window, bounds, approval). We close that loop.
• Finance: rate fixings publication (SCB series, the LIBOR->SOFR apparatus) - trusted-publisher tables with governance, the strongest cultural precedent for “a table whose updates follow declared rules”.
• Tech: content-addressed storage (git, IPFS) and reference-data/master-data management. Solved plumbing, consumed as-is.

The novel bit, once more, is the closing of the loop: the table is governed BY the contract that consumes it - update cadence, bounds, and approval as signed, executable terms.

5.5 Trust anchors: how a referenced artifact is believed

A signature on the data itself is better still - the two are not alternatives, they are a hierarchy, and only one of them survives replay:

1. Data-level signature (the goal). The publisher signs the artifact ITSELF - an eIDAS qualified seal on the price list, the index series, the register (XAdES for XML, JAdES for JSON payloads). The signature travels with the data: it survives mirroring, caching, re-hosting, and decades of archival, and verification is offline and deterministic. This is the only trust model compatible with the replay covenant - a TLS session cannot be re-verified in 2035; a sealed document can.
2. Transport-level + ingest attestation (the fallback, today’s reality). Where the publisher does not seal (SCB does not seal its series downloads), the platform fetches over HTTPS with certificate pinning and appends a signed ingest attestation event: fetched series X from URL Y at time T, TLS certificate Z, content hash H - trust shifts to the platform’s ingest process, explicitly and auditably. Weaker, named as weaker.
3. Unsigned, unpinned = a declared risk. A contract MAY reference an unattested source, but the linter flags it and the reference carries trust: none visibly. No silent trust.

Rule of the log: store artifacts + their signatures, never URLs alone. A URL is a place; an artifact is a hash. And the ecosystem push follows: the artifact registry should require publisher seals for public publications - “the publisher-signed price list” is to tables what Peppol was to invoices, and the sealing burden is one signature at publish time.

5.6 Artifact classes (public list vs contract bilaga - both, distinctly)

Class	Example	Signed by	Governance
Public publication	SCB index series, F-skatt register, sanction lists	the publisher (seal) - or ingest-attested (5.5)	publisher’s own; contracts consume as fact-source (the fixings case)
Contract appendix (bilaga)	prisbilaga, SLA annex, rate table	the CONTRACT’s parties - part of the Ricardian bundle, hashed with the prose	the update contract of §5.2 (cadence, bounds, approval)
Shared framework artifact	Adda ramavtal price appendix	the framework holder (central purchasing body)	framework’s governance; hundreds of call-off contracts pin/track it (§5.3)
Party-maintained register	attestordning (buyer’s), approved-subcontractor list (supplier’s)	the maintaining party	declared in its header; counterparty gets a receipt on every change

Same reference mechanics for all four (hash, versions, effective dates); what differs is who signs and whose rules govern updates. A contract’s artifacts: block states the class of each reference, so trust is readable off the manifest - just like capabilities are readable off the ports.