The method

Disensor is the reference implementation of a method: controlled disagreement. This page explains the idea. The exact contract, with the schema keys, the enums and the validator rules, lives in the reference and the filling guide.

The problem

A coding assistant reviewing its own work shares that work’s blind spots. Asking it to self-critique produces self-critique, not review: the assumptions it missed while writing are the same ones it misses while re-reading.

The method’s answer is to decorrelate. Let a model from another family attack it, one whose training and failure modes are different. Capability is not what makes it useful here. Failing somewhere else is.

The cycle

1. Generate. A model produces the plan or the diff.
2. Attack. A model from another family reviews it with an adversarial brief whose hash is recorded: anyone can recompute it and see what the reviewer was actually asked.
3. Verify. The generator checks every finding against the repository or the execution and drives it to a terminal state: incorporated, debt recorded, owner decision, refuted, or escalated without resolution. A verifiable refutation has to bring evidence; an interpretive one has to be looked at by a human.
4. Declare. The cycle closes when every finding reached a terminal state.

The interesting step is the third one. A reviewer’s finding is not automatically true: it may be a false positive, and the method demands that a refutation bring evidence, not opinion. When the refutation is interpretive rather than verifiable, the artifact forces a human to look at it.

That demand belongs to the method. How far the validator enforces it changes with each schema version, and the known limits are declared in the reference: not everything the method asks for is something a machine can check.

The residue declaration

What the tool defines and enforces is the artifact the cycle ends with: a JSON file versioned in the repository, next to the code it judges.

It records the actors and their family, every finding with its terminal state, the event’s metrics, and the residue, which is the block that gives the whole thing its name. Residue is what the cycle could not close by itself and rests on someone’s judgement.

Why residue and not coverage

This is the design decision that orders everything else.

An artifact reporting coverage would read as a seal of quality, and a seal of quality is an invitation to stop looking. The declaration lists what the cycle could not close by itself, by name and with whatever evidence exists. It aims the human reviewer’s scrutiny at the points where the cycle fell short.

Residue is wider than “what was left open”. A finding the generator refuted with evidence is closed, and still enters the residue, because the refutation is the principal’s over the reviewer’s and someone has to be able to audit it. The residue has three classes: escalation without decision, principal refutation and execution gap. The residue/v0.4 schema adds two more for the degraded modes, reviewer_correlation and reviewer_hardening_gap, which record the reviewer’s limitations rather than the code’s.

That has a cost the method accepts on purpose: an honest declaration can look worse than a false one. More automation would not fix it, so the method states it instead.

The limit

The validator detects the empty field and the generic marker. It does not detect the false declaration, and no tool can. Someone has to open merged pull requests at random and read them.

The gate also runs inside the workflow it audits. No code of its own crosses that boundary; the platform and the deployment do. Five controls are required, not suggested:

1. A strict required check, or a merge queue.
2. CODEOWNERS over the effective configuration and over .github/workflows/.
3. A ruleset or required workflow defined outside the audited repository.
4. Pinning the Action by SHA rather than by tag.
5. An administrative bootstrap, because the first pull request that adds the gate cannot make itself the root of trust.

The reasoning behind each one is in deployment requirements.

The paper

Rocchia, N. (2026). Desacuerdo controlado: revisión adversarial automatizada con un segundo asistente de código en el desarrollo de software. DOI 10.5281/zenodo.21633495.

The paper’s terminology is Spanish; the schema contract and the CLI have been English since v0.2. The reference includes the glossary that maps one to the other.