@sanity/ailf-studio 1.19.0 → 2.0.1

package/dist/index.js

@@ -9,9 +9,9 @@ import { useClient } from "sanity";
 
 // src/lib/constants.ts
 var API_VERSION = "2026-03-11";
-var isProduction = process.env.NODE_ENV === "production";
-var ARTIFACT_API_BASE_URL = isProduction ? "https://ailf-api.sanity.build/v1" : "http://localhost:3000/v1";
 var ENV = globalThis.process?.env ?? {};
+var isProduction = process.env.NODE_ENV === "production";
+var ARTIFACT_API_BASE_URL = ENV.SANITY_STUDIO_AILF_API_BASE_URL ?? (isProduction ? "https://ailf-api.sanity.build/v1" : "http://localhost:3000/v1");
 var REFERENCE_DATASET = ENV.SANITY_STUDIO_AILF_REF_DATASET ?? "next";
 var REFERENCE_WORKSPACE = ENV.SANITY_STUDIO_AILF_REF_WORKSPACE ?? "editorial";
 var AILF_DATASET = ENV.SANITY_STUDIO_AILF_DATASET ?? "ailf-prod-private";
@@ -209,6 +209,529 @@ var FEATURE_FLAGS = {
   }
 };
 
+// ../shared/dist/glossary.js
+var GLOSSARY = {
+  // -- Overview stats -------------------------------------------------------
+  overallScore: {
+    label: "Overall Score",
+    long: "A weighted average across all feature areas, using the gold scoring profile: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%)."
+  },
+  docLift: {
+    label: "Doc Lift",
+    long: "How much the docs help, compared to the model's training data alone. Calculated as ceiling minus floor, where ceiling includes Doc Coverage and floor does not. Higher is better."
+  },
+  actualScore: {
+    label: "Actual Score",
+    long: "How well an AI agent scores when it has to find docs on its own through web search and page fetching. This is the real-world scenario. Only available in full mode."
+  },
+  retrievalGap: {
+    label: "Retrieval Gap",
+    long: "The score lost because agents can't find or use all the relevant docs. Calculated as ceiling minus actual. Lower is better; zero means agents find everything."
+  },
+  infraEfficiency: {
+    label: "Infra Efficiency",
+    long: "What percentage of the docs' potential quality actually reaches agents (actual \xF7 ceiling). 100% means agents find and use all relevant docs perfectly."
+  },
+  // -- Three-layer decomposition columns ------------------------------------
+  floor: {
+    label: "Floor",
+    long: "Output-quality composite without documentation \u2014 Task Completion (60%) and Code Correctness (40%) only. Doc Coverage is excluded because it's undefined when no docs are provided. This tells you what the model already knows from its training data."
+  },
+  ceiling: {
+    label: "Ceiling",
+    long: "Score with gold-standard docs injected directly into the prompt. This is the best the documentation can do."
+  },
+  actual: {
+    label: "Actual",
+    long: "Score when an AI agent finds docs on its own through web search and page fetching. This is the real-world experience."
+  },
+  retGap: {
+    label: "Ret. Gap",
+    long: "Quality lost to discoverability (ceiling minus actual). The gap between what the docs could deliver and what agents actually get."
+  },
+  efficiency: {
+    label: "Efficiency",
+    long: "What fraction of the docs' quality reaches agents in practice (actual \xF7 ceiling, shown as a percentage)."
+  },
+  invertedRetGap: {
+    label: "Inverted Retrieval Gap",
+    long: "\u26A0\uFE0F Inverted retrieval gap: agents that can't find the docs actually score higher, because the docs hurt performance. This usually means there's a doc quality problem."
+  },
+  // -- Per-area score columns -----------------------------------------------
+  score: {
+    label: "Score",
+    long: "Ceiling composite for this feature area: Task Completion \xD7 50% + Code Correctness \xD7 25% + Doc Coverage \xD7 25%."
+  },
+  taskCompletion: {
+    label: "Task Completion",
+    long: "Can the LLM implement the requested feature? Graded 0\u2013100."
+  },
+  codeCorrectness: {
+    label: "Code Correctness",
+    long: "Is the generated code idiomatic, correct, and following best practices? Graded 0\u2013100."
+  },
+  docCoverage: {
+    label: "Doc Coverage",
+    long: "Did the docs provide the information needed to implement the feature? Graded 0\u2013100. This dimension only contributes to the ceiling composite (with docs) \u2014 it's excluded from the floor composite because it's undefined without documentation."
+  },
+  tests: {
+    label: "Tests",
+    long: "Number of test cases in this feature area."
+  },
+  // -- Comparison deltas ----------------------------------------------------
+  overallDelta: {
+    label: "Overall \u0394",
+    long: "Change in overall score between the two runs. Positive means the experiment scored higher."
+  },
+  actualDelta: {
+    label: "Actual \u0394",
+    long: "Change in actual (agent-retrieved) score between runs. Positive means agents did better."
+  },
+  retGapDelta: {
+    label: "Ret. Gap \u0394",
+    long: "Change in retrieval gap between runs. Negative is good here: it means the gap shrank and agents found more relevant docs."
+  },
+  efficiencyDelta: {
+    label: "Efficiency \u0394",
+    long: "Change in infrastructure efficiency between runs. Positive means agents are capturing more of the docs' potential."
+  },
+  // -- Comparison table columns ---------------------------------------------
+  baseline: {
+    label: "Baseline",
+    long: "The reference run you're comparing against."
+  },
+  experiment: {
+    label: "Experiment",
+    long: "The new run you're evaluating."
+  },
+  delta: {
+    label: "Delta",
+    long: "Difference between experiment and baseline. Positive means improvement, negative means regression."
+  },
+  change: {
+    label: "Change",
+    long: "Whether the change is meaningful: improved, regressed, or unchanged (within the noise threshold)."
+  },
+  // -- Grader judgments ------------------------------------------------------
+  lowScoringJudgments: {
+    label: "Low-Scoring Judgments",
+    long: "The grading model's explanations for tests that scored below 70/100."
+  },
+  judgmentReason: {
+    label: "Judgment Reason",
+    long: "The grading model's natural language explanation of what went wrong."
+  },
+  // -- Diagnostics overview ---------------------------------------------------
+  healthStrong: {
+    label: "Strong (80+)",
+    long: "Feature areas scoring 80 or above. The docs are working well for these features \u2014 AI agents produce correct, complete implementations."
+  },
+  healthAttention: {
+    label: "Needs Attention (70\u201379)",
+    long: "Feature areas scoring 70\u201379. These are okay but could be improved \u2014 there may be gaps in specific dimensions like doc coverage or code correctness."
+  },
+  healthWeak: {
+    label: "Weak (<70)",
+    long: "Feature areas scoring below 70. The docs are not providing enough support for AI agents to implement these features correctly."
+  },
+  negativeDocLiftMetric: {
+    label: "Negative Doc Lift",
+    long: "Number of areas where the documentation actually hurts AI performance \u2014 the model scores higher without docs than with them. This usually means the docs contain outdated patterns or incorrect examples."
+  },
+  weakAreas: {
+    label: "Weak Areas",
+    long: "Feature areas where the overall score is below 70. These need the most attention \u2014 low scores mean AI agents consistently struggle to implement these features."
+  },
+  docsHurt: {
+    label: "Docs Hurt Performance",
+    long: "Areas where the floor score (no docs) is higher than the ceiling score (with docs). The documentation may be actively misleading the model. These docs should be reviewed."
+  },
+  retrievalIssues: {
+    label: "Retrieval Issues",
+    long: "Areas where AI agents can find less than 70% of the available doc quality. The docs exist and are good, but agents can't discover them through search. Consider improving page titles, metadata, or search engine indexing."
+  },
+  dimWeaknesses: {
+    label: "Dimension Weaknesses",
+    long: "Individual grading dimensions scoring below 50 within an area. These are the specific skills where AI agents fail most \u2014 task completion (can it build the feature?), code correctness (is the code right?), or doc coverage (did it use the docs?)."
+  },
+  efficiencyAnomalies: {
+    label: "Efficiency Anomalies",
+    long: "Areas where agent efficiency exceeds 100% \u2014 meaning agents perform better with self-found docs than with gold-standard docs injected directly. This can indicate doc quality issues (injected docs confuse the model) or agent memorization."
+  },
+  docLiftWins: {
+    label: "Doc Lift Wins",
+    long: "Areas where documentation boosts AI performance by 5 or more points. Higher doc lift means the docs are providing crucial information that the model doesn't already know."
+  },
+  retrievalExcellence: {
+    label: "Retrieval Excellence",
+    long: "Areas where AI agents successfully find and use at least 85% of the available doc quality through web search. Good retrieval means your docs are well-indexed and easy for agents to discover."
+  },
+  // -- Model breakdown --------------------------------------------------------
+  modelBreakdown: {
+    label: "Model Breakdown",
+    long: "Break down scores by individual LLM model. The default 'All Models' view shows the cross-model average. Select a specific model to see how it performed independently \u2014 useful for spotting models that struggle with specific feature areas."
+  },
+  // -- Strengths (positive diagnostics) ---------------------------------------
+  strengths: {
+    label: "Strengths",
+    long: "What's working well: high-scoring areas, dimensions where the docs are strong, and areas where AI agents successfully find and use the documentation."
+  },
+  // -- Recommendations / gap analysis ----------------------------------------
+  recommendations: {
+    label: "Recommendations",
+    long: "Prioritized remediation plan from gap analysis. Each recommendation identifies a documentation problem, the affected feature area, and the estimated score lift from fixing it."
+  },
+  totalPotentialLift: {
+    label: "Total Potential Lift",
+    long: "Aggregate potential score lift if all identified gaps were fixed. This is a conservative estimate \u2014 each gap targets the median of non-bottlenecked dimensions, not 100."
+  },
+  failureMode: {
+    label: "Failure Mode",
+    long: "The type of failure the grader emitted. Cross-cutting modes apply to any dimension (api-error, model-limitation, false-floor, unclassified). Per-dimension extensions cover documentation problems (missing-docs, incorrect-docs, outdated-docs, poor-structure), spec adherence (spec-mismatch), tool use (tool-misuse, chaotic-process, missing-recovery), and knowledge probes (factual-error, incompleteness, currency-violation, hallucination)."
+  },
+  estimatedLift: {
+    label: "Estimated Lift",
+    long: "Estimated composite score improvement if this gap is fully fixed. Based on raising bottleneck dimensions to the median of non-bottlenecked dimensions."
+  },
+  confidence: {
+    label: "Confidence",
+    long: "How confident we are in this diagnosis (D0049 ceiling-cross-check derivation). High = the grader's emitted failure mode agrees with the structural ceiling-decomposition signal. Medium = signals disagree (or the ceiling pattern is not informative for this score). Low = passing scores never classify; treat as absent."
+  },
+  // -- Agent behavior --------------------------------------------------------
+  agentBehaviorOverview: {
+    label: "Agent Behavior",
+    long: "How AI agents interacted with your documentation during evaluation: what they searched for, which pages they visited, and how much time they spent on network requests."
+  },
+  searchQueries: {
+    label: "Search Queries",
+    long: "The exact search queries agents used to find documentation. Helps you understand how agents discover your content and whether your docs appear for relevant queries."
+  },
+  docSlugsVisited: {
+    label: "Unique Doc Slugs",
+    long: "Documentation page slugs that agents actually visited during evaluation. Compare against canonical docs to see if agents found the right pages."
+  },
+  externalDomains: {
+    label: "External Domains",
+    long: "Non-Sanity domains that agents contacted during evaluation. High external domain counts may indicate agents couldn't find what they needed in your docs."
+  },
+  avgDocPagesVisited: {
+    label: "Avg Pages Visited",
+    long: "Average number of documentation pages visited per test. Higher counts can mean agents need to consult many pages (complex task) or can't find the right one quickly."
+  },
+  avgSearchesPerformed: {
+    label: "Avg Searches",
+    long: "Average number of web searches performed per test. High search counts can indicate docs are hard to discover through search engines."
+  },
+  avgNetworkTimeMs: {
+    label: "Avg Network Time",
+    long: "Average time spent on network requests per test. Includes page fetches, search queries, and API calls."
+  },
+  totalRequests: {
+    label: "Total Requests",
+    long: "Total number of HTTP requests the agent made during the test, including searches, page visits, and API calls."
+  },
+  totalBytesDownloaded: {
+    label: "Total Bytes Downloaded",
+    long: "Total bytes downloaded by the agent. Large downloads may indicate the agent is fetching many pages or very large documents."
+  },
+  // -- Dimension deltas -----------------------------------------------------
+  dimTaskCompletion: {
+    label: "Task Completion \u0394",
+    long: "Change in task completion between runs. Positive means implementations are more complete."
+  },
+  dimCodeCorrectness: {
+    label: "Code Correctness \u0394",
+    long: "Change in code correctness between runs. Positive means better code quality."
+  },
+  dimDocCoverage: {
+    label: "Doc Coverage \u0394",
+    long: "Change in doc coverage between runs. Positive means the docs are providing more useful information."
+  },
+  // -- Per-area trend delta ----------------------------------------------------
+  areaDelta: {
+    label: "Area \u0394",
+    long: "Score change for this area compared to the previous evaluation run."
+  },
+  // -- Source values -----------------------------------------------------------
+  sourceProduction: {
+    label: "Production",
+    long: "Production source \u2014 docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today."
+  },
+  sourceBranch: {
+    label: "Branch",
+    long: "Branch source \u2014 docs fetched from a branch or draft dataset. Use this to preview how content changes affect scores before publishing."
+  },
+  sourceLocal: {
+    label: "Local",
+    long: "Local source \u2014 docs fetched from local files or a local dev server. Useful for testing doc changes before pushing."
+  },
+  // -- Report list columns ----------------------------------------------------
+  reportScore: {
+    label: "Score",
+    long: "The overall ceiling composite for this evaluation run: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%), averaged across all feature areas."
+  },
+  reportMode: {
+    label: "Mode",
+    long: "The evaluation mode determines which reference points are measured. Different modes test different aspects of how AI agents interact with documentation."
+  },
+  reportTrigger: {
+    label: "Trigger",
+    long: "What initiated this evaluation run. Knowing the trigger helps you understand whether a score change was from a content edit, a code deploy, or a scheduled check."
+  },
+  // -- Mode values -----------------------------------------------------------
+  modeBaseline: {
+    label: "Baseline",
+    long: "Baseline mode \u2014 tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do)."
+  },
+  modeFull: {
+    label: "Full",
+    long: "Full mode \u2014 runs baseline + agentic. Compares ceiling (injected docs) against actual (agent-retrieved docs) to measure retrieval gap and infrastructure efficiency."
+  },
+  modeAgentic: {
+    label: "Agentic",
+    long: "Agentic mode \u2014 the AI agent finds docs on its own via web search. Measures real-world performance: can agents actually discover and use your documentation?"
+  },
+  modeObserved: {
+    label: "Observed",
+    long: "Observed mode \u2014 records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis."
+  },
+  modeDebug: {
+    label: "Debug",
+    long: "Debug mode \u2014 a diagnostic run for pipeline development. May use non-standard configurations or limited task sets."
+  },
+  // -- Trigger values --------------------------------------------------------
+  triggerManual: {
+    label: "Manual",
+    long: "Manually triggered \u2014 someone ran the evaluation pipeline by hand, either locally or via the Studio UI."
+  },
+  triggerCi: {
+    label: "CI",
+    long: "CI-triggered \u2014 the evaluation ran automatically as part of a pull request or merge pipeline."
+  },
+  triggerSchedule: {
+    label: "Scheduled",
+    long: "Scheduled \u2014 the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time."
+  },
+  triggerWebhook: {
+    label: "Webhook",
+    long: "Webhook-triggered \u2014 a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early."
+  },
+  triggerCrossRepo: {
+    label: "Cross-Repo",
+    long: "Cross-repo \u2014 triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks."
+  }
+};
+
+// ../shared/dist/generated/help-content.js
+var HELP_TOPICS = [
+  {
+    "id": "negative-doc-lift",
+    "title": "When Docs Hurt: Negative Doc Lift",
+    "body": `The ceiling score is _lower_ than the floor score. The canonical docs actively
+hurt the model's performance. This is a negative Doc Lift: the model produces
+better output from its training data alone than when given the "correct"
+documentation.
+
+This will happen. It is not an error condition \u2014 it is a high-signal diagnostic
+that demands investigation. A negative Doc Lift means one or more of the
+following:
+
+- **Outdated documentation** \u2014 the docs describe an older API version or
+  pattern, and the model's training data has absorbed a newer version. The docs
+  are actively teaching the model the wrong thing. _Action: update the docs to
+  reflect the current API._
+
+- **Misleading documentation** \u2014 the docs are technically accurate but
+  structured in a way that leads the model to an incorrect implementation path.
+  Ambiguous phrasing, conflicting code examples, or poor organization can cause
+  a model to produce worse code than its baseline intuition. _Action:
+  restructure or rewrite the docs for clarity._
+
+- **Adversarial context dilution** \u2014 the canonical doc set is too large or
+  contains too much tangential content, and the relevant signal gets buried in
+  noise. The model performs better with no docs because fewer tokens means less
+  distraction. _Action: trim the canonical doc set or restructure docs to
+  front-load the most relevant information._
+
+- **Model training data superiority** \u2014 for mature, well-known features (e.g.,
+  basic GROQ queries, standard Studio setup), the model may have absorbed
+  high-quality examples from training data (blog posts, Stack Overflow, open
+  source code) that are simply better than the official documentation. _Action:
+  improve the docs to meet or exceed the quality of community content the model
+  learned from._`,
+    "source": "docs/design-docs/scenario-matrix/evaluation-ceiling.md",
+    "related": [
+      "doc-lift",
+      "three-layer"
+    ]
+  },
+  {
+    "id": "three-layer",
+    "title": "Floor, Ceiling, and Actual Scores",
+    "body": "- **Doc Lift** = `ceiling score \u2212 floor score`. Positive when docs help,\n  negative when docs hurt. This is the fundamental documentation value metric.\n  When negative, it triggers the interference investigation described above\n- **Retrieval gap** = `ceiling score \u2212 agentic score`. The cost of imperfect\n  discovery. Should be minimized via infrastructure investment (`llms.txt`,\n  `.md` endpoints, better navigation, SEO). Note: this metric is only meaningful\n  when Doc Lift is positive \u2014 if the docs themselves are harmful, a large\n  retrieval gap might paradoxically be _protective_ (agents that can't find the\n  bad docs may outperform agents that can)\n- **Doc quality gap** = `100 \u2212 ceiling score`. The ceiling itself is below\n  perfect. This is the documentation team's problem \u2014 the docs need improvement\n  regardless of how they're delivered\n- **Infrastructure efficiency** = `agentic score / ceiling score`. What fraction\n  of the documentation's potential value actually reaches agents? A ratio of\n  0.90 means infrastructure delivers 90% of the doc quality. A ratio of 0.50\n  means half the documentation value is lost in delivery. When the ceiling is\n  below the floor, this ratio is undefined \u2014 report it as \"N/A (negative Doc\n  Lift)\" rather than producing a misleading number\n\n### Decomposition: the healthy case (positive Doc Lift)\n\n```\nfloor score                      \u2192 model's inherent knowledge\n  + Doc Lift (ceiling \u2212 floor)   \u2192 documentation quality contribution\n  \u2212 retrieval gap (ceiling \u2212 agentic) \u2192 discovery/infrastructure loss\n  = agentic score                \u2192 what users actually experience\n```\n\n### Decomposition: the interference case (negative Doc Lift)\n\n```\nfloor score                      \u2192 model's inherent knowledge\n  \u2212 |Doc Lift| (floor \u2212 ceiling) \u2192 documentation interference penalty\n  \u2212 retrieval gap (ceiling \u2212 agentic) \u2192 discovery/infrastructure loss\n  = agentic score                \u2192 what users actually experience\n\n  but note: agentic score may exceed ceiling score here, because\n  agents that fail to find the interfering docs avoid the penalty.\n  In this case the \"retrieval gap\" inverts \u2014 poor retrieval is a\n  net positive. The framework should flag this explicitly:\n  \"Retrieval failure is masking a documentation quality problem.\"\n```\n\nBoth decompositions are valid expressions of the **core measurement model**.\nEvery scenario in the matrix is asking about one or more of these three layers:\ninherent knowledge, documentation quality, or discovery effectiveness. The sign\nof the Doc Lift determines which layer needs urgent attention.",
+    "source": "docs/design-docs/scenario-matrix/evaluation-ceiling.md",
+    "related": [
+      "doc-lift",
+      "negative-doc-lift",
+      "retrieval-gap",
+      "scoring-model"
+    ]
+  },
+  {
+    "id": "comparing-runs",
+    "title": "Comparing Evaluation Runs",
+    "body": "## How comparison works\n\nThe Compare view lets you select any two evaluation reports and see a detailed\nside-by-side breakdown. One report is the **baseline** (your reference point)\nand the other is the **experiment** (what you're evaluating).\n\n## Reading the comparison\n\nFor each feature area, you'll see:\n\n- **Delta** \u2014 The score difference (experiment minus baseline). Positive means\n  the experiment scored higher.\n- **Change** \u2014 Whether the delta is meaningful: **improved**, **regressed**, or\n  **unchanged**. This accounts for the noise threshold \u2014 small deltas within the\n  noise band are marked unchanged even if they're non-zero.\n\n## The noise threshold\n\nNot every score change is real. LLM responses vary between runs, and the grader\nmodel has its own variance. The comparison applies a noise threshold (currently\nconfigured per-evaluation) to filter out statistical noise. Only changes that\nexceed this threshold are classified as improvements or regressions.\n\n## What to compare\n\n- **Before and after a doc change** \u2014 Did your edits actually improve scores?\n- **Production vs. branch** \u2014 Will publishing this content release help or hurt?\n- **Different models** \u2014 How does Claude compare to GPT on the same docs?\n- **Baseline vs. full mode** \u2014 Is the retrieval gap shrinking over time?\n\n## Per-area deltas\n\nThe most actionable part of the comparison is the per-area breakdown. If your\noverall score improved but one area regressed, the per-area deltas tell you\nexactly which area needs attention.",
+    "source": "docs/help/comparing-runs.md",
+    "related": [
+      "reading-score-trends",
+      "scoring-model"
+    ]
+  },
+  {
+    "id": "doc-lift",
+    "title": "Doc Lift: Do Your Docs Help?",
+    "body": "## What is doc lift?\n\n**Doc lift** is the difference between how an AI performs _with_ your\ndocumentation and how it performs _without_ it:\n\n```\nDoc lift = ceiling score \u2212 floor score\n```\n\n- **Ceiling score** \u2014 the AI's score when gold-standard docs are injected\n  directly into its prompt.\n- **Floor score** \u2014 the AI's score with no documentation at all, relying only on\n  its training data.\n\nA positive doc lift means your docs are helping. The higher the number, the more\nvalue your documentation provides beyond what the model already knows.\n\n## What good doc lift looks like\n\n- **Doc lift of 15+** \u2014 Your docs are providing crucial information the model\n  doesn't already know. This is a strong signal that the docs are worth\n  maintaining and improving.\n- **Doc lift of 5\u201315** \u2014 Docs are helping, but the model's training data covers\n  a lot of the ground already. The docs are adding incremental value.\n- **Doc lift near zero** \u2014 The docs aren't adding much. Either the model already\n  knows the material, or the docs aren't providing useful implementation\n  guidance.\n\n## Negative doc lift\n\nA **negative** doc lift means the documentation is actively hurting the AI's\nperformance \u2014 the model produces _better_ code without your docs than with them.\nThis is never ignorable. See the \"When Docs Hurt\" help topic for causes and\nremediation.\n\n## Where you see it\n\nDoc lift appears in several places in the dashboard:\n\n- **Overview stats** \u2014 The aggregate doc lift across all areas.\n- **Per-area score table** \u2014 Doc lift for each feature area, so you can see\n  which docs help most and which help least.\n- **Comparison view** \u2014 Doc lift deltas between two runs, showing whether your\n  doc changes increased or decreased documentation value.",
+    "source": "docs/help/doc-lift.md",
+    "related": [
+      "three-layer",
+      "negative-doc-lift",
+      "scoring-model"
+    ]
+  },
+  {
+    "id": "getting-started",
+    "title": "Getting Started",
+    "body": `## What does AILF measure?
+
+The AI Literacy Framework measures how well your documentation helps AI coding
+tools (like Claude Code, Cursor, ChatGPT, and Copilot) implement features
+correctly. When a developer asks an AI agent "set up a webhook in Sanity," the
+agent needs to find the right docs and produce working code. AILF scores how
+well that goes.
+
+## The key number: AI Literacy Score
+
+Every evaluation produces a score from 0\u2013100, composed of three dimensions:
+
+- **Task Completion (50%)** \u2014 Can the AI implement the feature at all?
+- **Code Correctness (25%)** \u2014 Is the generated code correct and idiomatic?
+- **Doc Coverage (25%)** \u2014 Did the docs provide the information needed?
+
+Higher is better. Scores above 80 mean the docs are working well for that
+feature. Scores below 70 need attention.
+
+## What you see in the dashboard
+
+- **Latest Reports** \u2014 The most recent evaluation runs with scores, areas
+  tested, and trend indicators.
+- **Score Timeline** \u2014 How scores change over time. Look for upward trends after
+  doc improvements.
+- **Compare** \u2014 Side-by-side comparison of any two runs to see what improved or
+  regressed.
+
+Click into any report for the full breakdown: per-area scores, diagnostics, and
+(for full-mode runs) how AI agents actually navigated your docs.
+
+## Quick orientation
+
+| If you see\u2026         | It means\u2026                                            |
+| ------------------- | ---------------------------------------------------- |
+| A score above 80    | Docs are working well for this area                  |
+| A score below 70    | Docs need improvement \u2014 AI agents struggle here      |
+| Positive doc lift   | Docs are helping (good!)                             |
+| Negative doc lift   | Docs are hurting \u2014 they're worse than no docs at all |
+| Large retrieval gap | Good docs exist but agents can't find them           |`,
+    "source": "docs/help/getting-started.md",
+    "related": [
+      "scoring-model",
+      "eval-modes"
+    ]
+  },
+  {
+    "id": "interpreting-diagnostics",
+    "title": "Interpreting Diagnostics",
+    "body": "## The diagnostics tab\n\nWhen you open a report and click the **Diagnostics** tab, you see a health\nsummary of your documentation across all feature areas. This is the most\nactionable view in the dashboard \u2014 it tells you exactly where to focus your doc\nimprovement efforts.\n\n## Health categories\n\nFeature areas are grouped into three health bands:\n\n- **Strong (80+)** \u2014 Docs are working well. AI agents produce correct, complete\n  implementations. No action needed unless you see regression.\n- **Needs Attention (70\u201379)** \u2014 Docs are okay but have gaps. There may be\n  specific dimensions (like code correctness or doc coverage) dragging the score\n  down. Worth investigating.\n- **Weak (below 70)** \u2014 Docs are not providing enough support. AI agents\n  consistently struggle with these features. These need priority attention.\n\n## Strengths vs. Issues\n\nThe diagnostics tab has two sub-views:\n\n**Strengths** highlights what's working: high-scoring areas, strong dimensions,\nand areas where agents successfully find and use your docs. Use this to\nunderstand what good looks like in your docs \u2014 and replicate it elsewhere.\n\n**Issues** lists the problems: weak areas, dimensions scoring below 50, negative\ndoc lift, retrieval problems, and (if gap analysis was run) specific\nrecommendations with estimated score lift.\n\n## Key diagnostic signals\n\n| Signal                         | What it means                              | What to do                               |\n| ------------------------------ | ------------------------------------------ | ---------------------------------------- |\n| **Negative doc lift**          | Docs are worse than no docs                | Rewrite or remove the offending docs     |\n| **Large retrieval gap**        | Good docs exist but agents can't find them | Improve page titles, metadata, SEO       |\n| **Low code correctness**       | Agents find the docs but produce bad code  | Add or fix code examples                 |\n| **Low doc coverage**           | The docs don't cover what the task needs   | Write new documentation                  |\n| **Efficiency anomaly (>100%)** | Agents do better without gold docs         | Injected docs may be confusing the model |",
+    "source": "docs/help/interpreting-diagnostics.md",
+    "related": [
+      "scoring-model",
+      "weaknesses-recommendations"
+    ]
+  },
+  {
+    "id": "reading-score-trends",
+    "title": "Reading Score Trends",
+    "body": "## What the timeline shows\n\nThe Score Timeline view plots your AI Literacy Score over time. Each point is an\nevaluation run \u2014 a snapshot of how well your docs support AI agents at that\nmoment.\n\n## What to look for\n\n**Upward trends** after doc changes confirm that your improvements are working.\nIf you rewrote a GROQ guide and the GROQ area score climbs in the next run,\nthat's direct evidence of impact.\n\n**Sudden drops** usually mean something changed: a doc was deleted, an API\nchanged without a doc update, or a new task was added that exposes a gap.\n\n**Flat lines** mean stability \u2014 neither improving nor regressing. This is fine\nfor mature areas but concerning for areas you're actively working on.\n\n## Meaningful change vs. noise\n\nSmall fluctuations (\xB12\u20133 points) between runs are normal \u2014 they come from LLM\nnon-determinism and grader variance. Focus on changes of **5+ points** sustained\nacross multiple runs. The comparison view applies a noise threshold to help\ndistinguish real changes from statistical noise.\n\n## Filtering the timeline\n\nUse the filters to focus on specific evaluation modes (baseline vs. full),\nspecific doc sources (production vs. branch), or specific feature areas.\nComparing the same area across modes reveals whether a problem is in the docs\nthemselves (baseline score) or in how agents find them (agentic score).",
+    "source": "docs/help/reading-score-trends.md",
+    "related": [
+      "scoring-model",
+      "comparing-runs"
+    ]
+  },
+  {
+    "id": "retrieval-gap",
+    "title": "Retrieval Gap & Infrastructure Efficiency",
+    "body": "## What is the retrieval gap?\n\nThe **retrieval gap** is the difference between the **ceiling score** (docs\ninjected directly into the AI's prompt) and the **actual score** (the AI agent\nfinds docs on its own via web search). It measures how much documentation\nquality is lost because agents can't find the right pages.\n\n```\nRetrieval gap = ceiling score \u2212 actual score\n```\n\nA retrieval gap of zero means agents find everything. A gap of 20 means 20\npoints of doc quality never reach the agents.\n\n## What is infrastructure efficiency?\n\n**Infrastructure efficiency** expresses the retrieval gap as a ratio:\n\n```\nInfrastructure efficiency = actual score / ceiling score\n```\n\nAn efficiency of 90% means agents capture 90% of your docs' potential. An\nefficiency of 50% means half the documentation value is lost to discoverability\nproblems.\n\n## What causes a large retrieval gap?\n\n- **Poor page titles** \u2014 Agents search by keyword. If your page title doesn't\n  match what a developer would ask, agents won't find it.\n- **Missing from search indexes** \u2014 Pages that aren't indexed by search engines\n  are invisible to agents that rely on web search.\n- **No `llms.txt`** \u2014 An `llms.txt` file gives agents a table of contents.\n  Without it, they rely entirely on search queries.\n- **No `.md` endpoints** \u2014 Agents that can fetch clean markdown directly\n  (instead of parsing HTML) get better context with less noise.\n- **Content spread across many pages** \u2014 If implementing a feature requires\n  reading 5 different pages, agents are less likely to find all of them.\n\n## How to shrink the retrieval gap\n\n1. **Add clear, keyword-rich page titles** that match how developers phrase\n   their questions.\n2. **Ensure pages are indexed** by search engines (no `noindex` meta tags on doc\n   pages).\n3. **Provide `llms.txt`** at your docs root so agents can browse a structured\n   table of contents.\n4. **Provide `.md` endpoints** so agents can fetch clean markdown instead of\n   parsing JavaScript-rendered HTML.\n5. **Consolidate related content** \u2014 fewer, more comprehensive pages are easier\n   for agents to find than many small fragments.\n\n## When the retrieval gap inverts\n\nIn rare cases, the actual score exceeds the ceiling score \u2014 agents that can't\nfind the docs perform _better_ than agents with gold-standard docs injected.\nThis means the docs themselves are hurting performance (negative doc lift), and\nagents that fail to find them accidentally avoid the damage. The dashboard flags\nthis as an **inverted retrieval gap** \u2014 it's a documentation quality problem,\nnot a discoverability win.",
+    "source": "docs/help/retrieval-gap.md",
+    "related": [
+      "three-layer",
+      "eval-modes",
+      "how-agents-work"
+    ]
+  },
+  {
+    "id": "scoring-model",
+    "title": "Understanding Scores",
+    "body": "## The three dimensions\n\nEvery evaluation task is scored on three dimensions, each graded 0\u2013100:\n\n- **Task Completion (50% weight)** \u2014 Can the AI implement the requested feature?\n  Does the output actually do what was asked?\n- **Code Correctness (25% weight)** \u2014 Is the generated code idiomatic, correct,\n  and following best practices?\n- **Doc Coverage (25% weight)** \u2014 Did the documentation provide the information\n  needed to implement the feature?\n\n## How the overall score is calculated\n\nThe three dimensions combine into a single **AI Literacy Score** per task using\nnamed scoring profiles from `config/rubrics.yaml`:\n\n```\nGold (with docs):    Total = Task \xD7 0.50 + Code \xD7 0.25 + Docs \xD7 0.25\nBaseline (no docs):  Total = Task \xD7 0.60 + Code \xD7 0.40\n```\n\nThe gold profile includes all three dimensions. The baseline profile excludes\nDoc Coverage because it is undefined when no documentation is provided. This\nensures Doc Lift (ceiling \u2212 floor) is a clean structural measurement of\ndocumentation value.\n\nThe weighted composite produces a score from 0\u2013100. Scores are then averaged\nacross all tasks in a feature area to produce a **per-area score**, and across\nall areas to produce the **overall score**.\n\n## What the numbers mean\n\n| Score range  | Interpretation                                                    |\n| ------------ | ----------------------------------------------------------------- |\n| **80\u2013100**   | Docs are working well \u2014 AI agents produce correct implementations |\n| **70\u201379**    | Needs attention \u2014 there may be gaps in specific dimensions        |\n| **Below 70** | Weak \u2014 AI agents consistently struggle with this area             |\n\n## Ceiling decomposition (baseline mode)\n\nWhen running in baseline mode, each task is evaluated twice \u2014 with and without\ndocumentation. This produces:\n\n- **Floor score** \u2014 Score without docs (what the model knows from training data\n  alone)\n- **Ceiling score** \u2014 Score with gold-standard docs injected directly into the\n  prompt\n- **Doc Lift** \u2014 Ceiling minus floor. Positive means docs help; negative means\n  docs hurt.\n- **Doc Quality Gap** \u2014 100 minus ceiling. Room for documentation improvement.\n\n## Three-layer decomposition (full mode)\n\nFull mode adds a third measurement \u2014 what happens when AI agents find docs on\ntheir own:\n\n- **Floor** \u2014 No docs (parametric knowledge only)\n- **Ceiling** \u2014 Gold-standard docs injected (best the docs can do)\n- **Actual** \u2014 Agent-retrieved docs (real-world performance)\n- **Retrieval Gap** \u2014 Ceiling minus actual (quality lost to findability)\n- **Infrastructure Efficiency** \u2014 Actual \xF7 ceiling (what fraction of doc quality\n  reaches agents)\n\n## Cost tracking\n\nEach evaluation also tracks token costs:\n\n- **Provider cost** \u2014 Token usage for generating implementations\n- **Grader cost** \u2014 Token usage for the grading model's assessments\n- **Total cost** \u2014 Both combined, reported in the score summary",
+    "source": "docs/help/scoring-model.md",
+    "related": [
+      "three-layer",
+      "doc-lift",
+      "eval-modes"
+    ]
+  },
+  {
+    "id": "weaknesses-recommendations",
+    "title": "Weaknesses & Recommendations",
+    "body": "## Understanding weaknesses\n\nThe Issues sub-tab in Diagnostics lists every area or dimension that scored\nbelow threshold. Each weakness entry shows:\n\n- **The feature area** \u2014 Which product feature is affected (e.g., GROQ,\n  Functions, Webhooks).\n- **The bottleneck dimension** \u2014 Which scoring dimension is dragging the area\n  down: task completion, code correctness, or doc coverage.\n- **The score** \u2014 How far below threshold the dimension scored.\n\n## Gap analysis recommendations\n\nWhen an evaluation runs with gap analysis enabled, the dashboard shows\n**prioritized recommendations** \u2014 specific actions ranked by estimated impact.\n\nEach recommendation includes:\n\n- **Failure mode** \u2014 The type of doc problem identified:\n  - `missing-docs` \u2014 The functionality isn't documented at all.\n  - `incorrect-docs` \u2014 The docs contain factual errors.\n  - `outdated-docs` \u2014 The docs describe an old API version or pattern.\n  - `poor-structure` \u2014 The docs exist but are hard to find or understand.\n- **Estimated lift** \u2014 How many score points fixing this gap would add. Based on\n  raising the bottleneck dimension to the median of non-bottleneck dimensions.\n  Conservative estimate \u2014 actual improvement may be higher.\n- **Confidence** \u2014 How sure the analysis is about this diagnosis (high, medium,\n  or low).\n- **Affected tasks** \u2014 Which specific evaluation tasks exposed this gap.\n\n## Low-scoring judgments\n\nBelow the recommendations, you'll find the **grader's explanations** for tests\nthat scored below 70. These are the raw assessments from the grading model\nexplaining exactly what went wrong \u2014 missing API calls, incorrect patterns,\nhallucinated features, etc.\n\nEach judgment shows the task, the dimension, the score, and the grader's natural\nlanguage reason. These are the most granular diagnostic signal available and\noften point directly to the doc section that needs fixing.",
+    "source": "docs/help/weaknesses-recommendations.md",
+    "related": [
+      "interpreting-diagnostics",
+      "scoring-model",
+      "negative-doc-lift"
+    ]
+  },
+  {
+    "id": "how-agents-work",
+    "title": "How AI Agents Find Documentation",
+    "body": "Understanding how popular AI coding agents retrieve and use documentation is\ncentral to the ai-literacy-framework evaluation framework. This document\nexplains the mechanisms used by common agents and how our test modes simulate\nthem.\n\n## The Documentation Access Problem\n\nWhen a developer asks an AI coding assistant \"Set up a Sanity Studio with a\ncustom blog schema,\" the agent needs to find and read the relevant Sanity\ndocumentation. But different agents do this in fundamentally different ways, and\nthose differences directly impact the quality of the response.\n\nThe framework measures this impact through four evaluation modes: **full**\n(default \u2014 runs baseline + agentic together), **baseline** (docs in prompt),\n**agentic** (tool-calling with real web access), and **observed** (instrumented\nsingle-call).\n\n## How Popular Agents Work\n\n### Claude Code (Anthropic)\n\nClaude Code has built-in tools including `WebSearchTool` and `WebFetchTool`.\nWhen a user asks a Sanity question:\n\n1. The model decides whether to search the web\n2. If so, it calls `WebSearchTool` with a query string\n3. Search results come back as structured data (titles, URLs, snippets)\n4. The model may call `WebFetchTool` to read specific pages\n5. The fetched content is returned as **rendered text** \u2014 Claude Code's fetch\n   tool handles JavaScript rendering internally, so even SPA pages return\n   readable content\n6. The model synthesizes the fetched docs with its training data to produce an\n   answer\n\n**Key characteristic**: Claude Code sees the web as rendered, readable text. It\ndoesn't get raw HTML soup. But it also doesn't know about agent-friendly\nendpoints like `.md` files or `llms.txt` \u2014 it fetches the same HTML pages a\nbrowser would load.\n\n### ChatGPT (OpenAI)\n\nChatGPT's browsing capability uses Bing search under the hood:\n\n1. The model decides to search (users can also explicitly ask it to browse)\n2. It searches via Bing, getting ranked results\n3. It can \"click\" on results to read page content\n4. Pages are rendered server-side and returned as text\n5. The model reads relevant sections and synthesizes an answer\n\n**Key characteristic**: ChatGPT's browsing is similar to Claude Code \u2014 it gets\nrendered content. The URLs visited are returned in citations. It also has no\nawareness of `llms.txt` or `.md` endpoints.\n\n### Cursor\n\nCursor takes a different approach:\n\n1. It maintains a pre-built index of popular documentation sites (`@docs`)\n2. Users can manually add documentation sources\n3. It also has web search capability for unknown topics\n4. Codebase context is injected automatically from the project\n\n**Key characteristic**: Cursor's `@docs` feature means it may have indexed\nSanity docs already, but the index may be outdated. For unknown topics, it falls\nback to web search like the other agents.\n\n### GitHub Copilot\n\nCopilot primarily relies on:\n\n1. The model's training data (parametric knowledge)\n2. Codebase context from the current project\n3. Bing search for `@workspace` queries in newer versions\n\n**Key characteristic**: Copilot historically had no web access, relying entirely\non training data. Newer versions can search, but the experience is similar to\nChatGPT.\n\n## The JavaScript SPA Problem\n\nSanity's documentation site (`sanity.io/docs`) is built with Next.js \u2014 a\nJavaScript single-page application. When an agent makes a raw HTTP request:\n\n```\nGET https://www.sanity.io/docs/schema-types\n\u2192 Returns ~125KB of HTML that is mostly:\n  - <script> tags for Next.js bundles\n  - React hydration data\n  - Navigation chrome\n  - Very little actual documentation text\n```\n\nReal agents handle this differently than a raw `fetch()`:\n\n| Agent         | Raw fetch? | Gets readable content? | How?                               |\n| ------------- | ---------- | ---------------------- | ---------------------------------- |\n| Claude Code   | No         | Yes                    | Built-in rendering in WebFetchTool |\n| ChatGPT       | No         | Yes                    | Server-side rendering via Bing     |\n| Cursor        | No         | Yes                    | Pre-built doc index                |\n| Raw `fetch()` | Yes        | **No**                 | Gets HTML soup                     |\n\nThis is why the agentic provider uses **Jina Reader** (`r.jina.ai`) as a\nreadability proxy in \"naive\" mode \u2014 it simulates the rendering capability that\nreal agents have built in.\n\n## Sanity's Agent-Friendly Endpoints\n\nSanity has invested in making their documentation accessible to AI agents\nthrough special endpoints:\n\n### `.md` endpoint\n\nAppending `.md` to any docs URL returns pure markdown:\n\n```\nGET https://www.sanity.io/docs/schema-types.md\nContent-Type: text/markdown;charset=UTF-8\n\n# Schema types\nSchema types are used to define the shape of your content...\n```\n\nThis returns **clean markdown** \u2014 no HTML, no JavaScript, no navigation. Just\nthe documentation content. Typical response size: 2-10KB (vs 125KB for the HTML\npage).\n\n### `llms.txt`\n\nSanity provides an `llms.txt` file at `https://www.sanity.io/docs/llms.txt` \u2014 a\nstructured listing of all documentation pages designed for AI agent consumption:\n\n```\n# Sanity\n## Docs\n- [Manage Sanity with code](https://www.sanity.io/docs/blueprints)\n- [Introduction](https://www.sanity.io/docs/blueprints-introduction)\n- [Deploy with GitHub Actions](https://www.sanity.io/docs/blueprints/blueprint-action)\n...\n```\n\nThis follows the emerging [llms.txt standard](https://llmstxt.org/) \u2014 a\nmachine-readable table of contents that tells agents what documentation is\navailable and where to find it.\n\n### Impact on Agent Performance\n\nOur smoke tests show the dramatic difference these endpoints make:\n\n| Metric           | Naive Agent (Jina) | Optimized Agent (.md) |\n| ---------------- | ------------------ | --------------------- |\n| Result           | \u274C FAIL            | \u2705 PASS               |\n| Latency          | 57.9s              | 15.2s (3.8\xD7 faster)   |\n| Bytes downloaded | 108 KB             | 59 KB (45% less)      |\n| Total requests   | 9                  | 6 (33% fewer)         |\n| Search queries   | 3                  | 0 (used llms.txt)     |\n\nThe optimized agent skips search entirely \u2014 it calls `list_docs(\"sanity.io\")` to\nget the `llms.txt` table of contents, identifies the relevant pages, and fetches\nthem directly as `.md`. No search round-trips, no proxy overhead, no content\ncleaning needed.\n\n## How Test Modes Map to Real Agents\n\n| Mode                       | Config                          | Simulates                  | Documentation Access                                                                                                       |\n| -------------------------- | ------------------------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `eval` (baseline)          | `promptfooconfig.yaml`          | No agent \u2014 docs in prompt  | Docs are injected directly into the prompt context, with and without variants                                              |\n| `eval:observed`            | `promptfooconfig.observed.yaml` | Non-agentic API call       | Single OpenAI API call, records the HTTP request but model doesn't browse                                                  |\n| `eval:agentic` (naive)     | `promptfooconfig.agentic.yaml`  | Claude Code, ChatGPT today | Model has `web_search` + `fetch_page` tools; pages fetched via Jina Reader (simulates JS rendering)                        |\n| `eval:agentic` (optimized) | `promptfooconfig.agentic.yaml`  | Ideal future agent         | Model has `web_search` + `fetch_page` + `list_docs` tools; fetches `.md` endpoints directly, uses `llms.txt` for discovery |\n| `agent-harness`            | compiled via compiler           | Real agent in sandbox      | Agent harness mode evaluates real agent behavior in a sandboxed environment (Docker, tempdir, git-worktree)                |\n\n### Why Both Naive and Optimized?\n\nThe comparison between naive and optimized modes answers a critical business\nquestion:\n\n> **\"How much does investing in agent-friendly documentation endpoints (`.md`,\n> `llms.txt`) improve the AI developer experience?\"**\n\nIf the optimized agent significantly outperforms the naive agent, it validates\nthe investment in these endpoints. The data from our tests provides concrete\nevidence for this.\n\n## Limitations of the Simulation\n\nWhile the agentic provider faithfully simulates agent behavior, there are\ndifferences from real agents:\n\n1. **Search quality**: We use DuckDuckGo via Jina as a search fallback. Real\n   agents use Bing (ChatGPT) or their own search (Claude Code). Search result\n   quality varies.\n\n2. **Page rendering**: Jina Reader is a good proxy for JS rendering, but may\n   produce slightly different output than what Claude Code or ChatGPT's internal\n   renderers produce.\n\n3. **Context window management**: Real agents have sophisticated context\n   management \u2014 they may truncate long pages, summarize content, or use sliding\n   windows. Our provider returns content up to a fixed limit (12KB).\n\n4. **Codebase context**: Real agents (especially Cursor and Copilot) inject the\n   developer's current codebase into context. Our eval doesn't simulate this \u2014\n   it only tests documentation retrieval.\n\n5. **Multi-turn interactions**: A real developer might have a conversation with\n   their agent, refining the request. Our eval tests single-turn interactions.\n\n## Future Directions\n\nThe architecture overhaul (Phase 4: agent harness mode) addressed several of\nthese goals \u2014 real agents can now be evaluated in sandboxed environments with\nfixture provisioning, tool manifests, and process-quality scoring. Remaining\ndirections:\n\n- **Subprocess agents** _(partially addressed by agent harness mode)_: The\n  harness supports running agents via entrypoints in Docker, tempdir, or\n  git-worktree sandboxes. Real `claude` CLI or other agent CLIs can be\n  configured as harness entrypoints.\n- **Anthropic/OpenAI native tools**: Use Claude's built-in `web_search` tool or\n  OpenAI's `web_search_preview` in the Responses API for more faithful\n  simulation of the agentic mode\n- **Agent-specific configs**: The compiler's mode handler system makes it\n  straightforward to create per-agent configurations\n- **Codebase context injection** _(partially addressed by fixture\n  provisioning)_: The agent harness fixture provisioner can inject project\n  workspaces, dependency manifests, and code contexts into sandbox environments",
+    "source": "docs/how-agents-work.md",
+    "related": [
+      "eval-modes",
+      "retrieval-gap"
+    ]
+  },
+  {
+    "id": "eval-modes",
+    "title": "Evaluation Modes",
+    "body": '> **This guide is for:** Anyone using AILF who wants to understand what modes\n> exist and when to use each one.\n\nAILF supports five canonical evaluation modes. Each mode measures a different\naspect of AI tool effectiveness.\n\n## Mode overview\n\n| Mode                | What it measures                                     | When to use it                        |\n| ------------------- | ---------------------------------------------------- | ------------------------------------- |\n| **literacy**        | Can AI agents implement features using your docs?    | Testing documentation quality         |\n| **mcp-server**      | Can an LLM correctly use your MCP server\'s tools?    | Testing MCP server implementations    |\n| **knowledge-probe** | What does the model know without any docs?           | Measuring baseline model knowledge    |\n| **agent-harness**   | Can an autonomous agent complete tasks in a sandbox? | Testing agent capabilities end-to-end |\n| **custom**          | Whatever you define                                  | Building your own evaluation type     |\n\n## Choosing a mode\n\n```\nWhat do you want to test?\n    \u2502\n    \u251C\u2500\u2500 "Are our docs helping AI agents?" \u2500\u2500\u2500\u2500\u2500\u2500\u2192 literacy\n    \u251C\u2500\u2500 "Does our MCP server work correctly?" \u2500\u2500\u2192 mcp-server\n    \u251C\u2500\u2500 "What does the model already know?" \u2500\u2500\u2500\u2500\u2192 knowledge-probe\n    \u251C\u2500\u2500 "Can an agent complete real tasks?" \u2500\u2500\u2500\u2500\u2192 agent-harness\n    \u2514\u2500\u2500 "Something else entirely" \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 custom\n```',
+    "source": "docs/modes.md",
+    "related": [
+      "scoring-model",
+      "three-layer"
+    ]
+  },
+  {
+    "id": "glossary",
+    "title": "Glossary",
+    "body": "**Overall Score**\n: A weighted average across all feature areas, using the gold scoring profile: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%).\n\n**Doc Lift**\n: How much the docs help, compared to the model's training data alone. Calculated as ceiling minus floor, where ceiling includes Doc Coverage and floor does not. Higher is better.\n\n**Actual Score**\n: How well an AI agent scores when it has to find docs on its own through web search and page fetching. This is the real-world scenario. Only available in full mode.\n\n**Retrieval Gap**\n: The score lost because agents can't find or use all the relevant docs. Calculated as ceiling minus actual. Lower is better; zero means agents find everything.\n\n**Infra Efficiency**\n: What percentage of the docs' potential quality actually reaches agents (actual \xF7 ceiling). 100% means agents find and use all relevant docs perfectly.\n\n**Floor**\n: Output-quality composite without documentation \u2014 Task Completion (60%) and Code Correctness (40%) only. Doc Coverage is excluded because it's undefined when no docs are provided. This tells you what the model already knows from its training data.\n\n**Ceiling**\n: Score with gold-standard docs injected directly into the prompt. This is the best the documentation can do.\n\n**Actual**\n: Score when an AI agent finds docs on its own through web search and page fetching. This is the real-world experience.\n\n**Ret. Gap**\n: Quality lost to discoverability (ceiling minus actual). The gap between what the docs could deliver and what agents actually get.\n\n**Efficiency**\n: What fraction of the docs' quality reaches agents in practice (actual \xF7 ceiling, shown as a percentage).\n\n**Inverted Retrieval Gap**\n: \u26A0\uFE0F Inverted retrieval gap: agents that can't find the docs actually score higher, because the docs hurt performance. This usually means there's a doc quality problem.\n\n**Score**\n: Ceiling composite for this feature area: Task Completion \xD7 50% + Code Correctness \xD7 25% + Doc Coverage \xD7 25%.\n\n**Task Completion**\n: Can the LLM implement the requested feature? Graded 0\u2013100.\n\n**Code Correctness**\n: Is the generated code idiomatic, correct, and following best practices? Graded 0\u2013100.\n\n**Doc Coverage**\n: Did the docs provide the information needed to implement the feature? Graded 0\u2013100. This dimension only contributes to the ceiling composite (with docs) \u2014 it's excluded from the floor composite because it's undefined without documentation.\n\n**Tests**\n: Number of test cases in this feature area.\n\n**Overall \u0394**\n: Change in overall score between the two runs. Positive means the experiment scored higher.\n\n**Actual \u0394**\n: Change in actual (agent-retrieved) score between runs. Positive means agents did better.\n\n**Ret. Gap \u0394**\n: Change in retrieval gap between runs. Negative is good here: it means the gap shrank and agents found more relevant docs.\n\n**Efficiency \u0394**\n: Change in infrastructure efficiency between runs. Positive means agents are capturing more of the docs' potential.\n\n**Baseline**\n: The reference run you're comparing against.\n\n**Experiment**\n: The new run you're evaluating.\n\n**Delta**\n: Difference between experiment and baseline. Positive means improvement, negative means regression.\n\n**Change**\n: Whether the change is meaningful: improved, regressed, or unchanged (within the noise threshold).\n\n**Low-Scoring Judgments**\n: The grading model's explanations for tests that scored below 70/100.\n\n**Judgment Reason**\n: The grading model's natural language explanation of what went wrong.\n\n**Strong (80+)**\n: Feature areas scoring 80 or above. The docs are working well for these features \u2014 AI agents produce correct, complete implementations.\n\n**Needs Attention (70\u201379)**\n: Feature areas scoring 70\u201379. These are okay but could be improved \u2014 there may be gaps in specific dimensions like doc coverage or code correctness.\n\n**Weak (<70)**\n: Feature areas scoring below 70. The docs are not providing enough support for AI agents to implement these features correctly.\n\n**Negative Doc Lift**\n: Number of areas where the documentation actually hurts AI performance \u2014 the model scores higher without docs than with them. This usually means the docs contain outdated patterns or incorrect examples.\n\n**Weak Areas**\n: Feature areas where the overall score is below 70. These need the most attention \u2014 low scores mean AI agents consistently struggle to implement these features.\n\n**Docs Hurt Performance**\n: Areas where the floor score (no docs) is higher than the ceiling score (with docs). The documentation may be actively misleading the model. These docs should be reviewed.\n\n**Retrieval Issues**\n: Areas where AI agents can find less than 70% of the available doc quality. The docs exist and are good, but agents can't discover them through search. Consider improving page titles, metadata, or search engine indexing.\n\n**Dimension Weaknesses**\n: Individual grading dimensions scoring below 50 within an area. These are the specific skills where AI agents fail most \u2014 task completion (can it build the feature?), code correctness (is the code right?), or doc coverage (did it use the docs?).\n\n**Efficiency Anomalies**\n: Areas where agent efficiency exceeds 100% \u2014 meaning agents perform better with self-found docs than with gold-standard docs injected directly. This can indicate doc quality issues (injected docs confuse the model) or agent memorization.\n\n**Doc Lift Wins**\n: Areas where documentation boosts AI performance by 5 or more points. Higher doc lift means the docs are providing crucial information that the model doesn't already know.\n\n**Retrieval Excellence**\n: Areas where AI agents successfully find and use at least 85% of the available doc quality through web search. Good retrieval means your docs are well-indexed and easy for agents to discover.\n\n**Model Breakdown**\n: Break down scores by individual LLM model. The default 'All Models' view shows the cross-model average. Select a specific model to see how it performed independently \u2014 useful for spotting models that struggle with specific feature areas.\n\n**Strengths**\n: What's working well: high-scoring areas, dimensions where the docs are strong, and areas where AI agents successfully find and use the documentation.\n\n**Recommendations**\n: Prioritized remediation plan from gap analysis. Each recommendation identifies a documentation problem, the affected feature area, and the estimated score lift from fixing it.\n\n**Total Potential Lift**\n: Aggregate potential score lift if all identified gaps were fixed. This is a conservative estimate \u2014 each gap targets the median of non-bottlenecked dimensions, not 100.\n\n**Failure Mode**\n: The type of failure the grader emitted. Cross-cutting modes apply to any dimension (api-error, model-limitation, false-floor, unclassified). Per-dimension extensions cover documentation problems (missing-docs, incorrect-docs, outdated-docs, poor-structure), spec adherence (spec-mismatch), tool use (tool-misuse, chaotic-process, missing-recovery), and knowledge probes (factual-error, incompleteness, currency-violation, hallucination).\n\n**Estimated Lift**\n: Estimated composite score improvement if this gap is fully fixed. Based on raising bottleneck dimensions to the median of non-bottlenecked dimensions.\n\n**Confidence**\n: How confident we are in this diagnosis (D0049 ceiling-cross-check derivation). High = the grader's emitted failure mode agrees with the structural ceiling-decomposition signal. Medium = signals disagree (or the ceiling pattern is not informative for this score). Low = passing scores never classify; treat as absent.\n\n**Agent Behavior**\n: How AI agents interacted with your documentation during evaluation: what they searched for, which pages they visited, and how much time they spent on network requests.\n\n**Search Queries**\n: The exact search queries agents used to find documentation. Helps you understand how agents discover your content and whether your docs appear for relevant queries.\n\n**Unique Doc Slugs**\n: Documentation page slugs that agents actually visited during evaluation. Compare against canonical docs to see if agents found the right pages.\n\n**External Domains**\n: Non-Sanity domains that agents contacted during evaluation. High external domain counts may indicate agents couldn't find what they needed in your docs.\n\n**Avg Pages Visited**\n: Average number of documentation pages visited per test. Higher counts can mean agents need to consult many pages (complex task) or can't find the right one quickly.\n\n**Avg Searches**\n: Average number of web searches performed per test. High search counts can indicate docs are hard to discover through search engines.\n\n**Avg Network Time**\n: Average time spent on network requests per test. Includes page fetches, search queries, and API calls.\n\n**Total Requests**\n: Total number of HTTP requests the agent made during the test, including searches, page visits, and API calls.\n\n**Total Bytes Downloaded**\n: Total bytes downloaded by the agent. Large downloads may indicate the agent is fetching many pages or very large documents.\n\n**Task Completion \u0394**\n: Change in task completion between runs. Positive means implementations are more complete.\n\n**Code Correctness \u0394**\n: Change in code correctness between runs. Positive means better code quality.\n\n**Doc Coverage \u0394**\n: Change in doc coverage between runs. Positive means the docs are providing more useful information.\n\n**Area \u0394**\n: Score change for this area compared to the previous evaluation run.\n\n**Production**\n: Production source \u2014 docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.\n\n**Branch**\n: Branch source \u2014 docs fetched from a branch or draft dataset. Use this to preview how content changes affect scores before publishing.\n\n**Local**\n: Local source \u2014 docs fetched from local files or a local dev server. Useful for testing doc changes before pushing.\n\n**Score**\n: The overall ceiling composite for this evaluation run: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%), averaged across all feature areas.\n\n**Mode**\n: The evaluation mode determines which reference points are measured. Different modes test different aspects of how AI agents interact with documentation.\n\n**Trigger**\n: What initiated this evaluation run. Knowing the trigger helps you understand whether a score change was from a content edit, a code deploy, or a scheduled check.\n\n**Baseline**\n: Baseline mode \u2014 tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).\n\n**Full**\n: Full mode \u2014 runs baseline + agentic. Compares ceiling (injected docs) against actual (agent-retrieved docs) to measure retrieval gap and infrastructure efficiency.\n\n**Agentic**\n: Agentic mode \u2014 the AI agent finds docs on its own via web search. Measures real-world performance: can agents actually discover and use your documentation?\n\n**Observed**\n: Observed mode \u2014 records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.\n\n**Debug**\n: Debug mode \u2014 a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.\n\n**Manual**\n: Manually triggered \u2014 someone ran the evaluation pipeline by hand, either locally or via the Studio UI.\n\n**CI**\n: CI-triggered \u2014 the evaluation ran automatically as part of a pull request or merge pipeline.\n\n**Scheduled**\n: Scheduled \u2014 the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.\n\n**Webhook**\n: Webhook-triggered \u2014 a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.\n\n**Cross-Repo**\n: Cross-repo \u2014 triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.",
+    "source": "packages/shared/src/glossary.ts",
+    "tags": [
+      "reference",
+      "glossary"
+    ]
+  }
+];
+
 // ../shared/dist/score-grades.js
 var GRADE_BOUNDARIES = {
   good: 80,
@@ -322,6 +845,21 @@ var EVAL_REQUEST_STATUS_QUERY = (
   }
 `
 );
+function buildTaskEvalPipelineRequest(args) {
+  const { areaId, dataset, projectId, tag, taskId } = args;
+  return {
+    dataset,
+    mode: "literacy",
+    ...projectId ? { projectId } : {},
+    publish: true,
+    publishTag: tag,
+    source: "production",
+    taskMode: "content-lake",
+    tasks: [taskId],
+    variant: "full",
+    ...areaId ? { areas: [areaId] } : {}
+  };
+}
 var TASK_REPORT_QUERY = (
   /* groq */
   `
@@ -454,18 +992,22 @@ var RunTaskEvaluationAction = (props) => {
     if (!taskId) return;
     const tag = `task-${slugify(taskId)}-${dateStamp()}`;
     const now = Date.now();
+    const pipelineRequest = buildTaskEvalPipelineRequest({
+      areaId,
+      dataset,
+      projectId,
+      tag,
+      taskId
+    });
     try {
       const evalRequest = await client.create({
         _type: EVAL_REQUEST_TYPE,
         dataset,
-        mode: "full",
+        pipelineRequest: JSON.stringify(pipelineRequest),
         projectId,
         requestedAt: new Date(now).toISOString(),
         requestedBy: currentUser?.id ?? "unknown",
-        status: "pending",
-        tag,
-        tasks: [taskId],
-        ...areaId ? { areas: [areaId] } : {}
+        status: "pending"
       });
       requestedAtRef.current = now;
       setState({
@@ -583,55 +1125,13 @@ var evalRequestSchema = defineType({
       type: "string"
     }),
     defineField({
-      description: "Evaluation mode",
-      group: ["main", "all-fields"],
-      initialValue: "baseline",
-      name: "mode",
-      options: {
-        list: [
-          { title: "Baseline", value: "baseline" },
-          { title: "Full", value: "full" },
-          { title: "Observed", value: "observed" },
-          { title: "Agentic", value: "agentic" }
-        ]
-      },
-      readOnly: true,
-      title: "Mode",
-      type: "string"
-    }),
-    defineField({
-      description: "Content release perspective ID (required for release evals)",
+      description: "Canonical PipelineRequest JSON. Source of truth for what the webhook handler dispatches. Parses against PipelineRequestSchema from @sanity/ailf-core.",
       group: ["main", "all-fields"],
-      name: "perspective",
-      readOnly: true,
-      title: "Perspective",
-      type: "string"
-    }),
-    defineField({
-      description: "Specific task IDs to evaluate (for task-scoped evals). When set, the pipeline only runs these tasks instead of the full suite.",
-      group: ["optional", "all-fields"],
-      name: "tasks",
-      of: [{ type: "string" }],
-      readOnly: true,
-      title: "Tasks",
-      type: "array"
-    }),
-    defineField({
-      description: "Feature areas to scope the evaluation. When set together with tasks, provides additional context for the pipeline.",
-      group: ["optional", "all-fields"],
-      name: "areas",
-      of: [{ type: "string" }],
-      readOnly: true,
-      title: "Areas",
-      type: "array"
-    }),
-    defineField({
-      description: "Run in debug mode (limits to a subset of test cases for fast feedback).",
-      group: ["optional", "all-fields"],
-      name: "debug",
+      name: "pipelineRequest",
       readOnly: true,
-      title: "Debug",
-      type: "boolean"
+      title: "Pipeline Request (JSON)",
+      type: "text",
+      validation: (rule) => rule.required()
     }),
     defineField({
       description: "Sanity project ID",
@@ -676,7 +1176,7 @@ var evalRequestSchema = defineType({
       type: "string"
     }),
     defineField({
-      description: "Request lifecycle: pending \u2192 dispatched \u2192 completed \u2192 failed. Only 'pending' is set by Studio; the webhook handler and pipeline callback update subsequent states.",
+      description: "Request lifecycle: pending \u2192 dispatched \u2192 completed \u2192 failed. Only 'pending' is set by Studio/dashboard; the webhook handler and pipeline callback update subsequent states.",
       group: ["main", "all-fields"],
       initialValue: "pending",
       name: "status",
@@ -692,34 +1192,16 @@ var evalRequestSchema = defineType({
       title: "Status",
       type: "string",
       validation: (rule) => rule.required()
-    }),
-    defineField({
-      description: 'Publish tag for the report (e.g. "release-my-release-2026-03-16")',
-      group: ["optional", "all-fields"],
-      name: "tag",
-      readOnly: true,
-      title: "Tag",
-      type: "string"
     })
   ],
   name: "ailf.evalRequest",
   preview: {
-    prepare({ perspective, status, tasks }) {
+    prepare({ status }) {
       const statusStr = typeof status === "string" ? status : "unknown";
-      let title;
-      if (typeof perspective === "string") {
-        title = perspective;
-      } else if (Array.isArray(tasks) && tasks.length > 0) {
-        title = tasks.length === 1 ? `Task: ${tasks[0]}` : `Tasks: ${tasks.slice(0, 3).join(", ")}${tasks.length > 3 ? "\u2026" : ""}`;
-      } else {
-        title = "Evaluation Request";
-      }
-      return { subtitle: statusStr, title };
+      return { subtitle: statusStr, title: "Evaluation Request" };
     },
     select: {
-      perspective: "perspective",
-      status: "status",
-      tasks: "tasks"
+      status: "status"
     }
   },
   title: "AILF Evaluation Request",
@@ -3621,318 +4103,108 @@ import {
   Tab as Tab3,
   TabList as TabList3,
   TabPanel as TabPanel3,
-  Text as Text54
-} from "@sanity/ui";
-import { useCallback as useCallback43, useEffect as useEffect18 } from "react";
-import { useRouter as useRouter5 } from "sanity/router";
-
-// src/lib/help-context.ts
-import {
-  createElement,
-  createContext,
-  useCallback as useCallback8,
-  useContext,
-  useState as useState4
-} from "react";
-var HelpContext = createContext(null);
-function HelpProvider({ children, defaultTopicId }) {
-  const [state, setState] = useState4({
-    open: false,
-    topicId: defaultTopicId ?? null,
-    history: []
-  });
-  const openHelp = useCallback8(
-    (topicId) => {
-      setState((prev) => ({
-        open: true,
-        topicId: topicId ?? prev.topicId ?? defaultTopicId ?? null,
-        history: []
-      }));
-    },
-    [defaultTopicId]
-  );
-  const closeHelp = useCallback8(() => {
-    setState((prev) => ({ ...prev, open: false }));
-  }, []);
-  const navigateTo = useCallback8((topicId) => {
-    setState((prev) => ({
-      ...prev,
-      history: prev.topicId ? [...prev.history, prev.topicId] : prev.history,
-      topicId
-    }));
-  }, []);
-  const goBack = useCallback8(() => {
-    setState((prev) => {
-      if (prev.history.length === 0) return prev;
-      const history = [...prev.history];
-      const topicId = history.pop();
-      return { ...prev, topicId, history };
-    });
-  }, []);
-  const value = {
-    open: state.open,
-    topicId: state.topicId,
-    openHelp,
-    closeHelp,
-    navigateTo,
-    goBack,
-    canGoBack: state.history.length > 0
-  };
-  return createElement(HelpContext.Provider, { value }, children);
-}
-function useHelp() {
-  const ctx = useContext(HelpContext);
-  if (!ctx) {
-    throw new Error("useHelp must be used within a <HelpProvider>");
-  }
-  return ctx;
-}
-
-// src/lib/judgment-drawer-context.tsx
-import {
-  createContext as createContext2,
-  useCallback as useCallback9,
-  useContext as useContext2,
-  useMemo as useMemo3,
-  useState as useState5
-} from "react";
-import { jsx as jsx10 } from "react/jsx-runtime";
-var JudgmentDrawerContext = createContext2(
-  null
-);
-function JudgmentDrawerProvider({ children }) {
-  const [active, setActive] = useState5(null);
-  const open = useCallback9((payload) => {
-    setActive(payload);
-  }, []);
-  const close = useCallback9(() => {
-    setActive(null);
-  }, []);
-  const value = useMemo3(
-    () => ({ active, close, isOpen: active != null, open }),
-    [active, close, open]
-  );
-  return /* @__PURE__ */ jsx10(JudgmentDrawerContext.Provider, { value, children });
-}
-function useJudgmentDrawer() {
-  const ctx = useContext2(JudgmentDrawerContext);
-  if (!ctx) {
-    throw new Error(
-      "useJudgmentDrawer must be called inside a <JudgmentDrawerProvider>"
-    );
-  }
-  return ctx;
-}
-
-// src/generated/help-content.ts
-var HELP_TOPICS = [
-  {
-    "id": "negative-doc-lift",
-    "title": "When Docs Hurt: Negative Doc Lift",
-    "body": `The ceiling score is _lower_ than the floor score. The canonical docs actively
-hurt the model's performance. This is a negative Doc Lift: the model produces
-better output from its training data alone than when given the "correct"
-documentation.
-
-This will happen. It is not an error condition \u2014 it is a high-signal diagnostic
-that demands investigation. A negative Doc Lift means one or more of the
-following:
-
-- **Outdated documentation** \u2014 the docs describe an older API version or
-  pattern, and the model's training data has absorbed a newer version. The docs
-  are actively teaching the model the wrong thing. _Action: update the docs to
-  reflect the current API._
-
-- **Misleading documentation** \u2014 the docs are technically accurate but
-  structured in a way that leads the model to an incorrect implementation path.
-  Ambiguous phrasing, conflicting code examples, or poor organization can cause
-  a model to produce worse code than its baseline intuition. _Action:
-  restructure or rewrite the docs for clarity._
-
-- **Adversarial context dilution** \u2014 the canonical doc set is too large or
-  contains too much tangential content, and the relevant signal gets buried in
-  noise. The model performs better with no docs because fewer tokens means less
-  distraction. _Action: trim the canonical doc set or restructure docs to
-  front-load the most relevant information._
-
-- **Model training data superiority** \u2014 for mature, well-known features (e.g.,
-  basic GROQ queries, standard Studio setup), the model may have absorbed
-  high-quality examples from training data (blog posts, Stack Overflow, open
-  source code) that are simply better than the official documentation. _Action:
-  improve the docs to meet or exceed the quality of community content the model
-  learned from._`,
-    "source": "docs/design-docs/scenario-matrix/evaluation-ceiling.md",
-    "related": [
-      "doc-lift",
-      "three-layer"
-    ]
-  },
-  {
-    "id": "three-layer",
-    "title": "Floor, Ceiling, and Actual Scores",
-    "body": "- **Doc Lift** = `ceiling score \u2212 floor score`. Positive when docs help,\n  negative when docs hurt. This is the fundamental documentation value metric.\n  When negative, it triggers the interference investigation described above\n- **Retrieval gap** = `ceiling score \u2212 agentic score`. The cost of imperfect\n  discovery. Should be minimized via infrastructure investment (`llms.txt`,\n  `.md` endpoints, better navigation, SEO). Note: this metric is only meaningful\n  when Doc Lift is positive \u2014 if the docs themselves are harmful, a large\n  retrieval gap might paradoxically be _protective_ (agents that can't find the\n  bad docs may outperform agents that can)\n- **Doc quality gap** = `100 \u2212 ceiling score`. The ceiling itself is below\n  perfect. This is the documentation team's problem \u2014 the docs need improvement\n  regardless of how they're delivered\n- **Infrastructure efficiency** = `agentic score / ceiling score`. What fraction\n  of the documentation's potential value actually reaches agents? A ratio of\n  0.90 means infrastructure delivers 90% of the doc quality. A ratio of 0.50\n  means half the documentation value is lost in delivery. When the ceiling is\n  below the floor, this ratio is undefined \u2014 report it as \"N/A (negative Doc\n  Lift)\" rather than producing a misleading number\n\n### Decomposition: the healthy case (positive Doc Lift)\n\n```\nfloor score                      \u2192 model's inherent knowledge\n  + Doc Lift (ceiling \u2212 floor)   \u2192 documentation quality contribution\n  \u2212 retrieval gap (ceiling \u2212 agentic) \u2192 discovery/infrastructure loss\n  = agentic score                \u2192 what users actually experience\n```\n\n### Decomposition: the interference case (negative Doc Lift)\n\n```\nfloor score                      \u2192 model's inherent knowledge\n  \u2212 |Doc Lift| (floor \u2212 ceiling) \u2192 documentation interference penalty\n  \u2212 retrieval gap (ceiling \u2212 agentic) \u2192 discovery/infrastructure loss\n  = agentic score                \u2192 what users actually experience\n\n  but note: agentic score may exceed ceiling score here, because\n  agents that fail to find the interfering docs avoid the penalty.\n  In this case the \"retrieval gap\" inverts \u2014 poor retrieval is a\n  net positive. The framework should flag this explicitly:\n  \"Retrieval failure is masking a documentation quality problem.\"\n```\n\nBoth decompositions are valid expressions of the **core measurement model**.\nEvery scenario in the matrix is asking about one or more of these three layers:\ninherent knowledge, documentation quality, or discovery effectiveness. The sign\nof the Doc Lift determines which layer needs urgent attention.",
-    "source": "docs/design-docs/scenario-matrix/evaluation-ceiling.md",
-    "related": [
-      "doc-lift",
-      "negative-doc-lift",
-      "retrieval-gap",
-      "scoring-model"
-    ]
-  },
-  {
-    "id": "comparing-runs",
-    "title": "Comparing Evaluation Runs",
-    "body": "## How comparison works\n\nThe Compare view lets you select any two evaluation reports and see a detailed\nside-by-side breakdown. One report is the **baseline** (your reference point)\nand the other is the **experiment** (what you're evaluating).\n\n## Reading the comparison\n\nFor each feature area, you'll see:\n\n- **Delta** \u2014 The score difference (experiment minus baseline). Positive means\n  the experiment scored higher.\n- **Change** \u2014 Whether the delta is meaningful: **improved**, **regressed**, or\n  **unchanged**. This accounts for the noise threshold \u2014 small deltas within the\n  noise band are marked unchanged even if they're non-zero.\n\n## The noise threshold\n\nNot every score change is real. LLM responses vary between runs, and the grader\nmodel has its own variance. The comparison applies a noise threshold (currently\nconfigured per-evaluation) to filter out statistical noise. Only changes that\nexceed this threshold are classified as improvements or regressions.\n\n## What to compare\n\n- **Before and after a doc change** \u2014 Did your edits actually improve scores?\n- **Production vs. branch** \u2014 Will publishing this content release help or hurt?\n- **Different models** \u2014 How does Claude compare to GPT on the same docs?\n- **Baseline vs. full mode** \u2014 Is the retrieval gap shrinking over time?\n\n## Per-area deltas\n\nThe most actionable part of the comparison is the per-area breakdown. If your\noverall score improved but one area regressed, the per-area deltas tell you\nexactly which area needs attention.",
-    "source": "docs/help/comparing-runs.md",
-    "related": [
-      "reading-score-trends",
-      "scoring-model"
-    ]
-  },
-  {
-    "id": "doc-lift",
-    "title": "Doc Lift: Do Your Docs Help?",
-    "body": "## What is doc lift?\n\n**Doc lift** is the difference between how an AI performs _with_ your\ndocumentation and how it performs _without_ it:\n\n```\nDoc lift = ceiling score \u2212 floor score\n```\n\n- **Ceiling score** \u2014 the AI's score when gold-standard docs are injected\n  directly into its prompt.\n- **Floor score** \u2014 the AI's score with no documentation at all, relying only on\n  its training data.\n\nA positive doc lift means your docs are helping. The higher the number, the more\nvalue your documentation provides beyond what the model already knows.\n\n## What good doc lift looks like\n\n- **Doc lift of 15+** \u2014 Your docs are providing crucial information the model\n  doesn't already know. This is a strong signal that the docs are worth\n  maintaining and improving.\n- **Doc lift of 5\u201315** \u2014 Docs are helping, but the model's training data covers\n  a lot of the ground already. The docs are adding incremental value.\n- **Doc lift near zero** \u2014 The docs aren't adding much. Either the model already\n  knows the material, or the docs aren't providing useful implementation\n  guidance.\n\n## Negative doc lift\n\nA **negative** doc lift means the documentation is actively hurting the AI's\nperformance \u2014 the model produces _better_ code without your docs than with them.\nThis is never ignorable. See the \"When Docs Hurt\" help topic for causes and\nremediation.\n\n## Where you see it\n\nDoc lift appears in several places in the dashboard:\n\n- **Overview stats** \u2014 The aggregate doc lift across all areas.\n- **Per-area score table** \u2014 Doc lift for each feature area, so you can see\n  which docs help most and which help least.\n- **Comparison view** \u2014 Doc lift deltas between two runs, showing whether your\n  doc changes increased or decreased documentation value.",
-    "source": "docs/help/doc-lift.md",
-    "related": [
-      "three-layer",
-      "negative-doc-lift",
-      "scoring-model"
-    ]
-  },
-  {
-    "id": "getting-started",
-    "title": "Getting Started",
-    "body": `## What does AILF measure?
-
-The AI Literacy Framework measures how well your documentation helps AI coding
-tools (like Claude Code, Cursor, ChatGPT, and Copilot) implement features
-correctly. When a developer asks an AI agent "set up a webhook in Sanity," the
-agent needs to find the right docs and produce working code. AILF scores how
-well that goes.
-
-## The key number: AI Literacy Score
-
-Every evaluation produces a score from 0\u2013100, composed of three dimensions:
-
-- **Task Completion (50%)** \u2014 Can the AI implement the feature at all?
-- **Code Correctness (25%)** \u2014 Is the generated code correct and idiomatic?
-- **Doc Coverage (25%)** \u2014 Did the docs provide the information needed?
-
-Higher is better. Scores above 80 mean the docs are working well for that
-feature. Scores below 70 need attention.
-
-## What you see in the dashboard
-
-- **Latest Reports** \u2014 The most recent evaluation runs with scores, areas
-  tested, and trend indicators.
-- **Score Timeline** \u2014 How scores change over time. Look for upward trends after
-  doc improvements.
-- **Compare** \u2014 Side-by-side comparison of any two runs to see what improved or
-  regressed.
-
-Click into any report for the full breakdown: per-area scores, diagnostics, and
-(for full-mode runs) how AI agents actually navigated your docs.
+  Text as Text54
+} from "@sanity/ui";
+import { useCallback as useCallback43, useEffect as useEffect18 } from "react";
+import { useRouter as useRouter5 } from "sanity/router";
 
-## Quick orientation
+// src/lib/help-context.ts
+import {
+  createElement,
+  createContext,
+  useCallback as useCallback8,
+  useContext,
+  useState as useState4
+} from "react";
+var HelpContext = createContext(null);
+function HelpProvider({ children, defaultTopicId }) {
+  const [state, setState] = useState4({
+    open: false,
+    topicId: defaultTopicId ?? null,
+    history: []
+  });
+  const openHelp = useCallback8(
+    (topicId) => {
+      setState((prev) => ({
+        open: true,
+        topicId: topicId ?? prev.topicId ?? defaultTopicId ?? null,
+        history: []
+      }));
+    },
+    [defaultTopicId]
+  );
+  const closeHelp = useCallback8(() => {
+    setState((prev) => ({ ...prev, open: false }));
+  }, []);
+  const navigateTo = useCallback8((topicId) => {
+    setState((prev) => ({
+      ...prev,
+      history: prev.topicId ? [...prev.history, prev.topicId] : prev.history,
+      topicId
+    }));
+  }, []);
+  const goBack = useCallback8(() => {
+    setState((prev) => {
+      if (prev.history.length === 0) return prev;
+      const history = [...prev.history];
+      const topicId = history.pop();
+      return { ...prev, topicId, history };
+    });
+  }, []);
+  const value = {
+    open: state.open,
+    topicId: state.topicId,
+    openHelp,
+    closeHelp,
+    navigateTo,
+    goBack,
+    canGoBack: state.history.length > 0
+  };
+  return createElement(HelpContext.Provider, { value }, children);
+}
+function useHelp() {
+  const ctx = useContext(HelpContext);
+  if (!ctx) {
+    throw new Error("useHelp must be used within a <HelpProvider>");
+  }
+  return ctx;
+}
 
-| If you see\u2026         | It means\u2026                                            |
-| ------------------- | ---------------------------------------------------- |
-| A score above 80    | Docs are working well for this area                  |
-| A score below 70    | Docs need improvement \u2014 AI agents struggle here      |
-| Positive doc lift   | Docs are helping (good!)                             |
-| Negative doc lift   | Docs are hurting \u2014 they're worse than no docs at all |
-| Large retrieval gap | Good docs exist but agents can't find them           |`,
-    "source": "docs/help/getting-started.md",
-    "related": [
-      "scoring-model",
-      "eval-modes"
-    ]
-  },
-  {
-    "id": "interpreting-diagnostics",
-    "title": "Interpreting Diagnostics",
-    "body": "## The diagnostics tab\n\nWhen you open a report and click the **Diagnostics** tab, you see a health\nsummary of your documentation across all feature areas. This is the most\nactionable view in the dashboard \u2014 it tells you exactly where to focus your doc\nimprovement efforts.\n\n## Health categories\n\nFeature areas are grouped into three health bands:\n\n- **Strong (80+)** \u2014 Docs are working well. AI agents produce correct, complete\n  implementations. No action needed unless you see regression.\n- **Needs Attention (70\u201379)** \u2014 Docs are okay but have gaps. There may be\n  specific dimensions (like code correctness or doc coverage) dragging the score\n  down. Worth investigating.\n- **Weak (below 70)** \u2014 Docs are not providing enough support. AI agents\n  consistently struggle with these features. These need priority attention.\n\n## Strengths vs. Issues\n\nThe diagnostics tab has two sub-views:\n\n**Strengths** highlights what's working: high-scoring areas, strong dimensions,\nand areas where agents successfully find and use your docs. Use this to\nunderstand what good looks like in your docs \u2014 and replicate it elsewhere.\n\n**Issues** lists the problems: weak areas, dimensions scoring below 50, negative\ndoc lift, retrieval problems, and (if gap analysis was run) specific\nrecommendations with estimated score lift.\n\n## Key diagnostic signals\n\n| Signal                         | What it means                              | What to do                               |\n| ------------------------------ | ------------------------------------------ | ---------------------------------------- |\n| **Negative doc lift**          | Docs are worse than no docs                | Rewrite or remove the offending docs     |\n| **Large retrieval gap**        | Good docs exist but agents can't find them | Improve page titles, metadata, SEO       |\n| **Low code correctness**       | Agents find the docs but produce bad code  | Add or fix code examples                 |\n| **Low doc coverage**           | The docs don't cover what the task needs   | Write new documentation                  |\n| **Efficiency anomaly (>100%)** | Agents do better without gold docs         | Injected docs may be confusing the model |",
-    "source": "docs/help/interpreting-diagnostics.md",
-    "related": [
-      "scoring-model",
-      "weaknesses-recommendations"
-    ]
-  },
-  {
-    "id": "reading-score-trends",
-    "title": "Reading Score Trends",
-    "body": "## What the timeline shows\n\nThe Score Timeline view plots your AI Literacy Score over time. Each point is an\nevaluation run \u2014 a snapshot of how well your docs support AI agents at that\nmoment.\n\n## What to look for\n\n**Upward trends** after doc changes confirm that your improvements are working.\nIf you rewrote a GROQ guide and the GROQ area score climbs in the next run,\nthat's direct evidence of impact.\n\n**Sudden drops** usually mean something changed: a doc was deleted, an API\nchanged without a doc update, or a new task was added that exposes a gap.\n\n**Flat lines** mean stability \u2014 neither improving nor regressing. This is fine\nfor mature areas but concerning for areas you're actively working on.\n\n## Meaningful change vs. noise\n\nSmall fluctuations (\xB12\u20133 points) between runs are normal \u2014 they come from LLM\nnon-determinism and grader variance. Focus on changes of **5+ points** sustained\nacross multiple runs. The comparison view applies a noise threshold to help\ndistinguish real changes from statistical noise.\n\n## Filtering the timeline\n\nUse the filters to focus on specific evaluation modes (baseline vs. full),\nspecific doc sources (production vs. branch), or specific feature areas.\nComparing the same area across modes reveals whether a problem is in the docs\nthemselves (baseline score) or in how agents find them (agentic score).",
-    "source": "docs/help/reading-score-trends.md",
-    "related": [
-      "scoring-model",
-      "comparing-runs"
-    ]
-  },
-  {
-    "id": "retrieval-gap",
-    "title": "Retrieval Gap & Infrastructure Efficiency",
-    "body": "## What is the retrieval gap?\n\nThe **retrieval gap** is the difference between the **ceiling score** (docs\ninjected directly into the AI's prompt) and the **actual score** (the AI agent\nfinds docs on its own via web search). It measures how much documentation\nquality is lost because agents can't find the right pages.\n\n```\nRetrieval gap = ceiling score \u2212 actual score\n```\n\nA retrieval gap of zero means agents find everything. A gap of 20 means 20\npoints of doc quality never reach the agents.\n\n## What is infrastructure efficiency?\n\n**Infrastructure efficiency** expresses the retrieval gap as a ratio:\n\n```\nInfrastructure efficiency = actual score / ceiling score\n```\n\nAn efficiency of 90% means agents capture 90% of your docs' potential. An\nefficiency of 50% means half the documentation value is lost to discoverability\nproblems.\n\n## What causes a large retrieval gap?\n\n- **Poor page titles** \u2014 Agents search by keyword. If your page title doesn't\n  match what a developer would ask, agents won't find it.\n- **Missing from search indexes** \u2014 Pages that aren't indexed by search engines\n  are invisible to agents that rely on web search.\n- **No `llms.txt`** \u2014 An `llms.txt` file gives agents a table of contents.\n  Without it, they rely entirely on search queries.\n- **No `.md` endpoints** \u2014 Agents that can fetch clean markdown directly\n  (instead of parsing HTML) get better context with less noise.\n- **Content spread across many pages** \u2014 If implementing a feature requires\n  reading 5 different pages, agents are less likely to find all of them.\n\n## How to shrink the retrieval gap\n\n1. **Add clear, keyword-rich page titles** that match how developers phrase\n   their questions.\n2. **Ensure pages are indexed** by search engines (no `noindex` meta tags on doc\n   pages).\n3. **Provide `llms.txt`** at your docs root so agents can browse a structured\n   table of contents.\n4. **Provide `.md` endpoints** so agents can fetch clean markdown instead of\n   parsing JavaScript-rendered HTML.\n5. **Consolidate related content** \u2014 fewer, more comprehensive pages are easier\n   for agents to find than many small fragments.\n\n## When the retrieval gap inverts\n\nIn rare cases, the actual score exceeds the ceiling score \u2014 agents that can't\nfind the docs perform _better_ than agents with gold-standard docs injected.\nThis means the docs themselves are hurting performance (negative doc lift), and\nagents that fail to find them accidentally avoid the damage. The dashboard flags\nthis as an **inverted retrieval gap** \u2014 it's a documentation quality problem,\nnot a discoverability win.",
-    "source": "docs/help/retrieval-gap.md",
-    "related": [
-      "three-layer",
-      "eval-modes",
-      "how-agents-work"
-    ]
-  },
-  {
-    "id": "scoring-model",
-    "title": "Understanding Scores",
-    "body": "## The three dimensions\n\nEvery evaluation task is scored on three dimensions, each graded 0\u2013100:\n\n- **Task Completion (50% weight)** \u2014 Can the AI implement the requested feature?\n  Does the output actually do what was asked?\n- **Code Correctness (25% weight)** \u2014 Is the generated code idiomatic, correct,\n  and following best practices?\n- **Doc Coverage (25% weight)** \u2014 Did the documentation provide the information\n  needed to implement the feature?\n\n## How the overall score is calculated\n\nThe three dimensions combine into a single **AI Literacy Score** per task using\nnamed scoring profiles from `config/rubrics.yaml`:\n\n```\nGold (with docs):    Total = Task \xD7 0.50 + Code \xD7 0.25 + Docs \xD7 0.25\nBaseline (no docs):  Total = Task \xD7 0.60 + Code \xD7 0.40\n```\n\nThe gold profile includes all three dimensions. The baseline profile excludes\nDoc Coverage because it is undefined when no documentation is provided. This\nensures Doc Lift (ceiling \u2212 floor) is a clean structural measurement of\ndocumentation value.\n\nThe weighted composite produces a score from 0\u2013100. Scores are then averaged\nacross all tasks in a feature area to produce a **per-area score**, and across\nall areas to produce the **overall score**.\n\n## What the numbers mean\n\n| Score range  | Interpretation                                                    |\n| ------------ | ----------------------------------------------------------------- |\n| **80\u2013100**   | Docs are working well \u2014 AI agents produce correct implementations |\n| **70\u201379**    | Needs attention \u2014 there may be gaps in specific dimensions        |\n| **Below 70** | Weak \u2014 AI agents consistently struggle with this area             |\n\n## Ceiling decomposition (baseline mode)\n\nWhen running in baseline mode, each task is evaluated twice \u2014 with and without\ndocumentation. This produces:\n\n- **Floor score** \u2014 Score without docs (what the model knows from training data\n  alone)\n- **Ceiling score** \u2014 Score with gold-standard docs injected directly into the\n  prompt\n- **Doc Lift** \u2014 Ceiling minus floor. Positive means docs help; negative means\n  docs hurt.\n- **Doc Quality Gap** \u2014 100 minus ceiling. Room for documentation improvement.\n\n## Three-layer decomposition (full mode)\n\nFull mode adds a third measurement \u2014 what happens when AI agents find docs on\ntheir own:\n\n- **Floor** \u2014 No docs (parametric knowledge only)\n- **Ceiling** \u2014 Gold-standard docs injected (best the docs can do)\n- **Actual** \u2014 Agent-retrieved docs (real-world performance)\n- **Retrieval Gap** \u2014 Ceiling minus actual (quality lost to findability)\n- **Infrastructure Efficiency** \u2014 Actual \xF7 ceiling (what fraction of doc quality\n  reaches agents)\n\n## Cost tracking\n\nEach evaluation also tracks token costs:\n\n- **Provider cost** \u2014 Token usage for generating implementations\n- **Grader cost** \u2014 Token usage for the grading model's assessments\n- **Total cost** \u2014 Both combined, reported in the score summary",
-    "source": "docs/help/scoring-model.md",
-    "related": [
-      "three-layer",
-      "doc-lift",
-      "eval-modes"
-    ]
-  },
-  {
-    "id": "weaknesses-recommendations",
-    "title": "Weaknesses & Recommendations",
-    "body": "## Understanding weaknesses\n\nThe Issues sub-tab in Diagnostics lists every area or dimension that scored\nbelow threshold. Each weakness entry shows:\n\n- **The feature area** \u2014 Which product feature is affected (e.g., GROQ,\n  Functions, Webhooks).\n- **The bottleneck dimension** \u2014 Which scoring dimension is dragging the area\n  down: task completion, code correctness, or doc coverage.\n- **The score** \u2014 How far below threshold the dimension scored.\n\n## Gap analysis recommendations\n\nWhen an evaluation runs with gap analysis enabled, the dashboard shows\n**prioritized recommendations** \u2014 specific actions ranked by estimated impact.\n\nEach recommendation includes:\n\n- **Failure mode** \u2014 The type of doc problem identified:\n  - `missing-docs` \u2014 The functionality isn't documented at all.\n  - `incorrect-docs` \u2014 The docs contain factual errors.\n  - `outdated-docs` \u2014 The docs describe an old API version or pattern.\n  - `poor-structure` \u2014 The docs exist but are hard to find or understand.\n- **Estimated lift** \u2014 How many score points fixing this gap would add. Based on\n  raising the bottleneck dimension to the median of non-bottleneck dimensions.\n  Conservative estimate \u2014 actual improvement may be higher.\n- **Confidence** \u2014 How sure the analysis is about this diagnosis (high, medium,\n  or low).\n- **Affected tasks** \u2014 Which specific evaluation tasks exposed this gap.\n\n## Low-scoring judgments\n\nBelow the recommendations, you'll find the **grader's explanations** for tests\nthat scored below 70. These are the raw assessments from the grading model\nexplaining exactly what went wrong \u2014 missing API calls, incorrect patterns,\nhallucinated features, etc.\n\nEach judgment shows the task, the dimension, the score, and the grader's natural\nlanguage reason. These are the most granular diagnostic signal available and\noften point directly to the doc section that needs fixing.",
-    "source": "docs/help/weaknesses-recommendations.md",
-    "related": [
-      "interpreting-diagnostics",
-      "scoring-model",
-      "negative-doc-lift"
-    ]
-  },
-  {
-    "id": "how-agents-work",
-    "title": "How AI Agents Find Documentation",
-    "body": "Understanding how popular AI coding agents retrieve and use documentation is\ncentral to the ai-literacy-framework evaluation framework. This document\nexplains the mechanisms used by common agents and how our test modes simulate\nthem.\n\n## The Documentation Access Problem\n\nWhen a developer asks an AI coding assistant \"Set up a Sanity Studio with a\ncustom blog schema,\" the agent needs to find and read the relevant Sanity\ndocumentation. But different agents do this in fundamentally different ways, and\nthose differences directly impact the quality of the response.\n\nThe framework measures this impact through four evaluation modes: **full**\n(default \u2014 runs baseline + agentic together), **baseline** (docs in prompt),\n**agentic** (tool-calling with real web access), and **observed** (instrumented\nsingle-call).\n\n## How Popular Agents Work\n\n### Claude Code (Anthropic)\n\nClaude Code has built-in tools including `WebSearchTool` and `WebFetchTool`.\nWhen a user asks a Sanity question:\n\n1. The model decides whether to search the web\n2. If so, it calls `WebSearchTool` with a query string\n3. Search results come back as structured data (titles, URLs, snippets)\n4. The model may call `WebFetchTool` to read specific pages\n5. The fetched content is returned as **rendered text** \u2014 Claude Code's fetch\n   tool handles JavaScript rendering internally, so even SPA pages return\n   readable content\n6. The model synthesizes the fetched docs with its training data to produce an\n   answer\n\n**Key characteristic**: Claude Code sees the web as rendered, readable text. It\ndoesn't get raw HTML soup. But it also doesn't know about agent-friendly\nendpoints like `.md` files or `llms.txt` \u2014 it fetches the same HTML pages a\nbrowser would load.\n\n### ChatGPT (OpenAI)\n\nChatGPT's browsing capability uses Bing search under the hood:\n\n1. The model decides to search (users can also explicitly ask it to browse)\n2. It searches via Bing, getting ranked results\n3. It can \"click\" on results to read page content\n4. Pages are rendered server-side and returned as text\n5. The model reads relevant sections and synthesizes an answer\n\n**Key characteristic**: ChatGPT's browsing is similar to Claude Code \u2014 it gets\nrendered content. The URLs visited are returned in citations. It also has no\nawareness of `llms.txt` or `.md` endpoints.\n\n### Cursor\n\nCursor takes a different approach:\n\n1. It maintains a pre-built index of popular documentation sites (`@docs`)\n2. Users can manually add documentation sources\n3. It also has web search capability for unknown topics\n4. Codebase context is injected automatically from the project\n\n**Key characteristic**: Cursor's `@docs` feature means it may have indexed\nSanity docs already, but the index may be outdated. For unknown topics, it falls\nback to web search like the other agents.\n\n### GitHub Copilot\n\nCopilot primarily relies on:\n\n1. The model's training data (parametric knowledge)\n2. Codebase context from the current project\n3. Bing search for `@workspace` queries in newer versions\n\n**Key characteristic**: Copilot historically had no web access, relying entirely\non training data. Newer versions can search, but the experience is similar to\nChatGPT.\n\n## The JavaScript SPA Problem\n\nSanity's documentation site (`sanity.io/docs`) is built with Next.js \u2014 a\nJavaScript single-page application. When an agent makes a raw HTTP request:\n\n```\nGET https://www.sanity.io/docs/schema-types\n\u2192 Returns ~125KB of HTML that is mostly:\n  - <script> tags for Next.js bundles\n  - React hydration data\n  - Navigation chrome\n  - Very little actual documentation text\n```\n\nReal agents handle this differently than a raw `fetch()`:\n\n| Agent         | Raw fetch? | Gets readable content? | How?                               |\n| ------------- | ---------- | ---------------------- | ---------------------------------- |\n| Claude Code   | No         | Yes                    | Built-in rendering in WebFetchTool |\n| ChatGPT       | No         | Yes                    | Server-side rendering via Bing     |\n| Cursor        | No         | Yes                    | Pre-built doc index                |\n| Raw `fetch()` | Yes        | **No**                 | Gets HTML soup                     |\n\nThis is why the agentic provider uses **Jina Reader** (`r.jina.ai`) as a\nreadability proxy in \"naive\" mode \u2014 it simulates the rendering capability that\nreal agents have built in.\n\n## Sanity's Agent-Friendly Endpoints\n\nSanity has invested in making their documentation accessible to AI agents\nthrough special endpoints:\n\n### `.md` endpoint\n\nAppending `.md` to any docs URL returns pure markdown:\n\n```\nGET https://www.sanity.io/docs/schema-types.md\nContent-Type: text/markdown;charset=UTF-8\n\n# Schema types\nSchema types are used to define the shape of your content...\n```\n\nThis returns **clean markdown** \u2014 no HTML, no JavaScript, no navigation. Just\nthe documentation content. Typical response size: 2-10KB (vs 125KB for the HTML\npage).\n\n### `llms.txt`\n\nSanity provides an `llms.txt` file at `https://www.sanity.io/docs/llms.txt` \u2014 a\nstructured listing of all documentation pages designed for AI agent consumption:\n\n```\n# Sanity\n## Docs\n- [Manage Sanity with code](https://www.sanity.io/docs/blueprints)\n- [Introduction](https://www.sanity.io/docs/blueprints-introduction)\n- [Deploy with GitHub Actions](https://www.sanity.io/docs/blueprints/blueprint-action)\n...\n```\n\nThis follows the emerging [llms.txt standard](https://llmstxt.org/) \u2014 a\nmachine-readable table of contents that tells agents what documentation is\navailable and where to find it.\n\n### Impact on Agent Performance\n\nOur smoke tests show the dramatic difference these endpoints make:\n\n| Metric           | Naive Agent (Jina) | Optimized Agent (.md) |\n| ---------------- | ------------------ | --------------------- |\n| Result           | \u274C FAIL            | \u2705 PASS               |\n| Latency          | 57.9s              | 15.2s (3.8\xD7 faster)   |\n| Bytes downloaded | 108 KB             | 59 KB (45% less)      |\n| Total requests   | 9                  | 6 (33% fewer)         |\n| Search queries   | 3                  | 0 (used llms.txt)     |\n\nThe optimized agent skips search entirely \u2014 it calls `list_docs(\"sanity.io\")` to\nget the `llms.txt` table of contents, identifies the relevant pages, and fetches\nthem directly as `.md`. No search round-trips, no proxy overhead, no content\ncleaning needed.\n\n## How Test Modes Map to Real Agents\n\n| Mode                       | Config                          | Simulates                  | Documentation Access                                                                                                       |\n| -------------------------- | ------------------------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `eval` (baseline)          | `promptfooconfig.yaml`          | No agent \u2014 docs in prompt  | Docs are injected directly into the prompt context, with and without variants                                              |\n| `eval:observed`            | `promptfooconfig.observed.yaml` | Non-agentic API call       | Single OpenAI API call, records the HTTP request but model doesn't browse                                                  |\n| `eval:agentic` (naive)     | `promptfooconfig.agentic.yaml`  | Claude Code, ChatGPT today | Model has `web_search` + `fetch_page` tools; pages fetched via Jina Reader (simulates JS rendering)                        |\n| `eval:agentic` (optimized) | `promptfooconfig.agentic.yaml`  | Ideal future agent         | Model has `web_search` + `fetch_page` + `list_docs` tools; fetches `.md` endpoints directly, uses `llms.txt` for discovery |\n| `agent-harness`            | compiled via compiler           | Real agent in sandbox      | Agent harness mode evaluates real agent behavior in a sandboxed environment (Docker, tempdir, git-worktree)                |\n\n### Why Both Naive and Optimized?\n\nThe comparison between naive and optimized modes answers a critical business\nquestion:\n\n> **\"How much does investing in agent-friendly documentation endpoints (`.md`,\n> `llms.txt`) improve the AI developer experience?\"**\n\nIf the optimized agent significantly outperforms the naive agent, it validates\nthe investment in these endpoints. The data from our tests provides concrete\nevidence for this.\n\n## Limitations of the Simulation\n\nWhile the agentic provider faithfully simulates agent behavior, there are\ndifferences from real agents:\n\n1. **Search quality**: We use DuckDuckGo via Jina as a search fallback. Real\n   agents use Bing (ChatGPT) or their own search (Claude Code). Search result\n   quality varies.\n\n2. **Page rendering**: Jina Reader is a good proxy for JS rendering, but may\n   produce slightly different output than what Claude Code or ChatGPT's internal\n   renderers produce.\n\n3. **Context window management**: Real agents have sophisticated context\n   management \u2014 they may truncate long pages, summarize content, or use sliding\n   windows. Our provider returns content up to a fixed limit (12KB).\n\n4. **Codebase context**: Real agents (especially Cursor and Copilot) inject the\n   developer's current codebase into context. Our eval doesn't simulate this \u2014\n   it only tests documentation retrieval.\n\n5. **Multi-turn interactions**: A real developer might have a conversation with\n   their agent, refining the request. Our eval tests single-turn interactions.\n\n## Future Directions\n\nThe architecture overhaul (Phase 4: agent harness mode) addressed several of\nthese goals \u2014 real agents can now be evaluated in sandboxed environments with\nfixture provisioning, tool manifests, and process-quality scoring. Remaining\ndirections:\n\n- **Subprocess agents** _(partially addressed by agent harness mode)_: The\n  harness supports running agents via entrypoints in Docker, tempdir, or\n  git-worktree sandboxes. Real `claude` CLI or other agent CLIs can be\n  configured as harness entrypoints.\n- **Anthropic/OpenAI native tools**: Use Claude's built-in `web_search` tool or\n  OpenAI's `web_search_preview` in the Responses API for more faithful\n  simulation of the agentic mode\n- **Agent-specific configs**: The compiler's mode handler system makes it\n  straightforward to create per-agent configurations\n- **Codebase context injection** _(partially addressed by fixture\n  provisioning)_: The agent harness fixture provisioner can inject project\n  workspaces, dependency manifests, and code contexts into sandbox environments",
-    "source": "docs/how-agents-work.md",
-    "related": [
-      "eval-modes",
-      "retrieval-gap"
-    ]
-  },
-  {
-    "id": "eval-modes",
-    "title": "Evaluation Modes",
-    "body": '> **This guide is for:** Anyone using AILF who wants to understand what modes\n> exist and when to use each one.\n\nAILF supports five canonical evaluation modes. Each mode measures a different\naspect of AI tool effectiveness.\n\n## Mode overview\n\n| Mode                | What it measures                                     | When to use it                        |\n| ------------------- | ---------------------------------------------------- | ------------------------------------- |\n| **literacy**        | Can AI agents implement features using your docs?    | Testing documentation quality         |\n| **mcp-server**      | Can an LLM correctly use your MCP server\'s tools?    | Testing MCP server implementations    |\n| **knowledge-probe** | What does the model know without any docs?           | Measuring baseline model knowledge    |\n| **agent-harness**   | Can an autonomous agent complete tasks in a sandbox? | Testing agent capabilities end-to-end |\n| **custom**          | Whatever you define                                  | Building your own evaluation type     |\n\n## Choosing a mode\n\n```\nWhat do you want to test?\n    \u2502\n    \u251C\u2500\u2500 "Are our docs helping AI agents?" \u2500\u2500\u2500\u2500\u2500\u2500\u2192 literacy\n    \u251C\u2500\u2500 "Does our MCP server work correctly?" \u2500\u2500\u2192 mcp-server\n    \u251C\u2500\u2500 "What does the model already know?" \u2500\u2500\u2500\u2500\u2192 knowledge-probe\n    \u251C\u2500\u2500 "Can an agent complete real tasks?" \u2500\u2500\u2500\u2500\u2192 agent-harness\n    \u2514\u2500\u2500 "Something else entirely" \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 custom\n```',
-    "source": "docs/modes.md",
-    "related": [
-      "scoring-model",
-      "three-layer"
-    ]
-  },
-  {
-    "id": "glossary",
-    "title": "Glossary",
-    "body": "**Overall Score**\n: A weighted average across all feature areas, using the gold scoring profile: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%).\n\n**Doc Lift**\n: How much the docs help, compared to the model's training data alone. Calculated as ceiling minus floor, where ceiling includes Doc Coverage and floor does not. Higher is better.\n\n**Actual Score**\n: How well an AI agent scores when it has to find docs on its own through web search and page fetching. This is the real-world scenario. Only available in full mode.\n\n**Retrieval Gap**\n: The score lost because agents can't find or use all the relevant docs. Calculated as ceiling minus actual. Lower is better; zero means agents find everything.\n\n**Infra Efficiency**\n: What percentage of the docs' potential quality actually reaches agents (actual \xF7 ceiling). 100% means agents find and use all relevant docs perfectly.\n\n**Floor**\n: Output-quality composite without documentation \u2014 Task Completion (60%) and Code Correctness (40%) only. Doc Coverage is excluded because it's undefined when no docs are provided. This tells you what the model already knows from its training data.\n\n**Ceiling**\n: Score with gold-standard docs injected directly into the prompt. This is the best the documentation can do.\n\n**Actual**\n: Score when an AI agent finds docs on its own through web search and page fetching. This is the real-world experience.\n\n**Ret Gap**\n: Quality lost to discoverability (ceiling minus actual). The gap between what the docs could deliver and what agents actually get.\n\n**Efficiency**\n: What fraction of the docs' quality reaches agents in practice (actual \xF7 ceiling, shown as a percentage).\n\n**Inverted Ret Gap**\n: \u26A0\uFE0F Inverted retrieval gap: agents that can't find the docs actually score higher, because the docs hurt performance. This usually means there's a doc quality problem.\n\n**Score**\n: Ceiling composite for this feature area: Task Completion \xD7 50% + Code Correctness \xD7 25% + Doc Coverage \xD7 25%.\n\n**Task Completion**\n: Can the LLM implement the requested feature? Graded 0\u2013100.\n\n**Code Correctness**\n: Is the generated code idiomatic, correct, and following best practices? Graded 0\u2013100.\n\n**Doc Coverage**\n: Did the docs provide the information needed to implement the feature? Graded 0\u2013100. This dimension only contributes to the ceiling composite (with docs) \u2014 it's excluded from the floor composite because it's undefined without documentation.\n\n**Tests**\n: Number of test cases in this feature area.\n\n**Overall Delta**\n: Change in overall score between the two runs. Positive means the experiment scored higher.\n\n**Actual Delta**\n: Change in actual (agent-retrieved) score between runs. Positive means agents did better.\n\n**Ret Gap Delta**\n: Change in retrieval gap between runs. Negative is good here: it means the gap shrank and agents found more relevant docs.\n\n**Efficiency Delta**\n: Change in infrastructure efficiency between runs. Positive means agents are capturing more of the docs' potential.\n\n**Baseline**\n: The reference run you're comparing against.\n\n**Experiment**\n: The new run you're evaluating.\n\n**Delta**\n: Difference between experiment and baseline. Positive means improvement, negative means regression.\n\n**Change**\n: Whether the change is meaningful: improved, regressed, or unchanged (within the noise threshold).\n\n**Low Scoring Judgments**\n: The grading model's explanations for tests that scored below 70/100.\n\n**Judgment Reason**\n: The grading model's natural language explanation of what went wrong.\n\n**Health Strong**\n: Feature areas scoring 80 or above. The docs are working well for these features \u2014 AI agents produce correct, complete implementations.\n\n**Health Attention**\n: Feature areas scoring 70\u201379. These are okay but could be improved \u2014 there may be gaps in specific dimensions like doc coverage or code correctness.\n\n**Health Weak**\n: Feature areas scoring below 70. The docs are not providing enough support for AI agents to implement these features correctly.\n\n**Negative Doc Lift Metric**\n: Number of areas where the documentation actually hurts AI performance \u2014 the model scores higher without docs than with them. This usually means the docs contain outdated patterns or incorrect examples.\n\n**Weak Areas**\n: Feature areas where the overall score is below 70. These need the most attention \u2014 low scores mean AI agents consistently struggle to implement these features.\n\n**Docs Hurt**\n: Areas where the floor score (no docs) is higher than the ceiling score (with docs). The documentation may be actively misleading the model. These docs should be reviewed.\n\n**Retrieval Issues**\n: Areas where AI agents can find less than 70% of the available doc quality. The docs exist and are good, but agents can't discover them through search. Consider improving page titles, metadata, or search engine indexing.\n\n**Dim Weaknesses**\n: Individual grading dimensions scoring below 50 within an area. These are the specific skills where AI agents fail most \u2014 task completion (can it build the feature?), code correctness (is the code right?), or doc coverage (did it use the docs?).\n\n**Efficiency Anomalies**\n: Areas where agent efficiency exceeds 100% \u2014 meaning agents perform better with self-found docs than with gold-standard docs injected directly. This can indicate doc quality issues (injected docs confuse the model) or agent memorization.\n\n**Doc Lift Wins**\n: Areas where documentation boosts AI performance by 5 or more points. Higher doc lift means the docs are providing crucial information that the model doesn't already know.\n\n**Retrieval Excellence**\n: Areas where AI agents successfully find and use at least 85% of the available doc quality through web search. Good retrieval means your docs are well-indexed and easy for agents to discover.\n\n**Model Breakdown**\n: Break down scores by individual LLM model. The default 'All Models' view shows the cross-model average. Select a specific model to see how it performed independently \u2014 useful for spotting models that struggle with specific feature areas.\n\n**Strengths**\n: What's working well: high-scoring areas, dimensions where the docs are strong, and areas where AI agents successfully find and use the documentation.\n\n**Recommendations**\n: Prioritized remediation plan from gap analysis. Each recommendation identifies a documentation problem, the affected feature area, and the estimated score lift from fixing it.\n\n**Total Potential Lift**\n: Aggregate potential score lift if all identified gaps were fixed. This is a conservative estimate \u2014 each gap targets the median of non-bottlenecked dimensions, not 100.\n\n**Failure Mode**\n: The type of failure the grader emitted. Cross-cutting modes apply to any dimension (api-error, model-limitation, false-floor, unclassified). Per-dimension extensions cover documentation problems (missing-docs, incorrect-docs, outdated-docs, poor-structure), spec adherence (spec-mismatch), tool use (tool-misuse, chaotic-process, missing-recovery), and knowledge probes (factual-error, incompleteness, currency-violation, hallucination).\n\n**Estimated Lift**\n: Estimated composite score improvement if this gap is fully fixed. Based on raising bottleneck dimensions to the median of non-bottlenecked dimensions.\n\n**Confidence**\n: How confident we are in this diagnosis (D0049 ceiling-cross-check derivation). High = the grader's emitted failure mode agrees with the structural ceiling-decomposition signal. Medium = signals disagree (or the ceiling pattern is not informative for this score). Low = passing scores never classify; treat as absent.\n\n**Agent Behavior Overview**\n: How AI agents interacted with your documentation during evaluation: what they searched for, which pages they visited, and how much time they spent on network requests.\n\n**Search Queries**\n: The exact search queries agents used to find documentation. Helps you understand how agents discover your content and whether your docs appear for relevant queries.\n\n**Doc Slugs Visited**\n: Documentation page slugs that agents actually visited during evaluation. Compare against canonical docs to see if agents found the right pages.\n\n**External Domains**\n: Non-Sanity domains that agents contacted during evaluation. High external domain counts may indicate agents couldn't find what they needed in your docs.\n\n**Avg Doc Pages Visited**\n: Average number of documentation pages visited per test. Higher counts can mean agents need to consult many pages (complex task) or can't find the right one quickly.\n\n**Avg Searches Performed**\n: Average number of web searches performed per test. High search counts can indicate docs are hard to discover through search engines.\n\n**Avg Network Time Ms**\n: Average time spent on network requests per test. Includes page fetches, search queries, and API calls.\n\n**Total Requests**\n: Total number of HTTP requests the agent made during the test, including searches, page visits, and API calls.\n\n**Total Bytes Downloaded**\n: Total bytes downloaded by the agent. Large downloads may indicate the agent is fetching many pages or very large documents.\n\n**Dim Task Completion**\n: Change in task completion between runs. Positive means implementations are more complete.\n\n**Dim Code Correctness**\n: Change in code correctness between runs. Positive means better code quality.\n\n**Dim Doc Coverage**\n: Change in doc coverage between runs. Positive means the docs are providing more useful information.\n\n**Area Delta**\n: Score change for this area compared to the previous evaluation run.\n\n**Source Production**\n: Production source \u2014 docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.\n\n**Source Branch**\n: Branch source \u2014 docs fetched from a branch or draft dataset. Use this to preview how content changes affect scores before publishing.\n\n**Source Local**\n: Local source \u2014 docs fetched from local files or a local dev server. Useful for testing doc changes before pushing.\n\n**Report Score**\n: The overall ceiling composite for this evaluation run: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%), averaged across all feature areas.\n\n**Report Mode**\n: The evaluation mode determines which reference points are measured. Different modes test different aspects of how AI agents interact with documentation.\n\n**Report Trigger**\n: What initiated this evaluation run. Knowing the trigger helps you understand whether a score change was from a content edit, a code deploy, or a scheduled check.\n\n**Mode Baseline**\n: Baseline mode \u2014 tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).\n\n**Mode Full**\n: Full mode \u2014 runs baseline + agentic. Compares ceiling (injected docs) against actual (agent-retrieved docs) to measure retrieval gap and infrastructure efficiency.\n\n**Mode Agentic**\n: Agentic mode \u2014 the AI agent finds docs on its own via web search. Measures real-world performance: can agents actually discover and use your documentation?\n\n**Mode Observed**\n: Observed mode \u2014 records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.\n\n**Mode Debug**\n: Debug mode \u2014 a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.\n\n**Trigger Manual**\n: Manually triggered \u2014 someone ran the evaluation pipeline by hand, either locally or via the Studio UI.\n\n**Trigger Ci**\n: CI-triggered \u2014 the evaluation ran automatically as part of a pull request or merge pipeline.\n\n**Trigger Schedule**\n: Scheduled \u2014 the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.\n\n**Trigger Webhook**\n: Webhook-triggered \u2014 a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.\n\n**Trigger Cross Repo**\n: Cross-repo \u2014 triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.",
-    "source": "packages/studio/src/glossary.ts",
-    "tags": [
-      "reference",
-      "glossary"
-    ]
+// src/lib/judgment-drawer-context.tsx
+import {
+  createContext as createContext2,
+  useCallback as useCallback9,
+  useContext as useContext2,
+  useMemo as useMemo3,
+  useState as useState5
+} from "react";
+import { jsx as jsx10 } from "react/jsx-runtime";
+var JudgmentDrawerContext = createContext2(
+  null
+);
+function JudgmentDrawerProvider({ children }) {
+  const [active, setActive] = useState5(null);
+  const open = useCallback9((payload) => {
+    setActive(payload);
+  }, []);
+  const close = useCallback9(() => {
+    setActive(null);
+  }, []);
+  const value = useMemo3(
+    () => ({ active, close, isOpen: active != null, open }),
+    [active, close, open]
+  );
+  return /* @__PURE__ */ jsx10(JudgmentDrawerContext.Provider, { value, children });
+}
+function useJudgmentDrawer() {
+  const ctx = useContext2(JudgmentDrawerContext);
+  if (!ctx) {
+    throw new Error(
+      "useJudgmentDrawer must be called inside a <JudgmentDrawerProvider>"
+    );
   }
-];
+  return ctx;
+}
 
 // src/lib/help-topics.ts
 function deriveHelpTopic(routerState) {
@@ -5296,100 +5568,6 @@ import {
   Text as Text17
 } from "@sanity/ui";
 
-// src/glossary.ts
-var GLOSSARY = {
-  // -- Overview stats -------------------------------------------------------
-  overallScore: "A weighted average across all feature areas, using the gold scoring profile: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%).",
-  docLift: "How much the docs help, compared to the model's training data alone. Calculated as ceiling minus floor, where ceiling includes Doc Coverage and floor does not. Higher is better.",
-  actualScore: "How well an AI agent scores when it has to find docs on its own through web search and page fetching. This is the real-world scenario. Only available in full mode.",
-  retrievalGap: "The score lost because agents can't find or use all the relevant docs. Calculated as ceiling minus actual. Lower is better; zero means agents find everything.",
-  infraEfficiency: "What percentage of the docs' potential quality actually reaches agents (actual \xF7 ceiling). 100% means agents find and use all relevant docs perfectly.",
-  // -- Three-layer decomposition columns ------------------------------------
-  floor: "Output-quality composite without documentation \u2014 Task Completion (60%) and Code Correctness (40%) only. Doc Coverage is excluded because it's undefined when no docs are provided. This tells you what the model already knows from its training data.",
-  ceiling: "Score with gold-standard docs injected directly into the prompt. This is the best the documentation can do.",
-  actual: "Score when an AI agent finds docs on its own through web search and page fetching. This is the real-world experience.",
-  retGap: "Quality lost to discoverability (ceiling minus actual). The gap between what the docs could deliver and what agents actually get.",
-  efficiency: "What fraction of the docs' quality reaches agents in practice (actual \xF7 ceiling, shown as a percentage).",
-  invertedRetGap: "\u26A0\uFE0F Inverted retrieval gap: agents that can't find the docs actually score higher, because the docs hurt performance. This usually means there's a doc quality problem.",
-  // -- Per-area score columns -----------------------------------------------
-  score: "Ceiling composite for this feature area: Task Completion \xD7 50% + Code Correctness \xD7 25% + Doc Coverage \xD7 25%.",
-  taskCompletion: "Can the LLM implement the requested feature? Graded 0\u2013100.",
-  codeCorrectness: "Is the generated code idiomatic, correct, and following best practices? Graded 0\u2013100.",
-  docCoverage: "Did the docs provide the information needed to implement the feature? Graded 0\u2013100. This dimension only contributes to the ceiling composite (with docs) \u2014 it's excluded from the floor composite because it's undefined without documentation.",
-  tests: "Number of test cases in this feature area.",
-  // -- Comparison deltas ----------------------------------------------------
-  overallDelta: "Change in overall score between the two runs. Positive means the experiment scored higher.",
-  actualDelta: "Change in actual (agent-retrieved) score between runs. Positive means agents did better.",
-  retGapDelta: "Change in retrieval gap between runs. Negative is good here: it means the gap shrank and agents found more relevant docs.",
-  efficiencyDelta: "Change in infrastructure efficiency between runs. Positive means agents are capturing more of the docs' potential.",
-  // -- Comparison table columns ---------------------------------------------
-  baseline: "The reference run you're comparing against.",
-  experiment: "The new run you're evaluating.",
-  delta: "Difference between experiment and baseline. Positive means improvement, negative means regression.",
-  change: "Whether the change is meaningful: improved, regressed, or unchanged (within the noise threshold).",
-  // -- Grader judgments ------------------------------------------------------
-  lowScoringJudgments: "The grading model's explanations for tests that scored below 70/100.",
-  judgmentReason: "The grading model's natural language explanation of what went wrong.",
-  // -- Diagnostics overview ---------------------------------------------------
-  healthStrong: "Feature areas scoring 80 or above. The docs are working well for these features \u2014 AI agents produce correct, complete implementations.",
-  healthAttention: "Feature areas scoring 70\u201379. These are okay but could be improved \u2014 there may be gaps in specific dimensions like doc coverage or code correctness.",
-  healthWeak: "Feature areas scoring below 70. The docs are not providing enough support for AI agents to implement these features correctly.",
-  negativeDocLiftMetric: "Number of areas where the documentation actually hurts AI performance \u2014 the model scores higher without docs than with them. This usually means the docs contain outdated patterns or incorrect examples.",
-  weakAreas: "Feature areas where the overall score is below 70. These need the most attention \u2014 low scores mean AI agents consistently struggle to implement these features.",
-  docsHurt: "Areas where the floor score (no docs) is higher than the ceiling score (with docs). The documentation may be actively misleading the model. These docs should be reviewed.",
-  retrievalIssues: "Areas where AI agents can find less than 70% of the available doc quality. The docs exist and are good, but agents can't discover them through search. Consider improving page titles, metadata, or search engine indexing.",
-  dimWeaknesses: "Individual grading dimensions scoring below 50 within an area. These are the specific skills where AI agents fail most \u2014 task completion (can it build the feature?), code correctness (is the code right?), or doc coverage (did it use the docs?).",
-  efficiencyAnomalies: "Areas where agent efficiency exceeds 100% \u2014 meaning agents perform better with self-found docs than with gold-standard docs injected directly. This can indicate doc quality issues (injected docs confuse the model) or agent memorization.",
-  docLiftWins: "Areas where documentation boosts AI performance by 5 or more points. Higher doc lift means the docs are providing crucial information that the model doesn't already know.",
-  retrievalExcellence: "Areas where AI agents successfully find and use at least 85% of the available doc quality through web search. Good retrieval means your docs are well-indexed and easy for agents to discover.",
-  // -- Model breakdown --------------------------------------------------------
-  modelBreakdown: "Break down scores by individual LLM model. The default 'All Models' view shows the cross-model average. Select a specific model to see how it performed independently \u2014 useful for spotting models that struggle with specific feature areas.",
-  // -- Strengths (positive diagnostics) ---------------------------------------
-  strengths: "What's working well: high-scoring areas, dimensions where the docs are strong, and areas where AI agents successfully find and use the documentation.",
-  // -- Recommendations / gap analysis ----------------------------------------
-  recommendations: "Prioritized remediation plan from gap analysis. Each recommendation identifies a documentation problem, the affected feature area, and the estimated score lift from fixing it.",
-  totalPotentialLift: "Aggregate potential score lift if all identified gaps were fixed. This is a conservative estimate \u2014 each gap targets the median of non-bottlenecked dimensions, not 100.",
-  failureMode: "The type of failure the grader emitted. Cross-cutting modes apply to any dimension (api-error, model-limitation, false-floor, unclassified). Per-dimension extensions cover documentation problems (missing-docs, incorrect-docs, outdated-docs, poor-structure), spec adherence (spec-mismatch), tool use (tool-misuse, chaotic-process, missing-recovery), and knowledge probes (factual-error, incompleteness, currency-violation, hallucination).",
-  estimatedLift: "Estimated composite score improvement if this gap is fully fixed. Based on raising bottleneck dimensions to the median of non-bottlenecked dimensions.",
-  confidence: "How confident we are in this diagnosis (D0049 ceiling-cross-check derivation). High = the grader's emitted failure mode agrees with the structural ceiling-decomposition signal. Medium = signals disagree (or the ceiling pattern is not informative for this score). Low = passing scores never classify; treat as absent.",
-  // -- Agent behavior --------------------------------------------------------
-  agentBehaviorOverview: "How AI agents interacted with your documentation during evaluation: what they searched for, which pages they visited, and how much time they spent on network requests.",
-  searchQueries: "The exact search queries agents used to find documentation. Helps you understand how agents discover your content and whether your docs appear for relevant queries.",
-  docSlugsVisited: "Documentation page slugs that agents actually visited during evaluation. Compare against canonical docs to see if agents found the right pages.",
-  externalDomains: "Non-Sanity domains that agents contacted during evaluation. High external domain counts may indicate agents couldn't find what they needed in your docs.",
-  avgDocPagesVisited: "Average number of documentation pages visited per test. Higher counts can mean agents need to consult many pages (complex task) or can't find the right one quickly.",
-  avgSearchesPerformed: "Average number of web searches performed per test. High search counts can indicate docs are hard to discover through search engines.",
-  avgNetworkTimeMs: "Average time spent on network requests per test. Includes page fetches, search queries, and API calls.",
-  totalRequests: "Total number of HTTP requests the agent made during the test, including searches, page visits, and API calls.",
-  totalBytesDownloaded: "Total bytes downloaded by the agent. Large downloads may indicate the agent is fetching many pages or very large documents.",
-  // -- Dimension deltas -----------------------------------------------------
-  dimTaskCompletion: "Change in task completion between runs. Positive means implementations are more complete.",
-  dimCodeCorrectness: "Change in code correctness between runs. Positive means better code quality.",
-  dimDocCoverage: "Change in doc coverage between runs. Positive means the docs are providing more useful information.",
-  // -- Per-area trend delta ----------------------------------------------------
-  areaDelta: "Score change for this area compared to the previous evaluation run.",
-  // -- Source values -----------------------------------------------------------
-  sourceProduction: "Production source \u2014 docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.",
-  sourceBranch: "Branch source \u2014 docs fetched from a branch or draft dataset. Use this to preview how content changes affect scores before publishing.",
-  sourceLocal: "Local source \u2014 docs fetched from local files or a local dev server. Useful for testing doc changes before pushing.",
-  // -- Report list columns ----------------------------------------------------
-  reportScore: "The overall ceiling composite for this evaluation run: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%), averaged across all feature areas.",
-  reportMode: "The evaluation mode determines which reference points are measured. Different modes test different aspects of how AI agents interact with documentation.",
-  reportTrigger: "What initiated this evaluation run. Knowing the trigger helps you understand whether a score change was from a content edit, a code deploy, or a scheduled check.",
-  // -- Mode values -----------------------------------------------------------
-  modeBaseline: "Baseline mode \u2014 tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).",
-  modeFull: "Full mode \u2014 runs baseline + agentic. Compares ceiling (injected docs) against actual (agent-retrieved docs) to measure retrieval gap and infrastructure efficiency.",
-  modeAgentic: "Agentic mode \u2014 the AI agent finds docs on its own via web search. Measures real-world performance: can agents actually discover and use your documentation?",
-  modeObserved: "Observed mode \u2014 records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.",
-  modeDebug: "Debug mode \u2014 a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.",
-  // -- Trigger values --------------------------------------------------------
-  triggerManual: "Manually triggered \u2014 someone ran the evaluation pipeline by hand, either locally or via the Studio UI.",
-  triggerCi: "CI-triggered \u2014 the evaluation ran automatically as part of a pull request or merge pipeline.",
-  triggerSchedule: "Scheduled \u2014 the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.",
-  triggerWebhook: "Webhook-triggered \u2014 a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.",
-  triggerCrossRepo: "Cross-repo \u2014 triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks."
-};
-
 // src/components/report-table/useContainerWidth.ts
 import { useCallback as useCallback13, useEffect as useEffect5, useRef as useRef4, useState as useState9 } from "react";
 var FULL_MIN = 900;
@@ -5703,8 +5881,14 @@ function ReportTable({
             ),
             tier !== "narrow" && /* @__PURE__ */ jsx20(ColHeader, { label: "Change" }),
             tier === "full" && /* @__PURE__ */ jsxs17(Fragment6, { children: [
-              /* @__PURE__ */ jsx20(ColHeader, { infoTip: GLOSSARY.reportMode, label: "Mode" }),
-              /* @__PURE__ */ jsx20(ColHeader, { infoTip: GLOSSARY.reportTrigger, label: "Trigger" }),
+              /* @__PURE__ */ jsx20(ColHeader, { infoTip: GLOSSARY.reportMode.long, label: "Mode" }),
+              /* @__PURE__ */ jsx20(
+                ColHeader,
+                {
+                  infoTip: GLOSSARY.reportTrigger.long,
+                  label: "Trigger"
+                }
+              ),
               /* @__PURE__ */ jsx20(
                 ColHeader,
                 {
@@ -5914,18 +6098,18 @@ var TRIGGER_TONE = {
   webhook: "positive"
 };
 var MODE_TIP = {
-  agentic: GLOSSARY.modeAgentic,
-  baseline: GLOSSARY.modeBaseline,
-  debug: GLOSSARY.modeDebug,
-  full: GLOSSARY.modeFull,
-  observed: GLOSSARY.modeObserved
+  agentic: GLOSSARY.modeAgentic.long,
+  baseline: GLOSSARY.modeBaseline.long,
+  debug: GLOSSARY.modeDebug.long,
+  full: GLOSSARY.modeFull.long,
+  observed: GLOSSARY.modeObserved.long
 };
 var TRIGGER_TIP = {
-  ci: GLOSSARY.triggerCi,
-  "cross-repo": GLOSSARY.triggerCrossRepo,
-  manual: GLOSSARY.triggerManual,
-  schedule: GLOSSARY.triggerSchedule,
-  webhook: GLOSSARY.triggerWebhook
+  ci: GLOSSARY.triggerCi.long,
+  "cross-repo": GLOSSARY.triggerCrossRepo.long,
+  manual: GLOSSARY.triggerManual.long,
+  schedule: GLOSSARY.triggerSchedule.long,
+  webhook: GLOSSARY.triggerWebhook.long
 };
 function ModeBadge({ mode }) {
   const badge = /* @__PURE__ */ jsx20(OutlineBadge, { tone: MODE_TONE[mode] ?? "default", children: mode });
@@ -6997,14 +7181,14 @@ function OverviewGrid({ overall }) {
   return /* @__PURE__ */ jsx25(Card10, { padding: 4, radius: 2, shadow: 1, children: /* @__PURE__ */ jsxs20(Stack16, { space: 4, children: [
     /* @__PURE__ */ jsxs20(Flex11, { align: "center", gap: 3, children: [
       /* @__PURE__ */ jsx25(Text21, { size: 3, weight: "semibold", children: "Agent Activity Overview" }),
-      /* @__PURE__ */ jsx25(GlossaryTip, { text: GLOSSARY.agentBehaviorOverview })
+      /* @__PURE__ */ jsx25(GlossaryTip, { text: GLOSSARY.agentBehaviorOverview.long })
     ] }),
     /* @__PURE__ */ jsxs20(Grid, { columns: [1, 2, 3], gap: 3, children: [
       /* @__PURE__ */ jsx25(
         StatCard,
         {
           label: "Avg Pages Visited",
-          tooltip: GLOSSARY.avgDocPagesVisited,
+          tooltip: GLOSSARY.avgDocPagesVisited.long,
           value: overall.avgDocPagesVisited.toFixed(1)
         }
       ),
@@ -7012,7 +7196,7 @@ function OverviewGrid({ overall }) {
         StatCard,
         {
           label: "Avg Searches",
-          tooltip: GLOSSARY.avgSearchesPerformed,
+          tooltip: GLOSSARY.avgSearchesPerformed.long,
           value: overall.avgSearchesPerformed.toFixed(1)
         }
       ),
@@ -7020,7 +7204,7 @@ function OverviewGrid({ overall }) {
         StatCard,
         {
           label: "Avg Network Time",
-          tooltip: GLOSSARY.avgNetworkTimeMs,
+          tooltip: GLOSSARY.avgNetworkTimeMs.long,
           value: formatDuration(overall.avgNetworkTimeMs)
         }
       ),
@@ -7028,7 +7212,7 @@ function OverviewGrid({ overall }) {
         StatCard,
         {
           label: "Unique Doc Slugs",
-          tooltip: GLOSSARY.docSlugsVisited,
+          tooltip: GLOSSARY.docSlugsVisited.long,
           value: String(overall.totalUniqueDocSlugs)
         }
       ),
@@ -7036,7 +7220,7 @@ function OverviewGrid({ overall }) {
         StatCard,
         {
           label: "Unique Search Queries",
-          tooltip: GLOSSARY.searchQueries,
+          tooltip: GLOSSARY.searchQueries.long,
           value: String(overall.totalUniqueSearchQueries)
         }
       ),
@@ -7109,7 +7293,7 @@ function FeatureActivityCard({
         items: slugs.items,
         label: "Pages Visited",
         tone: "primary",
-        tooltip: GLOSSARY.docSlugsVisited,
+        tooltip: GLOSSARY.docSlugsVisited.long,
         totalCount: slugs.totalCount,
         truncated: slugs.truncated
       }
@@ -7120,7 +7304,7 @@ function FeatureActivityCard({
         items: behavior.externalDomains,
         label: "External Domains",
         tone: "caution",
-        tooltip: GLOSSARY.externalDomains
+        tooltip: GLOSSARY.externalDomains.long
       }
     )
   ] }) });
@@ -7151,7 +7335,7 @@ function SearchQueryList({
   return /* @__PURE__ */ jsxs20(Stack16, { space: 3, children: [
     /* @__PURE__ */ jsxs20(Flex11, { align: "center", gap: 3, wrap: "wrap", children: [
       /* @__PURE__ */ jsx25(Text21, { size: 2, weight: "semibold", children: "Search Queries" }),
-      /* @__PURE__ */ jsx25(GlossaryTip, { text: GLOSSARY.searchQueries }),
+      /* @__PURE__ */ jsx25(GlossaryTip, { text: GLOSSARY.searchQueries.long }),
       /* @__PURE__ */ jsx25(Badge4, { tone: "default", children: totalCount }),
       truncated && /* @__PURE__ */ jsxs20(Text21, { muted: true, size: 1, children: [
         "(showing ",
@@ -7746,7 +7930,7 @@ function DiagnosticsOverview({
               gridTemplateColumns: showDocMetrics ? "repeat(3, 1fr)" : "repeat(2, 1fr)"
             },
             children: [
-              /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.overallScore, children: /* @__PURE__ */ jsx29(
+              /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.overallScore.long, children: /* @__PURE__ */ jsx29(
                 ScoreCard,
                 {
                   delta: comparison?.deltas.overall,
@@ -7756,7 +7940,7 @@ function DiagnosticsOverview({
                   value: Math.round(overall.avgScore)
                 }
               ) }),
-              showDocMetrics && /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.docLift, children: /* @__PURE__ */ jsx29(
+              showDocMetrics && /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.docLift.long, children: /* @__PURE__ */ jsx29(
                 ScoreCard,
                 {
                   delta: comparison?.deltas.docLift,
@@ -7766,7 +7950,7 @@ function DiagnosticsOverview({
                   value: Math.round(overall.avgDocLift)
                 }
               ) }),
-              /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.tests, children: /* @__PURE__ */ jsx29(
+              /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.tests.long, children: /* @__PURE__ */ jsx29(
                 ScoreCard,
                 {
                   label: "TESTS",
@@ -7786,14 +7970,21 @@ function DiagnosticsOverview({
               gridTemplateColumns: showDocMetrics ? "repeat(2, 1fr)" : "1fr"
             },
             children: [
-              showDocMetrics && /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.negativeDocLiftMetric, children: /* @__PURE__ */ jsx29(
-                MetricCard,
+              showDocMetrics && /* @__PURE__ */ jsx29(
+                HoverTip,
                 {
-                  label: "Negative Doc Lift",
-                  sentiment: negativeDocLiftSentiment(negativeDocLiftCount),
-                  value: `${negativeDocLiftCount} area${negativeDocLiftCount === 1 ? "" : "s"}`
+                  display: "block",
+                  text: GLOSSARY.negativeDocLiftMetric.long,
+                  children: /* @__PURE__ */ jsx29(
+                    MetricCard,
+                    {
+                      label: "Negative Doc Lift",
+                      sentiment: negativeDocLiftSentiment(negativeDocLiftCount),
+                      value: `${negativeDocLiftCount} area${negativeDocLiftCount === 1 ? "" : "s"}`
+                    }
+                  )
                 }
-              ) }),
+              ),
               durationMs != null && durationMs > 0 ? /* @__PURE__ */ jsx29(
                 HoverTip,
                 {
@@ -7824,7 +8015,7 @@ function DiagnosticsOverview({
             gridTemplateColumns: "repeat(3, 1fr)"
           },
           children: [
-            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.actualScore, children: /* @__PURE__ */ jsx29(
+            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.actualScore.long, children: /* @__PURE__ */ jsx29(
               ScoreCard,
               {
                 delta: comparison?.deltas.actualDelta,
@@ -7834,7 +8025,7 @@ function DiagnosticsOverview({
                 value: Math.round(overall.avgActualScore)
               }
             ) }),
-            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.retrievalGap, children: /* @__PURE__ */ jsx29(
+            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.retrievalGap.long, children: /* @__PURE__ */ jsx29(
               ScoreCard,
               {
                 label: "RETRIEVAL GAP",
@@ -7844,7 +8035,7 @@ function DiagnosticsOverview({
                 value: overall.avgRetrievalGap != null ? Math.round(overall.avgRetrievalGap) : 0
               }
             ) }),
-            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.infraEfficiency, children: /* @__PURE__ */ jsx29(
+            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.infraEfficiency.long, children: /* @__PURE__ */ jsx29(
               ScoreCard,
               {
                 label: "EFFICIENCY",
@@ -7869,7 +8060,7 @@ function DiagnosticsOverview({
             gridTemplateColumns: "1fr 1fr 1fr"
           },
           children: [
-            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.healthStrong, children: /* @__PURE__ */ jsx29(
+            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.healthStrong.long, children: /* @__PURE__ */ jsx29(
               HealthCard,
               {
                 color: strong.length > 0 ? "emerald" : "muted",
@@ -7878,7 +8069,7 @@ function DiagnosticsOverview({
                 label: "Strong (80+)"
               }
             ) }),
-            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.healthAttention, children: /* @__PURE__ */ jsx29(
+            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.healthAttention.long, children: /* @__PURE__ */ jsx29(
               HealthCard,
               {
                 color: attention.length === 0 ? "muted" : "amber",
@@ -7887,7 +8078,7 @@ function DiagnosticsOverview({
                 label: "Attention (70-79)"
               }
             ) }),
-            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.healthWeak, children: /* @__PURE__ */ jsx29(
+            /* @__PURE__ */ jsx29(HoverTip, { display: "block", text: GLOSSARY.healthWeak.long, children: /* @__PURE__ */ jsx29(
               HealthCard,
               {
                 color: weak.length === 0 ? "muted" : "red",
@@ -9408,7 +9599,7 @@ function JudgmentList({
       /* @__PURE__ */ jsx36(
         Tooltip8,
         {
-          content: /* @__PURE__ */ jsx36(Box22, { padding: 2, style: { maxWidth: 260 }, children: /* @__PURE__ */ jsx36(Text30, { size: 2, children: GLOSSARY.lowScoringJudgments }) }),
+          content: /* @__PURE__ */ jsx36(Box22, { padding: 2, style: { maxWidth: 260 }, children: /* @__PURE__ */ jsx36(Text30, { size: 2, children: GLOSSARY.lowScoringJudgments.long }) }),
           placement: "bottom",
           portal: true,
           children: /* @__PURE__ */ jsx36(Text30, { muted: true, size: 1, children: /* @__PURE__ */ jsx36(HelpCircleIcon6, {}) })
@@ -10493,7 +10684,7 @@ var fmLabel = {
 };
 function failureModeTip(mode) {
   const desc = FAILURE_MODE_DESCS[mode];
-  if (!desc) return GLOSSARY.failureMode;
+  if (!desc) return GLOSSARY.failureMode.long;
   return /* @__PURE__ */ jsxs31(Text33, { size: 2, style: { lineHeight: 1.5 }, children: [
     /* @__PURE__ */ jsx40("span", { style: fmLabel, children: mode }),
     " \u2014 ",
@@ -10502,7 +10693,7 @@ function failureModeTip(mode) {
 }
 function confidenceTip(level) {
   const desc = CONFIDENCE_DESCS[level];
-  if (!desc) return GLOSSARY.confidence;
+  if (!desc) return GLOSSARY.confidence.long;
   const icons = { high: "\u{1F7E2}", medium: "\u{1F7E1}", low: "\u{1F534}" };
   return /* @__PURE__ */ jsxs31(Text33, { size: 2, style: { lineHeight: 1.5 }, children: [
     icons[level],
@@ -11126,27 +11317,42 @@ function dateStamp2() {
   const d = /* @__PURE__ */ new Date();
   return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
 }
+function buildRerunPipelineRequest(args) {
+  const { scope, sourceReportId, tag } = args;
+  return {
+    areas: scope.areas,
+    dataset: scope.dataset,
+    mode: scope.mode,
+    ...scope.perspective ? { perspective: scope.perspective } : {},
+    projectId: scope.projectId,
+    publish: true,
+    publishTag: tag,
+    source: "production",
+    sourceReportId,
+    taskMode: "content-lake",
+    ...scope.taskIds && scope.taskIds.length > 0 ? { tasks: scope.taskIds } : {}
+  };
+}
 function buildRequestDoc(scope, meta) {
   const shortId = slugify2(meta.reportId.slice(0, 12));
   const tag = `rerun-${shortId}-${dateStamp2()}`;
   const now = (/* @__PURE__ */ new Date()).toISOString();
+  const pipelineRequest = buildRerunPipelineRequest({
+    scope,
+    sourceReportId: meta.reportId,
+    tag
+  });
   return {
     _type: EVAL_REQUEST_TYPE2,
-    // Spread all scope fields — new EvalScope fields are automatically
-    // included without changes here
-    areas: scope.areas,
     dataset: scope.dataset,
-    mode: scope.mode,
-    ...scope.perspective ? { perspective: scope.perspective } : {},
+    pipelineRequest: JSON.stringify(pipelineRequest),
     projectId: scope.projectId,
-    ...scope.taskIds && scope.taskIds.length > 0 ? { tasks: scope.taskIds } : {},
-    // Request metadata
     requestedAt: now,
     requestedBy: meta.userId,
-    // Lineage — links this request back to the source report
+    // Lineage — duplicated on the document for projection convenience.
+    // Authoritative copy is on pipelineRequest.sourceReportId.
     sourceReportId: meta.reportId,
-    status: "pending",
-    tag
+    status: "pending"
   };
 }
 function RerunEvaluationAction({
@@ -11495,9 +11701,9 @@ import { Box as Box28, Flex as Flex29, Stack as Stack31, Text as Text40 } from "
 var DIMENSION_TOOLTIPS = {
   agentOutput: "Quality and completeness of the agent's output. Graded 0\u2013100.",
   assertionPassRate: "Fraction of structural assertions that passed. Graded 0\u2013100.",
-  codeCorrectness: GLOSSARY.codeCorrectness,
-  docCoverage: GLOSSARY.docCoverage,
-  taskCompletion: GLOSSARY.taskCompletion,
+  codeCorrectness: GLOSSARY.codeCorrectness.long,
+  docCoverage: GLOSSARY.docCoverage.long,
+  taskCompletion: GLOSSARY.taskCompletion.long,
   toolUsage: "How effectively the agent used available tools (file read/write, shell, etc.). Graded 0\u2013100."
 };
 function dimensionLabel2(key) {
@@ -11595,9 +11801,9 @@ import { Fragment as Fragment14, jsx as jsx56, jsxs as jsxs39 } from "react/jsx-
 var DIMENSION_TOOLTIPS2 = {
   agentOutput: "Quality and completeness of the agent's output. Graded 0\u2013100.",
   assertionPassRate: "Fraction of structural assertions that passed. Graded 0\u2013100.",
-  codeCorrectness: GLOSSARY.codeCorrectness,
-  docCoverage: GLOSSARY.docCoverage,
-  taskCompletion: GLOSSARY.taskCompletion,
+  codeCorrectness: GLOSSARY.codeCorrectness.long,
+  docCoverage: GLOSSARY.docCoverage.long,
+  taskCompletion: GLOSSARY.taskCompletion.long,
   toolUsage: "How effectively the agent used available tools (file read/write, shell, etc.). Graded 0\u2013100."
 };
 function tableTier(width) {
@@ -11707,7 +11913,7 @@ function AreaScoresGrid({
               direction: sortDir,
               label: "Score",
               onClick: () => handleSort("score"),
-              tooltip: GLOSSARY.score
+              tooltip: GLOSSARY.score.long
             }
           ),
           /* @__PURE__ */ jsx56(
@@ -11737,10 +11943,10 @@ function AreaScoresGrid({
               direction: sortDir,
               label: "Lift",
               onClick: () => handleSort("lift"),
-              tooltip: GLOSSARY.docLift
+              tooltip: GLOSSARY.docLift.long
             }
           ),
-          tier === "full" && hasActual && /* @__PURE__ */ jsx56(ColHeader2, { label: "Actual", tooltip: GLOSSARY.actualScore })
+          tier === "full" && hasActual && /* @__PURE__ */ jsx56(ColHeader2, { label: "Actual", tooltip: GLOSSARY.actualScore.long })
         ]
       }
     ),
@@ -11919,7 +12125,7 @@ function AreaRow({
                 /* @__PURE__ */ jsx56("span", { style: { color: "var(--card-muted-fg-color)" }, children: "/100" }),
                 ".",
                 " ",
-                GLOSSARY.score
+                GLOSSARY.score.long
               ] }),
               children: /* @__PURE__ */ jsx56(
                 "div",
@@ -11942,11 +12148,11 @@ function AreaRow({
               )
             }
           ),
-          !isNarrow && delta != null && delta !== 0 && /* @__PURE__ */ jsx56(HoverTip, { text: GLOSSARY.areaDelta, children: /* @__PURE__ */ jsx56(DeltaIndicator, { delta, icon: true, size: 1 }) })
+          !isNarrow && delta != null && delta !== 0 && /* @__PURE__ */ jsx56(HoverTip, { text: GLOSSARY.areaDelta.long, children: /* @__PURE__ */ jsx56(DeltaIndicator, { delta, icon: true, size: 1 }) })
         ] }),
         /* @__PURE__ */ jsxs39(Flex27, { align: "center", gap: 2, wrap: "wrap", children: [
           /* @__PURE__ */ jsx56(Text38, { size: 2, weight: "medium", children: area.feature }),
-          area.negativeDocLift && showLift && /* @__PURE__ */ jsx56(HoverTip, { text: GLOSSARY.docsHurt, children: /* @__PURE__ */ jsx56(
+          area.negativeDocLift && showLift && /* @__PURE__ */ jsx56(HoverTip, { text: GLOSSARY.docsHurt.long, children: /* @__PURE__ */ jsx56(
             "span",
             {
               style: {
@@ -11995,7 +12201,7 @@ function AreaRow({
               ),
               " ",
               "pts. ",
-              GLOSSARY.docLift
+              GLOSSARY.docLift.long
             ] }),
             children: /* @__PURE__ */ jsxs39(
               Text38,
@@ -12017,7 +12223,7 @@ function AreaRow({
         tier === "full" && hasActual && /* @__PURE__ */ jsx56(
           HoverTip,
           {
-            text: area.actualScore != null ? `${area.feature} actual score: ${Math.round(area.actualScore)}/100. ${GLOSSARY.actualScore}` : `No agentic data for ${area.feature}.`,
+            text: area.actualScore != null ? `${area.feature} actual score: ${Math.round(area.actualScore)}/100. ${GLOSSARY.actualScore.long}` : `No agentic data for ${area.feature}.`,
             children: /* @__PURE__ */ jsx56(
               Text38,
               {
@@ -12334,7 +12540,7 @@ function StrengthsList({
       /* @__PURE__ */ jsxs41(Flex29, { align: "center", gap: 2, wrap: "wrap", children: [
         /* @__PURE__ */ jsx58(CheckmarkCircleIcon2, { style: { color: "#34d399" } }),
         /* @__PURE__ */ jsx58(Text40, { size: 2, weight: "medium", children: "Strong Areas (70+)" }),
-        /* @__PURE__ */ jsx58(InfoTip, { text: GLOSSARY.strengths }),
+        /* @__PURE__ */ jsx58(InfoTip, { text: GLOSSARY.strengths.long }),
         hasModels && /* @__PURE__ */ jsx58(Box28, { style: { marginLeft: "auto" }, children: /* @__PURE__ */ jsx58(
           ModelSelector,
           {
@@ -12367,7 +12573,7 @@ function StrengthsList({
               Math.round(EFFICIENCY_POSITIVE * 100),
               "%+ efficiency)"
             ] }),
-            /* @__PURE__ */ jsx58(InfoTip, { text: GLOSSARY.retrievalExcellence })
+            /* @__PURE__ */ jsx58(InfoTip, { text: GLOSSARY.retrievalExcellence.long })
           ] })
         }
       ),
@@ -12492,7 +12698,7 @@ function WeaknessesList({
       /* @__PURE__ */ jsxs43(Flex31, { align: "center", gap: 2, wrap: "wrap", children: [
         /* @__PURE__ */ jsx60(ErrorOutlineIcon3, { style: { color: "#f87171" } }),
         /* @__PURE__ */ jsx60(Text42, { size: 2, weight: "medium", children: "Weak Areas (<70)" }),
-        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.weakAreas }),
+        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.weakAreas.long }),
         hasModels && /* @__PURE__ */ jsx60(Box30, { style: { marginLeft: "auto" }, children: /* @__PURE__ */ jsx60(
           ModelSelector,
           {
@@ -12516,7 +12722,7 @@ function WeaknessesList({
       /* @__PURE__ */ jsxs43(Flex31, { align: "center", gap: 2, children: [
         /* @__PURE__ */ jsx60(ErrorOutlineIcon3, { style: { color: "#f87171" } }),
         /* @__PURE__ */ jsx60(Text42, { size: 2, weight: "medium", children: "Docs Hurt Performance (Negative Doc Lift)" }),
-        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.docsHurt })
+        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.docsHurt.long })
       ] }),
       /* @__PURE__ */ jsx60(Box30, { style: sectionStyle("red"), children: docsHurt.map((area, i) => /* @__PURE__ */ jsxs43(
         Box30,
@@ -12575,7 +12781,7 @@ function WeaknessesList({
       /* @__PURE__ */ jsxs43(Flex31, { align: "center", gap: 2, children: [
         /* @__PURE__ */ jsx60(SearchIcon9, { style: { color: "#fbbf24" } }),
         /* @__PURE__ */ jsx60(Text42, { size: 2, weight: "medium", children: "Retrieval Issues (<70% efficiency)" }),
-        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.retrievalIssues })
+        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.retrievalIssues.long })
       ] }),
       /* @__PURE__ */ jsx60(Box30, { style: sectionStyle("amber"), children: retrievalIssues.map((area, i) => /* @__PURE__ */ jsxs43(
         Box30,
@@ -12633,7 +12839,7 @@ function WeaknessesList({
       /* @__PURE__ */ jsxs43(Flex31, { align: "center", gap: 2, children: [
         /* @__PURE__ */ jsx60(WarningOutlineIcon3, { style: { color: "#fbbf24" } }),
         /* @__PURE__ */ jsx60(Text42, { size: 2, weight: "medium", children: "Dimension Weaknesses (<50)" }),
-        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.dimWeaknesses })
+        /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.dimWeaknesses.long })
       ] }),
       /* @__PURE__ */ jsx60(Box30, { style: neutralCardStyle, children: dimWeaknesses.map(({ area, dims }, i) => /* @__PURE__ */ jsxs43(
         Box30,
@@ -12740,7 +12946,7 @@ function WeaknessesList({
             /* @__PURE__ */ jsxs43(Flex31, { align: "center", gap: 2, children: [
               /* @__PURE__ */ jsx60(BoltIcon2, { style: { color: "#fbbf24" } }),
               /* @__PURE__ */ jsx60(Text42, { size: 2, weight: "medium", children: "Efficiency Anomalies (>100%)" }),
-              /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.efficiencyAnomalies })
+              /* @__PURE__ */ jsx60(InfoTip, { text: GLOSSARY.efficiencyAnomalies.long })
             ] }),
             /* @__PURE__ */ jsx60(Text42, { muted: true, size: 2, children: "Agent outperforms injected docs \u2014 may indicate doc quality issues or agent memorization." })
           ] })
@@ -12950,11 +13156,17 @@ function ReportDetail({
             /* @__PURE__ */ jsx61(
               HoverTip,
               {
-                text: SOURCE_TIP[provenance.source.name] ?? GLOSSARY.reportMode,
+                text: SOURCE_TIP[provenance.source.name] ?? GLOSSARY.reportMode.long,
                 children: /* @__PURE__ */ jsx61(Badge9, { mode: "outline", tone: "default", children: provenance.source.name })
               }
             ),
-            /* @__PURE__ */ jsx61(HoverTip, { text: MODE_TIP2[provenance.mode] ?? GLOSSARY.reportMode, children: /* @__PURE__ */ jsx61(Badge9, { tone: "primary", children: provenance.mode }) }),
+            /* @__PURE__ */ jsx61(
+              HoverTip,
+              {
+                text: MODE_TIP2[provenance.mode] ?? GLOSSARY.reportMode.long,
+                children: /* @__PURE__ */ jsx61(Badge9, { tone: "primary", children: provenance.mode })
+              }
+            ),
             /* @__PURE__ */ jsx61(
               ReportActions,
               {
@@ -13180,16 +13392,16 @@ function DiagnosticsPanel({
   ] }) });
 }
 var MODE_TIP2 = {
-  agentic: GLOSSARY.modeAgentic,
-  baseline: GLOSSARY.modeBaseline,
-  debug: GLOSSARY.modeDebug,
-  full: GLOSSARY.modeFull,
-  observed: GLOSSARY.modeObserved
+  agentic: GLOSSARY.modeAgentic.long,
+  baseline: GLOSSARY.modeBaseline.long,
+  debug: GLOSSARY.modeDebug.long,
+  full: GLOSSARY.modeFull.long,
+  observed: GLOSSARY.modeObserved.long
 };
 var SOURCE_TIP = {
-  branch: GLOSSARY.sourceBranch,
-  local: GLOSSARY.sourceLocal,
-  production: GLOSSARY.sourceProduction
+  branch: GLOSSARY.sourceBranch.long,
+  local: GLOSSARY.sourceLocal.long,
+  production: GLOSSARY.sourceProduction.long
 };
 var inlineCodeStyle = {
   background: "var(--card-code-bg-color, rgba(255,255,255,0.06))",
@@ -15159,6 +15371,20 @@ import {
   useDataset as useDataset2,
   useProjectId as useProjectId2
 } from "sanity";
+function buildReleaseEvalPipelineRequest(args) {
+  const { mode, perspectiveId, projectId, sourceDataset, tag } = args;
+  return {
+    dataset: sourceDataset,
+    mode: "literacy",
+    perspective: perspectiveId,
+    ...projectId ? { projectId } : {},
+    publish: true,
+    publishTag: tag,
+    source: "production",
+    taskMode: "content-lake",
+    variant: mode
+  };
+}
 var API_VERSION2 = "2026-03-11";
 var EVAL_REQUEST_TYPE3 = "ailf.evalRequest";
 var POLL_INTERVAL_MS2 = 3e4;
@@ -15286,17 +15512,22 @@ function createRunEvaluationAction(options = {}) {
       const releaseTitle = release.metadata?.title ?? perspectiveId ?? "release";
       const tag = `release-${slugify3(releaseTitle)}-${dateStamp3()}`;
       const now = Date.now();
+      const pipelineRequest = buildReleaseEvalPipelineRequest({
+        mode,
+        perspectiveId,
+        projectId,
+        sourceDataset,
+        tag
+      });
       try {
         const doc = await ailfClient.create({
           _type: EVAL_REQUEST_TYPE3,
           dataset: sourceDataset,
-          mode,
-          perspective: perspectiveId,
+          pipelineRequest: JSON.stringify(pipelineRequest),
           projectId,
           requestedAt: new Date(now).toISOString(),
           requestedBy: currentUser?.id ?? "unknown",
-          status: "pending",
-          tag
+          status: "pending"
         });
         requestedAtRef.current = now;
         setState({ requestId: doc._id, startedAt: now, status: "requested" });
@@ -15423,7 +15654,6 @@ export {
   ArchiveTaskAction,
   AssertionInput,
   CanonicalDocInput,
-  GLOSSARY,
   GraduateToNativeAction,
   HelpDrawer,
   HelpProvider,