6 Sensor Trust: Evidence and Review

6.1 Start With the Decision

A sensor reading should not trigger action until its source, age, quality, and limits can be reviewed. Trust begins with visible evidence.

6.2 Route Overview

This is part 1 of 4. Continue with Sensor Trust: Production Records.

6.3 Part Objectives

• Review a sensor claim using provenance, freshness, and quality evidence.
• Set a bounded action and retest rule for uncertain readings.

6.4 Chapter Roadmap

• Begin With One Report You No Longer Trust
• Start With Trust That Must Be Earned Again
• In 60 Seconds
• First Step: Keep Trust Evidence Reviewable
• Minimum Viable Understanding
• Prerequisites
• Trust Implementation Scope
• Trust Review Loop
• Trust Evidence Record
• Observation Evidence
• Trust Update Evidence
• Bounded Trust Actions
• Worked Review: Forwarding Trust Gate
• Common Mistakes
• Knowledge Check
• Matching Quiz
• Ordering Quiz

6.5 Begin With One Report You No Longer Trust

Picture a relay node that has missed some forwards. One odd event may come from a weak link, a full queue, a low cell, or harmful action. The first choice is not whether the node is good or bad. It is which current evidence may change one bounded decision.

Write the expected act, the observed act, the count, the time span, and the related checks. State how the trust value may move. State which route or data choice it may affect. Then try a safe test. Use another path, ask for a fresh reading, or wait for a known good event. Keep a way for sound new evidence to restore the node.

Fast blocking can protect a service, but one false label may cut off an honest weak node. Slow action can avoid a false charge, but it may let bad data spread. A score may aid rank, but it does not prove motive. This first pass does not supply one rule for every site. Use the Practitioner layer to build the evidence record and bounded action. Use the Under the Hood layer to inspect updates, stale state, linked faults, attacks, and recovery. Those routes keep trust open to proof and repair.

6.6 Start With Trust That Must Be Earned Again

Trust management starts when the system can no longer treat every node report or relay action as equally reliable. The goal is not to punish a node from one odd reading; it is to update confidence from observable cooperation, contradiction, recovery, and repeated behavior.

Use this chapter to keep the trust rule tied to evidence. Each trust change should say what was observed, how confidence changed, what action is allowed, and what would restore or reduce trust later.

6.7 In 60 Seconds

Trust management turns behavior evidence into cautious decisions about whether a node, route, or observation source should be relied on. A useful trust decision does not guess motive. It records expected behavior, observed cooperation evidence, related checks, a local scoring rule or label, the bounded action, and the retest trigger that could change the decision.

This chapter is about implementation decisions, not a universal trust algorithm. The safest design is reviewable: the system should be able to explain why trust changed, which decision was affected, and what evidence would restore, revise, or escalate the trust state.

6.8 Learning Objectives

By the end of this chapter, you will be able to:

• Identify the evidence a trust-management rule needs before it affects routing or data acceptance.
• Separate observation evidence, trust state, action boundary, confidence, and retest trigger.
• Explain why local trust thresholds must be documented as configuration rather than universal facts.
• Choose bounded trust actions that protect the affected decision without overclaiming intent.
• Review a trust record for missing evidence, stale assumptions, or action that is larger than the evidence supports.

6.9 First Step: Keep Trust Evidence Reviewable

6.10 Minimum Viable Understanding

Trust is a current decision state based on evidence, not a permanent identity for a node. Cooperation evidence must be tied to an expected role such as forwarding, acknowledging, sensing, or corroborating, and the rule must preserve the observations and related checks behind its decision. A bounded action may reduce reliance, request corroboration, avoid one route, or keep the record open. Every trust decision also needs a retest trigger capable of confirming, changing, or clearing the current state.

6.11 Prerequisites

• Sensor Node Behaviors: Taxonomy: behavior labels used by trust review records.
• Sensor Node Behavior Classification: evidence-first classification before trust action.
• Selfish & Malicious Nodes: cooperation and active-disruption evidence.
• Dumb Nodes & Recovery: conservative handling for limited diagnostic evidence.
• Mine Safety Case Study: a decision context where visible trust evidence matters.

6.12 Trust Implementation Scope

Trust management is most useful when a system needs to decide whether to rely on a node or path for a specific purpose. In this module, keep the scope narrow:

• forwarding and acknowledgement evidence for route choice;
• plausibility and corroboration evidence for accepting sensor values;
• freshness and identity evidence for deciding whether a record is current;
• confidence notes for cases that remain suspect or unknown;
• retest conditions that keep the decision reversible.

The chapter does not assume a single correct formula, tool feature, or network policy. A local system may use labels, scores, rule checks, or a combination of them. Whatever the rule is, it should be documented well enough for a reviewer to trace the decision back to observable evidence.

