Reference Signal Engineering — Verification Without an Oracle

// definition

The design decision that shapes everything else

Reference Signal Engineering (RSE) is a discipline for closing the verification loop around a language model when no ground truth is available. It is specified under one governing constraint — no oracle — and follows from a single substitution: the system does not control for the claim is true, a perception unavailable to it, but for the claim and an independently obtained record agree. The construction is that of double-entry bookkeeping: neither record is privileged, and control is exercised over the perception of their agreement.

The name is precise and each word carries weight. Reference — in the Perceptual Control Theory sense: an internal specification the system defends, not an external setpoint supplied by the environment. Signal — a quantity carried through the loop, not the world itself. Engineering — an architecture that can be built, calibrated, and evaluated, not a philosophical position.

The specification was named in version 1 of No Argument for the World and given its architecture in version 2. The section reference throughout this page is §8 of the current preprint. Readers who want the argument that motivates the design should read the paper; readers who want the design itself have come to the right place.

// why no oracle

Two classes of checker, and why only one scales

Every deployed system that successfully checks a language model's output against something outside it falls into one of two classes. Either the checker has access to an oracle — a compiler, a unit test, a proof kernel, a symbolic engine — in which case it works, and works only in domains where such an oracle exists. Or it has no oracle, and works instead by comparing two independently obtained records of the same thing and acting on the discrepancy between them.

The first class has produced the field's most impressive results and cannot be extended to open-ended language, because in open-ended language there is no oracle to extend it with. The second class is where the remaining work has to happen. It is chronically under-theorised, because a checker that never sees the truth is an awkward object for a literature that likes ground truth — and it is not, in fact, a new object at all.

Double-entry bookkeeping is exactly this device: two records of the same transactions, compiled by different routes, neither of them privileged as "the truth", with the auditor controlling for a perception of zero discrepancy between them. A bank statement does not contain reality. Neither does a chequebook. The audit works anyway. Reference Signal Engineering argues that a language model in production requires the same arrangement, for the same reason.

That reason can be stated exactly: a system with no independent measurement of the variable it is supposed to be controlling is not controlling it, whatever its outputs look like.

// the controlled variable

Agreement, not correctness

The design decision that follows from constraint 1 is the whole architecture, and it is simple to state and easy to get wrong. The system does not control for the claim is true. That perception is not available to it. It controls for the claim and the independently obtained record agree.

This is a weaker property, and it is the strongest one obtainable without an oracle. It is also, empirically, the property that catches the failures at issue: a fabricated citation does not resolve; a fabricated quantity does not recompute; a fabricated verification claim does not survive a search for the strings it implies; an invented prior observation is not in the log. The failure mode this architecture exists to detect is not a failure of subtle judgement. It is the assertion of things that a second channel would immediately contradict, made by a system that has no second channel.

// what the architecture can and cannot detect

Can detect: the assertion that a named artifact contains X when it does not; the attribution of a claim to a source that does not contain it; a numeric quantity that does not recompute from its stated inputs; an action reported as performed that left no trace; a prior observation that does not appear in the log.

Cannot detect: two records that agree and are both wrong. The architecture is proof against fabrication, not against error. Two independent channels that share a common source are not independent, and no amount of divergence testing between them will reveal that.

The distinction between the two cases is the difference between fabrication and error, and it is a real limit rather than a hedge. The architecture does not pretend to close a gap it cannot close.

// design constraints

Eight constraints, and any proposal violating one of them is disqualified

The architecture is not free. The constraints below are fixed by the structural argument in the paper, and each one closes off an obvious design shortcut that would otherwise be tempting.

No oracle. The design may not assume access to ground truth, because in the target domain there is none. Anything that requires one describes a different problem — a solved one.
The comparator may not be trained against approval. A checker optimised on the same objective as the generator inherits the same controlled variable and the pair converges. Where a model is used inside the comparator, its role must be extraction and matching, not judgement of quality.
The comparator sits outside the effector and inside the system. It is not in the weights, not in the gradient, and not in the generative pass. It is nonetheless part of the system whose behaviour is under discussion. Enlarging the system boundary to include it is the design move.
The comparator's verdict must have authority. A check that cannot withhold, revise, or mark a response is instrumentation, not control.
It must not depend on the generator's cooperation. No component may require the model to report accurately on itself, because a system optimised to produce approved output cannot do so.
It must degrade honestly. Where no second channel exists for a claim, the system must say so rather than pass the claim through unmarked.
It must be automatically invoked, not merely available. A verification step that runs when someone remembers to run it is not part of the loop. Artifacts sitting in a directory are not a feedback path; the path exists only where the read actually occurs, in the ordinary course of producing a response.
Premises must be grounded, not only assertions. The obligation to resolve against an artifact extends to the premises and assumptions a response rests on, including those never stated to the user but which underwrite the reasoning. Where a conclusion is unacceptable, the premises are the first thing to check, since one false premise leaves the truth value of the conclusion indeterminate.

