Multi-Perspective Review

The core mechanism involves instructing the model to adopt specific personas or stakeholder viewpoints. Common examples include:

• The Expert Critic: Scrutinizes for technical accuracy and depth.
• The Novice User: Identifies confusing jargon and missing foundational explanations.
• The Adversary: Actively seeks logical flaws, edge cases, and potential misinterpretations.
• The Compliance Officer: Checks for alignment with rules, ethics, and safety guidelines. This simulation creates a virtual panel review, uncovering blind spots a single perspective would miss.

By mandating analysis from conflicting angles, the technique directly counters cognitive biases inherent in a model's single-pass generation. It compels the examination of:

• Confirmation Bias: Forcing the 'adversary' persona challenges the initial conclusion.
• Curse of Knowledge: The 'novice' persona highlights assumptions and unclear terminology.
• Framing Effects: Reviewing the output from multiple stakeholder goals reveals how the problem's framing influenced the solution. This structured critique is more reliable than a generic 'check your work' instruction.

Effective implementation requires pre-defining the evaluation axes for each perspective. The prompt must specify not just who is reviewing, but what they are looking for. For example:

• For Factual Grounding: "From the Expert's view, cite source line numbers that contradict any claim."
• For Security: "From the Adversary's view, list three ways this API call could be maliciously exploited."
• For Clarity: "From the Novice's view, rewrite the two most complex sentences." This transforms open-ended review into a bounded, verifiable sub-task.

Multi-perspective review is typically one phase within a larger self-correction loop. The standard pattern is:

1. Initial Generation: Produce a first-draft answer.
2. Multi-Perspective Analysis: Execute the review prompt to generate distinct critiques.
3. Synthesis & Revision: A final instruction integrates the critiques to produce a revised, robust output. This separates the critique from the revision, preventing the model from prematurely defending its initial output and leading to more substantive edits.

This technique is distinguished from a simple self-critique prompt by its enforced diversity of viewpoint. A generic critique often results in shallow, affirmative feedback (e.g., "The answer is comprehensive"). Multi-perspective review mandates constructive conflict by design. Key Differentiator: It operationalizes the concept of 'steel-manning' opposing arguments, requiring the model to build the strongest possible case against its own position, which dramatically improves problem-solving rigor and error detection.

This method is critical for applications where error cost is extreme. Prime use cases include:

• Legal & Compliance Drafting: Reviewing a contract clause from the perspectives of each party and a regulator.
• Technical Architecture: Assessing a system design from the views of a security engineer, a cost optimizer, and a DevOps lead.
• Medical Triage Advice: Evaluating a summary from a doctor's, a patient's, and a medical ethicist's standpoint.
• Financial Reporting: Analyzing a market summary through bullish, bearish, and regulatory lenses. It injects a form of procedural rigor into otherwise stochastic LLM outputs.

Instructs the model to evaluate its output from the distinct viewpoints of different stakeholders involved in or affected by the decision. This surfaces conflicting interests and unintended consequences.

Example Prompt: "Review the proposed product launch plan. First, analyze it from the perspective of the engineering team (focusing on feasibility and technical debt). Second, analyze it from the perspective of the marketing team (focusing on messaging and market fit). Third, analyze it from the perspective of a customer advocate (focusing on usability and value). Synthesize the key tensions and recommendations."

Key Angles:

• Internal: Engineering, Marketing, Legal, Finance, Support.
• External: End-User, Regulator, Investor, Competitor, Partner.

Directs the model to separately analyze the potential benefits (reward) and the potential drawbacks or dangers (risk) of its proposed answer or solution. This forces a balanced evaluation beyond initial optimism.

Example Prompt: "You have proposed a new data architecture. Now, conduct a multi-perspective review: 1) Enumerate and detail all potential performance gains and strategic advantages (the reward perspective). 2) Independently, enumerate and detail all potential implementation risks, failure modes, and hidden costs (the risk perspective). Provide a final integrated assessment."

Output Structure: Often results in a two-column table or clearly separated sections, preventing the conflation of pros and cons.

Commands the model to assess its output across different time horizons. A solution optimal in the short-term may create long-term liabilities, and vice-versa.

Example Prompt: "Critique the proposed software migration strategy from three temporal perspectives:

• Immediate (Next 3 months): Analyze rollout complexity and team disruption.
• Medium-term (1 Year): Analyze maintenance burden and scalability.
• Long-term (3+ Years): Analyze technology lock-in and adaptability to future trends. Identify the perspective where the proposal is weakest."

Common Frameworks: Short-Term (Tactical), Medium-Term (Strategic), Long-Term (Visionary).

