Nous Research · The Hermes journey

Methods · Adversarially verified transformation

5×2×3: engineering agreement you can inspect

My architecture for separating analysis, production, and judgment—so a convincing answer never becomes its own proof.

By Axl Ibiza, MBA · Public source companion · September 2026

01 / 5

Five regional analyses

Five analysts examine pinned regions and make explicit claims about boundaries, consumers, and a candidate extraction. The shared source is fixed; the judgments are separate.

02 / 5

Five independent witnesses

A second set examines the same regions independently. Witness agreement is evidence to examine, not a substitute for the underlying source or a guarantee of correctness.

03 / 5

Five regional adjudications

Conflicting claims are rechecked against the source. The result is a constrained consensus contract that states what may change and what must remain true.

04 / 5

One implementer per accepted slice

Implementation proceeds from the accepted contract. Keeping the slice bounded makes the transformation and its verification legible.

05 / 5

Two fresh reviewers per slice

Correctness and adversarial review examine the committed change. Both must approve. A rejection returns the slice for correction and review; the producer does not grant its own acceptance.

5 → 5 → 5 → 1 → 2 describes the published sequence; it is not thirty interchangeable runs. Implementation and final review repeat per accepted slice. Read the source discussion →

An explanatory companion to Axl Ibiza, MBA’s published All Gods Must Die (August 2026). Campaign results below are historical reports from that edition. Scholarly context is identified separately; the original paper remains available in full.

The problem begins before the code changes

A large refactor can fail while every participant believes it succeeded. An analyst misunderstands a dependency. An implementer follows that analysis faithfully. A reviewer reads the same explanation and confirms the same mistake. Three approvals may represent one assumption traveling through three voices.

I developed 5×2×3 to interrupt that chain. Its central design decision is to separate the people or agents who propose a transformation from those who can accept it, and to make their claims answerable to a pinned artifact. Analysis is independent before it is reconciled; implementation follows an agreed contract; acceptance combines mechanical checks with fresh review. This is the decomposition method published in All Gods Must Die: Adversarially Verified Transformation. Read the definition and method, pp. 7 and 24–27.

The practical question is precise: what must remain true when a load-bearing system changes, and who has independently established that it remains true? A diagram of agents is only useful when it explains that authority structure.

Read the geometry as a sequence

The published decomposition has five regional analyses, five matching adversarial cross-checks, and five regional adjudications. It then proceeds through one blind implementer and two fresh reviewers for each agreed slice. The useful visual sequence is 5 → 5 → 5 → 1 → 2, with the final two stages repeated as the campaign produces further slices. It is not a multiplication giving a fixed total of thirty agents. Method and cost accounting, pp. 24–27, 31.

Stage What becomes visible What remains independent Condition for advancing
Five regional analysts Definitions, state, consumers, dependency clusters, candidate extraction windows Each analyst investigates a pinned region A written, inspectable regional analysis
Five adversarial witnesses A second account of the same regions and potential failure paths The matching first analysis is withheld until the witness has written its own Differences are made explicit
Five regional adjudicators Both accounts and the actual pinned source Claims are re-checked against source rather than resolved by confidence An agreed slice contract and a blocked-work list
One implementer per slice The agreed contract, original bytes, destination, and required checks Witness reasoning is withheld A bounded change with its verification evidence
Two fresh reviewers per slice The actual committed change and its evidence Reviewers do not see each other’s verdict or an expected verdict Both approve; either rejection returns the slice for repair

Each transition changes who can see which evidence and who can authorize the next step. That information structure gives the method its meaning.

The first product is a map

Before a function moves, the method needs a reliable account of the system around it. Five line-range regions distribute the reading burden. Those regions are investigation boundaries, not a decision that the final architecture should contain five modules. A coherent responsibility may cross a regional boundary; the analysis must preserve that fact.

The published regional deliverables include an inventory of definitions with exact spans, a map of cohesive clusters and dependencies, and a census of external consumers. They also include a candidate extraction window, a hash of that window at the pinned commit, and a census of overlapping open work. These artifacts answer different questions: what exists, what belongs together, who depends on it, which bytes are proposed to move, and who else is changing them. Regional analysis, p. 25.

From scattered records to meaningful constellations

