@sanity/ailf 7.2.2 → 7.3.0

package/dist/_vendor/ailf-core/types/report-validity.d.ts

@@ -0,0 +1,60 @@
+/**
+ * @sanity/ailf-core — Report validity (data-health axis)
+ *
+ * `ReportValidity` is the post-hoc data-health assessment of a published
+ * report, orthogonal to `provenance.classification` (run intent, D0037).
+ * It is a top-level sibling of the legacy `ReportDegradation` flag, which it
+ * subsumes (`degraded:true → validity.status:"degraded"`).
+ *
+ * Authored independently of the Zod schema so the schema can assert
+ * `satisfies z.ZodType<ReportValidity>` and turn drift into a build error
+ * (D0045). Populated by the confidence-tiered detector
+ * (`W-report-validity-detector`) and the eval write path
+ * (`W-stamp-validity-write-path`); gated everywhere by the shared
+ * `includeInDefaultTrends` predicate (`W-trustworthiness-predicate`).
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ * @see docs/design-docs/report-trustworthiness-model.md
+ */
+/**
+ * The validity-status vocabulary. Single `as const` tuple so the runtime Zod
+ * `z.enum(...)` and the `ReportValidityStatus` type derive from one source —
+ * the same drift-proofing the `DEGRADED_ENRICHMENT_FIELDS` tuple uses.
+ *
+ *  - `ok`         — trustworthy; included in default trends.
+ *  - `degraded`   — enrichment/grading failed (subsumes the legacy `degraded`
+ *                   flag).
+ *  - `incomplete` — expected grains genuinely missing, after the report-shape
+ *                   caveat is accounted for (see design doc).
+ *  - `suspect`    — passed structural checks but flagged for review (anomaly or
+ *                   ambiguous heuristic).
+ */
+export declare const REPORT_VALIDITY_STATUSES: readonly ["ok", "degraded", "incomplete", "suspect"];
+export type ReportValidityStatus = (typeof REPORT_VALIDITY_STATUSES)[number];
+/**
+ * How the validity verdict was reached. A `"manual"` verdict is authoritative
+ * — re-running the detector never overwrites it (the detector emits a re-run
+ * only over `"auto"` verdicts).
+ */
+export type ReportValidityMethod = "auto" | "manual";
+/**
+ * Post-hoc data-health assessment of a published report.
+ *
+ * Top-level on the `Report` (a judgment about the report's *data*), NOT under
+ * `provenance` (which records run *intent*). Additive and nullable: pre-stamp
+ * reads have no `validity` and are treated as trustworthy until backfilled.
+ */
+export interface ReportValidity {
+    /** Data-health verdict. */
+    status: ReportValidityStatus;
+    /** Which detector rules fired — the audit trail behind `status`. */
+    reasons: string[];
+    /** Whether an automated rule or a human produced this verdict. */
+    method: ReportValidityMethod;
+    /** Detector ruleset version, so re-assessments are comparable. */
+    rulesetVersion: string;
+    /** When the verdict was produced (ISO 8601 UTC). */
+    assessedAt: string;
+}
+/** Type guard for {@link ReportValidityStatus}. */
+export declare function isReportValidityStatus(value: unknown): value is ReportValidityStatus;

package/dist/_vendor/ailf-core/types/report-validity.js

@@ -0,0 +1,42 @@
+/**
+ * @sanity/ailf-core — Report validity (data-health axis)
+ *
+ * `ReportValidity` is the post-hoc data-health assessment of a published
+ * report, orthogonal to `provenance.classification` (run intent, D0037).
+ * It is a top-level sibling of the legacy `ReportDegradation` flag, which it
+ * subsumes (`degraded:true → validity.status:"degraded"`).
+ *
+ * Authored independently of the Zod schema so the schema can assert
+ * `satisfies z.ZodType<ReportValidity>` and turn drift into a build error
+ * (D0045). Populated by the confidence-tiered detector
+ * (`W-report-validity-detector`) and the eval write path
+ * (`W-stamp-validity-write-path`); gated everywhere by the shared
+ * `includeInDefaultTrends` predicate (`W-trustworthiness-predicate`).
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ * @see docs/design-docs/report-trustworthiness-model.md
+ */
+/**
+ * The validity-status vocabulary. Single `as const` tuple so the runtime Zod
+ * `z.enum(...)` and the `ReportValidityStatus` type derive from one source —
+ * the same drift-proofing the `DEGRADED_ENRICHMENT_FIELDS` tuple uses.
+ *
+ *  - `ok`         — trustworthy; included in default trends.
+ *  - `degraded`   — enrichment/grading failed (subsumes the legacy `degraded`
+ *                   flag).
+ *  - `incomplete` — expected grains genuinely missing, after the report-shape
+ *                   caveat is accounted for (see design doc).
+ *  - `suspect`    — passed structural checks but flagged for review (anomaly or
+ *                   ambiguous heuristic).
+ */
+export const REPORT_VALIDITY_STATUSES = [
+    "ok",
+    "degraded",
+    "incomplete",
+    "suspect",
+];
+/** Type guard for {@link ReportValidityStatus}. */
+export function isReportValidityStatus(value) {
+    return (typeof value === "string" &&
+        REPORT_VALIDITY_STATUSES.includes(value));
+}

