> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletwall.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Independent Authority

> A WalletWall assurance pattern for avoiding common-mode validation errors by separating normative authority, independent oracles, and implementation artifacts.

# Independent Authority

WalletWall treats agreement as strong evidence only when the things agreeing can **fail independently**.

Two manifests, models, fixtures, or implementations can agree perfectly and still share the same assumption when they were produced from the same interpretation. That makes independence a property of **provenance**, not simply the number of artifacts being compared.

<Info>
  **Assurance rule:** Never let the artifact under test participate in defining its own truth.
</Info>

## The pattern

For trust-bearing contracts, WalletWall prefers this validation shape:

```mermaid theme={null}
flowchart LR
    S["Frozen normative source"] --> O["Independent extraction / oracle"]
    S --> A["Implementation artifact A"]
    S --> B["Implementation artifact B"]
    O --> G["Reconciliation guards"]
    A --> G
    B --> G
    G --> E["Evidence-backed result"]
```

rather than relying only on:

```text theme={null}
artifact A ↔ artifact B
```

A two-way comparison is useful for detecting disagreement. It cannot, by itself, establish which side is correct. If both artifacts share the same interpretation, even agreement may carry little new information.

## A lesson from the BigQuery contract

A useful example emerged while hardening WalletWall's BigQuery contract. The `logical_resolve_head` manifest described three writer identities, while the IAM contract described three different identities. A direct manifest-to-IAM comparison correctly showed that the two artifacts disagreed, but it could not determine the intended answer.

The frozen §9.5a per-row CAS authority provided an independent source: it required all five identities. Deriving a separate writer oracle from that normative source resolved the discrepancy and also exposed additional cases where implementation artifacts agreed with each other but not with the specification.

The useful lesson was not that comparison failed. The comparison did exactly what it could do. The lesson was that **reconciliation needs an authority neither compared artifact can influence**.

## Why a third implementation is not automatically independent

Adding more implementations does not necessarily add more evidence.

If three implementations were generated from the same interpretation, they may all reproduce the same misunderstanding. One independently derived oracle can provide more information than several mutually agreeing implementations.

WalletWall applies this principle in several places:

* canonical digest implementations are pinned to independently derived byte vectors;
* IAM and manifest declarations reconcile against specification-derived authority rather than only against each other;
* fixture expectations must be exercised by behavioral models, not merely referenced;
* mutation results are grounded in measured guard execution rather than declared expectations;
* completeness checks start from the normative contract and map forward to implementation, rather than asking implemented artifacts to define their own scope.

## The counterweight: make intent explicit

Independent authority answers **where truth comes from**. There is an equal and opposite failure mode: the system can be correct today while its correctness still depends on knowledge that was never written down.

A second BigQuery lesson made that visible. A tighter `@@row_count` provenance model stopped accepting the nearest preceding DML statement as the intended producer. The existing SQL was behaving correctly, but four operations — T7, P6, A3, and R1 — became ambiguous because multiple statements matched the same keyword and target. The old guard happened to choose the intended statement because of statement ordering. Nothing recorded *why* that statement was the intended one.

The fix was not to suppress the new guard. It was to declare the missing intent. Identity atoms such as `current_object_version_id` and `resolve_generation + 1` made the intended producer explicit and stable across harmless reordering.

<Info>
  **Counter-rule:** When a stronger guard rejects something you believe is correct, first ask what you know that the guard does not. Encode that knowledge before adding an exception.
</Info>

This distinguishes **incidental correctness** from **declared correctness**:

```text theme={null}
"It works because this statement happens to be nearest"
                    ↓
"It is this operation because these declared semantic properties identify it"
```

A broad exception says, in effect, *trust this case*. A declaration says *here is why this case is correct*.

That distinction matters during refactoring. Code can remain correct while statements, files, or execution order change. When intent is explicit, the proof moves with the behavior. When intent exists only in ordering or developer memory, a green guard may simply be preserving an accident.

Together, the two assurance principles form a useful pair:

| Question                                                | Principle                                                                                                                   |
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Who gets to define truth?**                           | Use an independent authority whose provenance is separate from the artifact under test.                                     |
| **What makes this specific behavior the intended one?** | Declare the semantic intent explicitly instead of relying on ordering, proximity, naming accidents, or unwritten knowledge. |

The practical review question is therefore not immediately *"how do we silence this false positive?"* It is:

> **What did we know that the guard did not, and why was that knowledge not encoded?**

Often, the missing declaration is the real improvement the stricter guard was asking for.

## Frozen does not mean infallible

A frozen specification is an authority for implementation conformance, not a claim that the specification can never be improved.

Freezing the contract separates two questions:

1. **Did the implementation follow the contract?**
2. **Is the contract itself sufficiently correct and complete?**

When an implementation contradicts an unambiguous requirement, the implementation changes. When the normative source is genuinely ambiguous or incomplete, that ambiguity is surfaced explicitly and resolved at the specification layer rather than silently invented downstream.

That separation keeps validation evidence interpretable: implementation correctness and specification quality remain related, but they are not allowed to define each other.