6.13 Trust Review Loop

The trust review loop starts with an expected role and ends with a bounded action plus a retest trigger. It is deliberately slower than an automatic “bad node” label because trust errors can remove useful evidence or hide unresolved uncertainty. Follow Figure 6.1 before changing reliance on a node or path.

Read Figure 6.1 from expected role to observation record, comparing what the node or path should have done with messages, acknowledgements, route behaviour, or readings actually observed. Check schedule, role, stale data, link conditions, and related nodes before applying the local rule that changes a label, score, or confidence. The bounded-action stage states which decision changes and which decisions remain untouched. Finish with the evidence that will reopen, clear, or escalate the record. This order keeps the trust update tied to a specific use rather than turning it into a universal judgement about the node.

6.14 Trust Evidence Record

A trust decision should leave behind a compact record. The record is not a log dump; it is the minimum review material needed to understand and challenge the decision later. Inspect Figure 6.2 so the decision context and expected role remain connected to cooperation evidence, policy, and the response boundary.

Read Figure 6.2 from decision context and expected role into observed cooperation, establishing which route, data path, or validation choice depends on what forwarding, acknowledgement, sensing, or corroboration duty. Related checks capture ordinary explanations and peer observations before local policy assigns a label, score band, or confidence. The action boundary states what may change and where it must stop, while the retest trigger names evidence that restores, revises, or closes the decision. If scores are used, record their local rule and inputs; neither a score nor a local threshold proves intent or defines a general property of sensor networks.

6.15 Observation Evidence

Trust evidence should be tied to a role that the node was expected to perform. Useful observations include:

• a message that should have been forwarded or acknowledged;
• a route participation claim that can be compared with related evidence;
• a reading that agrees or disagrees with other current observations;
• a missing or stale record that affects the decision;
• a recovered record that changes confidence in earlier evidence.

Observation evidence is strongest when it separates absence, contradiction, and non-cooperation. A missing acknowledgement may support a suspect state, but it does not by itself prove selfish or malicious behavior.

6.16 Trust Update Evidence

A trust update is the point where evidence becomes a decision state. The rule can be simple, but it should be inspectable:

• What evidence source is allowed to change trust?
• How recent must the evidence be for the current decision?
• Does related-node evidence support or weaken the update?
• Does the update reduce confidence, change a label, or change an action?
• What uncertainty remains after the update?

This is where many weak trust systems fail. If the implementation changes route behavior without preserving the observation record, reviewers cannot tell whether the action was justified, too broad, or based on stale context.

6.17 Bounded Trust Actions

Trust actions match the evidence. The system may request corroboration before accepting a reading, prefer a path with stronger cooperation evidence for the affected route, or avoid relying on a suspect node for shared work while review remains open. It may mark a source unavailable for the current decision rather than hide the gap, or leave trust unchanged when evidence is too thin. None of these outcomes justifies permanent exclusion by default: the action states exactly what changes and which future evidence could change it back.

6.18 Worked Review: Forwarding Trust Gate

Scenario: a node is expected to relay messages for a path, but the review record shows inconsistent cooperation. The node still reports its own readings, so the issue is not simple silence.

Concrete example: a parking-lot mesh node sends its own occupancy readings but inconsistently forwards neighboring bay-status records during the same review windows. The trust action can reduce reliance on that node for the affected relay path while still preserving its own local readings with their normal quality checks.

Evidence review

The reviewer records the expected relay role, the observed forwarding evidence, related path observations, and ordinary explanations such as schedule mismatch or changed role assignment. If evidence is thin, the trust state should remain suspect rather than selfish or malicious.

Trust decision

The local rule reduces reliance on that node for the affected route. The action does not discard the node’s unrelated sensing evidence, and it does not assign intent beyond the record.

Retest

The record names the evidence that would reopen the decision: a later relay observation under the same expected role, a corrected role assignment, or corroborating path evidence that changes confidence.

This review is useful because it protects a route decision while preserving uncertainty. It does not treat a local trust action as a universal judgement about the node.

6.19 Common Mistakes

Do not assign trust labels without recording the expected role and observations, or treat a score or threshold as proof of motive. A trust action must not spill into unrelated decisions, and a healthy or trusted state must not hide missing evidence. When scores are used, document the local policy inputs. Keep every change reversible by recording its retest trigger, and let implementation examples illustrate—not replace—the review record that explains the decision.

6.20 Knowledge Check

6.21 Matching Quiz

6.22 Ordering Quiz

6.23 Continue to the Next Part

Carry this evidence into Sensor Trust: Production Records, which begins with Sensor Behavior Production Record.