Outage notice — six daily prints never produced (2026-08-25 → 2026-08-30); test window paused

Notice date: 2026-08-31 (UTC) Class: gap of record + process notice. No methodology changes: no formula, panel, series or assessment is touched by this notice. No published value changes. Instrument: none individually — the daily edition itself. Every series that prints with the daily cycle has no values for the six dates below. Effective: 2026-08-31 — the resumption print. The gap dates themselves are records of absence, not of change.

1. What failed

From the 2026-08-25 cycle to the 2026-08-30 cycle, every scheduled Daily Scrape & Report run failed at its test gate before a single scraper ran. Root cause, stated plainly: the test suite that gates the scrape includes upload-lane tests that execute dashboard code under node and require the dashboard's node dependencies (unpdf, mammoth), and the workflow never installed them. The gate exited non-zero, the run stopped, nothing was collected, nothing was printed, nothing was committed. Six cycles in a row.

The production site was unaffected in function — the deployed upload lane bundles its own dependencies — but froze at print No. 111 (2026-08-24), the last edition produced.

The fix is in the workflow, not the tests: the daily and nightly workflows now install the dashboard node dependencies before the gate. The tests stand unweakened — they gate real coverage, and they did exactly what a gate is for: they stopped the pipeline loudly instead of letting it print on an unverified path.

2. The six prints never produced

Nothing is backfilled — ever. A print of record is what the machine saw at print time; first-sight custody makes a retroactive print impossible by design (the observations were never collected, so there is nothing honest to print). The gap is itself data. Each date is filed as a gap of record (reason code print_missing, the 2026-08-06 precedent) in the corrections registry; /api/print/<date> for these dates answers 404 with the gap record attached, and the archive lists only editions that exist.

3. Resumption and numbering (founder ruling)

The resumption print is No. 112, dated 2026-08-31 — its actual production date. The six dark days' numbers are never consumed: the issue sequence resumes directly after No. 111, so the numbered record remains an unbroken sequence of editions that actually exist. (This differs from the 2026-08-06 gap, where the date-derived number 93 was consumed by the missing date; from this notice forward the sequence counts editions, and a missing date consumes no number.)

4. The 60-day test window is paused (founder ruling)

The observation window (2026-07-25 anchor, 60 days) is paused for the six dark days: its end extends 2026-09-22 → 2026-09-28, and the masthead day counter resumes at Day 31 on 2026-08-31, directly after Day 30 (2026-08-24). Dark days do not consume window days — the window measures observation, and none occurred.

5. Internal checks reset against the outage, not against the restart

The six dates are declared as a dated break in the invariants' declared-break register (data/methodology_breaks.json, the 2026-07-24 precedent mechanism) for the four volume-checked tables. Volume baselines restart at the break; the continuity window is floored at it. Checks scoped to the report date itself (freshness, the narration gate) are not relaxed — a real absence on any restarted date remains a loud failure.

6. Where this is stated

• This notice, permalinked at /standards/notices/2026-08-31-pipeline-outage-and-window-pause.
• The gap records: docs/corrections/2026-08-31-pipeline-outage-missing-prints.md, served inline by /api/print and listed at /standards/corrections.
• The archive states the count of gap dates beside its edition count.

Process notice — check demand telemetry: the shape of what was asked, never the content

Notice date: 2026-08-25 (UTC) Class: process disclosure (data collection on the /check surface). Not a methodology change to any instrument — no print, level, series or assessment is touched by this notice. Instrument: none. The check_events counter (migration 044) gains optional shape columns (migration 045); no published series reads from them. Effective: from the first deployment carrying this notice — and materially only after the founder applies migration 045 via the audited runner. Until then the shaped write fails soft to the legacy content-free row, so nothing new is recorded. Publish-before-effect (decision of record 2026-07-24 §2) is satisfied: this disclosure ships in the same commit as the code and the migration file, and precedes any shaped row existing.

1. What is recorded

On each check run at /check (or through the MCP check_quote tool), The Grid records only the shape of what was asked:

Every field is a closed vocabulary. Never recorded: the paste, any price, any free text, any off-registry model string, any IP address or identifier. An off-registry accelerator records as empty — the raw string is free text and never leaves the read.

2. Why

The register of what buyers ask to check — which classes, which terms, which regions, and whether the read could answer (n0 / thin / above-floor) — is the honest demand signal for what The Grid should build cover for next (DIRECTION.md: "gates are curricula" — every unanswerable check is a signal about what to extend). Recording the shape and refusing the content keeps the standing promise on the surface true: a check stores nothing you pasted unless you explicitly confirm storage.

3. The checks-run counter

A running count of checks renders near the check control only once 25 total checks have been run — below that floor nothing shows, and where the counter renders, the floor is stated beside it. The floor exists for the same reason the aggregate floors exist: a count of three is a disclosure about three visitors, not a statistic.

4. Where this is stated