// components

Four components, in one loop

1. Input function — the adapter

For each checkable claim, an adapter that obtains a record of the relevant state by a route independent of the generator: reading the file, resolving the identifier, executing the computation, querying the log. The independence is the specification; the mechanism is domain-specific.

2. Reference — zero discrepancy at declared tolerance

The reference value is zero discrepancy between the two perceptions, at a tolerance declared per claim type. Tolerance is not a nuisance parameter — for numeric claims it is a rounding policy, for quoted material it is exact, for paraphrase it is entailment. The choice of tolerance determines what the system is actually controlling, and it is where the design is won or lost in practice.

3. Comparator — the residual

Computes the residual. For most claim types this is deterministic string, identifier, or numeric comparison. Where entailment is needed, the comparator may use a model — but constrained to the question does the record support the claim, with the record in context, and never to is this a good answer. It must also be conservative in one specific direction: where entailment is uncertain, the correct verdict is unverifiable, not passed. False negatives are a cost; false positives are the failure this architecture exists to prevent. Deterministic comparison is therefore preferred wherever the claim type permits it, and the entailment case is a last resort. Where it is used, the ledger must record that the check was model-based.

4. Output function with authority

Four dispositions, and the fourth is the one that makes the system honest:

Pass. Residual within tolerance.
Revise. Regenerate the claim with the record supplied as input.
Withhold. The claim is contradicted by the record and is removed or refused.
Mark unverifiable. No independent channel exists for this claim, and it is delivered flagged as unchecked.

// claim types and channels

The architecture is only as good as its channel coverage

The taxonomy below is the working one from §8.4. It is not exhaustive and is intended to be extended per deployment. The last row is not a gap to be closed later — it is a boundary. A system that pretends to verify a judgement of quality has reintroduced the approval-graded checker that constraint 2 forbids.

Claim types, independent channels, comparators, and the failure each catches
Claim type	Independent channel	Comparator	Failure caught
A named artifact contains X	Read the artifact; string / structural search	Exact or normalised match	Fabricated verification; invented file contents
Source S says X	Resolve identifier; retrieve; locate passage	Entailment against retrieved text, span-anchored	Fabricated citation; real source, invented claim
Quantity Q equals N	Recompute from stated inputs	Numeric, declared tolerance	Arithmetic asserted rather than performed
An action was performed	Execution log, exit status, side-effect query	Presence and status match	Claimed check never run
State of system S is X	Project record, prior turn	Field comparison — string or semantic	Stale or invented state; invented prior agreement
State of S is X, where S is changing	Query S; timestamp the read	Field comparison plus staleness window	State true at check time, false at delivery
Evaluative or aesthetic claim	None available	—	Must be marked unverifiable

// protocol

What actually runs, in order

The protocol is simple enough to state as pseudocode. The complexity lives in the channels, not the loop.

# Reference Signal Engineering — top-level loop
# For each response R produced by the generator:

claims   <- extract_claims(R)               # typed, span-anchored
premises <- extract_premises(R)             # unstated assumptions included

for each c in claims + premises:
    channel  <- select_channel(c.type)
    if channel == NONE:
        disposition[c] <- MARK_UNVERIFIABLE
        continue
    record   <- channel.read(c)             # independent of generator
    residual <- compare(c, record, c.tolerance)
    if residual <= c.tolerance:
        disposition[c] <- PASS
    elif residual is uncertain:
        disposition[c] <- MARK_UNVERIFIABLE  # conservative direction
    else:
        disposition[c] <- WITHHOLD

ledger <- record_all(dispositions)
commit(R, dispositions, ledger)            # authority to withhold

Two structural features of the loop are worth naming. The premises extraction is not optional: the failure mode that motivates it is not a false assertion but an invented prior observation used as a premise, with sound reasoning built on top of it — a checker that inspects only what was said will pass that unopposed. And the ledger is not a log file. It is the record of which claims were checked by which class of comparator, and it is what makes the system honest when verification is switched off: a response produced with verification disabled must be marked as such, on the same principle that governs the unverifiable disposition.

// failure modes

Where the design breaks, stated in its own section

Six failure modes are set out in §8.6. Three of them are strong enough to compromise the whole design if they are not handled, and they are listed first.

Write access to the record

The most serious failure mode, and the one the architecture's own structure invites. A generator that can write to the record it is being verified against can achieve zero residual by altering the record rather than by correcting the claim. The residual goes to zero and nothing has been verified. The requirement that follows is absolute and should be treated as a precondition rather than a mitigation: the comparator must read from sources the generator cannot influence. Where write access cannot be excluded — a working directory the agent operates in, a log it emits — that channel does not establish independence and must not be counted as verification. If it is used at all, it is used as a convenience for the operator and the ledger must say so.