The published method explicitly calls for a cluster map: cohesive groups of definitions sharing state or responsibility, with dependencies within and across the five regions. It then selects a leaf cluster with few outside dependencies as an extraction candidate. Clustering here has an inspectable criterion and a concrete purpose: discover a boundary that can become a safe unit of change. The paper specifies these outputs; it does not name a machine-learning algorithm for producing them. Exact regional deliverables, p. 25.

Machine-learning context. Cluster analysis is a foundational unsupervised-learning task: grouping unlabeled observations by an explicit notion of relatedness. The scikit-learn clustering reference describes that broader technique. Here, the primary artifacts establish source-guided cluster maps and independently checked extraction boundaries. They do not identify a fitted statistical model, a named clustering algorithm, or a measured accuracy score. The methodological relationship is useful; the implementation claim must remain narrower than it.

The public campaign record shows this terminology doing real coordination work. My August 5 web-server update enumerates seven open extraction PRs, one per cluster, with named responsibilities such as model assignment, gateway topology, managed files, and messaging. My August 6 compressor update records fifteen load-bearing clusters, a five-lane first-pass agreement, and a specific candidate window, then states that the blind cross-check and collision census are being dispatched. Those are different stages of work: the second record establishes a reported analysis result and next gate, not a completed extraction.

The distinction between discovery and binding matters. Similarity can suggest that two records belong together. It does not by itself establish a dependency, shared root cause, or completed fix. Those claims need source inspection and explicit evidence. The paper carries this logic into the issue and PR layer through its interlock model: work, ownership, dependencies, credit, and closure receive explicit public relationships. Its security-series discussion explains why related fixes must expose their collective closure argument and remaining gaps. Interlock model and security-series example, pp. 15–16.

This is why graph composition matters to my work. A file’s contents alone cannot establish a safe extraction. Imports, shared state, tests, patches, neighboring PRs, and issue ownership all constrain the move. The graph includes both runtime dependencies and the human coordination needed to preserve them. The onsite interlock visualization recovers the latter from actual repository records and linking comments. Its visible lines represent captured source links; proximity on the screen helps exploration but does not establish a new relationship.

Blinding changes the evidence available

The second pass is deliberately adversarial. It is asked to look for failure classes that a plausible extraction can conceal: ineffective patches, import-time faults, missing globals, incomplete consumer counts, and collisions with work already in flight. Its value is that it must produce an account before borrowing the first account’s conclusions.

Blinding here is an information constraint. It reduces opportunities for anchoring on another lane’s interpretation. It does not make shared training data, shared model limitations, or shared specifications disappear. Two independent contexts can still make the same mistake. My paper explicitly discusses correlated judgment and treats agreement as a gate paired with a mechanical evidence layer. Threats to validity, pp. 31–32.

Scholarly context: agreement has several meanings

Zheng and colleagues’ Judging LLM-as-a-Judge examines position, verbosity, and self-enhancement biases as well as reasoning limitations. Its experiments concern evaluation of assistant responses and human preferences; they do not establish a defect-detection rate for this Hermes method. The relevant connection is methodological: the presentation of an artifact can influence a model’s judgment, so judgment needs both information controls and checks external to that judgment. Zheng et al., 2023.

My paper discusses agreement coefficients but reports no population estimate of inter-rater reliability. Two approving reviews on a slice are an operational acceptance condition, not a measured probability that the slice is correct. That distinction matters when interpreting the visual journey: the diagram shows which gates were specified, while actual campaign records establish which gates ran on a particular change. Related work and limits, pp. 19, 32, 56.

Consensus is adjudication against the artifact

The adjudicator receives both regional accounts and verifies load-bearing claims at the pin. Disagreement becomes work to resolve. It is not settled by choosing the more fluent explanation, averaging conclusions, or granting the orchestrator an informal deciding vote.

The published decision order gives existing overlapping work priority, then considers module-state entanglement and the dependency structure of candidate leaf clusters. A technically attractive extraction may therefore remain blocked because another contributor is already changing the same window. This is a meaningful result: the campaign has discovered a coordination constraint before turning it into a merge conflict. Consensus, pp. 25–26.

The consensus contract narrows what implementation may do. It identifies the slice, its source window and destination, its byte evidence, its execution order, and blocked alternatives. The implementer can reason about the contract and perform the move without being supplied the witnesses’ entire chain of persuasion.

Acceptance has two different layers