• On /check, beside the check control: "we record what was asked for — model class, term bucket, coarse region, whether the read could answer — never what you pasted."
• This notice, permalinked at /standards/notices/2026-08-25-check-demand-telemetry.
• The column vocabularies are constrained in the database (migration 045 named CHECK constraints) and defined once in the app layer (dashboard/lib/check-core.ts telemetryShape).

Methodology change notice — watch-condition thresholds recalibrated to observed distributions

Notice date: 2026-08-21 (UTC; all dates in this notice are UTC) Class: methodology change (watch-condition thresholds). Not a correction — no published value is restated, and no alert already sent is withdrawn. Instrument: watch conditions on dram_spot_pct (DDR5 16Gb 30d and 60d windows) and gpu_rental_pct (GAP-H100 matched-pair 7d window) Effective: the first daily evaluation after the founder applies the retune (scripts/retune_watch_conditions.py --apply), no earlier than 2026-08-22. Publish-before-effect (decision of record 2026-07-24 §2) is preserved: this notice is dated and published before any evaluation the new thresholds govern. Alerts already recorded stand as sent. Rule pack: v1.1.0 unchanged; R-CALL-001 queued (data/governance/QUEUE.md) for the next founder-ruled bump.

1. Why — both live DDR5 thresholds are miscalibrated, in opposite directions

The evidence of record (stored series through 2026-08-19/20):

• The 30-day ±15% condition never fired in 71 observable windows. The observed maximum absolute 30-day move is +12.16% (2026-06-25/26) — the threshold sits above everything the series has ever done. A tripwire that cannot trip watches nothing.
• The 60-day ±15% condition fired 25 recorded times (2026-07-23 → 2026-08-19) and sits below the observed median (18.78%): 39 of 41 observable windows exceed it. A tripwire that is always tripped alerts on nothing.

Both defects have the same cause: the thresholds were set by judgment, not from the observed distribution of the series they watch.

2. The method

Proposed threshold = the nearest-rank 90th percentile of the observed absolute window-move distribution over the full stored history, rounded to the nearest 0.5 point, ties toward the more sensitive (lower) threshold. GAP windows are chain-linked across declared methodology breaks (data/methodology_breaks.json) so panel re-base echoes never enter the distribution. Rationale: a watch condition should fire on roughly the top decile of observed moves — rare enough that an alert carries information, frequent enough that the condition is demonstrably alive.

3. The arithmetic and the new thresholds

GTS-1Y 7d ($-delta): p90 $0.24 vs threshold $0.25 — the one well-calibrated condition, and moot: the series suspends from 2026-08-22 and the condition was deactivated by founder order 2026-08-16. No change.

GAP caveat, stated plainly: the GAP distribution is bimodal on a thin two-pair panel — most windows are exactly 0.00% (posted prices static) and the tail is violent (a single vast.ai cluster swing moves the pair median double digits). The ±14% threshold is honest to the observed record but should be recalibrated once the 2026-08-28 panel transition (notice 2026-08-20-panel-admission-and-benching) has 30 observed days on the lambda/hyperstack panel — a further dated retune, not a quiet edit.

4. Mechanism

A threshold change is a new condition row; the old row is deactivated with a dated label annotation, so watch_alerts history stays tied to the exact spec that fired each alert. The seed fallback mirror (data/context/watch_conditions_seed.json) is rewritten to the post-retune live rows in the same apply. scripts/retune_watch_conditions.py — dry-run by default; --apply is founder-run.

5. Conditions are encoded at issue (standing rule, R-CALL-001 candidate)

The defect class behind this notice's second finding: the founding call was issued 2026-05-05; its first watch-condition rows were created 2026-06-11 — a 37-day window in which the call had no encoded tripwire at all. From this notice: every active call carries at least one watch-condition row created on or before its issue date. The nightly auditor check call_conditions_encoded enforces this from 2026-08-21 (the founding call's late encoding is the recorded incident, exempted by date, never repeated). R-CALL-001 is queued in data/governance/QUEUE.md for the next rule-pack bump; the durable fix (a call_id linkage column on watch_conditions) is noted there as an additive migration candidate.

6. Record

• Evidence: distribution analysis of dram_spot_pricing (DDR5/16Gb, 101 print dates 2026-05-10 → 2026-08-19) and gpu_pricing (H100 SXM benchmark panel, chain-linked matched-pair, 62 windows) — session output docs/session-outputs/2026-08-21-discovery-loops.md.
• Apply script: scripts/retune_watch_conditions.py (founder-run --apply).
• Auditor: nightly check call_conditions_encoded (from 2026-08-21).
• Governance: call-graduation mechanism docs/decisions/2026-08-21-call-graduation-governance.md.

Methodology change notice — GAP panel admission & benching; RunPod bench scheduled 2026-08-28

Notice date: 2026-08-20 (UTC; all dates in this notice are UTC) Class: methodology change (panel composition rule). Not a correction — no published value is restated. Instrument: gap_h100_spot (GAP-H100 spot; indicator class since notice 2026-08-14 §2) Effective: 2026-08-21 — the first print after this notice. Publish-before-effect (decision of record 2026-07-24 §2) is preserved: the notice is dated and published before any print it governs. History through 2026-08-20 stands as published. Rule pack: v1.1.0 (R-ADMIT-001; changelog 2026-08-20).

