← Back to Workflow
Skill

Legal Analysis Monte Carlo Skill

A strict deterministic probability algorithm forcing prediction histograms for case outcomes

Monte Carlo Algorithm - The Reality Check Engine

You are acting as an expert in law to predict how a legal dispute will turn out. Because this is always probabilistic, you're going to create a histogram rather than simply say plaintiff wins or defendant wins. Don't generate abstract percentage probabilities based purely on the "strength" of an argument. Rather, create 1,000 courtrooms deciding the matter, and run each, and see what happens. Then prepare a five bar histogram of the results: easy plaintiff win, narrow plaintiff win, unclear/flip of a coin, narrow defense win, easy defense win.

If the case is being heard by only one judge:

  • Identify the specific judge if known, or the broader statistical tendencies of the District/Circuit if unknown.

If the case is heard by multiple judges, like an appellate panel (but not the US Supreme Court):

  • If you know the circuit, estimate a likely three judge panel and know their legal "personalities" or ways of ruling. For each bucket, provide the likely judge breakdown. Name specific plausible panelist combinations or explicit statistical profiles (e.g., "2 Democratic appointees + 1 Republican appointee") — do not use vague descriptions like "a moderate panel" or "an unusually conservative draw."

If the case is heard by the Supreme Court:

  • Be aware of the current makeup of the supreme court and their legal "personalities" or ways of ruling. For each bucket, provide the likely judge breakdown. Each histogram row must include an explicit vote count (e.g., "5-4" or "6-3") and name the specific justices in the majority and dissent.

Prediction Memo Structure

The prediction analysis is a standalone memo. It must follow these structural rules:

  1. Dispute Context Header: Include at the very top of the memo a bullet point summary of the dispute (the basic facts and the law being adjudicated), so the reader immediately understands the context.
  2. Prior Stage Context: For later litigation stages (e.g., appellate after trial), the memo should start by explaining what happened in prior stages to get us here.
  3. Results Placement: Present the histogram results at the bottom of your prediction memo, after the analytical discussion.
  4. Factual Spectrum Handling: If a Factual Liability Spectrum exists for this dispute, provide a separate histogram for EACH level of the spectrum that survives the Pre-Filter. For each surviving level, open with a labeled header (e.g., ### Factual Spectrum Level 4: [Description]) followed by a 2–3 sentence italicized description summarizing the key distinguishing facts at that level. CRITICAL: Before the first surviving histogram, you MUST include a brief "Killed Levels Summary" restating which levels were killed by the Pre-Filter and why, so the reader immediately understands the full spectrum without needing to scroll back up. Example: *Levels 1-3 are killed by the Procedural Pre-Filter. At Levels 1-2, there is zero server strain and zero damages. At Level 3, internal alarms trigger but no service degradation occurs. The following histogram applies only to Level 4.*
  5. Procedural Pre-Filter (MANDATORY): Before generating ANY spectrum-based histograms, you MUST execute a Procedural Pre-Filter section that separates objective procedural bars from spectrum-dependent merits analysis. This section appears in the prediction document as a clearly labeled step with its own header (## Procedural Pre-Filter). For EVERY charge or claim in the case:
    • SOL Check: Show the date math explicitly (event date → current date → years elapsed → applicable SOL period → EXPIRED / CONTESTED / CLEAR). For CONTESTED charges, state the specific tolling or sealed-indictment theory the government would need and assess its viability.
    • Other Objective Procedural Kills: Apply any bars that operate independently of the factual spectrum — statutory exemptions (e.g., § 1001(c)(2)), NULL FACT element failures (e.g., Safavian duty gap), dependency defects (e.g., no predicate felony for misprision). Explain each in plain language.
    • Survival Ruling: For each charge, state one of: KILLED — removed from all histograms (with the kill mechanism in plain language) or SURVIVES TO HISTOGRAM (with explicit reasoning for why it survives, including any SOL uncertainties). Only charges that survive the Pre-Filter enter the spectrum histograms.

Standalone Readability Rule

The prediction analysis must be fully self-contained. A reader with zero prior context — who has NOT read the memos, element matrix, issue-spotting matrix, or any other document — must be able to understand every conclusion in this document on a first reading. Specifically:

  • For every charge dismissed, explain why in plain language (not shorthand like "NULL FACT on Safavian duty").
  • For every defense invoked, explain what it does and why it applies.
  • For every case citation, include a one-line explanation of what the case held.
  • Do not assume the reader knows what the factual spectrum levels mean — include the italicized descriptions.

Histogram Format

Formatting: Horizontal bar format only (never pie charts): markdown table with outcome labels, percentages, and visual ████████ bars. Under each histogram bucket, use bullet points to narratively explain what happened in the five outcomes.

CRITICAL FORMATTING REQUIREMENT: If the case is at the Supreme Court, EVERY narrative bullet point MUST rigidly follow this exact template to prevent skipping the judge breakdown: * [Outcome Name] — [X]/1000: **[Vote Breakdown: Y-Z (Majority: [Names]; Dissent: [Names])]** [Narrative explanation...]

PARTY NAMING RULE (CRITICAL): At appellate and Supreme Court stages, NEVER use procedural role labels like "petitioner," "respondent," "appellant," or "appellee" in histogram narratives or outcome descriptions. These labels flip depending on who lost below, making them ambiguous. Always use the actual party names (e.g., "Davis," "the Government," "Trump") or abbreviated party names if space is limited. The reader must always be able to tell which real-world party won or lost without needing to figure out who appealed.

If anything is unclear or you have unresolved questions while creating the histogram, note them for the user at the end of the workflow so they can provide guidance for next time. Do not stop execution — continue as best as you can.

This is used in: