Mockup v3 · Interaction design only — no backend wiring · data mirrors Configuration Automation.xlsx · deployment status
Lab Automation AdminAcuity v4 DEV TH

The brain of MDSi lab configuration automation.

Every rule defined here drives a real device in a real bay. When equipment is racked in any MDSi lab, the platform identifies it, finds its order, asks this system what to load — OS, firmware, base configuration — and configures it end-to-end. You are editing the instructions the robots follow.

1 · Device rackedbay port wakes, show versionidentifies item + serial 2 · Order foundserial → D365 / Acuity ordercustomer + site config 3 · Standards resolvedTHIS SYSTEM · division → businessexception hierarchy answers 4 · Files pulledOS images + configs fromversioned Azure storage 5 · Configured ✓loaded · validated · loggedready to unrack & ship
0
active standards
0
items in the OS catalog
0
customers configured
0
divisions inheriting (Charter)
0
files under version control
Start here

Configuration Standards

Who gets what: one rule per customer × item × load type. Set it once at the business level; add a division row only where an exception is needed.

The catalog

OS Versions

The valid software versions per item, with a default. This is what constrains the dropdowns and what the lab compares devices against.

The vault

Files

The actual OS images and config files, in versioned Azure storage. Upload, replace, archive — every change keeps history.

The answer

Effective Config

Pick any division and see exactly what the lab robot will receive — with the provenance of every line.

The trail

Activity

Every change, who made it, and the before/after. Because a wrong rule here configures a wrong device there.

Phase 2 vision

Lab Status Board

The live per-bay view technicians will watch once the lab runtime ships — driven by the rules you define here.

Configuration Standards

Charter Communications Business rules apply to every division unless a division override exists.
6 active standards
ScopeLoad typeItemVersionFileActive
CHAR000OSMX960OSMX960V32134.txtos-images/juniper/mx960/OSMX960V32134.txtY
CHAR253 · CarolinasOSMX960OSMX960v9823424.txtos-images/juniper/mx960/OSMX960v9823424.txtY
CHAR000Base ConfigMX960configs/juniper/mx960/charter-base.cfgY
CHAR000OSC9300L-48P-4G-Ecat9k_iosxe.17.03.04.SPA.binos-images/cisco/c9300/…17.03.04.SPA.bin migratingY
CHAR000OSISR4331-SEC/K9isr4400-universalk9.17.09.09no file — resolve before runtimeY
CHAR000OSC9500-32QCcat9k_iosxe.17.09.09.SPA.binos-images/cisco/c9500/…17.09.09.SPA.binY
CHAR000OSQFX5100jinstall-qfx-5-14.1X53-D36.3os-images/juniper/qfx/…14.1X53inactive
New standard — validated as you type
CHAR000 business
OS ▾
A9K-RSP-8G
✓ Parts Master: Cisco ASR 9000 route processor
ASR9K-iosxr-px-6.7.1 ▾
os-images/cisco/asr9k/6.7.1.tar
✓ No duplicate — CHAR000 · OS · A9K-RSP-8G has no active standard; existing combinations are blocked at save with a jump-to-row offer

OS Version Maintenance

Valid versions per item. The default (★) pre-fills standards; the runtime compares devices against it.
C9500-32QCCatalyst 9500 · Cisco
Default VersionFileUsed byActive
cat9k_iosxe.17.09.09.SPA.binos-images/cisco/c9500/17.09.09/ v32 standardsY
cat9k_iosxe.17.15.05.SPA.binos-images/cisco/c9500/17.15.05/ v1Y
cat9k_iosxe.16.11.01.SPA.bingacm-file-01 (legacy) migrateY
Customer pins — exception on the default
CHAR000 pins cat9k_iosxe.16.11.01 — older build, validated for their change window  Every other customer follows the item default. Pins resolve division → business, exactly like standards.

Files