The mechanical layer checks propositions that can be made reproducible: moved-byte identity against the pin, name identity across the public seam, compilation, and relevant behavior. Fresh reviewers inspect whether the transformation and its evidence actually satisfy the contract. Neither layer replaces the other. Extraction and re-review, p. 26; seam qualification, p. 54.

An explanatory acceptance expression is:

Accept a slice = byte fidelity ∧ seam evidence ∧ required checks ∧ correctness approval ∧ adversarial approval.

This is a reading aid for the published method, not a statistical model or a claim of complete formal verification. In particular, a byte hash says nothing about an untested external dependency. A reviewer’s approval cannot repair a failed identity check. And a test suite may give false reassurance if its patched function is no longer on the real execution path.

Either reviewer’s rejection closes the acceptance path. Repair produces a revised artifact and returns to review. The orchestrator coordinates delivery and records the outcome; it does not certify its own coordination as independent analysis. The method therefore has an explicit place for dissent and an explicit route back from it. Re-review and authority, pp. 26–27.

What the historical record actually shows

The August 2026 paper documents seven defect classes across its decomposition and interlock work. Reading the detailed ledger matters: four entries identify the adversarial second review, two identify consensus checking, and one identifies direct verification of a propagated citation. Those are different mechanisms and deserve separate credit. Defect ledger, pp. 30 and 58.

Recorded finding Where the paper says it was caught Why it matters
A patch no longer reached the extracted collector Adversarial review Green-looking tests can exercise the wrong object
Eager access introduced a circular-import crash Adversarial review Moving unchanged text can change initialization behavior
An extracted module lacked an imported global Adversarial review An error path can fail after the happy path passes
A re-export exposed more names than agreed Adversarial review The implementation can drift from a sound contract
An open-PR census counted six where twelve existed Consensus adjudication Incomplete coordination evidence changes the safe plan
Recommended windows overlapped active PRs Consensus live check Current work can invalidate an earlier extraction choice
An unsupported precedent spread across seventeen issue bodies Direct verification Repetition is not corroboration

These findings are evidence that distinct checking stages found concrete defects in this campaign. They are not a controlled estimate of how much better 5×2×3 performs than another review process. The paper describes one repository and one model-family setting and explicitly qualifies its evidence as directional rather than causal. Limitations, pp. 32 and 56–57.

Why the method extends beyond a single PR

The output is more than a moved function. Each slice remains connected to its problem issue, campaign, neighboring work, credit, and verification record. A reviewer can inspect a local diff; an interlocked campaign explains why that diff exists, what it depends on, and what remains unfinished.

This is the larger contribution I want readers to see. I am designing systems of evidence around systems of code. The method gives uncertainty a place to become explicit, objections a route to affect the artifact, and future contributors a record they can inspect rather than a story they must trust. Interlock and shared architecture, pp. 15–16 and 52–54.

The next chapter follows that structure into the code itself: Godfile decomposition—how and why. The companion code-review chapter examines what rigorous participation looks like at the review surface.

Sources and reading

  1. Ibiza, Axl, MBA. (2026). All Gods Must Die: Adversarially Verified Transformation. August 2026 edition, 68 pages. Method: pp. 24–27; defects: pp. 30, 58; limitations and claim refinements: pp. 31–34, 53–57. Read onsite · Original PDF.
  2. Zheng, L., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS Datasets and Benchmarks. Primary paper, arXiv:2306.05685. Used here for contextual analysis of model-judgment bias, not as validation of Hermes campaign outcomes.
  3. NousResearch/hermes-agent, issue #78647. Public campaign coordination record cited by the paper. Open original issue · Inspect the onsite record. The live issue may have changed since the paper’s August snapshot.
  4. Ibiza, Axl. (2026, August 5–6). Public cluster-analysis and extraction updates on #78647. Seven web-server cluster PRs · Compressor cluster map and next verification stage. Historical source statements about the reported stage, not certification of today’s implementation.
Continue · Architecture

Twelve failures. One architectural cause.

Follow the twelve issue classes into a common authority model—and back out through the proof required at each boundary.

Continue · Godfile decomposition

Make the system legible. Preserve its behavior.

Why concentrated responsibility becomes a liability, and how a controlled extraction earns its equivalence claim.

Continue · Code review

Review the claim. Follow the boundary.

Public examples of technical scrutiny: identity, recovery, type continuity, tests, and contributor credit.