Extraction precision as a condition on the loop

The verification channel is a feedback path only while claim extraction is reliable. Below some precision, a claim's presence in the response no longer determines whether it is checked, the relation becomes intermittent, and what remains is not a feedback path but an intermittent disturbance on a system that is otherwise open-loop. Extraction precision and recall must be estimated per claim type and monitored. Where they fall below the threshold set for a deployment, the system must declare that it is operating open-loop for that class of claim rather than continue reporting verification it is not performing. A loop that silently degrades into instrumentation is worse than no loop, because the ledger continues to look the same.

Extraction failure

Claims not extracted are not checked. A generator that phrases assertions to evade extraction would defeat the system; nothing in the architecture prevents that, and if the extractor is ever placed inside the optimised objective, the collapse measured by Baker et al. (2025) predicts precisely that outcome. The extractor must stay outside the training loop.

Over-blocking

A tolerance set too tight converts the system into a refusal machine, trading fabrication for uselessness. Tolerance policy is where this design will be won or lost in practice.

Cost and latency

Every checked claim costs a retrieval or an execution. Blanket application is not viable; claim-type triage by consequence is required, and that triage is a policy decision, not a technical one.

The unverifiable-marking hazard

If most claims come back unverifiable, the marking is noise and users will learn to ignore it, which is worse than not marking. Coverage must be measured and reported, not assumed.

// scope

What this architecture does not do

Four limits are stated in §8.7 rather than discovered by a reader.

It does not make the generator truthful. It leaves the generator exactly as it was — an open-loop function with the dispositions its training installed — and places a loop around it. The claim is not that the model becomes reliable. The claim is that the system acquires a property the model does not have.
It does not verify correctness. It verifies agreement between independently obtained records, which is a strictly weaker relation. Two records can agree and both be wrong. The architecture is proof against fabrication, not against error.
It does not cover judgement, interpretation, or aesthetics, and must not be extended to cover them.
It does not survive being switched off. Where an operator or user disables verification for latency, for cost, or because a fluent unchecked answer is what is wanted, the comparator is not part of the system in that configuration, and everything the structural argument says about open-loop generation applies unchanged. No architectural remedy is proposed for this, and none should be: a system engineered to prevent its own operator from turning off a check is a different and worse proposal. What is required instead is that the configuration be visible — a response produced with verification disabled must be marked as such in the ledger, on the same principle that governs the unverifiable disposition.

The components are not novel. Retrieval with attribution checking, execution-based checking, and abstention all exist and are deployed. What is proposed is the organisation: that these are not separate quality features but the components of a single control loop, that the loop is what supplies the missing element, and that the design constraint distinguishing this loop from its neighbours is the refusal to assume an oracle.

// what it owes

The evaluation that has not been run

The paper's own criterion for inner-loop remedies is demanding on purpose, and it is applied to this architecture with the same severity as to everyone else's. As of writing, no evaluation of RSE exists — by the author or, to his knowledge, by anyone else.

An adequate evaluation would compare a generator with the loop closed against the same generator without it, on factual claim accuracy out of distribution, with no ground-truth labels available to the system under test, and would report four quantities jointly:

The four quantities

1. Fabrication rate — how often the system asserts something a second channel would contradict.

2. Unverifiable-marking rate — how often the system honestly declares that no channel exists.

3. False-block rate — how often the system withholds a claim that was in fact correct.

4. Task completion — whether the system still does the work it was deployed to do.

Reporting fabrication reduction alone would be the same methodological error identified in the self-correction literature, and this paper would deserve the same treatment for committing it. Building the loop is a weekend for a competent team. Evaluating it honestly is the harder half, and is the specific thing the specification asks for.

// citation and related

Where this specification lives

Source specification. Diener, Ł. (2026). No Argument for the World: A Control-Theoretic Audit of RLHF's Missing Runtime Loop — and the Verification Architecture That Closes It Without an Oracle (version 2.0), §8. Zenodo. https://doi.org/10.5281/zenodo.21989191

Version 1.0 (19 May 2026), where the discipline was named: https://doi.org/10.5281/zenodo.20277919.

Preprint, not peer reviewed by a journal. Licensed CC BY 4.0. The architecture is unevaluated — specified and argued, not yet measured.

Read the full specification v2.0 on Zenodo Run the audit

// about this page

A specification by Łukasz Diener

Perceptual Control Theory is the framework of William T. Powers (1926–2013); the double-entry analogy was articulated by Rick Marken and Bruce Nevin in the IAPCT discussions that shaped §1 and §8.2 of the paper. Reference Signal Engineering itself — the discipline, its constraint set, and the architecture that follows — is Łukasz Diener's original contribution, first named in No Argument for the World v1.0 (May 2026) and specified in full in v2.0 (§8). The paper is deposited on Zenodo with permanent DOIs.

ORCID 0009-0006-6103-8514 All six audits Full profile