mdsisprocketfilesdev · Azure Blob Storage Every OS image and config file the lab pulls, under real version control — uploads never overwrite, they version.
os-images / juniper / mx960 2 files · 5 versions
OSMX960v9823424.txt
2.1 MB · Tommy Dent · Jul 18, 2026
v2 current used by 1 standard
v2Uploaded by Tommy Dent — “validated on CHAR253 bench unit”Jul 18 · 2.1 MB
v1Initial migration from \\gacm-file-01Jul 15 · 2.1 MB
OSMX960V32134.txt
2.0 MB · migration import · Jul 15, 2026
v1 current used by 1 standard
v1Initial migration from \\gacm-file-01Jul 15 · 2.0 MB
⇪ Drop a file here, or click to upload
New name = new file · existing name = new version (nothing is ever overwritten) · verified against the OS catalog before it lands

Effective Configuration

Exactly what the lab runtime receives for a division — resolution is the product, not a preview.
Charter Communications
CHAR000 · 50 divisions
Flip divisions and watch the OS row change — one division pins an older build, 49 ride the business standard.
MX960Juniper MX
OSOSMX960v9823424.txtos-images/juniper/mx960/OSMX960v9823424.txtdivision override · CHAR253
Base Configcharter-base.cfgconfigs/juniper/mx960/charter-base.cfgbusiness standard · CHAR000
C9300L-48P-4G-ECatalyst 9300
OScat9k_iosxe.17.03.04.SPA.binos-images/cisco/c9300/…17.03.04.SPA.binbusiness standard · CHAR000
Site-specificfrom order attachmentsapplied after standards — never stored hereorder scope · Acuity
ISR4331-SEC/K9Cisco ISR 4400
OSisr4400-universalk9.17.09.09no file — runtime will skip & flagbusiness standard · CHAR000

Activity

Every change, attributed — because a wrong rule here configures a wrong device there.
SP
Shannon Payne created a division override — CHAR253 · OS · MX960
− inherited: OSMX960V32134.txt (business · CHAR000)
+ override:  OSMX960v9823424.txt (division · CHAR253)
TD
Tommy Dent uploaded OSMX960v9823424.txt v2 — “validated on CHAR253 bench unit”
TD
Tommy Dent added OS version — N540-ACC-SYS · ncs540l-golden-x86_64-7.11.21 set default
TD
Tommy Dent deactivated — QFX5100 · OS · jinstall-qfx-5-14.1X53
− isActive: Y
+ isActive: N · reason: superseded by 21.2X4.1
Excel import — 34 standards seeded from Configuration Automation.xlsx · 0 errors, 2 warnings (legacy paths)

Lab Status Board

PHASE 2 VISION — not in the current build The ConfigBot status page, reborn: live per-bay state, pushed — driven by the standards you define here.

Alpharetta · Lab 1

Rack A · 8 bays
queue 3avg config 11m 40sexceptions today 1completed 14
Bay 01complete
C9500-32QC · FCW2318L0GH
SO-0048112 · Charter CHAR253 · ready to unrack
6/6 · evidence emailed to technician group
Bay 02configuring
MX960 · JN12AC0F92
SO-0048119 · Charter CHAR253 · OS override active
3/6 · loading OSMX960v9823424.txt
Bay 03warnings
ISR4331-SEC/K9 · FDO2233A1KQ
2 warnings during base config — review before ship
5/6 · paused for review
Bay 04no order match
N540-ACC-SYS · FOC2519N3XZ
Serial not found on any picked order line (D365/BYOD)
Bay 05identifying
detecting… link up on port 5
1/6 · running show version
Bay 06idle
listening on 10.14.6.106
Bay 07idle
listening on 10.14.6.107
Bay 08idle
listening on 10.14.6.108

Requirements Checklist

Every requirement from Shannon's workbook and the July 14/15 meetings — the project's living scoreboard.
0visible+

44 requirements · 19 visible in this mockup · 11 already deployed to Azure · 3 designed · 11 Phase 2 (lab runtime)

Status legend: IN MOCKUP visible in this UI · DEPLOYED real and live in Azure/Auth0 today · DESIGNED specified, built with the API · PHASE 2 lab runtime scope. The checkbox column is yours — a local scratchpad for review sessions (saved in this browser only).

The workbook, mapped — every column of Configuration Automation.xlsx lands here

