docs(falsify): 40-lesson run readiness — FALSIFIED, two hard, two soft - #318
Merged
Merged
Conversation
Release candidate: the §5.1 ruling, and six guards that were not guarding
release: 1.2.0 to main
release: 1.3.0 to main
release: 1.4.0 to main
Claim audited: "we are ready for a new full (40-lesson) run."
HARD 1 — views-models still pins VIEWS_POSTPROCESSING_PIN="1.1.1" in both
launchers. A run launched now installs the build whose findability guard checks
2 of 110 artefacts and cannot see the sidecar by construction — the exact defect
that made today's delivery unservable. 1.4.0 exists, is tagged, is on PyPI, and
is referenced by nothing. views-models#439 carries the one-line diff.
HARD 2 — a fresh launcher environment is unbuildable (views-models#516, open).
xarray is unpinned in postprocessors/{un_fao,un_crafd}/requirements.txt, and
views-datafactory's `xarray>=2024.1,<2026` cap permits 2025.12.0, which requires
pandas>=2.1 against the platform's pandas 1.5.3. Today's pod works only because
xarray was hand-pinned to 2024.3.0 on it. So the claim holds only if the run
reuses that exact pod and its env survives the launcher's dry-run check.
SOFT 3 — the SELECTION half of the findability guard still depends on an ordering
guarantee that does not exist. #314 made the per-object half order-independent;
the legs loop still resolves through pipeline-core's get_latest_file_id, which
documents "newest by creation timestamp" and takes files_list[0] from an unsorted
result. Held since August, so order has been favourable rather than guaranteed,
and the set it indexes into grows ~120 documents per run at 40 lessons. The
failure mode is a FALSE invisible-delivery on a healthy run. Stub S7 below.
SOFT 4 — ADR-013 §4.6's capacity inequality (assembled-run size x safety factor
<= consumer serving RAM) is an open maintainer item, and its reference figure is
28.6 GB at 36 months, already stated as larger than the serving host's RAM. 40
lessons raises it ~11%. Whether that matters depends on the run's S, which this
seat does not know — recorded rather than asserted.
PASSED — P4, the one I most expected to break: the new per-object query works on
the live path. `_build_partner_read_store` sets store.model_path = None, and
get_predictions_by_metadata injects `filters["name"]` only when model_path has a
model_name, so the C-77 suppression holds for documents() as well as for
latest_file_id. Verified in pipeline-core at datastore.py:423-432.
Only S7 is assertable in this repo. HARD 1 and HARD 2 are other repositories'
state and views-models is not in this repo's CI sibling checkout (ADR-016), so a
test reaching for them would pass vacuously — a guard that cannot fire (C-102).
They are recorded in the module docstring with their issue numbers instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ANY1CCy9Xo7zjMY4XJ69v9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
/falsifyon "we are ready for a new full (40-lesson) run." Verdict: FALSIFIED.1.1.1— a run now installs the build whose guard checks 2 of 110 artefactsHARD 1 is the one that matters: 1.4.0 is tagged, on PyPI, and referenced by nothing. A run launched now reproduces today's unservable delivery exactly.
HARD 2 means "ready" holds only if the run reuses today's exact pod — its env works because xarray was hand-pinned on it.
The probe I most expected to break, passed. The new per-object query works on the live path:
store.model_path = Nonesuppresses pipeline-core's name injection forget_predictions_by_metadataas well asget_latest_file_id, so C-77 holds fordocuments(). Verified atdatastore.py:423-432.Only S7 is assertable here. The two hards are other repos' state, and views-models is not in this repo's CI sibling checkout — a test reaching for them would pass vacuously (C-102). Recorded in the module docstring with issue numbers instead.
🤖 Generated with Claude Code
https://claude.ai/code/session_01ANY1CCy9Xo7zjMY4XJ69v9