A classic dialectical method where the model is instructed to role-play two opposing mindsets: one focused on finding flaws (Devil's Advocate) and one focused on maximizing potential (Optimist).

Example Prompt: "First, act as a Devil's Advocate. Ruthlessly critique the business plan I've generated. Find every logical flaw, overstatement, and vulnerable assumption. Then, act as a Strategic Optimist. Build upon the same plan, identifying how to strengthen its best elements, mitigate the flaws found, and expand its upside potential. Combine insights into a revised plan."

Mechanism: This creates internal debate, moving the model beyond its default reasoning pathway to generate more robust, stress-tested outputs.

Instructs the model to evaluate its solution using two distinct reasoning frameworks. This checks if a solution derived from analogies holds up under fundamental scrutiny.

Example Prompt: "You have designed a system based on an analogy to distributed computing. Now, review it from two perspectives:

1. First-Principles Perspective: Break the problem down to its fundamental truths. Does the design logically follow from these basics, ignoring the analogy?
2. Analogy-Based Perspective: Does the analogy hold perfectly? Where does it break down, and what compensating mechanisms are needed? Highlight any divergences between the two perspectives."

Use Case: Particularly valuable for innovative or creative proposals that may be over-reliant on historical patterns.

Directs the model to self-assess its output against two often competing quality dimensions. This prevents overly verbose yet comprehensive answers, or overly brief yet incomplete ones.

Example Prompt: "Review your generated technical documentation. First, from a Completeness Auditor perspective: List every missing detail, assumed knowledge, or unanswered question a new engineer would have. Second, from a Conciseness Editor perspective: Identify every redundant sentence, tangential explanation, or overly verbose section. Propose a final version that optimally balances both audits."

Application: Essential for generating reports, summaries, instructions, and any communication where information density must be optimized.

A self-correction loop is a prompting technique where a language model is instructed to iteratively critique and revise its own output to improve accuracy, coherence, or adherence to constraints. It is the overarching iterative process that techniques like multi-perspective review operate within.

• Core Mechanism: The model generates an initial response, performs a self-assessment, and then produces a revised version. This cycle can be repeated multiple times.
• Key Distinction: While multi-perspective review focuses on the analysis phase from different viewpoints, the self-correction loop describes the complete, cyclical execution process of generation, critique, and revision.

The critique-generate cycle is a fundamental two-phase pattern within self-correction. First, the model produces a structured critique of a draft response. Second, it generates an improved version based explicitly on that critique.

• Direct Relationship: Multi-perspective review is a specialized form of the critique phase, where the critique is generated by analyzing the output through distinct, predefined lenses (e.g., user, expert, critic).
• Implementation: This cycle makes the model's reasoning for changes explicit and auditable, separating the fault-finding logic from the creative regeneration task.

Multi-agent self-review is an architectural pattern that simulates a panel review by using multiple, distinct model instances or personas to critique a single output. It is a technical implementation strategy for achieving multi-perspective analysis.

• Architecture: Instead of one model trying to adopt multiple viewpoints sequentially, separate model calls (or system prompts defining different personas) are used to generate independent critiques. These are then synthesized.
• Advantage: This approach can reduce viewpoint contamination and more effectively simulate genuine disagreement or diverse expertise, leading to a more robust consensus critique.

Constitutional self-review is a process where a language model evaluates its output against a predefined set of principles or rules—a 'constitution'—governing safety, ethics, or legality. It is a perspective-driven review with a fixed, normative lens.

• Fixed Perspective: The 'perspective' is the set of constitutional principles. The model acts as a compliance officer auditing its output against these rules.
• Contrast with MPR: While multi-perspective review often uses fluid, task-dependent viewpoints (e.g., a beginner, a lawyer), constitutional review uses a consistent, principled framework applied across all tasks to ensure alignment.

Adversarial self-testing is a self-correction instruction where the model is prompted to role-play as a dedicated critic or attacker seeking to find weaknesses, edge cases, or failure modes in its own output.

• Perspective as Attack Vector: This employs a specifically hostile or skeptical viewpoint, focusing on breaking the argument or finding vulnerabilities.
• Application: It is highly effective for stress-testing logical reasoning, code, or security-related plans. It complements multi-perspective review by ensuring one of the analytical angles is intentionally destructive to uncover hidden flaws.

An internal consistency check is a self-correction step where a language model is prompted to ensure all parts of its generated response are logically coherent and free from contradictions. It is a foundational, single-perspective review focused on logical integrity.

• Core Focus: This check operates from the perspective of pure logic, verifying that Statement A does not conflict with Statement B within the same output.
• Building Block: It is often one of the first and most critical perspectives applied in a multi-perspective review framework, as an output that fails its own internal logic is fundamentally flawed before other viewpoints (clarity, completeness) are even considered.