The evidence behind
a contract trigger.

An automated contract can apply its rules exactly and still act on a mistaken report. The evidence that starts the action belongs in the design: what was observed, who supplied it, and which other reports depend on the same source?

Consider a hypothetical supplier paid when a delivery is confirmed. Three reporting services send signed messages, and the payment rule accepts agreement from any two. The design looks more dependable than relying on one report. But all three services may obtain their answer from the same warehouse database. A mistaken delivery entry can then arrive with three valid signatures.

My paper with Antoaneta Serguieva, Sustainable blockchain-enabled services: Smart contracts, published in the proceedings of the 2017 IEEE International Conference on Big Data, provides a useful starting point. A public manuscript was deposited in 2018. It proposes a hierarchy of software agents and cryptographic keys for managing conditional contracts and their subcontracts. Its contract model specifies states, transitions, triggering conditions and where parameters are obtained. Agent processes can monitor both on-chain and off-chain information.

Follow the trigger back to the observation

The paper's building-contract example separates planning and building-standard approvals into stages represented by transactions. That organisation makes the source of each condition consequential: where does the approval enter the process?

Assessing an implementation also requires checking the inputs on which it acts. The proposal is a design contribution, rather than field validation of an operating service.

NIST's Blockchain Technology Overview, Section 7.3, describes the external-data problem directly. A ledger may record sensor readings or human reports without establishing that they match events outside the system. Sensors can malfunction, and people can enter false information. A delivery claim therefore needs an observation process as well as a transaction record.

For the hypothetical supplier, the relevant question is precise. Did the goods reach the specified recipient, or did a warehouse system merely mark them as dispatched? Both messages could be authentic records. Only one may satisfy the agreed payment condition.

Count independent observations

A simple calculation shows why the relationship between sources matters. Suppose three observers each make a binary classification, delivered or not delivered. Each has a ten-per-cent probability of giving the wrong answer on a case, and their errors are mutually independent. A majority is wrong when exactly two observers are wrong, or when all three are wrong.

The probability is 3 × 0.1² × 0.9 + 0.1³ = 0.028, or 2.8 per cent. Now change the arrangement: three otherwise perfect reporting services all repeat one upstream classification, which is wrong ten per cent of the time. Their majority is then wrong ten per cent of the time. Adding reporting services has not reduced that common-source error.

These figures are hypothetical arithmetic, not measured failure rates or a model of every oracle network. They isolate one assumption that a procurement specification can easily hide. Distinct signing keys and separate service names do not establish independent observations. The buyer needs to know whether the services share a sensor, a database, a transformation or an operator.

Keep the route from evidence to action

The W3C PROV Primer offers a vocabulary for describing that route. It distinguishes entities, the activities that use or produce them, and the agents responsible for those activities. Its account of derivation allows a later report to be connected to the material from which it was produced.

Applied to the delivery example, I would retain the original observation, the service that collected it, the processing steps, the resulting report and the rule version that consumed it. Observation time, report time and action time would remain separate. A newly signed report could still describe an old event or a different consignment.

This record would help an investigator locate shared dependencies and reconstruct a decision. Its own accuracy would still need checking. A provenance description is evidence about a production process; assessing the underlying observation remains part of the work.

Test the service before trusting the trigger

A proposed evaluation would hold the payment rule fixed and vary the evidence supplied to it. Cases would include independent observations, several reports copied from one source, a delayed message, a duplicate, an identifier mismatch, conflicting observations and a missing report. The expected response would be specified before each test: proceed, wait, reject or refer the case for review.

The comparison would record incorrect releases, unnecessary holds, time to resolution and the work required to resolve an exception. It would also identify who can correct an input and who authorises a subsequent action. This is a test plan, not a report of experiments already performed.

The contractual hierarchy helps organise a complicated service. Following each trigger back through its evidence helps determine what that organisation can safely automate. The useful purchase is the complete arrangement: observation, accountable reporting, conditional execution and a defined response when the evidence is inadequate.