Setup Inventory Investigation

"24 computers, 24 monitors, 24 keyboards, 24 mice, 24 headsets." Done, right?

Not really. Which computers are for what? Which stations share a switch? Do we have spares? Which headset belongs where, and which one is starting to fail? Which machine is the broadcast computer, and what software does it need? Who's responsible for maintaining any of it? "24 computers" turns out to be almost no information at all.

Why inventory exists

A useful inventory answers what we have, where it is, what it's for, what condition it's in, what it depends on, and what happens if it fails. Nobody joins esports dreaming of spreadsheet asset tracking — but when a mouse dies five minutes before competition, the person who knows exactly where the spare mouse is becomes very popular, very quickly.

Fields worth tracking

Asset ID. A unique label, like PC-07.

Category. Workstation, display, input, audio, network, broadcast, or software.

Location. Where it physically is.

Function. Why it exists.

Dependency. What it needs to work.

Condition. Ready, needs attention, or out of service.

Replacement or backup. What happens if it fails.

Software belongs in inventory too

It's easy to forget. If every workstation needs a game client, voice application, drivers, an operating system, a browser, and possibly a required background service, then versions and updates matter, and consistency across stations often matters even more.

Configuration drift

Imagine twelve supposedly identical computers. Over time: one gets an update the others don't, one keeps an old game version, one has a changed microphone setting, one has a different display setting, one is missing required software. Systems drift away from their intended configuration on their own, just from ordinary use — that's called configuration drift.

A baseline is the known intended configuration you compare against — operating system ready, game installed and updated, voice software ready, audio input tested, display configured, network connected. Without a baseline, "this computer is configured wrong" has no real meaning, because there's nothing to be wrong relative to.

The fictional lab: Robotnix Arena Lab B

Eight stations. Station 01 is a player workstation, fully ready. Station 02 is a player workstation with an intermittently failing headset microphone. Station 03 is a player workstation running a game version behind the lab's current baseline. Station 04 is a player workstation working normally. Station 05 is a player workstation with a reported mouse double-click issue. Station 06 is a player workstation working normally. Station 07 is a caster station with a headset, microphone, and second monitor. Station 08 is a broadcast station with capture hardware, production software, and a large storage requirement.

Shared equipment: SWITCH-01 connects Stations 01-06; SWITCH-02 connects Stations 07-08; there's one ROUTER-01, one internet connection, one SPARE-MOUSE-01, and one SPARE-HEADSET-01.

Your job: turn this into an operational inventory.

Investigation 1: build the inventory

Create a table with columns for asset, category, function, condition, whether it's shared, and whether a backup exists. Start with entries like PC-01 (workstation, player station, ready, not shared), Headset-02 (audio, voice and game audio, needs attention, not shared, backup available), and Switch-01 (network, connects PCs 01-06, ready, shared). Continue until you've covered the whole lab.

Investigation 2: find the priorities

You have fifteen minutes before practice. Current problems: Headset-02's intermittent microphone, PC-03's outdated game version, and Mouse-05's double-click issue. All three could matter — prioritize using impact, urgency, whether a backup is available, and time to resolve.

The mouse might be the easiest fix: swap in the spare, done. The outdated game might need more time because an update has to download and install. The headset might have a spare too. This is exactly why inventory, dependencies, and time all have to be weighed together rather than fixed in whatever order they were reported.

Investigation 3: shared dependency risk

Which asset worries you most, even if nothing is currently broken? Probably Switch-01 — six player stations depend on it, so its blast radius is large even while it's working fine. Inventory isn't only about finding what's already broken; it helps you see risk before it becomes a failure.

Investigation 4: missing inventory

What's missing from the fictional list above? Think about power, cables, software, accounts, adapters, storage, and display cables. Add at least five missing categories or items to your inventory, and defend why each one belongs.

Investigation 5: build the dependency map

Using the fictional lab, include at minimum: player PC, monitor, input device, headset, operating system, game, switch, router, internet, and game service. Add arrows, then identify three critical dependencies, two shared dependencies, and two possible single points of failure.

Your final artifact

Build the Esports Setup Inventory + Dependency Map in two parts.

Part A: inventory. At least fifteen assets or components, each with an ID, category, function, condition, dependency, and backup/response plan.

Part B: dependency map. At least ten nodes, spanning hardware, software, network, service, and user/environment.

Add a criticality layer — mark each node critical, important, or supporting, and remember that classification depends on the system's actual goal. Defend at least three of your ratings.

Suggested structure

Ten slides work well: lab purpose; workstation anatomy; hardware inventory; software/service inventory; network and shared infrastructure; dependency map; current issues; priority decisions; backup and spare strategy; what we'd inspect next. A spreadsheet plus one diagram slide is also fine — whatever actually communicates the system.

The maintenance question

Look at your inventory. Which component should get attention before it fails, not after — a failing mouse, an intermittent headset, low storage, outdated software? That's maintenance thinking: acting on a warning sign instead of waiting for a complete failure.

Final defense

Your instructor picks one item from your inventory. In forty-five seconds, answer: what does it do, what depends on it, what does it depend on, what happens if it fails, and what's the backup? Answering all five means you understand more than "it's a mouse."

Before you leave

Finish: the most important thing our inventory revealed wasn't the number of devices — it was __________. Explain why.

Source note

This investigation directly applies Middle Township Unit 5 expectations around hardware/software interaction, integrated systems, reliability, design constraints, maintenance, repair, accessibility, and network dependency.

The fictional Robotnix Arena Lab B, the configuration-baseline model, the technical inventory structure, criticality analysis, and the dependency-map project are original Robotnix Academy components.