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.
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.
OS Versions
The valid software versions per item, with a default. This is what constrains the dropdowns and what the lab compares devices against.
Files
The actual OS images and config files, in versioned Azure storage. Upload, replace, archive — every change keeps history.
Effective Config
Pick any division and see exactly what the lab robot will receive — with the provenance of every line.
Activity
Every change, who made it, and the before/after. Because a wrong rule here configures a wrong device there.
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.| Scope | Load type | Item | Version | File | Active |
|---|
OS Version Maintenance
C9500-32QC Valid versions per item. The default (★) pre-fills standards; the runtime compares devices against it.| Default | Version | File | SHA-256 | Used by | Active |
|---|
Files
mdsisprocketfilesdev · Azure Blob Storage Every OS image and config file the lab pulls. Images are immutable and checksum-locked; base configs are revisioned records. Nothing is ever silently overwritten.Effective Configuration
Exactly what the lab runtime receives for a division — resolution is the product, not a preview.Activity
Every change, attributed — because a wrong rule here configures a wrong device there.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 baysRequirements Checklist
Every requirement from Shannon's workbook and the July 14/15 meetings — the project's living scoreboard.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 UI | Exactly as specified |
|---|---|---|
| Customer ID · “Business with Division override” | Standards → Scope column | CHAR000 business rows + CHAR253 indented override rows; resolution shown live in Effective Config |
| Load Type · dropdown OS/Firmware/Base Config | Standards → Load type + filter chips | Constrained dropdown in the editor; extensible list, filters actually filter |
| ITEM ID · “validated against Item Master” | Standards editor → Item field | Typeahead + live ✓ “Parts Master: Cisco ASR 9000…” — invalid items can't save |
| Version · “dropdown based upon Item” | Standards editor ← OS Versions catalog | Version list scoped to the selected item; never free text |
| File Path · free-form → Azure (Jul 15 decision) | File column → Files view | UI surfaces file NAME + version chip; the full path is derived and lives behind a ⧉ copy-path command. Legacy \\gacm-file-01 rows flagged “migrating” |
| isActive? | Active column + filter | Active-only default; inactive rows dimmed with restore; excluded from resolution |
| OS Versions sheet · item/version/default location | OS Versions view | Multiple versions per item, ★ default, per-customer pins (Jul 15), file links |
| Workflow rows 1–9 (the automation sequence) | Overview pipeline + Lab Board | Detect → 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.
Brains and settings — why files never change
The robot needs two kinds of files. A brain file (the software that goes inside a box) and a settings sheet (the box's name, its network, its rules).
Brain files are like a game disc: once it's made, nobody is allowed to change it — ever. If the makers build a better brain, it gets a new name and we add it as a new choice. Before the robot puts a brain in a box, it checks the file's fingerprint to make sure it's the exact same disc we tested. No surprises.
Settings sheets are different — grown-ups improve them over time. Every change gets a number: sheet 1, sheet 2, sheet 3. Old sheets are never thrown away, so if sheet 3 has a mistake, we can go right back to sheet 2.
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.
Images vs configs — two different rules
OS images are immutable. An operating-system image is a signed file released by the vendor (Cisco, Juniper…) with a published checksum — a digital fingerprint. Sprocket records that fingerprint at upload and re-checks it every time the lab flashes a device. You can never upload "a new version" of the same image file — a new build from the vendor is a new file, added to the catalog as a new version entry. That's how you guarantee the bytes you tested are the bytes that ship.
Base configs are living documents. They're templates MDSi writes and improves, so each upload creates a numbered revision (rev 1, rev 2…) with the whole history kept. Before a new revision goes live, Sprocket shows exactly which customers' standards will pick it up — and lets you pin them to the old revision if they're not ready.
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. Artifacts live in Azure Blob Storage: OS/firmware images are immutable and checksum-pinned (a new build is a new file + a new OsVersion record — the golden-image pattern), base-config templates are revisioned records, and referenced artifacts are deletion-protected. Blob versioning + soft delete remain enabled underneath purely as the operational safety net.
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.
The artifact model — version the record, not the file
Three entities carry the file story. An OsVersion record binds (item, version label) → exactly one immutable image file plus its SHA-256; standards reference the record, never a path. A config artifact is an explicitly revisioned template — each revision is itself immutable once written, and "current" is a pointer the roll-forward/pin choice controls. The blob layer (Azure Storage with versioning + soft delete) sits underneath as an operational safety net only — it is not a product concept.
Consequences worth internalizing: changing what the lab flashes is always an explicit, audited act (add a version record, promote a standard, or roll a config revision) — never a side effect of an upload. Integrity is end-to-end: checksum recorded at upload, verified before flash. And customer pins target version records, so there is no hidden byte-level drift to reason about.
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.
Artifact identity semantics
Formally: image artifacts are content-addressed values (identity ≡ SHA-256; the filename is a human alias), while config artifacts are named references over an append-only revision chain. The catalog is a partial function (item, label) → artifact hash; standards compose with it, so resolution yields a hash the runtime must verify before execution — closing the TOCTOU window between validation and flash. Mutation is excluded from the value domain: every state change is a new fact (new version record, new revision, new promotion event), which makes the audit trail a total order over causally meaningful acts rather than a diff log over mutable state. Azure blob versioning is deliberately demoted to infrastructure-level durability; product invariants never depend on it.
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 Managed Services Sparing vs Spectrum Sparing — one exception, 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.
Why immutable files matter to the business
The costliest lab failure mode is silent change: a file someone "fixed" overnight re-imaging every customer device the next morning. This design makes that impossible. OS images cannot change after upload — a new vendor build is a new, visibly separate catalog entry, and every flash re-verifies the checksum recorded on the day the build was validated. Config changes are explicit revisions with a blast-radius preview: before rev 3 goes live you see exactly which customers pick it up, and you can hold any of them on rev 2. Every change is attributable — who, when, why — which is precisely the change-control story Charter and Comcast audits ask for. The engineering cost of this discipline is near zero; the outage class it eliminates is the expensive one.
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. OS images are immutable: uploaded once, checksum-locked, verified before every flash — a new build is a new file + catalog entry. Base configs are revisioned: each upload creates rev N+1 with history kept and a blast-radius preview (roll forward or pin). 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).