SUBTASK #63: Resolve conflicting evidence (2.2.4.2)

Open
  • Is something wrong?
#66 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@PavlockBlaine03 is already working on this.

Since Oct 30, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
72/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend, testing

Research direction

Start with the rules on issue #63 and the evidence weights and record in #64; inspect backend/services/scan/evidence.py and the signature match work in #65 before implementing backend/services/scan/resolve_conflicts.py. Run tests/services/scan/test_resolve_conflicts.py without a database or network. Done means the listed cases pass and conflict strength uses the shared count_points function.

Written by the indexing model from the issue text.

Description

backend Medium Priority subtask

What to do

A pure function that looks at all of a device's evidence and, when the evidence points to different device types, keeps the type with the stronger evidence and drops the rest from scoring (spec 7.1). Its result tells the next steps which type won and which evidence counts.

Background

  • Spec 7.1: "If evidence points to different device types, the system shall assign the type supported by the stronger evidence and count only the evidence that supports it."
  • System design 2.2.4.2: "Keep the device type with stronger evidence and drop the rest from scoring." It filters data only and calls no sibling module.
  • Its input is the device's evidence: signature matches from #65, which carry a device_type_id, plus OUI evidence from match_oui, which names a vendor but no type.
  • The tie rule and the weights are agreed on #63 and live in evidence.py (#64).
  • Rules are in #63.

Steps

  • Agree how evidence is counted and record it on #63. Proposal: each evidence type counts once. A device with three matching mDNS services gets the mDNS weight once, not three times. Otherwise one chatty device could reach 100 from a single source.
  • count_points(items) -> int in evidence.py: the points a set of evidence is worth under that rule, before the cap. Subtask 4 uses the same function, so "stronger" here and the score there can never disagree.
  • Resolution record in resolve_conflicts.py:
    • device_type_id: the winning type, or None when there is none
    • kept: the evidence that counts toward the score
    • dropped: the evidence left out, so the device detail page can show it as "conflicting"
    • winning_matches: the winning type's signature matches, which subtask 5 uses for the name and model
  • resolve_conflicts(matches, other_evidence) -> Resolution, pure:
    • Evidence without a type (OUI) never conflicts and is always kept
    • Signature matches are grouped by device type. A group's strength is count_points of its evidence.
    • The strongest group wins; its evidence is kept, and every other group's is dropped
    • A tie for strongest: no type wins, and all signature evidence is dropped (the agreed tie rule). OUI evidence is still kept.
    • No signature matches: no type, and nothing is dropped
    • The order the evidence comes in doesn't change the result
  • Unit tests, with hand-made matches:
    • No signature matches: the type is None, and OUI evidence is kept
    • One type: it wins, and everything is kept
    • Two types: the stronger wins, and the weaker one's evidence is dropped
    • Three mDNS matches for type A against mDNS plus SSDP for type B: B wins, because each evidence type counts once
    • A tie: no type, signature evidence dropped, OUI kept
    • Shuffled input gives the same result
    • count_points: one evidence type counted once, different types added together

Where

  • backend/services/scan/resolve_conflicts.py
  • backend/services/scan/evidence.py (add count_points)
  • tests/services/scan/test_resolve_conflicts.py

Done when

  • All the tests above pass without a database or network
  • "Stronger" is measured with count_points, the same function the score uses

Depends on

  • Evidence weights and the shared evidence record (#64)
  • Match evidence to device signatures (#65), for the SignatureMatch record
Dominant language
Python
Stars
1
Forks
1
Avg merge
9h 31m
Merged PRs (30d)
36

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Bearkat-Professionals/Software-Engineering-Project

All issues in Bearkat-Professionals/Software-Engineering-Project

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.