activation-concept-page

[AndreasAbdi]

{
"project": "Model Atlas — Activation Canonical Concept Page",
"branchName": "activation-concept-page",
"description": "Publish one canonical English activation concept page, backed by the existing registry record and localized messages, so readers can understand what activations do across architectures and move cleanly between the glossary, activation variants, and feed-forward network docs.",
"context": {
"customerAsk": "Add one canonical English concept page for activation, because the site already has the glossary term and several activation-module pages but still lacks the broad plain-language explainer that helps normal readers understand what activations do across architectures. Keep this as one narrow, reviewable content slice on current main. Scope: create the canonical concept page plus colocated messages/en.json and any needed assets.json, using the existing published concept.activation registry record rather than creating a duplicate concept. Classify the page correctly with the project docs, wire aliases, tags, and related links so readers can move between glossary/activation, relu, leaky-relu, silu, swiglu, and feed-forward-network, and add only the focused validation coverage needed for the touched page and discovery surfaces. The prose should explain in simple language what an activation function changes, why models need nonlinear steps, and how readers should distinguish hidden-layer activations from output softmax without turning the page into a math lecture. Keep the slice English-only and avoid reopening Japanese/Vietnamese shipped manifests, tokenizer pages, or broad taxonomy churn beyond what is required to land the page cleanly. Acceptance criteria: the activation concept page exists on current main as a canonical docs page, resolves against the existing registry record, connects cleanly to nearby activation and feed-forward pages, and focused touched checks pass.",
"problem": "The repository already ships the published concept.activation registry record, a glossary entry for activation, and multiple nearby activation-module pages, but it does not ship the canonical concept page that explains activation as the broad idea across architectures. Readers therefore have a gap between the short glossary definition and the more specific ReLU, SiLU, SwiGLU, and feed-forward pages, with no plain-language bridge that explains what nonlinear activations change, why hidden layers need them, and how internal activations differ from output softmax.",
"solution": "Create a canonical concept page at /docs/concepts/activation using the standard concept-page structure, localized English messages, and the existing concept.activation registry record. Keep the copy simple and technical-layperson-friendly, connect the page to the activation glossary and nearby activation-module pages through focused discovery metadata and links, and add only the narrow validation needed to prove route, registry, message, and nearby discovery integrity."
},
"acceptanceCriteria": [
"A canonical docs page exists for activation under the concepts docs tree, binds to registryId: concept.activation, and renders in the standard docs shell.",
"The page uses colocated messages/en.json and any required assets.json, with reader-facing copy resolved through message keys rather than hard-coded prose in page.mdx.",
"The opening summary and primary sections explain, in simple language, what an activation function changes, why nonlinear steps matter, and how hidden-layer activations differ from output softmax.",
"Readers can move cleanly between the new activation concept page, glossary/activation, relu, leaky-relu, silu, swiglu, and feed-forward-network through the touched related-doc, alias, tag, or focused inline-link surfaces.",
"The implementation stays English-only and does not reopen Japanese or Vietnamese manifests, tokenizer pages, or broad taxonomy work beyond what is required for this page to land cleanly.",
"Focused validation proves the canonical activation concept page resolves against the existing published registry record and that the touched discovery surfaces remain valid.",
"Quality gate: typecheck, lint, and targeted tests pass."
],
"userStories": [
{
"id": "activation-concept-page-001",
"title": "Publish the canonical activation concept page",
"description": "As a reader trying to understand activation functions, I want one canonical activation page so I can learn the broad idea before diving into specific module variants.",
"acceptanceCriteria": [
"A canonical concept page exists at /docs/concepts/activation with frontmatter that binds to concept.activation, plus colocated messages/en.json and any required local assets.json.",
"The page follows the concept template pattern and keeps page.mdx structural, with reader-facing text resolved through messages/en.json.",
"The page opens with one folded openingSummary and explains in plain language that activation functions apply a nonlinear rule to layer outputs so stacked layers can model richer patterns than repeated linear transforms alone.",
"The page renders in the standard docs shell and is understandable in isolation before narrowing into feed-forward or module-specific examples.",
"Typecheck passes",
"Verify in browser using the Browser plugin"
],
"priority": 1,
"passes": true,
"notes": ""
},
{
"id": "activation-concept-page-002",
"title": "Connect the activation bridge page to nearby activation docs",
"description": "As a reader exploring activation topics, I want the canonical activation page connected to the glossary, module variants, and feed-forward network page so I can move between the broad concept and concrete examples without dead ends.",
"acceptanceCriteria": [
"The activation concept page exposes clear navigation to glossary/activation, relu, leaky-relu, silu, swiglu, and feed-forward-network through registry-backed related docs and any required focused inline links.",
"Touched discovery metadata keeps aliases and tags aligned with concept.activation so representative queries such as activation, activation function, hidden activation, and layer output resolve to the canonical concept surface appropriately.",
"The page clearly distinguishes hidden-layer activations from output softmax in narrative copy without turning the page into a math-heavy explanation.",
"Any supporting copy changes outside the new page remain narrowly scoped to reader movement to or from the activation concept page.",
"Typecheck passes",
"Tests pass",
"Verify in browser using the Browser plugin"
],
"priority": 2,
"passes": true,
"notes": ""
},
{
"id": "activation-concept-page-003",
"title": "Add focused validation for page contract and activation discovery",
"description": "As a maintainer, I want targeted automated proof for the activation concept slice so registry, message, route, and nearby discovery regressions are caught without unrelated test churn.",
"acceptanceCriteria": [
"Automated validation or tests confirm the canonical activation concept page resolves against the existing published concept.activation registry record instead of creating a duplicate concept record.",
"Automated validation or tests cover the touched discovery surface for the page, such as route resolution, English message loading, and at least one related-doc or search-oriented expectation for the canonical activation concept route.",
"Coverage remains focused on observable behavior for this page slice and does not expand into unrelated locale manifests, tokenizer pages, or broad inventory assertions.",
"Typecheck passes",
"Tests pass"
],
"priority": 3,
"passes": true,
"notes": ""
}
]
}

[AndreasAbdi]

Follow-up mergeability patch pushed in c2a7a4c. This addressed the failing PR test job by: 1. adding the missing batch-014 planner fixture, 2. narrowing the CI filename guard to new src/tests/ci coverage instead of historical repo-wide files, 3. updating downstream related-doc, search, architecture-index, and docs-link-validator expectations to use /docs/concepts/activation where registry-derived links now resolve to the canonical activation concept page, and 4. switching stale fake-docs linkcheck fixtures to invalid-fragment fixtures that still exercise the validator under the catch-all docs route.