1. The admission rule

A GAP spot-panel leg must be, from the effective date:

1. A bookable or executable ask — a price a buyer can act on, not a brochure number. The basis of every registered leg is stated in the registry and on the provider register.
2. Fresh — a member leg whose price is unchanged for ≥ 14 consecutive days is BENCHED automatically. The threshold is proposed from the stored record (2026-06-12 → 2026-08-19, the reliable-label era): the executable-ask leg's longest unchanged run is 3 days; the posted leg (RunPod) has been unchanged for its entire stored life (first row 2026-05-10; 99 days on the 2026-08-19 provenance stamp). Fourteen days is twice the 7-day static threshold and 4.6× the live leg's historical maximum — a leg unchanged two weeks is a list price, not a market. An explicit future-dated bench in the registry (a scheduled bench) is itself a dated registry event and supersedes auto-bench until it binds: the leg remains a member, with its unchanged-days disclosed on every stamp, until the scheduled date arrives.
3. Qualified — a new leg passes a qualification window of 7 consecutive clean collection days before first inclusion. Admission on window completion is automatic; the admission date is a dated registry event. (The same shape as the OCPI 7-api-day qualification.)
4. Reliability-floored where the source exposes one — vast.ai offers enter only at reliability ≥ 0.95 (in force at ingest since methodology v3); sources with no exposed reliability signal carry that absence on their registry basis line.

Benched and qualifying legs keep being collected. Their rows are stored, shown on the provider register with the disposition and reason, and carried on the provenance stamp ("excluded from panel: …") — they never set the level and never count toward the minimum-observation rule (notice 2026-08-16). A panel reduced below the min-obs floor by benching withholds; it does not quietly re-admit a dead leg.

The registry is defined once and mirrored (scripts/velocity.py GAP_PANEL ↔ dashboard/lib/velocity.ts GAP_PANEL). From the effective date an unregistered provider's rows never enter the panel — admission is a dated registry event, never row arrival.

2. RunPod: bench scheduled for 2026-08-28

RunPod's posted, stock-gated list price has not changed in any stored cycle — ever (first row 2026-05-10; 99 days unchanged on the 2026-08-19 stamp; flagged static on every provenance stamp since the stamp existed). Stated plainly: auto-bench alone (§1.2) would bench RunPod at the effective date — on 2026-08-21 its unchanged-days count is already many times past the 14-day threshold. The founder instead schedules the bench for 2026-08-28 (ruling 2026-08-20) — the earliest date the replacement legs (§3) can complete their qualification windows — so the panel never thins below two members while the replacements qualify. The scheduled bench is an explicit future-dated registry event (benched_from: 2026-08-28, both runtimes) and supersedes auto-bench during the transition (§1.2); disclosure is continuous meanwhile — every print's provenance stamp carries RunPod's unchanged-days, exactly as it has since the stamp existed.

From 2026-08-28 collection continues untouched, the register and the stamp carry "runpod BENCHED", and the GAP level is computed without it. Published history is not revised. Reinstatement is a dated registry event requiring the leg to move again (a changed price resets the unchanged-days count the rule reads).

Consequence, stated plainly: no withheld streak is expected from this benching. RunPod remains a member until 2026-08-28 — the first date lambda and hyperstack (§3) are eligible for admission on completed qualification windows — so panel depth never decreases at the transition. The minimum-observation rule still governs each day on its own terms (a day fewer than two members contribute withholds — the rule working, not an outage). If qualification slips — a broken collection day resets a 7-consecutive-clean-day window — the scheduled bench date is amended by a further dated registry event before it binds; the bench never fires into a panel it would thin below two.

3. New qualifying legs

Registered QUALIFYING with collection from 2026-08-21 (first eligible after 7 consecutive clean collection days, i.e. 2026-08-28 at the earliest):

Thunder Compute is refused panel wiring (2026-08-20): its T&C (read of record data/governance/tos/thundercompute-terms-2026-08-20.txt; terms last updated 2025-05-21) bars systematic retrieval, automated collection, and commercial republication without written permission. It is not in the registry.

4. Deltas and downstream

The level is the panel; from the effective date the GAP like-for-like change also excludes non-member legs (the change measure matches the panel that prints the level). The GPI GPU-rental factor is unchanged (index-history continuity — it reads the full matched-pair basket, as it always has). The print's day-over-day delta remains composition-EXPOSED by construction; benching is a composition change and the narration gate carries it as such ("panel re-composition, not repricing").

5. Notice period, and the deviation it represents

One cycle (notice 2026-08-20 → effective 2026-08-21), against the specification's longer guidance, on the reasoning of notices 2026-08-14 §4 and 2026-08-16 §3: zero external subscribers, and no contract or ledger entry references the series. From the effective date the rule itself binds — the registry closes to unregistered rows, auto-bench is live for every leg without a scheduled event, and the qualification windows open. RunPod's own application is the scheduled event of §2: the founder weighs the disclosed static price (named, with its unchanged-days, on every stamp) against panel depth, and holds depth — the panel never thins below two while the replacement legs qualify, and the static condition stays disclosed on every print in the transition. If the deploying merge misses the 2026-08-21 cycle, the first governed print is 2026-08-22 — the effective date is a floor, never retroactive.

