A meta description is relevant when it accurately reflects the page, matches the likely search intent, and gives a specific reason to click. TypeSafe AI’s Jev can help check those qualities as structured decisions. Jev is TypeSafe AI’s first System One model: it evaluates data placed in a request’s `state` and answers atomic `Score` or `Choice` questions. It returns typed values, probability distributions, and confidence rather than prose.
That boundary matters for SEO work. Jev does not open a URL, crawl a page, explain what is wrong, or write a replacement meta description. A crawler or page-fetching service must collect the evidence first. Jev can then score the supplied page evidence and classify an overall verdict. Your code applies review rules, while an editor or a separate generative model handles any rewrite. This guide shows a bounded workflow for doing that without treating a model score as a guaranteed SEO outcome.
What Jev can and cannot do in this workflow
TypeSafe AI’s introduction to Jev describes a model built for typed decisions rather than free-text generation. For a meta description review, that makes Jev useful for four narrow outputs:
- a `Score` for factual alignment with the page;
- a `Score` for alignment with the target search intent;
- a `Score` for specificity;
- a `Choice` verdict: `strong`, `partial`, `weak`, or `insufficient_evidence`.
Jev should not fetch the URL, infer missing page text, propose a new description, or provide a written rationale. It can only evaluate evidence supplied in `state`. If the state contains a title but no meaningful page summary, `insufficient_evidence` is a valid result.
This workflow complements Screpy’s meta description guide, which explains how to write and improve descriptions. The purpose here is narrower: decide whether an existing description is relevant enough to pass, requires review, or lacks sufficient evidence for a safe decision.
Prepare the SEO evidence before calling Jev
A production check starts outside the model. Fetch or crawl the canonical page and normalize the fields that matter to the decision. Do not send an unexplained URL and expect Jev to browse it.
A useful state object can include:
- the canonical URL as an identifier;
- the current meta description;
- the page title and primary heading;
- a concise, evidence-based summary extracted from the main content;
- the target query or query cluster;
- the intended search intent;
- relevant entities, products, services, or factual claims found on the page.
Run deterministic checks before model evaluation. Confirm that the page is indexable, the canonical is correct, and the description exists. Measure length and detect exact duplicates with code. Exclude navigation, cookie notices, and unrelated template text from the page summary.
These checks belong to a standard on-page SEO and content optimization process. Jev adds a typed relevance decision; it does not replace technical validation.
Use separate Score questions for separate qualities
A single question such as “How good is this meta description?” hides too many judgments. The result is hard to calibrate and difficult to act on. Split the review into atomic questions.
The Score primitive uses an ordered criteria array. Each level should describe observable evidence. Three separate scores work well:
- Factual alignment: Does every meaningful claim in the description have support in the supplied page evidence?
- Intent match: Does the description address the supplied query and its stated search intent?
- Specificity: Does the description communicate page-specific value instead of reusable marketing language?
Keep the scales descriptive. A score of four should mean something reviewers can recognize, such as “all material claims are supported.” Avoid criteria based on vague adjectives like “excellent” or “SEO-friendly.”
A fractional score can reflect probability spread across neighboring levels. That is useful, but it is still model evidence, not a measurement of rankings or click-through rate.
Add one Choice question for the routing verdict
After the atomic scores, use Choice to classify the overall case. The available choices should map directly to workflow actions:
- `strong`: evidence supports the description and it matches the intent;
- `partial`: the description is broadly relevant but one material dimension is weak;
- `weak`: it is misleading, generic, or poorly aligned with the intent;
- `insufficient_evidence`: the supplied state cannot support a safe verdict.
This verdict does not replace the three scores. It gives the workflow a stable routing label. Because TypeSafe questions are evaluated independently, do not instruct the verdict question to calculate an average from other question responses. Give it the same page evidence and define the complete decision criteria inside that question.
Example TypeSafe request
The request below uses the documented `state`, `model`, and `questions` structure. The page evidence has already been fetched and prepared by another system.
{
"model": "jev-latest",
"state": {
"url": "https://example.com/technical-seo-audit",
"meta_description": "Find technical SEO issues affecting crawlability and indexation with a structured website audit.",
"page_title": "Technical SEO Audit Guide",
"primary_heading": "How to Run a Technical SEO Audit",
"page_summary": "A step-by-step guide to crawling a site, checking indexability, reviewing canonicals, and prioritizing technical issues.",
"target_query": "how to run a technical SEO audit",
"search_intent": "Informational: the searcher wants a practical audit process."
},
"questions": {
"factual_alignment": {
"type": "score",
"instructions": "Score whether the meta description's material claims are supported by the supplied page evidence.",
"criteria": [
"Claims conflict with the evidence",
"Several material claims lack support",
"Most claims are supported, with a meaningful gap",
"Claims are supported, with only a minor ambiguity",
"All material claims are directly supported"
]
},
"intent_match": {
"type": "score",
"instructions": "Score how closely the meta description matches the supplied target query and search intent.",
"criteria": [
"Does not address the stated intent",
"Touches the topic but serves a different intent",
"Partly serves the intent",
"Closely serves the intent with a minor omission",
"Directly serves the stated intent"
]
},
"specificity": {
"type": "score",
"instructions": "Score how specifically the meta description represents this page rather than generic SEO marketing copy.",
"criteria": [
"Entirely generic or unrelated",
"Mostly generic",
"Contains one page-specific element",
"Mostly page-specific",
"Clearly specific to the supplied page"
]
},
"overall_verdict": {
"type": "choice",
"instructions": "Classify the meta description using only the supplied page and intent evidence.",
"criteria": {
"strong": "The evidence supports the description and it directly matches the stated intent.",
"partial": "The description is broadly relevant but one material dimension is weak.",
"weak": "The description is misleading, generic, or poorly aligned with the intent.",
"insufficient_evidence": "The supplied state cannot support a safe verdict."
}
}
}
}
The criteria are deliberately short and bounded. In a real implementation, review them with SEO editors and test them against labeled examples from your site.
Illustrative response
The following values are an illustrative example, not measured performance and not a claim about TypeSafe accuracy on this page.
{
"model": "jev-1.13.0",
"answers": {
"factual_alignment": {
"type": "score",
"score": 3.91,
"confidence": 0.86,
"legend": {
"0": "Claims conflict with the evidence",
"1": "Several material claims lack support",
"2": "Most claims are supported, with a meaningful gap",
"3": "Claims are supported, with only a minor ambiguity",
"4": "All material claims are directly supported"
},
"probabilities": {
"0": 0.01,
"1": 0.02,
"2": 0.12,
"3": 0.55,
"4": 0.3
}
},
"intent_match": {
"type": "score",
"score": 4.18,
"confidence": 0.89,
"legend": {
"0": "Does not address the stated intent",
"1": "Touches the topic but serves a different intent",
"2": "Partly serves the intent",
"3": "Closely serves the intent with a minor omission",
"4": "Directly serves the stated intent"
},
"probabilities": {
"0": 0.01,
"1": 0.01,
"2": 0.08,
"3": 0.59,
"4": 0.31
}
},
"specificity": {
"type": "score",
"score": 3.28,
"confidence": 0.72,
"legend": {
"0": "Entirely generic or unrelated",
"1": "Mostly generic",
"2": "Contains one page-specific element",
"3": "Mostly page-specific",
"4": "Clearly specific to the supplied page"
},
"probabilities": {
"0": 0.02,
"1": 0.08,
"2": 0.18,
"3": 0.52,
"4": 0.2
}
},
"overall_verdict": {
"type": "choice",
"choice": "strong",
"confidence": 0.74,
"probabilities": {
"strong": 0.62,
"partial": 0.28,
"weak": 0.06,
"insufficient_evidence": 0.04
}
}
}
}
The response gives your code stable fields to store, compare, and route. It does not contain a diagnosis paragraph or a revised meta description.
Interpret probabilities and confidence carefully
TypeSafe’s confidence guidance treats confidence as a signal derived from the response distribution. It is not a guarantee that the answer is correct. A confident answer can still disagree with an experienced reviewer, especially when the state is incomplete or the criteria do not match the site’s standards.
Review the full probability distribution. A `strong` choice with substantial probability on `partial` is less decisive than the same choice with nearly all probability concentrated on `strong`. Similar logic applies when a Score distribution spans several levels.
Example routing rules might be:
- auto-pass only when verdict is `strong`, verdict confidence is at least 0.85, and all three scores meet your calibrated floor;
- send `partial` and any confidence below 0.85 to an editor;
- send `weak` to the rewrite queue;
- re-fetch evidence for `insufficient_evidence`;
- never auto-publish a rewrite based only on these outputs.
These numbers are examples. Calibrate thresholds with reviewed pages, including good descriptions, generic descriptions, unsupported claims, mixed-intent pages, and thin content. Track false passes and unnecessary reviews before using automation at scale.
Keep deterministic and generative work outside Jev
Your surrounding system should own the operations that are not typed judgments.
Crawler or fetcher: downloads the canonical page, extracts the description and main content, and records HTTP and indexability signals.
Deterministic code: checks presence, pixel or character constraints, duplicates, canonical consistency, structured data, and business rules. It can also combine the typed outputs into a queue priority.
Jev: returns the three scores and one bounded verdict from the supplied evidence.
Editor: checks nuance, brand voice, factual sensitivity, and whether the snippet sets the right expectation.
Generative model or writer: drafts alternatives only after the workflow identifies a weak description. Generated text must receive its own factual and editorial review.
Google may create a search result snippet from page content instead of using the meta description. Its snippet documentation is the right reference for that behavior. This makes page quality and descriptive accuracy more important than treating one tag as guaranteed display text.
A practical production workflow
- Crawl indexable canonical pages and collect current metadata.
- Run deterministic checks for missing, duplicated, truncated, or template-driven descriptions.
- Build a compact state object from verified page evidence and the mapped search intent.
- Ask the three Score questions and the Choice verdict.
- Store the response with the input version, model version, criteria version, and timestamp.
- Apply calibrated routing thresholds in code.
- Send uncertain, partial, and weak cases to a human review queue.
- Let an editor or separate generation step write changes.
- Recheck the new description against the page before publication.
- Sample passed cases regularly and adjust criteria when reviewers find drift.
For teams already using typed SEO classification, the same operating principles appear in Screpy’s guide to classifying keyword search intent with TypeSafe AI’s Jev. Reuse governance patterns such as versioned criteria and reviewed calibration sets, while keeping the actual questions specific to meta description relevance.
QA checklist
Before trusting the workflow, confirm that the page evidence came from the canonical page, the target intent is explicit, and each question tests one quality. Check that criteria are ordered for every Score and mutually understandable for Choice. Log distributions as well as selected values. Route missing evidence to collection, not to rewriting.
Reviewers should be able to trace every decision to the stored state and question version. If two editors consistently disagree with the model on a class of pages, fix the evidence or criteria before changing the threshold. The workflow creates a repeatable review system only when human feedback changes the system.
Frequently asked questions
Can TypeSafe AI’s Jev open a URL and inspect the page?
No. Fetch or crawl the page first, then place the relevant evidence in `state`.
Can Jev rewrite a weak meta description?
No. Jev returns typed decisions rather than new prose. Use an editor or a separate generative model for rewriting.
Does high confidence prove that a description is correct?
No. Confidence reflects the response distribution. Validate thresholds against labeled examples from your own site.
Should every weak result be changed automatically?
No. Route weak and uncertain cases for review. Editors should confirm factual accuracy, intent, and brand fit before publication.