Chassis

Podcast 2 — In conversation

Speaker A: I want to raise something that came up at work. We were discussing a new server procurement and the vendor kept referring to the blade chassis. Half the room was saying CHAS-sis, and the vendor was saying SHAS-ee. Was someone wrong?

Speaker B: The vendor had it right. The correct British pronunciation is SHAS-ee — rhyming with glassy. The CH makes a SH sound, as in the French original, and the final S is completely silent. CHAS-sis is a very common mispronunciation, probably because people read it phonetically before they hear it spoken. You will hear CHAS-sis in American English too, so it is not without precedent, but in British technical and engineering contexts, SHAS-ee is standard.

Speaker A: What about the plural? Is it SHAS-eez?

Speaker B: Both pronunciations are acceptable for the plural. The spelling remains chassis — no change — but you can say SHAS-ee, treating singular and plural identically as you would with sheep, or you can say SHAS-eez, adding an implied Z sound for the plural. In practice, SHAS-eez is more common in formal or technical speech when you need to make clear you are talking about more than one.

Speaker A: And in terms of meaning — the chassis is the frame, yes? But how is it different from saying frame or shell?

Speaker B: Frame is the most direct alternative, but chassis carries specific engineering implications. A chassis is not just any frame — it is the load-bearing skeleton, the structure that everything else depends on. A shell or a casing is the outer covering, the exterior. The chassis is internal and structural. In a car, the chassis is underneath; the body panels and cabin are on top of it. You can strip the body off and the chassis still rolls.

Speaker A: And in the server context — the blade chassis holds the blades but is not itself a compute device?

Speaker B: Correct. The server chassis is infrastructure — it supplies power, cooling, backplane networking, and physical mounting for the blades. Each blade is an independent server that plugs into the chassis. The chassis is passive in the sense that it does not compute, but it is active in providing the shared resources that make the blades operational. Think of it as the skeleton that gives the body its organisation.

Speaker A: I have also heard chassis used more loosely — like a software chassis or an application chassis. Is that legitimate?

Speaker B: Yes, it is an established metaphorical use in software engineering. A software chassis refers to the base framework or boilerplate — the foundational structure on which a specific application is built. A chassis in this sense provides logging, configuration management, dependency injection, database connection pooling, error handling — the load-bearing infrastructure that every application needs, so you do not rebuild it from scratch each time. The application-specific code is bolted on top, just as the car body is bolted to the vehicle chassis.

Speaker A: So chassis implies that something is structural, foundational, and shared — not something you normally see or change, but something everything else depends on.

Speaker B: That is exactly right. If you are describing an architectural layer in those terms, chassis is precisely the word.

Podcast 3 — Prompt engineering

Speaker B: Chassis works well in developer prompts because it immediately signals a base structural layer — the foundational framework that other things mount onto. It implies shared infrastructure, load-bearing architecture, and reusability. Let us build out the prompts.

Speaker A: Starting with the automotive side or the software side?

Speaker B: The most directly useful starting point is a vehicle fleet prompt since that is the word's native domain:

Speaker B: PROMPT: Build a fleet chassis inspection and maintenance tracker using Node.js, Express, and React. Each vehicle in the fleet must have a chassis record capturing chassis number, vehicle type, manufacture date, chassis material specification, last inspection date, next inspection due date, and current structural condition rating from one to five. Inspection reports must be stored with photos, inspector name, defects found, and remediation status. The dashboard must highlight vehicles with overdue inspections in red and those due within 30 days in amber. Include a chassis history view showing the full inspection and repair timeline for any selected vehicle.

Speaker A: The chassis number is the unique identifier that persists through the entire life of the vehicle regardless of engine changes or bodywork repairs — it is the right anchor for a fleet record.

Speaker B: Now a database schema prompt using chassis as the foundational entity:

Speaker B: PROMPT: Design a PostgreSQL schema for a server chassis management system used in a data centre. Include tables for chassis, chassis_slots, blade_servers, chassis_power_supplies, and chassis_network_ports. Each chassis record must store the rack location, model, manufacturer, purchase date, warranty expiry, total slot count, and current firmware version. Each blade_server record must reference a chassis_slot. Include a view called chassis_capacity_summary that shows for each chassis the total slots, occupied slots, available slots, and total power draw from all installed blades. Add a trigger that logs any slot assignment or removal to a chassis_audit_log table.

Speaker A: The slot assignment trigger is important — data centre teams need a clear audit trail of exactly when blades were installed and removed from each chassis.

Speaker B: Now a software architecture prompt — the application chassis pattern:

Speaker B: PROMPT: Build a reusable application chassis in Node.js that provides the foundational infrastructure for any REST API service built by the team. The chassis must include structured JSON logging with correlation IDs, a configuration loader that reads from environment variables with schema validation, a database connection pool for PostgreSQL with automatic health checks, a graceful shutdown handler that drains in-flight requests before closing connections, standardised error response formatting, and a request validation middleware that enforces JSON schema on configured routes. Document each chassis component clearly so teams can extend it without modifying the shared core.

Speaker A: A shared application chassis reduces the time to start a new service from days to hours — you get all the infrastructure for free and only write the business logic.

Speaker B: Here is a UI component prompt using the chassis metaphor:

Speaker B: PROMPT: Design a page chassis layout component for a SaaS application using vanilla JavaScript and CSS. The chassis must provide the structural frame for every page: a fixed top navigation bar, a collapsible left sidebar with navigation items, a main content area that fills the remaining space, and an optional right panel that can be toggled. The chassis must handle responsive breakpoints so that the sidebar collapses to an icon rail at tablet width and hides entirely on mobile. Individual page views slot into the main content area without needing to redeclare the surrounding structure. Ensure keyboard navigation works correctly across all chassis regions.

Speaker A: The chassis metaphor immediately communicates that this is the structural outer container, not the content itself. Any developer reading that brief understands they are building infrastructure, not a feature.

Speaker B: And the final prompt — a full manufacturing quality control system built around the chassis:

Speaker B: PROMPT: Build a full-stack chassis quality control application for a vehicle manufacturing facility using Node.js, Express, React, and PostgreSQL. The system must track each vehicle chassis from initial fabrication through final assembly. At each production stage — frame welding, surface treatment, component mounting, and final inspection — a quality control record must be created capturing the stage, the inspector, the measurements taken, any deviations from specification, and the pass or fail outcome. A chassis may not advance to the next stage if the current stage has not been passed. The operations manager dashboard must show the current stage distribution across all active chassis and flag any that have been held at the same stage for more than four hours.

Speaker A: The stage-gate logic — a chassis cannot advance until the current stage passes — is exactly the kind of structural constraint that the word chassis implies. The frame must be sound before you build on top of it.

Speaker B: That is the core lesson for prompts. When you write chassis, you are telling the AI that you are describing a load-bearing layer — something foundational, shared, and non-optional. The components above it depend on it being correct. Build it right first, and everything else follows.