package/dist/_vendor/ailf-shared/generated/help-content.js

@@ -78,11 +78,12 @@ export const HELP_TOPICS = [
     },
     {
         "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 — 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 — 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 (±2–3 points) between runs are normal — 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).",
+        "title": "Reading the Analytics View",
+        "body": "## What this view answers\n\nThe Analytics view is built around one question: **did your doc changes move the\nscore, and why?** Rather than open on a chart and leave you to find the story,\nit leads with the answer — a plain-language verdict and the areas that moved\nmost — then lets you drill down into the evidence.\n\n## The control bar\n\nThe top row picks what you're looking at:\n\n- **Metric** — which number to track (composite score, doc lift, retrieval gap,\n  and so on).\n- **Break down by** — how to split it (feature area, team, model, source).\n- **Bucket** — how to group runs over time (per run, per day).\n- **Range** — how far back to look (for example, the last 30 days).\n\nThe second row holds the active **filter chips** — use _Add filter_ to scope to\na team, source, or mode — and a scope hint (reports in scope vs. total). Every\nknob and filter is saved in the URL, so a shared link reproduces exactly what\nyou see. Use **Copy link** to grab it.\n\n## Overall — the read\n\nThe **verdict strip** is the headline. In plain language it says whether docs\nare pulling ahead or slipping, and shows the headline metric with its change (Δ)\nsince the start of the range, a model → agent → docs decomposition bar, and a\ncoverage cell (how many reports and high-confidence groups are in scope).\n\n## Movers\n\nThe **movers board** leads with the top **Improved** and **Regressed** areas as\ncards — not the average. Each card shows the area, its value and Δ, a\ndecomposition bar, the release that most likely caused the move, and a\nconfidence read. A low-confidence **watch** callout flags big swings backed by\ntoo few runs: watch them, don't celebrate them yet.\n\nClick a mover card to reveal and decompose that series in the evidence chart.\n\n## The evidence\n\nThe **focus chart** has two modes:\n\n- **Compare** plots the selected series over time. It defaults to a focused set\n  (the movers plus the highest-volume areas) with a _show all_ expansion, and\n  draws release markers inline.\n- **Decompose** shows the ceiling / floor / actual band for a single series,\n  with causal story cards anchored to each release marker (for example, _\"Docs\n  +3 ~5 −1 → doc-lift +8 measured around this release\"_).\n\nDecompose is offered for the composite metric broken down by feature area — the\ncase where the model → agent → docs story is meaningful.\n\n## The breakdown table\n\nOne row per area (or per whatever you broke down by), each with an inline\ndecomposition bar, a sparkline, confidence, Δ, \"docs add,\" and a report count.\nSort any column, and click a row to cross-highlight it in the chart. Export the\ntable to CSV.\n\n## Meaningful change vs. noise\n\nSmall movements between runs are normal — they come from model non-determinism\nand grader variance. This view leans on **confidence** (how many runs back a\nnumber) and the **movers ranking** rather than a single ±point threshold: trust\na sustained move in a high-confidence area over a large swing in a\nlow-confidence one. The low-confidence watch exists precisely to stop you\nover-reading thin data.\n\n## Measured, not invented\n\nThe causal story is computed from real data, never fabricated. Release markers\ncome from the doc-change counts already recorded in each report, and the\n\"measured around this release\" doc-lift effect is derived from the real ceiling\n− floor series around the marker. Per-area prose (\"the editor API changed\") is\nintentionally not shown — the data carries change counts, not hand-written\nexplanations.",
         "source": "docs/help/reading-score-trends.md",
         "related": [
             "scoring-model",
+            "doc-lift",
             "comparing-runs"
         ]
     },
