PSCI: The Spec Contract — a technique that makes the model learn the document's rules before it answers

Run sequentially — each step as a separate request, or all combined in one structured prompt.

STEP 1: SPECIFICATION INDUCTION
Input: document/context + task
Action: extract all implicit rules, constraints, formats
Output: contract K = {k1, k2, ..., kn} — a numbered list of obligations

STEP 2: CONTRACT-GUIDED GENERATION
Input: task + document + contract K
Action: produce a draft Y0, following every item in K
Output: draft answer

STEP 3: VERIFICATION (adversarial checker)
Input: task + document + contract K + draft Y0
Action: verify each item Ki
Output: diagnosis d = [(ki, status, reason)]
       status: SATISFIED / PARTIAL / VIOLATED

STEP 4: REPAIR
Input: everything above + diagnosis d
Action: fix only PARTIAL and VIOLATED items, keep the rest intact
Output: final answer Ŷ

Task: You're a seller on an e-commerce marketplace who received a 40-page product-listing guideline from a supplier brand. You need to write a listing for a new item — mosquito repellent. The guideline scatters dozens of requirements across its pages: banned words, mandatory warnings, SKU format, description structure, rules for placing safety symbols. Violate even one, and the listing gets rejected for revision.

Prompt (Step 1 — Specification Induction):

You are an expert in product listing compliance.

Below is a brand's guideline for creating product listings on marketplaces:

[GUIDELINE]
{paste guideline text}
[/GUIDELINE]

My task: write a listing for a mosquito repellent called "AntiMosquito Pro 200ml."

Before writing the listing — extract ALL mandatory requirements from the guideline that apply to this task. Pay special attention to:
— format and structure (block order, length, headings)
— banned words and phrasing
— mandatory warnings and markings
— edge cases and exceptions
— exact phrases or labels that must be used verbatim

Format as a numbered list: "Obligation N: [rule description]".
Don't write the listing yet — just the list of obligations.

Prompt (Step 2 — Contract-Guided Generation):

Here is the list of obligations from the guideline:
{list from step 1}

Now write the product listing for "AntiMosquito Pro 200ml,"
strictly following every item on the list.

Prompt (Step 3 — Verification):

Check the listing against every obligation.

List of obligations:
{list from step 1}

Listing:
{listing from step 2}

For each item, indicate:
— SATISFIED / PARTIAL / VIOLATED
— If not SATISFIED: what exactly is violated and where

Verification only — do not rewrite the listing.

Prompt (Step 4 — Repair):

Here is the listing with a violation diagnosis:

Listing: {from step 2}
Diagnosis: {from step 3}

Fix only the items marked PARTIAL and VIOLATED.
Leave everything else unchanged.
Output the final listing.

Result: The end product is a listing that has demonstrably passed every requirement in the document. The process is transparent — you see the rule list from step 1, the diagnosis from step 3, and exactly what got fixed. This is especially valuable for documents with dozens of hidden constraints: technical guidelines, contracts, corporate policies, marketplace requirements.

The LLM's weakness: The model generates a response while keeping your question in focus. Anything explicitly tied to the question, it handles well. But requirements from the document that aren't directly linked to the question stay on the periphery — they're never activated as generation constraints. Imagine reading an assignment and catching a footnote in the margin out of the corner of your eye. You registered the content, but by the time you write your answer, the footnote has "fallen out" of focus. That's exactly what happens with rules scattered throughout a document.

The LLM's strength: When directly asked "extract all the rules from this document," the model does great. The research found that when the model was explicitly given an extraction task, it recovered 94.4% of hidden requirements with a contradiction rate below 0.5%. The capability is there — it just needs to be properly activated.

How the method exploits this: PSCI splits the task into two separate acts. First, full attention goes solely toward extracting rules from the document — with no distraction from composing an answer. Then generation proceeds under explicit control of those rules. The checker doesn't look at overall text quality — it looks at a specific contract item, which is far more precise than a generic "critique yourself."

Control levers: - Level of detail in step 1 → the more specifically you ask to break down rule types (formats / bans / edge cases / exact phrasing), the more complete the contract - Steps 3-4 can be skipped for simple documents → saves tokens when the document is short and the cost of error is low - Step 3 can be swapped for a specific specialist persona: "You are a strict compliance lawyer" → sharper critique - The depth of step 1 can be tuned: "only critical requirements" vs. "absolutely everything, including minor details"

A universal template for the whole PSCI cycle in one place:

=== STEP 1: SPECIFICATION EXTRACTION ===
Read the following document with an extraction task in mind, not an answering one:

[DOCUMENT]
{document, guideline, or requirements text}
[/DOCUMENT]

My task: {description of what needs to be created/written/done}

Extract ALL requirements from the document relevant to this task:
— mandatory formats and structures
— bans and restrictions
— edge cases and exceptions
— exact phrasing or labels that must be followed verbatim
— completeness conditions (what MUST be included)

Format as a numbered list. List only — no answer to the task yet.

