Skip to main content

​
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.
Assurance rule: Never let the artifact under test participate in defining its own truth.

​
The pattern

For trust-bearing contracts, WalletWall prefers this validation shape: rather than relying only on:
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.
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.
This distinguishes incidental correctness from declared correctness:
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: 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.