@@ -142,7 +143,7 @@ export const HELP_TOPICS = [
     {
         "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 ÷ ceiling). 100% means agents find and use all relevant docs perfectly.\n\n**Floor**\n: Output-quality composite without documentation — 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 ÷ ceiling, shown as a percentage).\n\n**Inverted Retrieval Gap**\n: ⚠️ 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 × 50% + Code Correctness × 25% + Doc Coverage × 25%.\n\n**Task Completion**\n: Can the LLM implement the requested feature? Graded 0–100.\n\n**Code Correctness**\n: Is the generated code idiomatic, correct, and following best practices? Graded 0–100.\n\n**Doc Coverage**\n: Did the docs provide the information needed to implement the feature? Graded 0–100. This dimension only contributes to the ceiling composite (with docs) — 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 Δ**\n: Change in overall score between the two runs. Positive means the experiment scored higher.\n\n**Actual Δ**\n: Change in actual (agent-retrieved) score between runs. Positive means agents did better.\n\n**Ret. Gap Δ**\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 Δ**\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 — AI agents produce correct, complete implementations.\n\n**Needs Attention (70–79)**\n: Feature areas scoring 70–79. These are okay but could be improved — 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 — 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 — 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 — 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% — 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 — 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 — 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 Δ**\n: Change in task completion between runs. Positive means implementations are more complete.\n\n**Code Correctness Δ**\n: Change in code correctness between runs. Positive means better code quality.\n\n**Doc Coverage Δ**\n: Change in doc coverage between runs. Positive means the docs are providing more useful information.\n\n**Area Δ**\n: Score change for this area compared to the previous evaluation run.\n\n**Production**\n: Production source — docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.\n\n**Branch**\n: Branch source — 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 — 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 — tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).\n\n**Full**\n: Full mode — 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 — 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 — records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.\n\n**Debug**\n: Debug mode — a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.\n\n**Manual**\n: Manually triggered — someone ran the evaluation pipeline by hand, either locally or via the Studio UI.\n\n**CI**\n: CI-triggered — the evaluation ran automatically as part of a pull request or merge pipeline.\n\n**Scheduled**\n: Scheduled — the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.\n\n**Webhook**\n: Webhook-triggered — a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.\n\n**Cross-Repo**\n: Cross-repo — triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.",
+        "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 ÷ ceiling). 100% means agents find and use all relevant docs perfectly.\n\n**Floor**\n: Output-quality composite without documentation — 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 ÷ ceiling, shown as a percentage).\n\n**Inverted Retrieval Gap**\n: ⚠️ 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 × 50% + Code Correctness × 25% + Doc Coverage × 25%.\n\n**Task Completion**\n: Can the LLM implement the requested feature? Graded 0–100.\n\n**Code Correctness**\n: Is the generated code idiomatic, correct, and following best practices? Graded 0–100.\n\n**Doc Coverage**\n: Did the docs provide the information needed to implement the feature? Graded 0–100. This dimension only contributes to the ceiling composite (with docs) — 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 Δ**\n: Change in overall score between the two runs. Positive means the experiment scored higher.\n\n**Actual Δ**\n: Change in actual (agent-retrieved) score between runs. Positive means agents did better.\n\n**Ret. Gap Δ**\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 Δ**\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 — AI agents produce correct, complete implementations.\n\n**Needs Attention (70–79)**\n: Feature areas scoring 70–79. These are okay but could be improved — 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 — 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 — 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 — 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% — 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 — 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 — 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 Δ**\n: Change in task completion between runs. Positive means implementations are more complete.\n\n**Code Correctness Δ**\n: Change in code correctness between runs. Positive means better code quality.\n\n**Doc Coverage Δ**\n: Change in doc coverage between runs. Positive means the docs are providing more useful information.\n\n**Area Δ**\n: Score change for this area compared to the previous evaluation run.\n\n**Production**\n: Production source — docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.\n\n**Branch**\n: Branch source — 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 — 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 — tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).\n\n**Full**\n: Full mode — 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 — 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 — records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.\n\n**Debug**\n: Debug mode — a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.\n\n**Manual**\n: Manually triggered — someone ran the evaluation pipeline by hand, either locally or via the Studio UI.\n\n**CI**\n: CI-triggered — the evaluation ran automatically as part of a pull request or merge pipeline.\n\n**Scheduled**\n: Scheduled — the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.\n\n**Webhook**\n: Webhook-triggered — a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.\n\n**Cross-Repo**\n: Cross-repo — triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.\n\n**Gold**\n: Gold variant — the relevant docs were injected into the prompt as context. This is the ceiling condition: the best the documentation can do.\n\n**Baseline**\n: Baseline variant — no documentation in the prompt. This is the floor condition: what the model already knows from its training data, used as the control for doc lift.\n\n**Naive**\n: Naive — the in-house agentic harness with naive prompting. The model runs in an agent loop with no doc-targeting strategy.\n\n**Optimized**\n: Optimized — the in-house agentic harness with optimized prompting. The model runs in an agent loop tuned for documentation retrieval.\n\n**Normal**\n: Normal — a direct vendor-API call. The model produces a single-shot completion with no agent loop.\n\n**Fail**\n: Fail — the model produced no usable output (empty response, API error, or token exhaustion). Distinct from a low score on output that was produced.\n\n**Low dim**\n: Low dim — the run produced output but at least one grading dimension scored below 60.\n\n**OK**\n: OK — the run produced output and every grading dimension scored 60 or above.",
         "source": "packages/shared/src/glossary.ts",
         "tags": [
             "reference",

package/dist/_vendor/ailf-shared/glossary.d.ts

@@ -314,5 +314,37 @@ export declare const GLOSSARY: {
         readonly label: "Cross-Repo";
         readonly long: "Cross-repo — triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.";
     };
+    readonly variantGold: {
+        readonly label: "Gold";
+        readonly long: "Gold variant — the relevant docs were injected into the prompt as context. This is the ceiling condition: the best the documentation can do.";
+    };
+    readonly variantBaseline: {
+        readonly label: "Baseline";
+        readonly long: "Baseline variant — no documentation in the prompt. This is the floor condition: what the model already knows from its training data, used as the control for doc lift.";
+    };
+    readonly engineNaive: {
+        readonly label: "Naive";
+        readonly long: "Naive — the in-house agentic harness with naive prompting. The model runs in an agent loop with no doc-targeting strategy.";
+    };
+    readonly engineOptimized: {
+        readonly label: "Optimized";
+        readonly long: "Optimized — the in-house agentic harness with optimized prompting. The model runs in an agent loop tuned for documentation retrieval.";
+    };
+    readonly engineNormal: {
+        readonly label: "Normal";
+        readonly long: "Normal — a direct vendor-API call. The model produces a single-shot completion with no agent loop.";
+    };
+    readonly statusFail: {
+        readonly label: "Fail";
+        readonly long: "Fail — the model produced no usable output (empty response, API error, or token exhaustion). Distinct from a low score on output that was produced.";
+    };
+    readonly statusLowDim: {
+        readonly label: "Low dim";
+        readonly long: "Low dim — the run produced output but at least one grading dimension scored below 60.";
+    };
+    readonly statusOk: {
+        readonly label: "OK";
+        readonly long: "OK — the run produced output and every grading dimension scored 60 or above.";
+    };
 };
 export type GlossarySlug = keyof typeof GLOSSARY;

package/dist/_vendor/ailf-shared/glossary.js

@@ -327,4 +327,39 @@ export const GLOSSARY = {
         label: "Cross-Repo",
         long: "Cross-repo — triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.",
     },
+    // -- Variant values (per-test docs condition) ------------------------------
+    variantGold: {
+        label: "Gold",
+        long: "Gold variant — the relevant docs were injected into the prompt as context. This is the ceiling condition: the best the documentation can do.",
+    },
+    variantBaseline: {
+        label: "Baseline",
+        long: "Baseline variant — no documentation in the prompt. This is the floor condition: what the model already knows from its training data, used as the control for doc lift.",
+    },
+    // -- Execution mode values (how the model was driven) ----------------------
+    engineNaive: {
+        label: "Naive",
+        long: "Naive — the in-house agentic harness with naive prompting. The model runs in an agent loop with no doc-targeting strategy.",
+    },
+    engineOptimized: {
+        label: "Optimized",
+        long: "Optimized — the in-house agentic harness with optimized prompting. The model runs in an agent loop tuned for documentation retrieval.",
+    },
+    engineNormal: {
+        label: "Normal",
+        long: "Normal — a direct vendor-API call. The model produces a single-shot completion with no agent loop.",
+    },
+    // -- Status values (per-test outcome) --------------------------------------
+    statusFail: {
+        label: "Fail",
+        long: "Fail — the model produced no usable output (empty response, API error, or token exhaustion). Distinct from a low score on output that was produced.",
+    },
+    statusLowDim: {
+        label: "Low dim",
+        long: "Low dim — the run produced output but at least one grading dimension scored below 60.",
+    },
+    statusOk: {
+        label: "OK",
+        long: "OK — the run produced output and every grading dimension scored 60 or above.",
+    },
 };

package/dist/_vendor/ailf-shared/index.d.ts

@@ -31,6 +31,7 @@ export { GRADE_BOUNDARIES, scoreGrade, type ScoreGrade, } from "./score-grades.j
 export { NOISE_THRESHOLD } from "./noise-threshold.js";
 export { CANONICAL_EVAL_MODES, isLiteracyVariant, LEGACY_EVAL_MODE_ALIASES, LITERACY_VARIANTS, RAW_EVAL_MODES, type EvalMode, type LiteracyVariant, type RawEvalMode, } from "./eval-modes.js";
 export { isKnownOwnerTeam, KNOWN_OWNER_TEAMS, normalizeOwnerTeam, resolveTeamRef, type SlugLike, } from "./owner-teams.js";
-export { isRunClassification, RUN_CLASSIFICATIONS, RUN_EXECUTOR_SURFACES, type RunClassification, type RunExecutor, type RunExecutorSurface, type RunExecutorSystem, type RunExecutorUser, type RunHost, type RunLineage, type RunOwner, type RunTool, } from "./run-classification.js";
+export { canonicalizeExecutorIdentity, isKnownExecutorIdentity, isRunClassification, looksLikeGeneratedExecutorId, normalizeRunClassification, RUN_CLASSIFICATIONS, RUN_EXECUTOR_SURFACES, type RunClassification, type RunExecutor, type RunExecutorSurface, type RunExecutorSystem, type RunExecutorUser, type RunHost, type RunLineage, type RunOwner, type RunTool, } from "./run-classification.js";
 export { type RunTrigger } from "./run-trigger.js";
 export { type RunContext } from "./run-context.js";
+export { includeInDefaultTrends, INCLUDE_IN_DEFAULT_TRENDS_GROQ, INCLUDE_IN_DEFAULT_TRENDS_SQL, type TrustGateReport, } from "./trustworthiness.js";

package/dist/_vendor/ailf-shared/index.js

@@ -30,4 +30,5 @@ export { GRADE_BOUNDARIES, scoreGrade, } from "./score-grades.js";
 export { NOISE_THRESHOLD } from "./noise-threshold.js";
 export { CANONICAL_EVAL_MODES, isLiteracyVariant, LEGACY_EVAL_MODE_ALIASES, LITERACY_VARIANTS, RAW_EVAL_MODES, } from "./eval-modes.js";
 export { isKnownOwnerTeam, KNOWN_OWNER_TEAMS, normalizeOwnerTeam, resolveTeamRef, } from "./owner-teams.js";
-export { isRunClassification, RUN_CLASSIFICATIONS, RUN_EXECUTOR_SURFACES, } from "./run-classification.js";
+export { canonicalizeExecutorIdentity, isKnownExecutorIdentity, isRunClassification, looksLikeGeneratedExecutorId, normalizeRunClassification, RUN_CLASSIFICATIONS, RUN_EXECUTOR_SURFACES, } from "./run-classification.js";
+export { includeInDefaultTrends, INCLUDE_IN_DEFAULT_TRENDS_GROQ, INCLUDE_IN_DEFAULT_TRENDS_SQL, } from "./trustworthiness.js";

package/dist/_vendor/ailf-shared/run-classification.d.ts

@@ -19,6 +19,59 @@
 export type RunClassification = "official" | "adhoc" | "experimental" | "test" | "external";
 export declare const RUN_CLASSIFICATIONS: readonly RunClassification[];
 export declare function isRunClassification(value: unknown): value is RunClassification;
+/**
+ * Normalize a free-form classification value to a canonical
+ * {@link RunClassification}.
+ *
+ * - Trims and lowercases.
+ * - Maps the legacy `ad-hoc` spelling onto canonical `adhoc`.
+ * - Defaults empty / unknown input to `adhoc` — D0037's documented
+ *   default bucket, biased away from the canonical `official` series.
+ *
+ * Pure and deterministic — reused by the detector (`W-report-validity-detector`)
+ * and the backfill (`W-backfill-report-validity`).
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ */
+export declare function normalizeRunClassification(value: string | undefined | null): RunClassification;
+/**
+ * Collapse a free-form executor name onto its canonical identity slug.
+ *
+ * - Trims and lowercases.
+ * - Maps known spellings (above) to one identity.
+ * - Passes unknown names through (trimmed + lowercased).
+ * - Returns `undefined` for empty / nullish input.
+ *
+ * Pure and deterministic — used by the validity detector
+ * (`W-report-validity-detector`) to recognize a known human before the
+ * generated-id heuristic runs, and by the backfill to de-drift
+ * `provenance.executor.name`.
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ */
+export declare function canonicalizeExecutorIdentity(name: string | undefined | null): string | undefined;
+/** Whether an executor name collapses to a recognized human identity. */
+export declare function isKnownExecutorIdentity(name: string | undefined | null): boolean;
+/**
+ * Heuristic: does an executor name look like a *generated* handle/id rather
+ * than a human name? (D0059 §Context flagged ids like `gDVzuuHam`,
+ * `gL78msEDh` in the report store.)
+ *
+ * Deterministic and deliberately conservative — it judges *shape* only:
+ * a single token (no whitespace) of length 7–12, alphanumeric, mixing
+ * upper- and lower-case, and either containing a digit or showing ≥4
+ * upper/lower transitions. The transition floor is calibrated against the
+ * observed sample so two-word PascalCase names ("JohnSmith" — 3
+ * transitions) are NOT flagged; the generated ids (≥4 transitions or a
+ * digit) are. Known identities are excluded by the caller
+ * ({@link isKnownExecutorIdentity}) before this runs, so collapsed
+ * spellings like `GabeStah` never reach it as a positive.
+ *
+ * False positives are tolerable: the detector only uses this to propose an
+ * `experimental` classification, which is reversible (label-and-exclude,
+ * never delete) and surfaced for human review during the backfill.
+ */
+export declare function looksLikeGeneratedExecutorId(name: string | undefined | null): boolean;
 /**
  * Attribution — which team and (optionally) individual the run *belongs to*.
  *

package/dist/_vendor/ailf-shared/run-classification.js

@@ -21,6 +21,117 @@ export function isRunClassification(value) {
     return (typeof value === "string" &&
         RUN_CLASSIFICATIONS.includes(value));
 }
+/**
+ * Lowercase legacy spelling → canonical classification. The `RunClassification`
+ * type has long been canonical `adhoc`, but historical report data carries the
+ * hyphenated `ad-hoc` spelling (D0059 §Context). Only observed drift belongs
+ * here.
+ */
+const RUN_CLASSIFICATION_ALIASES = {
+    "ad-hoc": "adhoc",
+};
+/**
+ * Normalize a free-form classification value to a canonical
+ * {@link RunClassification}.
+ *
+ * - Trims and lowercases.
+ * - Maps the legacy `ad-hoc` spelling onto canonical `adhoc`.
+ * - Defaults empty / unknown input to `adhoc` — D0037's documented
+ *   default bucket, biased away from the canonical `official` series.
+ *
+ * Pure and deterministic — reused by the detector (`W-report-validity-detector`)
+ * and the backfill (`W-backfill-report-validity`).
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ */
+export function normalizeRunClassification(value) {
+    if (!value)
+        return "adhoc";
+    const trimmed = value.trim().toLowerCase();
+    if (!trimmed)
+        return "adhoc";
+    const canonical = RUN_CLASSIFICATION_ALIASES[trimmed] ?? trimmed;
+    return isRunClassification(canonical) ? canonical : "adhoc";
+}
+/**
+ * Lowercased executor-name spelling → canonical identity slug. One human
+ * appears under several spellings in the historical report store
+ * (D0059 §Context: `Gabe Wyatt` / `GabeStah` / `gabewyatt`); collapsing
+ * them lets attribution and `classification` queries treat them as one
+ * person. Only observed drift belongs here — unknown names pass through.
+ */
+const EXECUTOR_IDENTITY_ALIASES = {
+    "gabe wyatt": "gabe-wyatt",
+    gabestah: "gabe-wyatt",
+    gabewyatt: "gabe-wyatt",
+};
+/**
+ * Collapse a free-form executor name onto its canonical identity slug.
+ *
+ * - Trims and lowercases.
+ * - Maps known spellings (above) to one identity.
+ * - Passes unknown names through (trimmed + lowercased).
+ * - Returns `undefined` for empty / nullish input.
+ *
+ * Pure and deterministic — used by the validity detector
+ * (`W-report-validity-detector`) to recognize a known human before the
+ * generated-id heuristic runs, and by the backfill to de-drift
+ * `provenance.executor.name`.
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ */
+export function canonicalizeExecutorIdentity(name) {
+    if (!name)
+        return undefined;
+    const trimmed = name.trim().toLowerCase();
+    if (!trimmed)
+        return undefined;
+    return EXECUTOR_IDENTITY_ALIASES[trimmed] ?? trimmed;
+}
+/** Whether an executor name collapses to a recognized human identity. */
+export function isKnownExecutorIdentity(name) {
+    if (!name)
+        return false;
+    return name.trim().toLowerCase() in EXECUTOR_IDENTITY_ALIASES;
+}
+/**
+ * Heuristic: does an executor name look like a *generated* handle/id rather
+ * than a human name? (D0059 §Context flagged ids like `gDVzuuHam`,
+ * `gL78msEDh` in the report store.)
+ *
+ * Deterministic and deliberately conservative — it judges *shape* only:
+ * a single token (no whitespace) of length 7–12, alphanumeric, mixing
+ * upper- and lower-case, and either containing a digit or showing ≥4
+ * upper/lower transitions. The transition floor is calibrated against the
+ * observed sample so two-word PascalCase names ("JohnSmith" — 3
+ * transitions) are NOT flagged; the generated ids (≥4 transitions or a
+ * digit) are. Known identities are excluded by the caller
+ * ({@link isKnownExecutorIdentity}) before this runs, so collapsed
+ * spellings like `GabeStah` never reach it as a positive.
+ *
+ * False positives are tolerable: the detector only uses this to propose an
+ * `experimental` classification, which is reversible (label-and-exclude,
+ * never delete) and surfaced for human review during the backfill.
+ */
+export function looksLikeGeneratedExecutorId(name) {
+    if (!name)
+        return false;
+    const token = name.trim();
+    if (token.length < 7 || token.length > 12)
+        return false;
+    if (!/^[A-Za-z0-9]+$/.test(token))
+        return false;
+    if (!/[A-Z]/.test(token) || !/[a-z]/.test(token))
+        return false;
+    if (/[0-9]/.test(token))
+        return true;
+    let transitions = 0;
+    for (let i = 1; i < token.length; i++) {
+        if (/[A-Z]/.test(token[i - 1]) !== /[A-Z]/.test(token[i]))
+            transitions++;
+    }
+    return transitions >= 4;
+}
 export const RUN_EXECUTOR_SURFACES = [
     "cli",
     "studio",

package/dist/_vendor/ailf-shared/trustworthiness.d.ts

@@ -0,0 +1,97 @@
+/**
+ * trustworthiness.ts — The single trust gate for reports (D0059).
+ *
+ * `includeInDefaultTrends` is the one definition of "show this report by
+ * default." Every surface (dashboard analytics, Studio presets, the BigQuery
+ * `reports.sql` view) references this predicate so the gate cannot drift
+ * between consumers.
+ *
+ * Two orthogonal axes decide inclusion:
+ *
+ *  - **Validity (data health, D0059)** — the *primary* gate. A report is
+ *    included only when its `validity.status` is `ok` OR validity is absent
+ *    (pre-stamp reads are trusted until backfilled — the rollout is additive
+ *    and nullable). Any non-`ok` status (`degraded` / `incomplete` /
+ *    `suspect`) excludes the report regardless of intent.
+ *  - **Intent (run classification, D0037)** — a *secondary* exclusion. The
+ *    explicit `test` and `experimental` classifications are dropped;
+ *    `adhoc` / `official` / `external` (and a missing classification) are kept.
+ *    `adhoc` is intentionally included — it holds real production one-offs;
+ *    the validity gate, not the intent gate, removes the bad ones inside it.
+ *
+ * We model a slim subset of the core `Report` shape (the two read axes) rather
+ * than importing `Report` / `ReportValidity` from `@sanity/ailf-core`: this
+ * package is the dependency-graph leaf and imports nothing from core. A full
+ * core `Report` is structurally assignable to {@link TrustGateReport}.
+ *
+ * The predicate is total — it never throws — and is kept trivially
+ * translatable to the two query-language forms it is materialized as on the
+ * other surfaces (`W-studio-bigquery-validity`): the GROQ filter behind the
+ * Studio "Trustworthy" preset ({@link INCLUDE_IN_DEFAULT_TRENDS_GROQ}) and the
+ * SQL boolean in the BigQuery `reports.sql` view
+ * ({@link INCLUDE_IN_DEFAULT_TRENDS_SQL}). Those constants live here, beside the
+ * function, so the one gate cannot drift between consumers; a cross-check test
+ * asserts all three forms agree across the full truth table.
+ *
+ * Note the SQL form is NULL-safe on *both* axes: a bare
+ * `classification NOT IN ('test','experimental')` would evaluate to `NULL`
+ * (not `TRUE`) for an unclassified row under SQL three-valued logic, silently
+ * excluding pre-taxonomy reports the TS predicate keeps — hence the explicit
+ * `classification IS NULL OR …`.
+ *
+ * @see docs/decisions/D0059-report-validity-axis-and-trustworthiness-gate.md
+ * @see docs/design-docs/report-trustworthiness-model.md — §Decision/3
+ */
+import type { RunClassification } from "./run-classification.js";
+/**
+ * Slim subset of a core `Report` — only the two axes the trust gate reads.
+ *
+ * `validity.status` is typed as a bare `string` (not core's
+ * `ReportValidityStatus`) so this leaf package imports nothing from
+ * `@sanity/ailf-core`; the predicate only distinguishes `"ok"` from
+ * everything else. `validity` absent/`null` ⇒ pre-stamp read ⇒ trusted.
+ */
+export interface TrustGateReport {
+    /** Data-health axis (D0059), top-level on the report. */
+    validity?: {
+        status: string;
+    } | null;
+    /** Run-intent axis (D0037), under provenance. */
+    provenance?: {
+        classification?: RunClassification | null;
+    } | null;
+}
+/**
+ * Whether a report should appear in default trend views.
+ *
+ * Validity is the primary gate; intent is a secondary exclusion. See the
+ * module header for the full rationale and the equivalent SQL.
+ *
+ * @returns `true` when the report is trustworthy enough to show by default.
+ */
+export declare function includeInDefaultTrends(report: TrustGateReport): boolean;
+/**
+ * GROQ form of {@link includeInDefaultTrends}, as a boolean expression over an
+ * `ailf.report` document. Drop it into a Studio structure filter with the
+ * document-type guard, e.g.
+ * `` `_type == "ailf.report" && ${INCLUDE_IN_DEFAULT_TRENDS_GROQ}` ``.
+ *
+ * GROQ's `in` returns `false` (not `null`) for an absent left operand, so an
+ * unclassified report passes the intent clause without an explicit
+ * `defined(...)` guard — matching the TS predicate's "missing ⇒ kept" rule.
+ * `defined(validity.status)` makes the absent-validity case trusted.
+ */
+export declare const INCLUDE_IN_DEFAULT_TRENDS_GROQ = "(!defined(validity.status) || validity.status == \"ok\") && !(provenance.classification in [\"test\", \"experimental\"])";
+/**
+ * SQL form of {@link includeInDefaultTrends}, as a boolean expression over the
+ * flattened `ailf.reports` BigQuery row (columns `validity_status`,
+ * `classification`). Materialized verbatim as the `include_in_default_trends`
+ * column in `packages/eval/config/bigquery/views/reports.sql`; an eval test
+ * asserts the view embeds this exact string.
+ *
+ * Both axes are NULL-safe so the column matches the TS predicate row-for-row:
+ * `classification NOT IN (...)` alone is `NULL` for an unclassified row under
+ * SQL three-valued logic, which a `WHERE`/boolean context treats as `FALSE` —
+ * silently dropping pre-taxonomy reports the TS predicate keeps.
+ */
+export declare const INCLUDE_IN_DEFAULT_TRENDS_SQL = "(validity_status IS NULL OR validity_status = 'ok') AND (classification IS NULL OR classification NOT IN ('test', 'experimental'))";