---
id: "20260708-0209-answered-2026-07-07"
title: "Capture: Dedupe-check on '[ANSWERED 2026-07-07, cycle 17] No — never on the page (Wayback 2014–2026)' topic — confirms fold-in into claim-linnainmaa-copenhagen-anecdote point 3 is real, no new research performed"
type: "capture"
status: "promoted"
promoted_to: []
not_promoted: ["Confirms point 3 of [[claim-linnainmaa-copenhagen-anecdote]] (the Copenhagen-park anecdote never appeared on Schmidhuber's who-invented-backpropagation page, Wayback 2014-2026). Dedupe confirmation only; nothing new to promote."]
promotion_note: "Processed 2026-07-09 (Fable clean-lane promotion marathon): fold-in verified accurate; no new notes. Same re-queue-of-[ANSWERED]-topic queue bug as the sibling dedupe captures."
origin: "batch"
model: "claude-sonnet-5"
date_created: "2026-07-08T00:00:00.000Z"
provenance: "batch run 2026-07-08; topic string arrived already marked '[ANSWERED 2026-07-07, cycle 17] No — never on the page (Wayback 2014–2026); already absorbed in claim-linnainmaa-copenhagen-anecdote point 3', itself harvested from 10-inbox/raw/2026-06-28-read-griewank-2012-directly-to-verify-a-the-backward-pass-structural-description-of-linnainmaas-algorithm-and-b-the-copenhagen-park-anecdote.md"
derived_from: []
tags: ["linnainmaa","griewank","schmidhuber","copenhagen-anecdote","history-of-computation","reverse-mode-ad","dedupe","housekeeping"]
source_url: "https://people.idsia.ch/~juergen/who-invented-backpropagation.html"
source_author: "Jürgen Schmidhuber"
source_date: "2026-07-01 (access date of prior verification capture); page self-dated 2014, updated 2020, 2022, 2025"
source_tier: 1
---


> [!info] Outcome: no new research — this is a duplicate of already-completed work
> This topic string, as received, already declares its own resolution: `[ANSWERED 2026-07-07, cycle 17] No — never on the page (Wayback 2014–2026); already absorbed in claim-linnainmaa-copenhagen-anecdote point 3`. Rather than re-running Wayback/live-page fetches that had already reached Tier 1 primary-source depth, this capture verifies the fold-in claim against the current state of the vault and confirms it is accurate. No new web fetches were performed beyond re-reading the notes already on file.

## What was checked

The core question behind this topic (harvested from the 2026-06-28 Griewank-verification capture) was: did Jürgen Schmidhuber's essay "[[Who Invented Backpropagation?]]" ever carry the Copenhagen-park anecdote about [[Seppo Linnainmaa]], possibly before a post-2019 revision removed it? Two vault artifacts were opened directly (not assumed from the topic string) to confirm the answer and its destination:

1. **`10-inbox/raw/20260701-1650-did-schmidhubers-who-invented.md`** — the original research capture (2026-07-01) that did the actual Wayback/live-page work. Its frontmatter records `status: promoted`, `promoted_to: "30-notes/claim-linnainmaa-copenhagen-anecdote.md (finding already absorbed there at cycle 1 — point 3 ... descends from this capture's resolution trail; no new note)"`. The capture directly fetched the live Schmidhuber page and a Wayback snapshot dated 2019-06-14, plus corroborating snapshots from 2014-10-25, 2016-01-02, 2024-12-25, and 2026-06-22 (the last four reported by a research subagent, flagged `[unverified — subagent-reported, method-consistent but not independently re-fetched by primary agent]`). None of the checked versions contain the word "Copenhagen." The two directly-verified data points (live page and the 2019-06-14 snapshot) are Tier 1 — Schmidhuber's own words, fetched via a transparent relay to the primary URL.
2. **`30-notes/claim-linnainmaa-copenhagen-anecdote.md`** — the promoted claim note, point 3: *"The anecdote is absent from Schmidhuber's page — Wayback snapshots from 2014–2026 never show it there (see the [[question-verify-griewank-2012-linnainmaa]] resolution trail). It belongs to Griewank 2012 alone; retellings that attribute it elsewhere are citing a citation."* This confirms the fold-in described in the topic string is present, accurate, and load-bearing in the promoted note — not merely asserted by the topic string.
3. **`50-questions/_answered/question-verify-griewank-2012-linnainmaa.md`** — the governing question, `status: answered`, with `flags_to_resolve` entries dated 2026-07-06 that trace the anecdote's confirmed primary home to Griewank's 2012 paper (verified verbatim, p. 389), consistent with the "absent from Schmidhuber, belongs to Griewank" conclusion.

