Skip to content

sampling-overview-concept-page#209

Open
AndreasAbdi wants to merge 5 commits into
mainfrom
sampling-overview-concept-page
Open

sampling-overview-concept-page#209
AndreasAbdi wants to merge 5 commits into
mainfrom
sampling-overview-concept-page

Conversation

@AndreasAbdi

Copy link
Copy Markdown
Contributor

{
"project": "Model Atlas — Sampling Overview Canonical Concept Page",
"branchName": "sampling-overview-concept-page",
"description": "Publish one canonical English sampling-overview concept page, backed by the existing concept.sampling-overview registry record and localized messages, so readers can understand the post-logit next-token choice step and move cleanly through the generation and sampling reader path.",
"context": {
"customerAsk": "Refill the queue with one more narrow concept-page slice that improves the generation reader path without replaying already-open tokenizer, attention, or alignment work. Add the canonical English concept page for sampling-overview using the existing published concept.sampling-overview registry record rather than introducing a duplicate concept. Scope: create the canonical concept page plus colocated messages/en.json and any needed assets.json; classify it correctly with the project docs; wire aliases, tags, and related links so readers can move between autoregressive-generation, decode, temperature, greedy-decoding, top-k-sampling, top-p-sampling, and nearby GPT-family pages; and add only the focused validation needed for the touched page and discovery surfaces. The page should explain in simple language what sampling changes after a model produces logits, why different strategies trade predictability against diversity, and how this overview differs from deeper pages for temperature or individual sampling methods. Keep the slice English-only and avoid touching locale infrastructure, tokenizer-family pages, or unrelated model/runtime code.",
"problem": "The repository already ships the published concept.sampling-overview registry record and an English glossary page for sampling overview, plus nearby pages for temperature, greedy-decoding, top-k-sampling, top-p-sampling, autoregressive-generation, and decode. What it does not yet ship is the canonical concept-page version of sampling-overview that acts as the broad explainer in the generation reader path. That leaves an avoidable gap between the short glossary entry and the narrower pages about specific controls or decoding methods, and it weakens discovery for readers who need a plain-language bridge from logits and probabilities to concrete token-selection strategies.",
"solution": "Publish src/content/docs/concepts/sampling-overview/page.mdx using the standard concept-page contract, with colocated messages/en.json and a minimal assets.json only if the page needs a structured teaching asset. Bind the page to the existing concept.sampling-overview record, keep the copy simple and technical-layperson-friendly, and clearly distinguish this overview page from deeper pages about temperature, greedy decoding, top-k sampling, and top-p sampling. Update only the focused aliases, tags, related-doc relationships, and discovery surfaces needed for readers to move cleanly between the overview, the generation loop, the decode step, the sampling-method pages, and nearby GPT-family pages."
},
"acceptanceCriteria": [
"A canonical docs page exists for sampling-overview under the concepts docs tree, binds to registryId: concept.sampling-overview, 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 that sampling is the post-probability next-token choice step, that different strategies trade predictability against diversity, and that these controls do not change the model's underlying knowledge.",
"The page clearly distinguishes the broad overview from deeper pages for temperature, greedy-decoding, top-k-sampling, and top-p-sampling.",
"Readers can move cleanly between the canonical overview page, autoregressive-generation, decode, temperature, greedy-decoding, top-k-sampling, top-p-sampling, and at least one nearby GPT-family page through touched related-doc, alias, tag, or focused inline-link surfaces.",
"The implementation stays English-only and does not reopen locale infrastructure, tokenizer-family pages, or unrelated model/runtime code.",
"Focused validation proves the canonical concept page resolves against the existing published registry record and that the touched discovery surfaces remain valid.",
"Quality gate: typecheck, lint, and focused touched tests pass."
],
"userStories": [
{
"id": "sampling-overview-concept-page-001",
"title": "Align the existing sampling overview record for canonical concept discovery",
"description": "As a reader searching for sampling basics, I want the existing concept.sampling-overview record to behave like a first-class broad concept so discovery surfaces can route me to one canonical explainer instead of only the glossary surface.",
"acceptanceCriteria": [
"The existing concept.sampling-overview record remains the canonical backing record and is adjusted only as needed with aliases, tags, related ids, or citations that fit a broad concept page.",
"Registry relationships connect the concept page to shipped nearby docs for autoregressive-generation, decode, temperature, greedy-decoding, top-k-sampling, top-p-sampling, and at least one nearby GPT-family page.",
"Discovery metadata distinguishes the broad concept page from the existing glossary entry without introducing a duplicate concept record or broad taxonomy churn.",
"Typecheck passes",
"Tests pass"
],
"priority": 1,
"passes": true,
"notes": ""
},
{
"id": "sampling-overview-concept-page-002",
"title": "Publish the canonical sampling overview concept page",
"description": "As a technical layperson learning generation, I want one broad sampling-overview page so I can understand what changes after logits exist and before one token is chosen, without having to infer that overview from several narrower pages.",
"acceptanceCriteria": [
"A canonical concept page exists at /docs/concepts/sampling-overview with matching frontmatter, messages/en.json, and a colocated assets.json that stays empty or minimal unless a structured teaching asset is genuinely needed.",
"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 that sampling is the final next-token decision step after logits have been turned into probabilities.",
"The page explains in plain language why stricter rules are usually more repeatable and looser rules usually allow more diversity, without presenting those tradeoffs as changes to model knowledge.",
"The page clearly states how this overview differs from deeper pages for temperature and specific strategies such as greedy decoding, top-k sampling, and top-p sampling.",
"The page renders at the canonical concept route in the standard docs shell.",
"Typecheck passes",
"Tests pass",
"Verify in browser using the Browser plugin"
],
"priority": 2,
"passes": true,
"notes": ""
},
{
"id": "sampling-overview-concept-page-003",
"title": "Connect the overview page to the generation reader path",
"description": "As a reader moving through generation topics, I want the overview page connected to the generation loop, decode step, specific sampling methods, and nearby GPT-family context so I can keep going without dead ends.",
"acceptanceCriteria": [
"The sampling-overview concept page exposes clear navigation to autoregressive-generation, decode, temperature, greedy-decoding, top-k-sampling, top-p-sampling, and at least one nearby GPT-family page through registry-backed related docs and any required focused inline links.",
"The page makes the relationship boundaries clear by presenting autoregressive-generation and decode as generation-path context, temperature as a probability-shaping control, and greedy-decoding or truncation methods as downstream token-choice rules.",
"Touched discovery metadata keeps aliases and tags aligned with representative queries such as sampling overview, token sampling, next-token sampling, sampling basics, and decoding strategy.",
"Any supporting changes outside the new page remain narrowly scoped to reader movement to or from the new concept page.",
"Typecheck passes",
"Tests pass",
"Verify in browser using the Browser plugin"
],
"priority": 3,
"passes": true,
"notes": ""
},
{
"id": "sampling-overview-concept-page-004",
"title": "Add focused validation for the new concept route and touched discovery surfaces",
"description": "As a maintainer, I want targeted automated proof for the sampling overview concept slice so registry, message, route, and nearby discovery regressions are caught without unrelated churn.",
"acceptanceCriteria": [
"Automated validation or tests confirm the canonical sampling-overview concept page resolves against the existing published concept.sampling-overview registry record instead of duplicate concept data.",
"Automated validation or tests cover the touched discovery surface for the new page, including default English message loading and at least one route, related-doc, or search-document expectation for the canonical concept route.",
"Coverage remains focused on observable behavior for this page slice and does not expand into locale infrastructure, tokenizer-family pages, or broad inventory assertions.",
"Typecheck passes",
"Tests pass"
],
"priority": 4,
"passes": true,
"notes": ""
}
]
}