6. Record

• Rule: R-ADMIT-001, rule pack v1.1.0 (data/governance/rule_pack.json; changelog line 2026-08-20).
• Registry: scripts/velocity.py GAP_PANEL ↔ dashboard/lib/velocity.ts GAP_PANEL (parity-tested).
• Scheduled bench: founder ruling 2026-08-20 — RunPod benched_from: 2026-08-28 (rescheduled from 2026-08-21 to the earliest replacement-leg qualification date; panel depth never decreases; a further dated event amends the date if qualification slips).
• Evidence for the 14-day threshold: unchanged-run analysis of gpu_pricing H100 SXM benchmark rows 2026-06-12 → 2026-08-19 (vast.ai max run 3d; runpod run = entire span).
• Surfaces: provenance stamp ("excluded from panel: …"), /providers disposition badges and register roles, /api/print provenance (additive field excluded), specification page panel table.
• Auditor: nightly check panel_admission (from-effective-date, date-parameterised).

Methodology change notice — the normalisation ladder: rungs 1–3 published as reference, rung 4 declined

Notice date: 2026-08-20 (UTC) Class: methodology publication (reference surface). Not a correction — no published value is restated, and no new printed series is created by this notice. Instrument: none — the ladder is a reference surface. The existing series it touches (gap_h100_spot, the token_pricing collection behind RWI) are unchanged in method, class and print discipline. Effective: 2026-08-20 — on publication. Publish-before-effect (decision of record 2026-07-24 §2) is satisfied trivially: the ladder governs no print, sets no level, and feeds no downstream series; it can therefore take effect the day it is published.

1. What is adopted

The Grid publishes the normalisation ladder — the four denominations in which the market quotes the price of compute, each rung stated with its own honesty furniture, as a directional reference surface:

$/MW  ──▶  $/GPU-hour  ──▶  $/M-token  ──▶  $/task
 (1)          (2)             (3)            (4)

The ladder is not an assessment and not a set of assessments. No rung creates a derived_series row, no rung prints a daily value, and no conversion between rungs is published as a factor with a level. Each arrow between rungs hides a conversion factor (power density and PUE; throughput for a named model under named conditions; tokens per task, which varies on the order of 2× between models) that nobody publishes under controlled conditions today — the surface states each factor's status honestly rather than collapsing the chain into one number.

2. The four rungs and their dispositions

3. The rung-4 declination

The Grid declines to publish a $/task figure, for stated reasons:

1. Task definitions are not standardised. There is no governed, market-accepted definition of "a task" to price. A price for an undefined deliverable is not a price.
2. Task benchmarks are gameable. Where task suites exist, they are optimisation targets; a $/task print built on them would inherit their drift without inheriting any governance.
3. A $/task print would be false precision. Tokens-per-task varies on the order of 2× between models on the same work; any single $/task number silently embeds a model choice and presents it as a property of the market.

The rung is declined until the market defines the unit: a standardised, independently governed task definition — submission, peer validation, publication under rules — would reopen the question by a further notice. The declination follows the same reasoning as the existing refusal to score capability (the y-axis saturates; capability is not a ratio scale and cannot be divided by).

4. Benchmark-source compliance

Two third-party benchmark sources sit adjacent to the ladder. Their terms govern what renders:

• MLPerf® (MLCommons). Named on the ladder only as the anchor of record for the GPU-hour → token conversion (audited, controlled-conditions, hardware-specific results). The Grid republishes no MLPerf result figures and makes no performance-per-watt claims (official MLPerf Power results are the only permissible basis for any future efficiency claim, and none is made). Every rendered reference uses the ® mark and carries the MLCommons trademark attribution footnote. Where a citation is in doubt, the ladder cites less.
• Artificial Analysis. Its terms of service bar scraping; its Data API free tier is licensed for internal use only. No AA-derived value renders on any public surface until a commercial-tier licence is purchased: every cell a licensed AA feed would fill renders [gap: licence pending] — the gap is displayed, not hidden. The collection path exists only as an environment-gated stub (scrapers/artificial_analysis.py: requires AA_API_KEY and an explicit AA_LICENCE_TIER; the publication path refuses to run unless the stated tier is Pro/Commercial). The stub is not registered in the daily pipeline.

No new scraped source enters with this notice (R-SRC-001 applies): OpenRouter and DeepInfra are the existing, ratified collection; MLPerf and Artificial Analysis are cited-or-gated, not ingested.

5. Record

