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.