@AndreasAbdi

Copy link
Copy Markdown
Contributor Author

Implemented sampling-overview-concept-page-004 on commit 164fd2b2.

Changes:

  • added src/lib/content/sampling-overview-concept-validation.test.ts
  • proved the shared concept.sampling-overview record keeps both published routes while getPublishedDocsEntryByRegistryId(...) resolves to the canonical concept route
  • covered default English page loading plus search-result metadata for /docs/concepts/sampling-overview

Local validation completed before push:

  • bun run lint
  • bun run typecheck
  • bun run test:website

@AndreasAbdi

Copy link
Copy Markdown
Contributor Author

BLOCKING review summary for 164fd2b2.

Findings:

  1. BLOCKING: prd.json:22-31 story sampling-overview-concept-page-001 is marked passes:true, but every acceptance criterion is structural or compile-time only. Per the review contract, each passing story needs at least one behavioral assertion with an observable outcome. Please add one, for example a search/discovery assertion that a representative query routes readers to /docs/concepts/sampling-overview instead of only proving registry metadata exists.

  2. BLOCKING: the validation slice expands inventory-style and path-helper assertions instead of staying focused on observable behavior. src/lib/source.test.ts:109-118 adds another route inventory constant, and src/lib/content/sampling-overview-concept-validation.test.ts:16-23 only proves directory/path constants. That conflicts with prd.json:77-80, which explicitly says coverage should stay focused on observable behavior and avoid broad inventory assertions. Replace these additions with rendered-navigation, route, or search behavior checks.

  3. BLOCKING: the new page copy still includes page-meta/site-structure framing that the docs-writing standard forbids. src/content/docs/concepts/sampling-overview/messages/en.json:18-24 contains Use this page as the broad bridge... and This overview is broader than the deeper pages... while this page explains.... Rewrite that section so it explains the concept relationships directly, without talking about the page’s role in the docs set.