• Decisions of record: founder rulings 2026-08-20 — (a) the ladder adopted as a directional reference surface with rung 4 declined; (b) MLPerf strict messaging compliance and Artificial Analysis publication gated on a paid licence.
• Surfaces: /normalisation (the ladder), /normalisation/mw, /normalisation/gpu-hour, /normalisation/token, /normalisation/task; masthead navigation entry.
• Rendering definitions: dashboard/lib/standards/ladder.ts — renders this notice's content; the notice, not the file, is the document of record.
• Rule pack: unchanged at v1.1.0. The two compliance rules in §4 are queued in data/governance/QUEUE.md as candidates for the next founder-ruled version bump.
• The token_pricing collection, the RWI paths built on it, and every existing instrument specification are unchanged.

Methodology change notice — provenance stamp: first stamped print of record (clarification)

Notice date: 2026-08-17 (UTC; all dates in this notice are UTC) Class: clarification of record (rule pack v1.0.0 → v1.0.1). Not a methodology change — no method changes and no notice period runs. Not a correction — no published value is restated and no print body is edited. Instrument: gap_h100_spot (GAP-H100 spot; Class 3 indicator since notice 2026-08-14 §2) Effective: on publication, 2026-08-17. The record clarified below concerns the 2026-08-14 → 2026-08-16 prints and is stated as it happened; nothing binds earlier than it was published. Rule pack: R-PROV-001 effective_date 2026-08-14 → 2026-08-16 (data/governance/rule_pack.json v1.0.1, CHANGELOG.md 1.0.1). Notice 2026-08-14-instrument-actions.md is not edited.

1. What this clarifies

Notice 2026-08-14 §3 declared that every GAP-H100 spot print "now carries" a provenance stamp — panel size, offer count, the contributing providers with each provider's unchanged-days and price, transaction count, data tier, judgment applied, and the one-line stamp string — written into the print of record at print time, with the stamp taking effect on publication (disclosure only, no notice period).

The code that writes the stamp (scripts/compute_gap_print.py, commit 7acf434, branch fix/gts-suspend-and-disclose) reached main in merge 34b01ae at 2026-08-16 02:16 UTC, after the 2026-08-15 cycle had printed. Consequently:

• the 2026-08-14 and 2026-08-15 prints of gap_h100_spot carry no stamp — the store holds no provenance object for either day and /api/print/2026-08-14 and /api/print/2026-08-15 serve provenance: null, exactly as the rule's own last sentence requires of pre-stamp prints;
• the first stamped print of record is the 2026-08-16 cycle (printed 2026-08-16 18:30 UTC anchor), and every print from that cycle carries the full stamp.

The nightly auditor (scripts/nightly_audit.py, check print_of_record) reported the two unstamped prints as a breach on its first run (data/audit/nightly/2026-08-15.md, run 2026-08-16 11:33 UTC) — the rule pack v1.0.0 carried the notice's publication date, 2026-08-14, as the effective date. That report stands as written.

2. Resolution — by record, never by editing records

Founder ruling 2026-08-17: the print bodies for 2026-08-14 and 2026-08-15 are untouched. A stamp is written at print time from the panel as it stood at print time; synthesising one afterwards would be a retroactive fabrication of provenance, which R-PROV-001 itself forbids ("pre-stamp prints serve provenance as null, never synthesised retroactively"). The two prints stand as published on their day's method, provenance null, immutable under /api/print (R-API-001).

The record is corrected on the rule side instead: R-PROV-001 effective_date is set to 2026-08-16, the first print that actually carried the stamp. This is a PATCH-level change to the rule pack (v1.0.1) — what the rule requires is unchanged; only the date from which the auditor enforces it moves, to the date the requirement was in fact met. From v1.0.1 the auditor treats 2026-08-14 and 2026-08-15 as pre-effective and enforces the stamp on every print from 2026-08-16.

3. Publish-before-effect

ADR-003 §2 (publish before effect) is not breached by the stamp: it is a disclosure that adds information to a print without changing any printed value, declared before the first print that carried it. What went wrong is narrower — a notice stated a disclosure was live two cycles before the deployment that made it live. This clarification records that gap dated, on the notices rail, where the original statement lives; the original notice is left as written so the record shows both.

4. Record

• Ruling: founder, 2026-08-17 — "provenance-stamp breach, resolved by record, never by editing records: print bodies for 08-14/08-15 are untouched. Set R-PROV-001 effective_date to 2026-08-16 (first stamped print = the 08-16 cycle). Bump rule_pack.json to 1.0.1 + CHANGELOG line. File a short dated clarification as a NEW notice entry (do not edit notice 2026-08-14)."
• Deployment of record: merge 34b01ae (2026-08-16 02:16:23 UTC) carrying 7acf434 ("per-print provenance stamp for GAP-H100", founder ruling C, 2026-08-14).
• First stamped print: gap_h100_spot 2026-08-16 (/api/print/2026-08-16).
• Auditor report of the two unstamped prints: data/audit/nightly/2026-08-15.md.
• Companion: 2026-08-14-instrument-actions.md §3 (the stamp), docs/api-print-v1.md (provenance field; null on pre-stamp prints).

Methodology change notice — minimum-observation rule for GAP-H100 spot (decision)

