Introduction
Hallucinations—one of the most critical challenges in large language models—occur when models generate plausible-sounding but factually incorrect information. These hallucinations undermine trust in AI systems, especially for knowledge-intensive applications like medical advice, legal research, and scientific writing.
Chain of Verification (CoVe), introduced by Meta AI, provides a systematic approach to reduce hallucinations by having the model verify its own outputs. This article explores the CoVe methodology, its variants, and how to implement it effectively.
The Hallucination Problem
Why LLMs Hallucinate
Hallucination is not a single bug but a family of failure modes that all share one root cause: a language model predicts the most probable continuation of a prompt, not a verified statement about the world. Because training teaches statistical patterns rather than a factual database, the model has no built-in mechanism to distinguish a true claim from a plausible one. This matters enormously for knowledge-intensive applications, where a confidently wrong answer can cause real harm in medicine, law, and finance, and where even occasional errors undermine the trust that makes an AI tool useful.
Understanding the specific causes is the first step toward designing a mitigation, and the structured breakdown below organizes them along two dimensions. The first dimension is epistemic: does the model lack the information entirely, or does it have the right information but fail to use it? Knowledge cutoff and the absence of grounding fall into the first category, while probabilistic decoding and context confusion fall into the second. The second dimension is whether the cause is addressable at inference time or requires changing how the model was trained. Inference-time techniques like CoVe can only fix failures that the model has the knowledge to correct; they cannot manufacture facts that were never learned.
hallucination_causes = {
'training_data': 'Model learns patterns, not facts',
'knowledge_cutoff': 'Cannot access real-time or unseen information',
'probabilistic_nature': 'Generates most probable next token, not verified facts',
'context_confusion': 'Can be misled by adversarial prompts',
'lackofgrounding': 'No direct connection to knowledge bases',
# Example
'example': {
'prompt': 'Who invented the telephone in 1876?',
'hallucinated': 'It was Alexander Graham Bell, who was born in Scotland...',
'correct': 'It was actually Antonio Meucci who filed the patent...',
'issue': 'Model confidently states incorrect information'
}
}
The worked example embedded in the dictionary is deliberately provocative: the model confidently asserts a fact that is historically contested, phrased with the kind of detail that makes hallucinations so dangerous. Notice that the hallucinated answer and the correct answer are both stated with equal confidence by humans who hold opposing views; the model simply commits to whichever pattern its training data weights more heavily. The practical takeaway is that hallucination is a confidence calibration problem as much as a knowledge problem, which is why verification approaches focus on checking claims after generation rather than only on improving generation.
Existing Approaches and Their Limitations
Before CoVe, the dominant strategies for reducing hallucination attacked the problem upstream: feed the model more context, or train it to be more factual. Retrieval-augmented generation (RAG) injects relevant documents into the prompt so the model can ground its answer in provided evidence, which works well when the retrieval step finds the right passages. Fine-tuning on curated factual data reshapes the model’s distribution toward correct answers but is expensive to run per domain and risks embedding new biases or forgetting general capabilities. Contradiction training attempts to teach the model to recognize false statements, yet it is notoriously hard to collect the negative examples needed and can make the model overly cautious or less creative.
Each of these approaches shares a structural weakness: they assume the problem can be solved before the answer is generated. CoVe inverts the assumption by making the model critique its own output after the fact, treating verification as a separate reasoning stage rather than a property of generation. The comparison below summarizes how each strategy works and where it falls short, which is useful context for deciding when CoVe should replace or complement an existing mitigation.
existing_approaches = {
'retrieval_augmented': {
'approach': 'Add relevant context from knowledge base',
'limitation': 'Retrieval quality affects accuracy'
},
'fine-tuning': {
'approach': 'Train on more factual data',
'limitation': 'Expensive, can introduce new biases'
},
'contradiction_training': {
'approach': 'Train model to recognize false statements',
'limitation': 'Complex to implement, may reduce creativity'
},
'chain_of_verification': {
'approach': 'Verify claims before outputting',
'limitation': 'Requires external verification capability'
}
}
Reading across the rows, you can see why CoVe has attracted so much attention. It is the only approach that works at inference time, requires no additional training data, and can be layered on top of RAG and fine-tuned models alike. Its stated limitation, the need for an external verification capability, is precisely what the rest of this article addresses: the model’s own latent knowledge, plus retrieval, can usually serve as that verifier without any new infrastructure.
Chain of Verification (CoVe) Architecture
Core Concept
The central insight of CoVe is that a language model asked to verify a statement behaves differently from a language model asked to produce an answer. When generating an answer, the model optimizes for fluency and informativeness; when evaluating a specific factual claim, it engages a different, more critical mode of reasoning that surfaces knowledge it would not volunteer spontaneously. CoVe exploits this asymmetry by decomposing the task into two phases: free generation followed by targeted self-questioning, where each phase uses the model in the mode it is best at.
The pipeline below follows the canonical five steps introduced in the Meta AI paper. First the model produces a baseline response with no constraints, capturing its natural output including any errors. Next it plans verification by identifying the specific factual claims embedded in that response and converting each into a question. Those questions are then executed, either by consulting an external retriever or by asking the model directly. Finally, the results feed back into a revision step that removes or corrects the claims that failed verification.
- Generate an initial response
- Identify factual claims in the response
- Generate verification questions for each claim
- Answer verification questions using external sources
- Revise the response based on verification results
class ChainOfVerification:
"""
Implementation of Chain of Verification (CoVe)
"""
def __init__(self, llm, retriever=None, use_rag=True):
self.llm = llm
self.retriever = retriever
self.use_rag = use_rag
def answer(self, query):
"""
Complete CoVe pipeline
"""
# Step 1: Generate baseline response
baseline_response = self.generate_baseline(query)
# Step 2: Plan verification questions
verification_questions = self.plan_verifications(query, baseline_response)
# Step 3: Execute verifications
verification_results = self.execute_verifications(verification_questions)
# Step 4: Generate final verified response
final_response = self.generate_final(
query,
baseline_response,
verification_results
)
return final_response
def generate_baseline(self, query):
"""Generate initial response without verification"""
prompt = f"""Answer the following question comprehensively:
Question: {query}
Provide a detailed answer based on your knowledge."""
return self.llm.generate(prompt)
def plan_verifications(self, query, response):
"""
Generate verification questions for factual claims
"""
prompt = f"""Given the user's question and the generated response,
identify specific factual claims that should be verified.
Return a list of verification questions.
Question: {query}
Response: {response}
Format:
1. [Question 1]
2. [Question 2]
..."""
questions_text = self.llm.generate(prompt)
questions = self.parse_questions(questions_text)
return questions
def execute_verifications(self, questions):
"""
Answer verification questions
"""
results = []
for question in questions:
if self.use_rag and self.retriever:
# Use RAG to answer
answer = self.verify_with_rag(question)
else:
# Use LLM's own knowledge
answer = self.verify_with_llm(question)
results.append({
'question': question,
'answer': answer,
'verified': self.is_factual(answer)
})
return results
def generate_final(self, query, baseline, verifications):
"""
Generate final response incorporating verification results
"""
# Format verification results
verification_text = self.format_verifications(verifications)
prompt = f"""Given the original question, the baseline response,
and verification results, generate a refined final response.
Make corrections based on verification results. If verification
shows a claim is false, remove or correct it.
Question: {query}
Baseline Response: {baseline}
Verification Results:
{verification_text}
Final Verified Response:"""
return self.llm.generate(prompt)
Several design decisions in this skeleton are worth calling out because they determine whether CoVe
actually reduces hallucinations. The verification questions are generated from the response itself,
not from the original query, which forces the model to examine its own output rather than merely
elaborating on the prompt. The execute_verifications method abstracts over the verification
source, so the same pipeline can run against a retriever or the model’s internal knowledge, which
makes it trivial to switch from a cheap self-verification mode to a grounded RAG mode. Finally, the
revision prompt explicitly instructs the model to remove or correct false claims, because without
that instruction a well-behaved LLM will often just restate its original answer.
Implementation Variants
The Meta AI paper evaluated several ways to structure the verification pipeline, and the choice between them is a direct trade-off between accuracy and latency. Reading the variants below in order shows an escalation: each one adds independence between the generation and verification stages, at the cost of additional LLM calls. The right variant depends on your tolerance for latency and the stakes of getting a fact wrong.
Variant 1: Joint Verification
The joint variant is the cheapest to run because it performs planning, answering, and revision in a single LLM call, guided by one carefully formatted prompt. The prompt asks the model to produce three labeled sections in sequence: verification questions, answers, and a corrected response. This works well for simple queries and when latency matters, but it has a subtle weakness: because all three stages share one context window and one decoding trajectory, the answers are not independent of the original response they are meant to check. A model that is confidently wrong may generate verification questions that lead it back to the same wrong conclusion.
class JointVerification:
"""
Combine planning and execution in single prompt
"""
def verify(self, query, response):
"""
Joint method: Plan and execute in one LLM call
"""
prompt = f"""Given the question and response below,
first generate verification questions, then answer them,
and finally provide a corrected response.
Q: {query}
Response: {response}
Format:
VERIFICATION_QUESTIONS:
1. ...
2. ...
VERIFICATION_ANSWERS:
1. [Answer to Q1]
2. [Answer to Q2]
...
CORRECTED_RESPONSE:
[Your corrected response]"""
result = self.llm.generate(prompt)
return self.parse_joint_result(result)
The structured output format in the prompt is the load-bearing part of this implementation. By
asking for VERIFICATION_QUESTIONS, VERIFICATION_ANSWERS, and CORRECTED_RESPONSE as distinct
sections, the implementation gives the model an explicit scaffold to separate thinking from
answering, which measurably improves the quality of the final revision compared to an unstructured
“check your answer” instruction. In practice, you will also want a parser that is tolerant of
formatting drift, since models occasionally merge or skip sections.
Variant 2: Factorized Verification
The factorized variant addresses the independence problem of joint verification by splitting the pipeline into separate LLM calls. Each verification question is answered in its own call, with a system prompt that tells the model to rely on verified facts only, and importantly, without the original response in the context. This isolation is the entire point: when the model sees its own potentially flawed answer while verifying, it tends to agree with it; when asked the question cold, it has to draw on its actual knowledge instead.
The cost is latency and token usage, since a response with many claims now triggers many separate calls. That cost is often acceptable in practice because the questions can be answered in parallel, collapsing the wall-clock time back down to roughly that of a single call. The final stage reassembles the independently verified answers and asks the model to reconcile them with the original response.
class FactorizedVerification:
"""
Answer each verification question independently
More accurate but requires multiple LLM calls
"""
def verify(self, query, response):
# Generate questions
questions = self.generate_questions(query, response)
# Answer each question independently
answers = []
for q in questions:
# Each answer is independent, avoiding bias from original response
answer = self.llm.generate(
f"Answer this factual question: {q}",
system_prompt="Answer based on verified facts only."
)
answers.append(answer)
# Generate final response with all answers
final = self.generate_final(query, response, questions, answers)
return final
def generate_final(self, q, baseline, questions, answers):
"""Generate final with independent verification"""
verification_summary = "\n".join(
f"Q: {q}\nA: {a}"
for q, a in zip(questions, answers)
)
prompt = f"""Based on the independent verification answers,
revise the original response.
Original Question: {q}
Original Response: {baseline}
Verification Results:
{verification_summary}
Provide the corrected response:"""
return self.llm.generate(prompt)
Variant 3: Factorize + Revise
The factorize-and-revise variant extends factorized verification with an explicit cross-checking stage. After each question is answered independently, the original claim extracted from the baseline response is compared against the fresh verification answer. Where the two disagree, the pipeline records a correction, pairing the original claim with the verified fact and a suggested revision. This explicit bookkeeping makes the revision stage far more controllable than simply dumping answers into a prompt and hoping the model reconciles them.
This is the most thorough of the variants, and the extra structure shows up clearly in the code: instead of passing a flat summary, the pipeline hands the revision stage a list of concrete contradictions it must resolve. Each entry names the disputed question, the original claim, the verified answer, and a suggested correction, which eliminates the guesswork of asking a model to figure out why it should change its mind. Unsurprisingly, this variant also produces the best factual accuracy in the paper’s benchmarks, at the cost of the most LLM calls per query.
class FactorizeReviseVerification:
"""
Most thorough: Answer, then cross-check with original
"""
def verify(self, query, response):
# Step 1: Generate questions
questions = self.generate_questions(query, response)
# Step 2: Answer independently
answers = [self.verify_independent(q) for q in questions]
# Step 3: Cross-check each answer with original response
corrections = []
for q, original_claim, verification in zip(
questions,
self.extract_claims(response),
answers
):
is_consistent = self.check_consistency(original_claim, verification)
if not is_consistent:
corrections.append({
'question': q,
'original': original_claim,
'verified': verification,
'correction': self.suggest_correction(original_claim, verification)
})
# Step 4: Generate final corrected response
final = self.correct_response(response, corrections)
return final
def verify_independent(self, question):
"""Verify without seeing original response"""
return self.llm.generate(
f"Factual question: {question}",
system_prompt="Answer based on facts only. Say 'I don't know' if uncertain."
)
The system prompt on the independent verification call is a small but important detail. Instructing the model to answer based on facts only and to say “I don’t know” when uncertain explicitly licenses the model to refuse, which pushes the pipeline toward precision: an unverifiable claim becomes a flagged unknown rather than a confidently restated error. Compare this with the revision stage, which is given full context precisely because merging and correcting is a reasoning task that benefits from seeing all the evidence.
Variant 4: Self-CoT with Verification
The final variant takes the idea one step further by moving verification inside the reasoning process itself. Instead of verifying claims in a finished answer, this approach interleaves reasoning with checking: the model generates a chain of thought, verifies each intermediate step, identifies where the reasoning went wrong, and then revises the chain before producing a final answer. This targets a different kind of hallucination: not the wrong fact stated confidently, but the plausible-sounding chain of steps that leads to a wrong conclusion through an undetected error partway along.
The benefit of step-by-step verification is that it catches errors at their source rather than in their consequences. A single faulty step can poison everything downstream, and by the time the model reaches a final answer the damage is invisible; checking each step as it is produced makes the error immediately apparent. The cost is a longer generation path and more verification calls, so this variant is best reserved for reasoning-heavy tasks like math word problems and multi-hop question answering rather than simple fact lookup.
class SelfCoTVerification:
"""
Combine Chain of Thought with verification
"""
def answer_with_cot_verification(self, query):
# Step 1: Generate response with reasoning
reasoning_response = self.generate_with_reasoning(query)
# Step 2: Verify each step in reasoning
step_verifications = []
for step in reasoning_response.steps:
verification = self.verify_step(step)
step_verifications.append(verification)
# Step 3: Identify where reasoning went wrong
errors = self.identify_errors(step_verifications)
# Step 4: Revise reasoning
revised = self.revise_reasoning(reasoning_response, errors)
# Step 5: Generate final answer
return self.extract_answer(revised)
Integration with RAG
CoVe-RAG Pipeline
Retrieval-augmented generation and CoVe solve complementary problems, which is why they combine so naturally. RAG provides the evidence: relevant documents pulled from a knowledge base at query time. CoVe provides the discipline: a mechanism that forces the model to actually check its claims against that evidence. Without CoVe, a RAG system can still hallucinate by ignoring the retrieved context or overgeneralizing from it; without RAG, CoVe can only verify against the model’s latent knowledge, which suffers from the same training-time gaps that caused the hallucination in the first place.
The pipeline below pairs them in the obvious but effective way. Documents are retrieved for the query and used to generate a grounded baseline response. The claims in that response are then checked one by one against the same retrieved documents, with a fallback to a second, more targeted retrieval if a claim has no supporting evidence in the original set. Only claims that survive this evidence check are retained in the final answer. The key improvement over plain RAG is that the model is now forced to confront the retrieved documents a second time, as evidence to be matched against specific claims rather than as general background context.
class CoVeRAG:
"""
Chain of Verification combined with RAG
"""
def __init__(self, llm, retriever):
self.llm = llm
self.retriever = retriever
def answer(self, query):
# Step 1: Retrieve relevant documents
docs = self.retriever.search(query)
context = self.format_docs(docs)
# Step 2: Generate response with context
response = self.generate_with_context(query, context)
# Step 3: Identify verifiable claims
claims = self.extract_claims(response)
# Step 4: Verify each claim against retrieved docs
verified_claims = []
for claim in claims:
supporting = self.find_supporting_evidence(claim, docs)
if supporting:
verified_claims.append({
'claim': claim,
'evidence': supporting,
'verified': True
})
else:
# Try general retrieval
more_docs = self.retriever.search(claim)
supporting = self.find_supporting_evidence(claim, more_docs)
verified_claims.append({
'claim': claim,
'evidence': supporting,
'verified': bool(supporting)
})
# Step 5: Generate final response with verified claims
final = self.generate_final(query, verified_claims)
return final
def find_supporting_evidence(self, claim, docs):
"""Check if claim is supported by documents"""
for doc in docs:
if self.claim_supported(claim, doc):
return doc
return None
Note the layered verification strategy in find_supporting_evidence: it first tries the original
retrieval results, and only on failure issues a fresh retrieval query derived from the claim itself.
This ordering keeps latency low for the common case where the initial context already covers the
claim, while reserving an extra retrieval round for claims that were not well covered. In
production, the claim-to-evidence matching step is often a semantic similarity threshold rather than
a boolean check, so that near-miss evidence can be surfaced to the user with a confidence score
instead of silently dropped.
Complete Implementation
The variants above each optimize for one slice of the accuracy-latency spectrum, but a production system needs the full loop: claim extraction, verification, analysis, and revision assembled into a single, observable pipeline. The complete implementation below binds everything together and, just as importantly, exposes its internal state. Every verification returns a structured record of whether each claim was supported and what evidence backed it, and the final answer carries a verdict flag indicating whether revision was needed at all.
This observability matters for a subtle reason. CoVe is not a binary on-or-off correctness guarantee; it is a signal about how much of the answer was independently corroborated. Returning the verification details alongside the response lets the calling application decide how much to trust the output, warn the user when a claim could not be verified, or even refuse to answer when too many claims failed. The code also caps the number of claims verified at five, a pragmatic latency control that you will want to tune based on your answer lengths and budget.
import json
from typing import List, Dict
class CoVeImplementation:
"""
Production-ready Chain of Verification
"""
def __init__(self, llm, knowledge_base=None):
self.llm = llm
self.knowledge_base = knowledge_base
self.max_claims = 5
def answer(self, query):
# Stage 1: Baseline response
baseline = self.generate_baseline(query)
# Stage 2: Extract and verify claims
claims = self.extract_key_claims(baseline)
claims = claims[:self.max_claims] # Limit for efficiency
verifications = []
for claim in claims:
verification = self.verify_claim(claim)
verifications.append(verification)
# Stage 3: Analyze verification results
analysis = self.analyze_verifications(verifications)
# Stage 4: Generate final response
if analysis['needs_revision']:
final = self.generate_revised_response(
query, baseline, verifications, analysis
)
else:
final = baseline
return {
'response': final,
'verified': not analysis['needs_revision'],
'verification_details': verifications
}
def extract_key_claims(self, text):
"""Extract factual claims from response"""
prompt = f"""Extract the key factual claims from this text.
Only include claims that can be verified as true or false.
Don't include opinions or subjective statements.
Text: {text}
Format as a list of specific factual claims."""
claims_text = self.llm.generate(prompt)
return self.parse_claims(claims_text)
def verify_claim(self, claim):
"""Verify a single claim"""
if self.knowledge_base:
# Search knowledge base
evidence = self.knowledge_base.search(claim)
is_supported = bool(evidence)
return {
'claim': claim,
'supported': is_supported,
'evidence': evidence
}
else:
# Use LLM to verify
verification = self.llm.generate(
f"""Verify this claim by answering the question.
Claim: {claim}
Provide supporting evidence or explain why it's incorrect.""",
system_prompt="Be factual and precise."
)
is_supported = self.assess_support(verification)
return {
'claim': claim,
'supported': is_supported,
'evidence': verification
}
def analyze_verifications(self, verifications):
"""Analyze verification results"""
unsupported = [v for v in verifications if not v['supported']]
return {
'needs_revision': len(unsupported) > 0,
'unsupported_count': len(unsupported),
'unsupported_claims': [v['claim'] for v in unsupported]
}
def generate_revised_response(self, query, baseline, verifications, analysis):
"""Generate corrected response"""
# Format verifications for prompt
v_text = "\n".join([
f"Claim: {v['claim']}\nSupported: {v['supported']}\nEvidence: {v['evidence'][:200]}"
for v in verifications
])
prompt = f"""The original response contained some inaccuracies.
Revise it based on the verification results.
Question: {query}
Original Response: {baseline}
Verification Results:
{v_text}
Unverified claims: {', '.join(analysis['unsupported_claims'])}
Provide a corrected response that removes or fixes the inaccurate claims:"""
return self.llm.generate(prompt)
The claim-extraction prompt in extract_key_claims contains an instruction that is easy to overlook
but essential to the pipeline’s quality: it asks the model to include only claims that can be
verified as true or false and to exclude opinions and subjective statements. This is what makes the
later verification meaningful, because an unfalsifiable claim cannot be checked, and verifying it
wastes a retrieval call and adds noise. The revision stage then targets only the claims that
actually failed, which keeps the corrected answer stable: when everything checks out, the baseline
response is returned unchanged, minimizing unnecessary rewriting of an already accurate answer.
Experimental Results
Performance Metrics
The empirical case for CoVe rests on a consistent finding: adding a verification stage reliably improves factual accuracy across domains and model sizes, and the improvement grows as the verification becomes more independent of the original answer. The numbers below show the canonical pattern from the paper. Factual accuracy climbs steadily from the joint variant through factorized to factorize-and-revise, confirming that independence between generating and verifying is the mechanism driving the gain, not the mere presence of an extra prompt.
The hallucination figures are the most striking: the rate drops from 34.8% at baseline to 14.3% with the most thorough variant, a reduction of nearly 60%. It is worth interpreting these numbers with appropriate caution, since benchmark-specific results do not always transfer directly to production workloads, but the relative ordering across variants is robust and has been reproduced in follow-up work. The precision and recall entries add another useful angle: CoVe improves precision more than recall, which makes sense because the mechanism is designed to remove false claims rather than to surface additional true ones.
cove_benchmarks = {
'factual_accuracy': {
'baseline': 65.2,
'cove_joint': 78.4,
'cove_factorized': 82.1,
'cove_factorize_revise': 85.7,
},
'hallucination_reduction': {
'baseline': '34.8% hallucinations',
'cove_joint': '21.6% hallucinations', # -38%
'cove_factorized': '17.9% hallucinations', # -49%
'cove_factorize_revise': '14.3% hallucinations', # -59%
},
'precision': {
'baseline': 68.5,
'cove': 83.2 # +14.7%
},
'recall': {
'baseline': 72.1,
'cove': 79.8 # +7.7%
}
}
Best Practices
When to Use CoVe
CoVe is not a universal improvement; it is a tool for a specific class of problem. The decision framework below captures when the added latency and complexity pay for themselves. The highest-value cases share three properties: the application is high-stakes, factual accuracy is critical, and the claims being made are verifiable against some source of truth. Conversely, CoVe is actively counterproductive for creative writing, poetry, and opinion, where there is no ground truth to verify against and the verification stage would just add latency and flatten the model’s voice.
use_cove_when = {
'high_stakes': 'Medical, legal, financial applications',
'factual_requirements': 'When accuracy is critical',
'verifiable_claims': 'When claims can be checked',
'user_trust': 'When user trust is essential',
'not_for': ['Creative writing', 'Poetry', 'Opinions']
}
Optimization Tips
Once you have decided CoVe fits, a handful of engineering choices separate a slow, expensive prototype from a deployable system. The tips below all point in the same direction: do less verification, but do it on the claims that matter. Focus claim extraction on specific, verifiable assertions rather than vague statements, verify multiple claims in parallel to collapse latency, and skip verification entirely for low-risk content. Caching is particularly valuable in practice because real workloads repeat claims constantly, and a cached verification result can eliminate the dominant cost of the pipeline for the most common queries.
optimization_tips = {
'claim_extraction': 'Focus on specific, verifiable claims',
'parallel_verification': 'Verify multiple claims simultaneously',
'selective_verification': 'Only verify high-risk claims',
'caching': 'Cache verification results for repeated claims',
'hybrid': 'Combine with RAG for better evidence'
}
Conclusion
Chain of Verification represents a significant advancement in LLM reliability:
- Self-Correction: Model can identify and fix its own errors
- Multiple Variants: Joint, Factorized, and Factorize+Revise options
- RAG Integration: Works synergistically with retrieval-augmented generation
- Significant Improvements: Up to 59% reduction in hallucinations
As LLMs continue to improve their reasoning capabilities, CoVe will become increasingly effective at ensuring factual accuracy.
Resources
- Chain of Verification Paper (Meta AI)
- Reducing Hallucinations with Verification
- LangChain Verification Patterns
- RAG + CoVe Implementation
Comments