Acceptance criteria:

  • PASS: A canonical docs page exists for sampling-overview under the concepts docs tree, binds to registryId: concept.sampling-overview, and renders in the standard docs shell.
  • PASS: The page uses colocated messages/en.json and assets.json, with reader-facing copy resolved through message keys rather than hard-coded prose in page.mdx.
  • PASS: The opening summary and primary sections explain that sampling is the post-probability next-token choice step, that strategies trade predictability against diversity, and that these controls do not change model knowledge.
  • PASS: The page clearly distinguishes the broad overview from deeper pages for temperature, greedy-decoding, top-k-sampling, and top-p-sampling.
  • PASS: Readers can move between the overview page, autoregressive-generation, decode, temperature, greedy-decoding, top-k-sampling, top-p-sampling, and gpt-2-report through inline links and related-doc surfaces. I verified the rendered route in the browser at http://127.0.0.1:3456/docs/concepts/sampling-overview.
  • PASS: The implementation stays English-only and does not reopen locale infrastructure, tokenizer-family pages, or unrelated model/runtime code.
  • FAIL: Focused validation does not fully stay within the requested behavioral scope because the change adds broad inventory/path assertions in src/lib/source.test.ts:109-118 and src/lib/content/sampling-overview-concept-validation.test.ts:16-23.
  • PASS: Quality gate passed. make test passed locally, and live PR checks are all green (lint, typecheck, test, test-build-contract, test-verify-contract, build-export, coverage, validate-data, linkcheck, test-integration).

Behavioral assertion check for stories marked passes:true:

  • FAIL: sampling-overview-concept-page-001 has no behavioral assertion in prd.json:25-30; all criteria are metadata/test-gate oriented.
  • PASS: sampling-overview-concept-page-002 includes route-render and browser-verification behavior.
  • PASS: sampling-overview-concept-page-003 includes observable navigation behavior and browser verification.
  • PASS: sampling-overview-concept-page-004 includes route/search behavior, but the added inventory-style assertions still need to be removed or replaced.

General website standards:

  • PASS: 1. Architecture and state fit the existing docs-content architecture and reuse the established content/registry/search layers.
  • PASS: 2. Components and interaction reuse the standard docs-shell components without new one-off UI.
  • PASS: 3. Styling and visual consistency stay inside the shared docs shell.
  • PASS: 4. Accessibility appears preserved by the shared shell and semantic section structure.
  • PASS: 5. Responsive behavior is unchanged by the content-only implementation.
  • PASS: 6. Performance and resilience impact is low and stays within existing static-doc patterns.
  • PASS: 7. Browser compatibility risk is low; the route rendered correctly in the local browser check.
  • PASS: 8. Localization structure is correct because copy lives in messages/en.json and the slice stays English-only.
  • FAIL: 9. Testing and diagnostics do not fully match the requested proof shape because part of the added coverage is inventory/path based instead of user-visible behavior.

Docs writing standards:

  • PASS: 1. The page is understandable in isolation.
  • FAIL: 2. The narrative body contains page-meta/site-structure prose in messages/en.json:18-24.
  • PASS: 3. The first sections explain what sampling is and why it matters in plain language.
  • PASS: 4. The title and first narrative mention use the full name.
  • PASS: 5. The sections have distinct jobs.
  • PASS: 6. No additional math is required for this concept.
  • PASS: 7. No graph or chart is required for this page’s teaching load.
  • PASS: 8. No math-definition misuse is present.
  • FAIL: 9. Customer-facing copy includes page-role framing in messages/en.json:18-24.
  • PASS: 10. References are present and I did not find an obviously incorrect citation mapping.
  • PASS: 11. Related docs/tags/citations support discovery without making the concept unintelligible on its own.
  • PASS: 12. Most copy is concise and direct, aside from the page-meta wording above.

