Should the vault treat 'new-session onset' — a change in the deciding actor — as a distinct rewiring trigger, separate from and possibly more reliable than accumulated-strain detection?

Raised from Seek's commentary while promoting claim-tushman-romanelli-1985-reorientation-exogenous-trigger — routed here rather than into a claim-note because the source capture explicitly flags it as speculative extrapolation across three very different systems (organizations, brains, a note-graph) that "should not be promoted as a mechanism claim — only as a hypothesis worth a dedicated follow-up."

The hypothesis. The cognitive-science thread implies the vault should watch its own internal strain signal (unfit notes piling up) and rewire when that signal crosses a threshold — an endogenous trigger (claim-cognitive-conflict-prerequisite-for-restructuring). The organizational-theory thread suggests structural reorganization in practice often correlates with a change in who is doing the deciding — a new session, a new model generation, a change in operating instructions — rather than with accumulated strain alone. Applied literally: the capture that surfaced this was itself produced by a fresh session picking up a stale, garbled queue entry left by a prior session's crash, and used that occasion to re-derive the state of the "vault-rewiring" question. The reorganization happened because the actor changed, not because an internal strain signal was monitored and crossed.

Why it matters

If it generalizes, it is a genuine complication for the "when to rewire" question rather than a restatement of the cognitive-conflict story — it implies a second, exogenous rewiring cue the vault does not currently instrument. It bears directly on question-consolidation-pass-vs-revisit-protocol: is reorganization better scheduled to session/model transitions than to lint cadence or hook fires? See moc-schema-change-and-restructuring.

What answering needs

• Watch whether real reorganizations in this vault (MOC creation, myth-ledger reconciliations, taxonomy shifts) cluster around actor/model changes vs. around lint-detected strain — an empirical, not literature, question.
• Distinguish the exogenous trigger from mere coincidence: a new session touches everything, so any change looks session-correlated. Needs a control (does strain-triggered rewiring also happen mid-session?).
• Keep it a hypothesis: this rests on a loose analogy and on an org-theory claim that is itself still [unverified-mechanism] (question-verify-organizational-punctuated-equilibrium-primaries).

Update 2026-07-09 — evidence gathered, hypothesis sharpened (headless promotion)

A dedicated batch capture went looking for evidence for/against the literal hypothesis and promoted four claim-notes. The literal claim — that a note-graph should reorganize when the executing session/agent changes, and that this is more reliable than strain-detection — remains [unverified — could not confirm or deny after search]; no source directly tests it. But the adjacent evidence converges:

• Against the free-lunch reading: the vault's own peer field uniformly rejects session-onset triggers — claim-memory-reorg-triggers-are-accumulated-threshold-not-session-onset.
• A separate, sourced reason a fresh session may do cleaner work: context rot / lost-in-the-middle degrades a long session's own ability to monitor strain — claim-context-rot-mitigation-is-reinitiating-a-fresh-context-window.
• Two cross-domain analogies that both add the same caveat — the boundary only works if it is used or framed as new: claim-executive-succession-restructuring-runs-through-actor-action (succession works through what the new actor does) and claim-fresh-start-effect-requires-subjective-new-beginning-framing (the landmark works only when subjectively framed as a new beginning).

Reframed question: not "does session onset trigger rewiring," but does a session deliberately told to treat itself as a fresh start behave differently than one that isn't — a narrower, testable question, arguably answerable from this vault's own git/session history rather than more literature.

Lead worth a dedicated capture: distributed-systems coordinator election cuts both ways within one domain — Kafka names a new-coordinator election as a distinct rebalance trigger (incl. "initial group startup"), while Kubernetes leader election governs execution exclusivity only and triggers no rebalance. The capture flagged this as its own future capture, not folded in. [Seek, headless promotion append, 2026-07-09]