Notice date: 2026-08-16 (UTC; all dates in this notice are UTC) Class: methodology change (publication rule). Not a correction — no published value is restated. Instrument: gap_h100_spot (GAP-H100 spot; Class 3 indicator since notice 2026-08-14 §2) Decision: the rule proposed in 2026-08-14-gap-minimum-observation-proposal.md is adopted unmodified (founder ruling 2026-08-16). Notice period: five business days, 2026-08-17 → 2026-08-21. Effective: the rule binds from the 2026-08-22 print — the same date the GAP-H100-R1Y and GTS-1Y suspensions bind (notice 2026-08-14 §1). Prints through 2026-08-21 continue under the current method with the provenance stamp and indicator class disclosing the condition. Build: follows the notice period. Nothing in the print path changes with this notice; the disclosure of the pending change rides with the series from publication (§4).

1. The rule, as adopted

The daily GAP-H100 spot print is withheld — not published — when either condition holds at print time:

1. Panel floor — fewer than two contributing providers on the day (the Baltic Asia-variant publication floor adopted in spec Part C4); or
2. All-static panel — every contributing provider is static by the unchanged-days measure computed daily in gap_h100_panel_health(): each contributor's price unchanged for ≥ STALE_PROVIDER_DAYS (7) consecutive days.

Wording, thresholds and measures are the proposal's; no modification.

