Richard opened by saying #628 had become unwieldy and he needed the right information in front of him to finish it. The issue body still described 2 October. Since then two PRs had merged, two follow-up issues had been opened, and #86 had closed that morning. So I read the six issues it leans on before saying anything, and checked each claim against the code and the live tables.

That reading changed what “loose ends” meant. Arm A had passed S3 and S4 two days earlier. The roadmap’s D12 rule makes the next and last retrain of the quarter the relation-fidelity export, which is exactly the bridged mode #628 built. Several items that looked optional on the issue, such as which bridges are approved and how the eval maps relation tokens back to Arm A’s categories, were really Arm B’s inputs. I laid out twelve decisions in three groups: those that change what Arm B trains on, one that changes what we read about her variants, and record-keeping that changes nothing the model sees. He answered all twelve in one message.

The state moved while I was reading. My first check of the stored predicates passed. A query a few minutes later showed her BRAF V600E rows already carrying names like Predictive_Resistance_Does Not Support. The #707 session had applied its in-place rename at 06:08–06:09 PDT, between my two reads. Its PR still said nothing on prod had changed. I left that work to that session, but I quoted the live counts rather than the PR’s.

One decision needed interpreting. Richard approved “option B” for D-Q4-01 and asked why it was still open “in the age of federation”. Plain B, where every source predicate gets its own qualifier, is the version he objected to on 1 October, because like meanings could not merge across graphs. The bridge merges he had just approved only exist under B′. I recorded B′, said so in the record, and asked him to tell me if he meant otherwise. The card was open for the dullest reason: nobody had written in its Decision section.

He also asked whether training on Does Not Support rows means the model learns negative paths, “unless I am misunderstanding this”. The honest answer came from reading ULTRA’s code rather than the paper. build_relation_graph keeps only which relations share an entity, not how often or under what name. So I measured the twins on prod. A Does Not Support relation and its Supports twin link the same way to all but 11 of the 124 other relation types in her sources, and those 11 are rare classes. Sensitivity and resistance are no better. The model can probably tell them apart, but only just. That is why #726 asks for a direction probe, not merely an export.

The finding I would most want a later session to see is the display defect. The read service groups relations by subject, object and predicate, and returned only the predicate. Since the rename, a CIViC evidence item saying V600E does not predict resistance to panitumumab sat under predicts_resistance_to. The Explorer, the API and the MCP tools all showed it as the claim it fails to support, on her own driver, for a drug in the same class as her cetuximab. Every edge now carries its source assertions, and the Explorer shows them, with Does Not Support in brighter, bold green. My first version used amber, until the frontend rules reminded me the house style marks state by green brightness alone. I checked it in a browser against a throwaway database, because booting this branch’s backend against prod would have cleared the live worker registry.

One slip, caught. I grepped the new PR body for closing keywords, but ran the grep beside gh pr create instead of in front of it. “The display fix #628 kept” reads to GitHub as “fix #628”. The PR was up before I saw the match, so I reworded it and confirmed GitHub listed no closing references. The memory index now says the grep has to gate the command.

By evening Richard had confirmed B′ and said yes to the sync and the ledger card.

• The restore. I had asked for his go-ahead on #725’s restore. He thought it was already done, and he was right: 660 evidence items went in at 06:14, five minutes after the rename. I had repeated a stale line from that PR’s body, and I corrected the comment where I’d written it.
• The merge. #725 had merged first, and it refreshed the same snapshot and tests my bridge PR depended on. So I merged main into a scratch branch and re-ran the bridge suites before merging #742.
• The sync. I dry-ran it against the live table, then synced: 21 bridges and 42 members, with diff clean.
• The ledger card. The fresh-run plan is card D-Q4-20, #755. Its body holds the checklist that decides when V1 counts as done.

The next morning Richard said “go on all five”, meaning the five follow-ups from the harvest.

• The deploy. I shipped exactly #743’s two frontend commits, from its merge commit, through a detached worktree. main by then held two newer frontend commits that no one had looked at for release, and whafa.com is public. Revision 00099 serves the build, and its bundle contains the new edge card.
• The rules. Seven rule bullets and a wishlist line went in as #786.
• The guard, which is the wrong turn. The night before, I had proposed a guard that asks before any frontend edit adding an amber, red, blue or gray class. I proposed it without measuring it. Before writing it, I replayed the 132 commits since October 2025 that touch frontend/src. It would have fired on 44% of file edits and 58% of commits, many of them the nightly fixer’s. Only 38 of the 140 files use no off-style colour at all. Every variant quiet enough to live with would have missed my own amber edit, because both components already used amber. So I held it and gave Richard the numbers instead. The style rule had not failed through its wording. It failed because I read the files through Bash, so the rule never loaded, and a guard would not have fixed that.