**Claim type**: historical (a negative/absence claim about what a specific web page has and has not contained over time) — load-bearing enough (it forecloses a "post-2019 revision" premise) that the original 2026-07-01 capture treated it at Tier 1-2 rigor rather than resting on Tier 3-4 secondary retellings.
**Sourcing floor**: Tier 3-4 acceptable for uncontested historical claims, escalating to Tier 1-2 for contested/surprising ones — met and exceeded; the original capture used direct Tier 1 primary-source fetches (live page + specific Wayback snapshot) for the two most load-bearing data points.

| Field | Value |
|---|---|
| source_title | "Who Invented Backpropagation?" |
| source_author | Jürgen Schmidhuber |
| source_url (live) | https://people.idsia.ch/~juergen/who-invented-backpropagation.html |
| source_url (2019-06-14 Wayback snapshot) | https://web.archive.org/web/20190614211621/https://people.idsia.ch/~juergen/who-invented-backpropagation.html |
| source_tier | 1 |
| exact_quote (live page, 2026-07-01 fetch) | "Explicit, efficient error backpropagation (BP) in arbitrary, discrete, possibly sparsely connected, NN-like networks was first described in a 1970 master's thesis (Linnainmaa, 1970, 1976)" |
| exact_quote (2019-06-14 snapshot) | "Explicit, efficient error backpropagation (BP) in arbitrary, discrete, possibly sparsely connected, NN-like networks apparently was first described in a 1970 master's thesis (Linnainmaa, 1970, 1976), albeit without reference to NNs." |
| negative finding | "The word 'Copenhagen' does not appear anywhere in the returned page text" (stated identically for both the live page and the 2019-06-14 snapshot) |

Neither `30-notes/claim-linnainmaa-copenhagen-anecdote.md` nor `50-questions/_answered/question-verify-griewank-2012-linnainmaa.md` required a correction as part of this dedupe check — the fold-in described in the topic string is accurate and already reflected in the promoted note, not merely asserted.

## Why no further web research was performed

The original 2026-07-01 capture already cleared the sourcing floor for this claim type with direct fetches of the live page and a Wayback snapshot bracketing the "post-2019 revision" framing, plus a Tier 1 corroborating primary artifact (Schmidhuber's own 2014-07-22 CMU Connectionists mailing-list post, independently fetched and confirmed, also containing no Copenhagen reference). That capture was explicitly marked `status: promoted` with its finding folded into `claim-linnainmaa-copenhagen-anecdote.md` point 3 rather than spun out as a standalone note (per that capture's own `not_promoted` field: "Negative finding as standalone note — folded; a never-was-there claim doesn't warrant its own file when the host note carries it"). Re-running Wayback fetches a second time would not add new evidence; it would only re-confirm what a prior pass already confirmed at Tier 1. Per the operating spec's instruction that a complete, non-forced outcome is valid, this capture records the dedupe finding rather than manufacturing new research on an already-closed question.

> [!note] Seek's commentary:
> Same pattern as the Griewank-2014 Table 5 dedupe-check from earlier this cycle (`10-inbox/raw/2026-07-08-griewank-2014-table-5-dedupe-check-already-answered-cycle-17.md`): the topic arrived pre-labeled `[ANSWERED ...]`, and checking the named destination confirms the label is honest rather than just self-reported. Worth flagging upstream (outside this capture's scope) that the batch queue appears to be re-surfacing multiple topics from the same 2026-06-28 Griewank-verification thread that already carry an `[ANSWERED cycle 17]` prefix — if that prefix is meant to suppress re-queuing, something in the harvesting/scheduling step isn't reading it. This is now the second such dedupe-only capture in this session; if a third appears from the same thread, that's a stronger signal the upstream fix is worth prioritizing over continuing to manually confirm each one.