US-21 — Analyse my whole network at once, not device by device #314

Activity

1. ARSH871-bot

   added this to the Phase 3 - market readiness milestone on Sep 10, 2026
2. ARSH871-bot

   self-assigned this

   on Sep 10, 2026
3. ARSH871-bot

   added

   size: LTwo weeks or more, or needs a team decision.Two weeks or more, or needs a team decision.

   phase: 3Market readiness -- what stands between us and a product someone could buy.Market readiness -- what stands between us and a product someone could buy.

   on Sep 10, 2026
4. ARSH871-bot commented on Sep 12, 2026

   

   ARSH871-bot

   on Sep 12, 2026

   OwnerAuthor

   More actions

   Rescoped before anyone started it, for the same reason as #320: the premise was wrong in our favour.

   This issue came from Discussion #296, which asked for "wall-clock time and memory recorded in docs/scale.md at 10, 50 and 100 devices". docs/scale.md already exists — @shubhamkataria2005 produced it for #218, which he owned and closed — and already records:

   devices   load + analyse
   10        4.3 s
   50        6.9 s
   
   "Roughly linear, and fast. Fifty devices in seven seconds.
    Scale is not the problem."
   

   So the timings were taken about six weeks before the story asking for them was written.

   What is genuinely outstanding

   1. Memory. Only wall-clock was measured. docs/scale.md says nothing about memory at any size.
   2. 100 devices. Measured at 10 and 50; tools/make_scale_fixture.py --devices 100 will generate it.
   3. The finding that actually matters, which neither Phase 3 backlog: twenty user stories, five each (proposal) #296 nor this issue mentioned, and which is the second half of scale.md:

   devices   findings   what policy compliance reported
   10        3          PC-049  9 of 10 not covered
   50        3          PC-049  49 of 50 not covered
   

   Three findings at fifty devices, the same as at one. The analysis does not grow with the network, because every rule names a specific device (#87). Fifty devices in, one device examined.

   That is not a performance problem. It is #87 wearing a different hat, and #316 and #319 already own the fix. What belongs here is making the gap visible: a multi-device scan should say N devices present, M examined rather than leaving a user to infer it from a suspiciously short list. A user who uploads fifty devices and gets three findings currently has no way to tell a clean network from an unexamined one — which is F-4 at estate scale.

   Why I am writing this up rather than quietly editing

   This is the second story in this milestone to ask for work already done, and both errors point the same way: they understated what we have.

   An overclaim gets caught the moment somebody tries the feature. An underclaim quietly funds a sprint of re-doing finished work, and nothing objects. It is the less alarming failure and the more expensive one.

   Both came from copying #296's wording faithfully instead of checking it against main. Copying a claim faithfully is not the same as checking it — which is the sentence this project has now had to write about the A-2 ratification table, the PF Sense blocker list, docs/traceability.md, and now twice about its own backlog.

   Also corrected on #348: the Scale section of docs/design/phase-3-backlog.md said "We have never run this on a network larger than a handful of devices. Every performance claim we might make is currently a guess." Both sentences were false, and docs/scale.md had been in the repository the whole time.

   #335 and #343 are rescoped in the same pass — #335 to build on scale.md's figure rather than pretend it does not exist, #343 to extend tools/preflight.py rather than grow a second thing that looks like it.
5. ARSH871-bot

   added a commit that references this issue on Sep 12, 2026

   A second story asked for work main had already done, and the same way…

   ...

   83071a7