SUBTASK #63: Assign identification level (2.2.4.4)

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

Maintainers usually reply within 1 day

@javi120467 is already working on this.

Since Oct 30, 2026.

Assessment

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

Research direction

Start with backend/services/scan/evidence.py and the existing IdentificationLevel, ScoreBreakdown, and resolution definitions referenced in the issue; then review the rules in issue #63. Implement the pure function in backend/services/scan/assign_level.py and cover the listed cases in tests/services/scan/test_assign_level.py. Done means all listed unit tests pass without a database or network, and every result has a level, type, and vendor.

Written by the indexing model from the issue text.

Description

backend Medium Priority subtask

What to do

A pure function that takes the outcome of conflict resolution, the score and the OUI vendor, and decides how well the device is identified (identified, partially identified or unidentified), along with the name, type, model and vendor to show. A device with no known type gets the "unknown" type.

Background

  • System design 2.2.4.4: "Classify as identified, partially identified, or unidentified and set name, type, model, and vendor (type defaults to 'unknown')."
  • Spec 7.2: identified shows name, type and model where known; partially identified (generic) shows type and vendor only; unidentified shows "Unknown".
  • Spec FR-05, FR-08 (classify as unknown when information is insufficient) and DI-03 (type defaults to unknown).
  • IdentificationLevel is in backend/records/enums.py (#39). The identified threshold IDENTIFIED_MIN_SCORE is in evidence.py (#64).
  • The level is never stored. It's worked out again from the evidence each time, and SH-4.1 (evaluate_flag) uses it to set the flag.
  • Rules are in #63.

Steps

  • UNKNOWN_TYPE_ID = 1 and UNKNOWN_VENDOR_ID = 1 in evidence.py, matching the seeded "unknown" rows and UNKNOWN_ID in reference data (#16)
  • Identification record in assign_level.py: level, device_type_id, vendor_id, device_name, model, score (the ScoreBreakdown from #67)
  • assign_level(resolution, score, vendor_id) -> Identification, pure, using the levels agreed on #63:
    • Identified: a type won, one of its matches gives a device name, and the score is at least IDENTIFIED_MIN_SCORE
    • Partially identified: not identified, but the type or the vendor is known
    • Unidentified: neither the type nor the vendor is known
    • No winning type: device_type_id is UNKNOWN_TYPE_ID. No OUI vendor: vendor_id is UNKNOWN_VENDOR_ID.
    • Name and model come from the winning matches: the match with the highest weight that has a name; on a tie, the lowest signature id. The model comes from the same match when it has one, otherwise from the next match in that order that does.
    • The vendor only ever comes from the OUI match; signatures don't set it
  • Unit tests, with hand-made resolutions and scores:
    • No evidence at all: unidentified, unknown type and vendor, no name
    • OUI vendor only: partially identified, unknown type (M2's provisional rule, now real)
    • A type but no name: partially identified
    • A type and name with a score at the threshold: identified
    • A type and name with a score one point below the threshold: partially identified
    • Tied types (no winner) with an OUI vendor: partially identified, unknown type
    • Two winning matches with different names: the choice follows the rule above and doesn't depend on input order
    • A model taken from the next match when the named match has none
    • UNKNOWN_TYPE_ID and UNKNOWN_VENDOR_ID equal UNKNOWN_ID in reference data

Where

  • backend/services/scan/assign_level.py
  • backend/services/scan/evidence.py (add the two unknown ids)
  • tests/services/scan/test_assign_level.py

Done when

  • All the tests above pass without a database or network
  • Every device gets a level, a type and a vendor; "unknown" is used, never None

Depends on

  • Evidence weights and the shared evidence record (#64)
  • Resolve conflicting evidence (#66) and Calculate confidence score (#67)
  • Evaluate Flag SH-4.1 (#39), for IdentificationLevel: done
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.