Validation evidence:

  • gh pr diff 209 reviewed in full.
  • Touched files and nearby concept-page patterns reviewed.
  • gh pr view 209 --comments, gh pr view 209 --json headRefOid,mergeStateStatus,statusCheckRollup, and gh pr checks 209 reviewed.
  • make test passed locally.
  • Browser QA completed on the rendered concept route. The repo instruction path docs/internal/processes/manual-qa.md referenced by the review workflow does not exist in this worktree, so I used direct route verification instead.

REJECTED until the blocking items above are fixed.

… the new concept route and touched discovery surfaces
@AndreasAbdi

Copy link
Copy Markdown
Contributor Author

Addressed the blocking review feedback on commit 8858bd2a.

Resolved items:

  • Replaced the inventory/path-only proof in src/lib/content/sampling-overview-concept-validation.test.ts with observable behavior checks: the canonical concept route now resolves through source.getPage(["concepts", "sampling-overview"]), the English search metadata maps /docs/concepts/sampling-overview, and docsSearchApi.search("sampling basics") ranks the canonical concept route first.
  • Removed the extra shared sidebar inventory expectation from src/lib/source.test.ts so this slice no longer widens broad route-inventory coverage.
  • Rewrote the customer-facing copy in src/content/docs/concepts/sampling-overview/messages/en.json to remove page-role framing. The affected sections now explain generation-path context and concept boundaries directly.

Validation on this head before push:

  • bun run lint
  • bun run typecheck
  • bun run test:website
  • Browser verification on http://127.0.0.1:3462/docs/concepts/sampling-overview via the webpack-backed dev server

PR diff rechecked after push: the sampling-overview concept page and its focused test files are present on PR #209. CI is now running on 8858bd2a.

@AndreasAbdi

Copy link
Copy Markdown
Contributor Author

Superseding review summary for head 8858bd2a8bbab2a696a0b195f5772abcd8a767b6.

Earlier blocking feedback about inventory-style validation and page-meta prose is cleared on this head. The new canonical page, registry wiring, focused behavioral tests, local make test, browser verification, and live CI checks all look good.

Remaining finding:

  1. BLOCKING: prd.json still fails the workflow's behavioral-assertion gate for story sampling-overview-concept-page-001.
    • That story is still marked passes:true, but its acceptance criteria in prd.json:25-30 are metadata/structure/quality-gate oriented:
      • canonical backing record remains in use
      • registry relationships connect nearby docs
      • discovery metadata distinguishes the broad concept page
      • typecheck passes
      • tests pass
    • Per the review contract, every story marked passes:true must include at least one observable behavioral assertion. The code now proves behavior, but the PRD acceptance criteria themselves still do not. Please update that story with at least one user-visible behavioral criterion, for example that a representative search or discovery path routes readers to /docs/concepts/sampling-overview rather than only the glossary entry.

Acceptance criteria:

  • PASS: A canonical docs page exists for sampling-overview under the concepts docs tree, binds to registryId: concept.sampling-overview, and renders in the standard docs shell. Verified in src/content/docs/concepts/sampling-overview/page.mdx and in browser at http://127.0.0.1:3462/docs/concepts/sampling-overview.
  • PASS: 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. page.mdx is structural and copy is message-backed.
  • PASS: The opening summary and primary sections explain in simple language that sampling is the post-probability next-token choice step, that different strategies trade predictability against diversity, and that these controls do not change the model's underlying knowledge. Verified in messages/en.json and rendered output.
  • PASS: The page clearly distinguishes the broad overview from deeper pages for temperature, greedy-decoding, top-k-sampling, and top-p-sampling. Verified in sections.commonConfusions and sections.readerPath.
  • PASS: Readers can move cleanly between the canonical overview page, autoregressive-generation, decode, temperature, greedy-decoding, top-k-sampling, top-p-sampling, and at least one nearby GPT-family page through touched related-doc, alias, tag, or focused inline-link surfaces. Verified in registry relationships, rendered inline links, related docs, and a live click-through from the overview page to Decode.
  • PASS: The implementation stays English-only and does not reopen locale infrastructure, tokenizer-family pages, or unrelated model/runtime code. The diff stays narrowly scoped to the new concept page, related registry links, and focused tests.
  • PASS: Focused validation proves the canonical concept page resolves against the existing published registry record and that the touched discovery surfaces remain valid. src/lib/content/sampling-overview-concept-validation.test.ts now checks canonical route resolution, search metadata, sidebar discovery, and live search behavior.
  • PASS: Quality gate: typecheck, lint, and focused touched tests pass. Local make test passed, and live PR checks are green.