=== STEP 2: GENERATION ===
Now complete the task, strictly following every item on the list above.
Before your answer, write: "Complying with [N] obligations from the contract."

=== STEP 3: VERIFICATION ===
Before considering the task done — check the draft above
against every item in the contract.

For each item: SATISFIED / PARTIAL / VIOLATED + reason (if not SATISFIED).
Verification only.

=== STEP 4: REPAIR ===
Fix all items marked PARTIAL and VIOLATED.
Keep everything else unchanged. Output the final answer.

Placeholders: - {document text} — a guideline, policy, spec sheet, contract, or instructions - {description of what needs to be created} — "write a product listing," "draft a customer response," "prepare a report using the required format"

🚀 Quick Start — paste into the chat:

Copy

Here's a template for the PSCI (spec contract) method. Adapt it to my task:
{your task}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what document/guideline you have and exactly what needs to be created — because PSCI only works when there's a concrete rule source and a concrete deliverable. It will take the pattern from the template and adapt the wording to your task.

⚠️ Requires a document with rules: The method only works when there's a concrete specification source — a guideline, spec sheet, manual, or contract. For "off-the-top-of-your-head" tasks with no reference document, PSCI offers no advantage over a plain prompt.

⚠️ 4 steps = 4 requests: The full cycle requires multiple messages and a lot of tokens. For short documents or low-stakes tasks, steps 1-2 are usually enough.

⚠️ Step 1 itself can miss things: If the document is very long (40K+ tokens), the contract from step 1 may be incomplete — the model won't capture 100% of the rules. It helps to explicitly list the rule types to look for (formats, bans, flags, edge cases).

⚠️ Not for subjective content: The method is built for tasks with verifiable criteria. For content without hard rules (free-form creative writing, opinion questions), the benefit is minimal.

The starting idea was refreshingly simple: the researchers used a fresh benchmark, CL-Bench, with 1,899 tasks — each task pairing a large document (10K tokens on average, up to 65K) with a question and 16+ evaluation criteria. Tasks were written by human experts to avoid training-data leakage. First, they tested the most obvious explanation for poor performance: "models can't find what they need in a long text." They ran 12 different retrieval and context-processing methods — RAG, GraphRAG, RAPTOR, Reflexion, and others. Not one gained more than +0.78 percentage points over a simple prompt with the full context. That was the signal that the problem lay elsewhere.

So they manually went through all 31,592 evaluation criteria: what exactly do they check — answer content or rule compliance? It turned out that 55.4% of criteria evaluate rules and constraints rather than facts. And in failed tasks where the model missed exactly one criterion, 75.3% of those final misses were rule violations, not factual errors. Next they checked traceability: are these rules even present in the document? 95.5% of the time — yes. The model had physically seen them but hadn't applied them.

The most surprising part: when the model was simply told outright to "extract all the rules from this document," it covered 94.4% of the hidden criteria. The capability was there all along — nobody had activated it. PSCI was tested on three models of different sizes, and all three showed the same ~+5-6 percentage point gain, and 17 sequential ablations made it clear: shuffle the contract → results drop below baseline; remove the contract but keep verification → results return to baseline. This proves it's the contract itself doing the work, not just extra computation.

1. Two-Step PSCI for Quick Tasks

For smaller documents, or when speed matters more than perfection — keep only steps 1 and 2. That alone captures most of the gain (step 1 alone accounts for ~63% of the total improvement, per the ablation data).

Read the document and first compile a list of all requirements for {task}.
Then immediately complete the task, following every item on the list.

[DOCUMENT]
{text}
[/DOCUMENT]

2. Personalized Checker → Sharper Critique

🔧 Technique: Faceless checker → specialist persona

Step 3 by default is a neutral check. Swap in a specific specialist persona to get sharper, more domain-relevant feedback:

Copy

You are a nitpicky lawyer specializing in contract law.
Check this contract against every item on the requirements list.
Flag the slightest deviation.

Works for any professional domain: regulator, editor, CTO.

3. Combining with Chain-of-Thought in Step 2

If the task requires not just completing the document's instructions but also explaining the reasoning behind decisions — add a "think out loud" instruction to step 2. This is especially useful for complex regulatory documents, where it matters to see exactly how the model is interpreting each rule.

Complete the task following the contract of obligations.
For each contract item, first write "Applying item N: [how exactly]",
then incorporate the result into your answer.

Paper: Agentic Context Learning with Self-Discovered Specification (preprint, 2025)

Benchmark: CL-Bench (Dou et al., 2026) — 1,899 tasks, 31,592 evaluation criteria

Authors: Jike Zhong, Ming Li, Yuxiang Lai, Ziyan Yang, Jingyu Xie, Jihyung Kil, Zheda Mai, Shao-Yuan Lo, Xiang Ren, Konstantinos Psounis, Yuanyuan Lei

Universities: University of Southern California, University of Florida, Emory University, Adobe Research, The Ohio State University, National Taiwan University

Contact: [email protected]