Workbook (Shannon/Tommy)Where it lives in this UIExactly as specified
Customer ID · “Business with Division override”Standards → Scope columnCHAR000 business rows + CHAR253 indented override rows; resolution shown live in Effective Config
Load Type · dropdown OS/Firmware/Base ConfigStandards → Load type + filter chipsConstrained dropdown in the editor; extensible list, filters actually filter
ITEM ID · “validated against Item Master”Standards editor → Item fieldTypeahead + live ✓ “Parts Master: Cisco ASR 9000…” — invalid items can't save
Version · “dropdown based upon Item”Standards editor ← OS Versions catalogVersion list scoped to the selected item; never free text
File Path · free-form → Azure (Jul 15 decision)File column → Files viewPaths are clickable chips into versioned Azure storage; legacy \\gacm-file-01 rows flagged “migrating”
isActive?Active column + filterActive-only default; inactive rows dimmed with restore; excluded from resolution
OS Versions sheet · item/version/default locationOS Versions viewMultiple versions per item, ★ default, per-customer pins (Jul 15), file links
Workflow rows 1–9 (the automation sequence)Overview pipeline + Lab BoardDetect → identify → order → resolve → execute → notify → complete, animated end-to-end

Meeting decisions — July 14 & 15 (Shannon · Tommy · Tom)

Help — what this is and how to use it

Pick the depth that fits. Every ⓘ dot across the app opens the same kind of explanation in place.

What is this?

MDSi has a big room full of computer machines called a lab. Companies buy internet boxes — the machines that make Wi-Fi and internet work — and MDSi gets each box ready before mailing it out. Getting a box ready means putting the right “brain” (software) inside it and telling it the right settings.

Right now, people do that by hand for every single box. Soon, robots-in-software will do it: you plug a box into a special shelf, and the computer figures out who bought it and sets it up all by itself.

This website is the instruction book for those robots. Grown-ups at MDSi write rules here like: “Every box going to Charter gets brain version 2.” The robot reads the rule and does exactly that. If one Charter office needs something special, you add one extra rule just for them — everyone else still follows the big rule.

How does it change the lab?

Today a person types into every box, which is slow and easy to get wrong. With these rules, the shelf does the work: plug in, lights blink, and a few minutes later the box is perfect — the same way, every time. The people get to watch a big board with green lights instead of typing all day.

What is this?

MDSi configures networking equipment (routers, switches, firewalls) for big customers like Charter and Lumen before shipping it. Every device needs the correct operating system version and configuration files loaded, and today technicians do that manually over a console cable.

The company is automating it: lab racks with network-connected bays detect a device the moment it's plugged in, look up which customer ordered it, and configure it automatically. For that to work, the automation needs a rulebook — this site is that rulebook.

The core idea is inheritance with exceptions: you set a rule once for a whole company (“Charter gets OS version X on this model”), and all ~50 of their regional divisions inherit it. If one division needs something different, you add a single override row for it — like a subclass overriding one method. The Effective Config screen shows the final answer for any division after inheritance is applied.

How does it change the lab?

Instead of a tech looking up requirements in spreadsheets and typing commands, the bay's software calls this system's rules, downloads the exact files from the Files screen's storage, applies them, verifies the result, and logs everything by serial number. Throughput scales with racks, not headcount, and every device gets configured identically.

What is this?

This is the administrative surface of MDSi's lab configuration automation platform — the system of record for customer configuration standards. The domain model is small and sharp: a CustomerStandard is a tuple (customerErpId, loadType, itemId) → (version, filePath, isActive), where customerErpId can reference either a business (e.g. CHAR000) or one of its divisions (CHAR253). Resolution walks division → business → none: an exception-based hierarchy identical in spirit to Acuity's existing product-catalog inheritance.

An OsVersion catalog per item constrains the version domain (no free text at the edges), designates a default, and supports per-customer pins with the same resolution semantics. Configuration artifacts live in Azure Blob Storage with blob versioning enabled — uploads create versions, never overwrites, and referenced versions are deletion-protected.

The runtime contract: when a device is racked, the lab's node server resolves (division, item) against this system and receives the effective load set with artifact URIs. The Effective Config view executes the same resolution the runtime will call — it is a truth-teller, not a simulation.

How does it change the lab?

It converts tribal knowledge and file shares into declarative, versioned, auditable data. Config drift disappears because there is exactly one resolution path; rollbacks become metadata operations (restore a version, flip a default); and the audit trail ties every device outcome to the rule and file version that produced it.

What is this?