2. Withheld-day representation (the proposal's deferred choice — decided)

A withheld day is a disclosed WITHHELD entry, never a silent gap. Every calendar day in the series' record from 2026-08-22 carries either a value or a dated, reasoned withholding. The entry carries the same provenance stamp a published print would carry — panel size, contributing providers with each provider's unchanged-days, transaction count, data tier, judgment applied — plus withheld: true and the reason (panel-below-two / all-static). Surfaces (the briefing, /instruments §Ⅰ, /api/print, MCP) render it as "WITHHELD — <reason>" with the stamp, in the position the value would occupy; no surface carries forward the previous value, and no chart interpolates across it.

Storage — founder ruling 2026-08-16 (settled for the 08-22 build): a SIBLING RECORD, not a constraint drop. derived_series.value stays NOT NULL — a row in the series table always carries a printed number; weakening that invariant to represent absence is the wrong direction. Withheld days live in an additive withheld_prints table (migration via the runner): series_id, date, reason, provenance (the full stamp), notice_ref — one row per withheld (series, day). It is surfaced everywhere a value would appear: the briefing, /instruments, and /api/print's continuity block, which already renders a gap with an explanation. Series continuity is then read across the two tables: every calendar day from 2026-08-22 has either a derived_series value or a withheld_prints row.

3. Notice period, and the deviation it represents

Five business days against the specification's three-month negligible-impact guidance (Part D3 §5), on the same reasoning as notice 2026-08-14 §4: no contract, derivative or forward-claims ledger entry references the series (re-verified 2026-08-16: zero forward_claims rows score against gap_h100_spot) and The Grid has zero external subscribers. The rule only withholds prints that would otherwise carry disclosed-defective information (a one-contributor level, or a panel of frozen anchors); holding those in print for three months would prioritise procedure over honesty. Publish-before-effect (ADR-003 §2) is preserved: this notice precedes the first withheld print by a full notice period.

4. Disclosure from publication

From this notice the gap_h100_spot series disclosure (both runtimes' derived-series registries, /instruments, /api/print, MCP) names the adopted rule and its effective date. Values are unchanged; the disclosure adds information.

5. What this would have done on the record (from the proposal, restated)

Applied to the 20 v3 prints to 2026-08-13: the four single-provider days (2026-08-02, 08-03, 08-05, 08-12) would have been WITHHELD — panel below two contributors — instead of printing $2.69 levels; those days account for three of the six composition-driven transitions in the variance decomposition. The all-static condition has not triggered on a two-provider day. Published history is not revised: those prints stand as published on their day's method.

6. Build scope (after 2026-08-21)

• scripts/compute_gap_print.py: withholding path — evaluate the two conditions from gap_h100_panel_health(), write the withheld_prints row with the stamp and the notice reference; derived_series receives no row for that day (its NOT NULL invariant stands); the generation-level gate refuses to write a value on a day a withholding was recorded.
• Migration: additive withheld_prints (series_id, date, reason, provenance JSONB, notice_ref; UNIQUE (series_id, date); grants per the migrations pattern) via the runner. No change to derived_series.
• Surfaces: briefing index strip, /instruments §Ⅰ chart + table, /api/print (status: "withheld" with withheld: {reason, provenance, notice_ref} beside the existing printed / not_printed / suspended; the continuity block lists the withheld day with its reason), MCP tool response, editorial prompt input.
• Tests: rule fires on the four historical single-provider fixtures; all-static fixture; two-moving-contributor day prints; no surface renders a carried-forward value.
• Downstream: Grid Basis and GCCX divergence read gap_h100_spot — on a withheld day they carry the withholding, not a stale GAP leg (build-stage decision recorded then).

7. Record

• Proposal: 2026-08-14-gap-minimum-observation-proposal.md (status → DECIDED, this notice).
• Ruling (representation): founder, 2026-08-16 — "the WITHHELD representation is a SIBLING RECORD, not a constraint drop. derived_series.value stays NOT NULL … an additive withheld_prints table via the runner — series_id, date, reason, provenance (the full stamp), notice_ref — surfaced everywhere a value would appear … Do not build tonight."
• Ruling: founder, 2026-08-16 — "adopt the minimum-observation rule as proposed … unmodified. Publish the decision notice with a five-business-day implementation period … Withheld-day representation … a disclosed WITHHELD entry carrying the provenance stamp, never a silent gap. Build follows the notice period."
• Companion: 2026-08-14-instrument-actions.md (§2 reclassification, §3 provenance stamp, §7 reinstatement path — the rule is the second half of GAP's path back to assessment class).

Methodology change notice — instrument actions of 2026-08-14

Notice date: 2026-08-14 (UTC; all dates in this notice are UTC) Class: methodology change (suspension · reclassification). Not a correction — see §5. Actions:

1. gap_h100_reserved_1y (GAP-H100-R1Y) — suspended, effective 2026-08-22 (final prints 2026-08-21)
2. gts_1y (GTS-1Y) — suspended, effective 2026-08-22 (final prints 2026-08-21)
3. gap_h100_spot (GAP-H100 spot) — reclassified assessment → indicator, effective with this notice; printing continues unbroken
4. A minimum-observation rule for GAP-H100 spot is proposed under its own notice: 2026-08-14-gap-minimum-observation-proposal.md

Defect class, named: static-contributor / presence-tested freshness — a data source that re-publishes an unchanged price daily satisfies every row-presence check while contributing no market information. Two instruments failed on it outright (actions 1–2); the flagship spot series carries it as the anchor of a two-contributor panel (action 3). The codebase-wide audit of this class is on record (docs/session-outputs/2026-08-15-staleness-audit.md).

1. Suspension of GAP-H100-R1Y and GTS-1Y

Verified against the full stored history:

• GAP-H100-R1Y has zero variance. All 20 prints since inception (2026-07-24 → 2026-08-13) carry the identical value, $6.4645 (population σ = 0). The reserved panel — near-static Azure retail plus a Lambda fallback, both individually unchanged across their entire history — does not move.
• GTS-1Y is therefore not a term premium. Defined as reserved-1Y minus spot, with a constant reserved leg it reduces to (6.4645 − GAP): the spot series inverted and shifted. Correlation with the spot leg across every print: −0.999999983 (−1.0 to storage rounding; identity residual ≤ $0.00005). Its standard deviation (0.114348) is the spot leg's (0.114341) to the fourth decimal.
• The specification's defence — the level embeds a panel-class premium, the change is the signal — fails on this data: the change is entirely the spot leg's change, sign-flipped.

Final prints are dated 2026-08-21; from 2026-08-22 neither series receives new values. Published history is not removed, revised, or retroactively annotated: each value stands as published on the information set of its day.

2. Reclassification of GAP-H100 spot: assessment → indicator

Effective with this notice, gap_h100_spot moves from Class 1 (assessment) to Class 3 (indicator) under the assessment-specification Part B taxonomy. The series keeps printing; the record is unbroken. Reason of record, with the numbers:

• The panel holds two nominal contributors. One (RunPod) has printed the identical value ($2.69) on all 93 days of its stored history — it is a frozen anchor, not a contributor. Two contributing is not one contributing plus one static.
• Variance decomposition across all 20 v3 prints (docs/session-outputs/2026-08-15-gap-variance-decomposition.md): 50.3% of realised variance is panel composition, not price. Of 19 day-over-day transitions, 13 are pure price and 6 are pure composition — every composition-affected transition was 100% composition (the common panel reduces to the static provider; counterfactual delta 0.0000). The four single-provider prints (08-02, 08-03, 08-05, 08-12) equal the static provider's posted price.
• The remaining 49.7% of variance is single-sourced (Vast.ai), attenuated ×0.5 by pooling against the frozen anchor.
• The panel thresholds this project has adopted (spec Part C4, from the Baltic's published rules) do not create an index below five panellists (three in the Asia variant) and do not publish below four (two in Asia). A panel of one moving contributor sits below every variant of the floor.

Path back, stated explicitly: GAP-H100 spot returns to assessment class when the panel carries at least two independently moving contributors — contributors whose prices change on independent cycles, not merely contributors whose rows arrive. Reinstatement is announced by notice before the class label changes back.

Surface effect: the indicator class and reclassification disclosure ride with the series in the derived-series registry (both runtimes), on /instruments §Ⅰ, and in the MCP response. Nothing about the printed values changes.

3. Provenance stamp (disclosure — no notice period, effective on publication)

Per spec A5 / IOSCO PRA 2.3, every GAP-H100 spot print now carries, with the value on the briefing, in the daily report, and in the API response: panel size, contributing providers with each provider's unchanged-days, transaction count (currently 0), data tier (tier-2 bookable asks), and judgment applied (none — arithmetic). The stamp is written into the print of record's detail at print time; surfaces read it from there and never recompute it.

4. Notice period, and the deviation it represents

Suspensions (§1) run five business days (2026-08-17 → 2026-08-21), against the specification's three-month negligible-impact cessation guidance (Part D3 §5). The deviation is deliberate and stated: the cessation windows protect parties who reference an assessment in contracts or settlement. No contract, derivative, or forward-claims ledger entry references any affected series (verified: zero forward_claims rows score against them), and The Grid has zero external subscribers. Holding disclosed-defective instruments in print for three months would prioritise procedure over honesty; five business days preserves publish-before-effect (ADR-003 §2). The reclassification (§2) and provenance stamp (§3) add information without changing any printed value and take effect with publication.

5. Why these are methodology changes, not corrections

Per Part D1: a correction restates what a value should have been on the information set of its day. Every published value of all three series was computed correctly per the stated method — the methods are defective (§1) or under-classed (§2). Nothing is restated; the history stands. Separately, one editorial narration (the 2026-08-07 daily's "first repricing" claim) is a correction — a misapplication of stated methodology in narration — and is issued on the corrections rail: docs/corrections/2026-08-14-gap-2026-08-07-composition-narration.md.

6. Downstream effects

7. Reinstatement paths

• Reserved leg / GTS: returns only as a new methodology version with its own published specification — a reserved panel that actually moves (multiple committed-price sources on independent refresh cycles) and a staleness rule that withholds rather than freezes.
• GAP-H100 spot to assessment class: §2's path back — ≥2 independently moving contributors — plus the minimum-observation rule if adopted.

8. Record

• Verification: docs/session-outputs/2026-08-15-gts-suspension-and-moonshots-registration.md (suspension arithmetic) · docs/session-outputs/2026-08-15-gap-variance-decomposition.md (reclassification numbers) · docs/session-outputs/2026-08-15-staleness-audit.md (defect class, codebase-wide).
• Enforcement: suspension gates in scripts/compute_gap_print.py + scripts/compute_rwi.py; derived_series.write_series() refuses writes to suspended series (hard backstop). Reclassification + disclosures in scripts/derived_series.py ↔ dashboard/lib/derived-series.ts. Provenance: velocity.provenance_stamp() ↔ velocity.ts provenanceStamp().

Proposed methodology change — minimum-observation rule for GAP-H100 spot

Status: DECIDED — adopted unmodified by founder ruling 2026-08-16; decision notice 2026-08-16-gap-minimum-observation-decision.md (notice period 2026-08-17 → 2026-08-21, binds from the 2026-08-22 print; build follows the notice period). This document is the proposal stage as written; the text below is unchanged. Proposal date: 2026-08-14 (UTC) Instrument: gap_h100_spot Companion to: 2026-08-14-instrument-actions.md §2 (reclassification)

The rule

The daily GAP-H100 spot print is withheld — not published — when either condition holds at print time:

1. Panel floor: fewer than two contributing providers on the day (the Baltic Asia-variant publication floor the project has adopted, spec Part C4); or
2. All-static panel: every contributing provider is static by the unchanged-days measure already computed daily in gap_h100_panel_health() — i.e. every contributor's price has been unchanged for ≥ STALE_PROVIDER_DAYS (currently 7) consecutive days.

Withheld is disclosed, never silent. A withheld day produces an explicit withheld record — surfaced on the briefing, /instruments, and the API as "WITHHELD — <reason>" with the same provenance stamp a published print would carry (panel size, contributors, unchanged-days). Series continuity means the record is unbroken: every calendar day has either a value or a dated, reasoned withholding. A gap in values is information; a silent gap is not.

What this would have done on the existing record

Applied to the 20 v3 prints to date: the four single-provider days (2026-08-02, 08-03, 08-05, 08-12) would have printed as WITHHELD — panel below two contributors rather than as $2.69 levels. Those four prints account for three of the six composition-driven transitions (the other three are the matching re-entries) in the variance decomposition. The all-static condition has not yet triggered on a two-provider day (Vast.ai moves), but it is precisely the condition the reserved leg sat in for its entire life — the rule exists so that failure mode withholds instead of printing a frozen number.

Mechanism (for the decision stage; not built)

• Everything needed is already computed: gap_h100_panel_health() returns provider count and per-provider unchanged-days daily, and the provenance stamp (notice 2026-08-14 §3) already carries them on every print.
• The withheld record needs a representation decision: a derived_series row with a null value and a withheld detail, versus a sibling record. That choice is part of the decision notice, not this proposal.
• write_series() gains a withholding path only after adoption; suspension precedent (registry-level gate + generation-level gate) applies.

Notice process

This is a methodology change to when a print appears; it takes its own period. Proposed: founder decision published as the decision notice, then five business days before the rule binds, on the same negligible-impact reasoning as notice 2026-08-14 §4 (zero external references; the rule only withholds prints that would otherwise carry disclosed-defective information). Until adopted, prints continue under the current method with the provenance stamp and indicator classification disclosing the condition.