How scoring works

Findings about the wording of an instruction, with the context still yours to review.

From file to findings

The file is read in your browser. The reader parses Markdown, preserves source lines, selects excerpts for isolated scoring, and marks recognized context dependencies. Nothing is sent for scoring until you ask for the prompt.

Eligible excerpts are submitted separately. Each request checks the language, screens for text that tries to redirect the evaluator, and combines local wording checks with model judgments. An excerpt can receive several findings or none.

File input accepts up to 64 KiB and 512 structural blocks. The first 150 ready excerpts are scored. A scored excerpt can contain at most 2000 characters, counted as JavaScript string units. Later excerpts, context-dependent ones and oversized ones remain visible as unreviewed text.

What the factors mean

• Verb force (F1). Recognized verbs and phrases describe how strongly an action is stated. A preference can be deliberate; making it mandatory would change its meaning.
• Prohibition framing (F2). A local check looks for a prohibition and an allowed alternative. Some prohibitions are complete on their own.
• Trigger distance (F3). A model judges when an instruction becomes relevant and whether that occasion is explicit. Standing requirements can be valid without a named event.
• Concreteness (F7). Local patterns recognize paths, tools, quantities, and other concrete targets. A missing match does not prove that an instruction is unclear, so a model also judges whether someone could check that the instruction was followed (Concrete enough to check); the finding needs both.
• Enforceability (F8). A model judges how much a deterministic tool could check. Lower values indicate more mechanical coverage; higher values indicate a greater need for judgment.

Additional model questions distinguish instructions from background (Reads as an instruction) and suggest a possible home: a standing rule, an event-driven hook, a task-specific skill, or a separate review pass. These suggestions require checking against your project.

Reading a finding

Findings identify something to inspect. They are not an overall grade, a probability of compliance, or an instruction to maximize every factor. Model values can vary between requests, especially near a decision threshold.

Before acting, check the original intent and surrounding conditions. Keep preferences as preferences, preserve valid prohibitions, and verify a replacement tool's coverage before removing the instruction it would enforce.

A clean result means that none of these checks produced a finding. It does not establish that the file is complete, correct, or likely to be followed.

What the refactoring prompt carries

The prompt is built locally from the reviewed snapshot. It carries source locations, scored evidence, and a list of ranges that remain unreviewed. Copying it does not make another model request.

Your receiving agent must read the current file, reconcile findings with its context, and preserve the intended requirements. Review the resulting changes before accepting them.

What still needs context

Excerpts are scored independently and in English. Disregard does not produce a file-wide judgment about contradictions, precedence, duplication, or completeness. Extraction and language screening use heuristics and can make mistakes. A heading can affect an excerpt's meaning without being recognized as a condition.

The interface has six languages, but translated interface text does not make scoring multilingual. Refused, failed, skipped, and context-dependent excerpts contribute no scored advice to the prompt.

The source code includes the current criteria and thresholds. The API reference describes the factor ranges, screening states, and request contract.

Which rules each model still needs

Disregard scores wording. A separate study asks a different question: which rules does a coding agent follow only when the instruction file states them? The answer differs by model, so each result below names the model it holds for.

Method

• Rules. 17 rules in eight categories: model idiom, conventions the repository shows, rules a tool already enforces, behavior the agent host already asks for, arbitrary conventions, duties in another file, facts the repository does not show, and rules that contradict the repository. Each rule has one small fixture repository and one coding task. Safety, authorization and secrets rules were not tested; they are kept by policy.
• Models. claude-haiku-4-5-20251001, claude-sonnet-5, claude-opus-5-5 and claude-fable-5-1 through Claude Code 2.1.283; gpt-6-luna, gpt-5.6-terra, gpt-6-sol and gpt-6-astra through Codex CLI 0.157.1. Every model ran at high reasoning effort, from 26 to 27 September 2026 (UTC).
• Probe. Each model did each task 5 times with the rule removed from the file. A rule followed in 5 of 5 runs is likely redundant for that model: a direction, not advice to remove it.
• Contrast. Where a model fell short of 5 of 5, it did the task 20 times without the rule and 20 times with it. The rule is necessary when the 95% bootstrap interval of the difference stays above zero; otherwise it is inconclusive. Calling a rule redundant would need 20 of 20 runs without it, and no likely redundant rule has had those runs yet.

Results

The contrast ran on Haiku 4.5, Sonnet 5 and Opus 5.5 only. Fable 5.1 and the four Codex models have probe results only. One of Astra's 85 probe runs failed before starting work and is not counted.

• With the rule in the file, every tested rule was followed in 20 of 20 runs, on all three contrast models.
• Six rules were necessary on all three contrast models, and no model followed them without the rule in any of 510 runs: naming tests *.spec.js, snake_case file names, updating docs/api.md, adding a changelog entry, a port number, and a timestamp unit. These are arbitrary conventions, duties in another file, and facts the repository does not show.
• Two rules were likely redundant on all eight models: using const or let instead of var, and adding a function to the existing file instead of a new one.
• For the other rules, a larger model is not always better. Without the rule, Haiku 4.5 added no unrequested Markdown file in 5 of 5 runs; Opus 5.5 added one in 20 of 20. Sonnet 5 and Opus 5.5 threw the project's own error class in 5 of 5 runs, even when a neighbouring file threw a plain Error; Haiku 4.5 threw it in 4 to 6 of 20. Conventions that the repository shows reached Haiku 4.5 in at most 6 of 20 runs.

What these results do not show

• Each rule was tested on one task. A model that follows a convention here may not on a rarer task, where the rule decides.
• No rule is labelled redundant, so nothing here supports removing a rule. A rule followed in 5 of 5 runs can still fail often.
• Whether an unneeded rule makes other rules less likely to be followed was not measured; one-rule fixtures cannot show it.
• Four fixtures show the convention in the repository. Results for those rules hold only while a repository keeps showing it.
• Results hold for these model identifiers, at high effort, on these dates. A model update can change them. The Codex runs had the account's apps and plugins available; their effect was not measured.
• The study's harness and run records are not part of this repository.

Where this is going

The aim is to tell a file's owner, for the models that read the file, which rules those models already follow unprompted and which ones they still need. A rule is only a candidate for removal when every model that reads the file, including small models used for subagents, follows it without being told. Disregard does not do this yet: today it reviews wording only.

Back to Disregard · Source · Privacy · Terms