Formally: a policy store with hierarchical scope resolution over a two-level customer taxonomy, feeding a distributed execution fabric. Standards form a partial function f(scope, item, loadType) → artifact; scopes are ordered division ≺ business, and resolution selects the most specific defined mapping — a longest-prefix-match over organizational rather than network space. The absence of a mapping is a valid result (the runtime skips that load type), which keeps the policy space sparse and the authoring burden proportional to exceptions, not population size.

Artifact integrity is delegated to Azure Blob versioning (immutable version chain, soft-delete recovery window), with referential protection: versions referenced by active standards are not deletable, only archivable — enforcing that any historically-resolvable policy remains materializable. Auditability is dual-plane: field-level mutation history on the policy store, and (Phase 2) per-serial execution logs on the runtime, joinable by rule identity — the provenance chain from “who changed the rule” to “which device got which bytes.”

The interesting systems property is the read path: resolution must be deterministic and low-latency (a device is physically waiting), which drives the Phase-1 API design — a single-call resolver with p95 < 500 ms — and motivates local caching at the lab edge for the air-gapped-facility case.

How does it change the lab?

It shifts the lab from an imperative, operator-driven process to a declarative, policy-driven one — with the classic benefits: idempotent re-execution, reproducibility across sites, and a clean separation between policy authorship (this system, business-facing) and policy execution (node servers, hardware-facing). The Phase-2 telemetry loop closes the control system: execution outcomes feed back into standards quality.

What is this, and why does it matter?

This is the control panel for the lab automation capability we described to Lumen — the piece that turns configuration knowledge into a durable company asset. Today that knowledge lives in spreadsheets, file shares, and experienced technicians' heads; every configured device depends on a person remembering correctly. This system makes it explicit: every customer's standards are defined once, inherited by all their divisions, and overridden only by exception — Shannon's model, exactly as he laid it out in the Configuration Automation workbook.

Operationally: lab throughput stops scaling with headcount. A racked device configures itself from these rules in minutes, identically at every warehouse we roll out to, with a serial-by-serial audit trail. Exceptions surface to a technician; the standard path needs nobody.

Commercially: this is the proof behind the Configuration Automation Supplement — the “order database as the single source of configuration truth” claim becomes a demonstrable screen (Effective Config) rather than a paragraph. It's customer-agnostic by design: Lumen triggered it, but Charter, AT&T, and every future logo use the same machinery — onboarding a new customer is authoring rules, not building software.

Risk posture: versioned files with restore, deletion-protection on anything in use, full change attribution, and role-gated access through the standard Acuity Auth0 model. The demo you can run today: open Standards → show the Charter business rule → flip to Effective Config → toggle Carolinas vs Great Lakes — one exception, forty-nine inheritances, zero ambiguity.

What it changes for the lab organization

Technicians move from typing configurations to supervising a board of green lights and handling flagged exceptions. Engineering owns templates and standards instead of one-off fixes. And every conversation with a customer about “how do you guarantee consistency?” now has a two-minute answer with a screen behind it.

How to use each screen (any level)

  • Overview — the map. The animated pipeline is clickable; the numbers are live counts. Start every demo here.
  • Standards — pick a customer (chips top-left), read business rows, spot amber override rows. The editor at the bottom validates item + version + duplicates before Save. Import/Export moves the Excel workbook in and out.
  • OS Versions — per item: its valid versions, the ★ default that pre-fills standards, and customer pins for exceptions. “Used by N standards” tells you what a change touches.
  • Files — the storage behind every rule. Click a file to expand its version timeline. Upload with the button or the drop zone: same name = new version, never an overwrite. Archive hides without destroying; only unreferenced files can be deleted, and soft delete keeps 30 days of undo.
  • Effective Config — the answer key. Choose a division; every line shows its value AND where it came from. If it looks wrong here, it will be wrong in the lab — fix the standard, not the device.
  • Activity — who changed what, when, with before/after. Your first stop when something surprises you.
  • Requirements (top right) — the project scoreboard mapping this UI to Shannon's workbook and meeting decisions.
  • Lab Board — Phase 2 preview of what technicians will watch. The rules you author here drive those bays.

Every ⓘ dot opens a two-tab card: About (what it is, for users) and DEV (which of Shannon's requirements it satisfies, for the build team).