Behavioral assertion check for stories marked passes:true:

  • FAIL: sampling-overview-concept-page-001 still has no explicit behavioral assertion in prd.json; this remains the blocking issue.
  • PASS: sampling-overview-concept-page-002 includes route-render and browser-verification behavior.
  • PASS: sampling-overview-concept-page-003 includes observable navigation behavior and browser verification.
  • PASS: sampling-overview-concept-page-004 includes observable route/search/discovery behavior and the implementation now matches that scope.

General website standards:

  • PASS: 1. Architecture and State The change stays inside the existing docs-content, registry, and search architecture without introducing new ownership problems.
  • PASS: 2. Components and Interaction The page reuses shared docs components and keeps orchestration in established layers.
  • PASS: 3. Styling and Visual Consistency The route uses the shared docs shell and established content components.
  • PASS: 4. Accessibility Shared semantic sections, links, and docs chrome are preserved; manual route verification did not reveal accessibility regressions.
  • PASS: 5. Responsive Design No custom layout was introduced; the route remains inside the standard responsive docs shell.
  • PASS: 6. Performance and Resilience This is static docs content plus focused registry/search updates, with low performance risk.
  • PASS: 7. Browser Compatibility and Progressive Enhancement The route rendered and navigated correctly in the browser verification pass.
  • PASS: 8. Localization Copy remains message-backed and English-only without structural localization churn.
  • PASS: 9. Testing and Diagnostics The new tests now prove route, search, and discovery behavior at the right layer.

Docs writing standards:

  • PASS: 1. The page is understandable in isolation and does not define the topic only through one architecture slot, one historical example, or one adjacent page.
  • PASS: 2. The narrative body stays focused on the concept and contains no self-referential, site-structure, process, phase, or page-meta copy.
  • PASS: 3. The first sections explain both what the concept is and why it matters in plain language for a technical layperson.
  • PASS: 4. The title and first narrative mention use the full name before acronyms or shorthand.
  • PASS: 5. Each section has a distinct job and does not restate the same thesis with slightly different wording.
  • PASS: 6. Mathematically heavy pages include the equations, notation, or symbolic derivations needed to teach the idea accurately. This page is not math-heavy, so no extra formalism is required.
  • PASS: 7. Visually, structurally, or conceptually heavy pages include the best graph, diagram, chart, comparison view, or algorithm presentation needed to teach the idea accurately. This overview page does not need a graph to meet its teaching load.
  • PASS: 8. Math sections keep concise symbol-only definitions directly under equations and avoid concept rows such as projections, grouping mechanics, or implementation steps. No math section is present.
  • PASS: 9. Customer-facing copy contains no reader-shortcut callouts, no on this page framing, and no internal workflow language.
  • PASS: 10. References and citations are present where factual claims need support, and every cited reference is correct.
  • PASS: 11. Related docs, tags, and citations support discovery, but the page body does not depend on hand-held cross-page explanation to make sense.
  • PASS: 12. The copy is concise, direct, and conformant with the technical-writing baseline in this document.

Graphing standards:

  • PASS: No graph/chart asset was added, and this concept page does not require one for accurate teaching.

Review-rule pass:

  • PASS: Correctness before style. I did not find a correctness regression in the implementation.
  • PASS: The change solves the stated product problem by adding the canonical concept page and wiring discovery around it.
  • PASS: Architecture and dependency fit stay within the existing docs, registry, and search systems.
  • PASS: Readability and maintainability are good; the page stays structural and the tests are focused.
  • PASS: Test and quality evidence is adequate on the code side: local make test passed, browser verification passed, and live CI is green.
  • FAIL: Workflow acceptance is still blocked because the PRD behavioral-assertion requirement for story sampling-overview-concept-page-001 is not yet satisfied in prd.json.

Validation evidence:

  • Reviewed gh pr diff 209 and the touched files in full.
  • Read surrounding canonical concept/glossary patterns and the required standards docs.
  • Ran make test locally: passed.
  • Checked live PR state with gh pr view 209 --json headRefOid,mergeStateStatus,statusCheckRollup and gh pr checks 209: all green on head 8858bd2a8bbab2a696a0b195f5772abcd8a767b6.
  • Verified the rendered route in the browser at http://127.0.0.1:3462/docs/concepts/sampling-overview and confirmed live navigation to /docs/glossary/decode.
  • The workflow instruction referenced docs/internal/processes/manual-qa.md, but that file does not exist in this worktree, so browser QA was performed directly on the route instead.

REJECTED until the remaining PRD behavioral-assertion blocker above is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant