The Analog Reliability Cabinet of Curiosities

There’s a special kind of magic in holding a failure in your hand.

A scorched connector. A cracked PCB. A printed screenshot of the dashboard that went flatline at 3:14 a.m. These little artifacts tell stories: what went wrong, who was there, what you didn’t yet know about your system.

Instead of letting those stories live only in memories and Slack threads, you can build something more powerful: an analog reliability cabinet of curiosities—a desk-sized museum of tiny failure artifacts that doubles as a front-end to your reliability engineering process.

This isn’t a cute conversation piece. Done well, it becomes a physical gateway into rigorous incident analysis, structured learning, and continuous improvement.

Why Build a Cabinet of Curiosities for Failure?

Many teams already have informal relics of failure:

• The burned-out power supply sitting on a shelf
• The printed error log pinned to a cubicle wall
• The weirdly warped 3D-printed part left on someone’s desk

They’re fun to look at and great for storytelling, but they’re usually disconnected from any serious reliability work. They become souvenirs, not systems.

A deliberately designed cabinet of curiosities changes that. It:

• Makes failures visible and persistent, instead of ephemeral.
• Invites questions and storytelling, which spread context and tacit knowledge.
• Connects every artifact to a structured retrospective and action items, so it feeds back into your reliability program.

In other words: it’s a physical index into your incident history, not just a collection of neat broken things.

Principle 1: Every Artifact Is a Reportable Event

If an artifact is important enough to keep, it’s important enough to log.

That means treating each failure artifact as a reportable event that enters your broader reliability engineering process. No exceptions for “small stuff” if you decide to display it.

For each artifact, capture at minimum:

• Event ID: A unique reference (e.g., INC-2025-017).
• Date and time of occurrence (or discovery).
• System / component involved.
• Impact summary: What was affected? How bad was it?
• Reporter / owner: Who found this? Who owns the follow-up?

That information should live in your incident tracking system or FRACAS database, not just on a sticky note. The cabinet item becomes the tangible handle to pull up that record.

A simple rule helps: no artifact enters the cabinet without an associated record. Want your burnt connector on display? File the event first.

Principle 2: Use a Structured Retrospective Template

Curiosity alone doesn’t produce reliability. Structure does.

To consistently learn from failures, use a standard retrospective template for every artifact-worthy incident. The template doesn’t have to be long, but it does have to be systematic.

A simple structure might include:

1. What Happened (Timeline)

   • Chronological events: detection → response → mitigation → recovery.
   • Who did what, using which tools, based on which signals.

2. What Went Wrong

   • Technical factors (e.g., design flaws, configuration errors).
   • Human and organizational factors (e.g., missing runbooks, alert fatigue).

3. What Went Well

   • Fast detection? Good collaboration? Existing safeguards that reduced impact?

4. Root Causes and Contributing Factors

   • Distinguish between true root causes and contributing conditions.
   • Use a method like “5 Whys” or fault tree analysis.

5. What Needs to Change

   • Design changes, process changes, monitoring changes, training.

6. Action Items

   • Concrete, assigned, time-bounded tasks with clear owners.

When someone points at an artifact in the cabinet and asks, “What’s this about?”, you should be able to open the retrospective and walk them through the full story.

Principle 3: Turn Artifacts into Data with FRACAS

A cabinet of curiosities gets really powerful when it integrates with Failure Reporting, Analysis, and Corrective Action Systems (FRACAS).

FRACAS gives you a formal framework to:

1. Report failures consistently
2. Analyze them for causes and patterns
3. Define corrective and preventive actions
4. Track those actions to closure

Your cabinet becomes a physical extension of FRACAS:

• Each artifact has a FRACAS record.
• Each record has a failure mode classification (e.g., overload, fatigue, misconfiguration, UI ambiguity).
• You can run reports on those records: frequency by failure mode, MTBF trends, recurring components, etc.

Some practical tips:

• Label everything: Attach a small tag or printed card to each artifact with its event ID, date, and a short title.
• Link to the record: Include a QR code or short URL that goes directly to its FRACAS entry.
• Standard categories: Use the same categories in your FRACAS system for hardware, firmware, and software events, so patterns emerge across disciplines.

The museum is charming; the FRACAS data behind it is where real reliability improvement happens.

Principle 4: Documented and Visible, Not Just Talked About

Teams love war stories: “Remember that time the logging system filled the disk and killed the API?”

Stories are great, but undocumented stories decay. Memory is noisy. New team members never hear them. Details get blurred, causes get misattributed.

Your cabinet of curiosities should enforce two norms:

1. If it’s worth telling, it’s worth writing down.
   Before that artifact goes in the drawer or on the shelf, its story is captured in a retrospective and logged in FRACAS.

2. If it’s worth writing, it should be visible.
   Summaries, timelines, and root cause diagrams can be printed and placed alongside the artifact or in a binder next to the cabinet.

This visibility:

• Helps onboarding: new team members literally walk the history of failure.
• Promotes psychological safety: everyone can see that failures are studied, not hidden.
• Reinforces that rigor is the norm, not optional.

Principle 5: Learning Without Action Isn’t Learning

A failure story without a behavior change is entertainment, not engineering.

For each artifact and incident:

• Extract explicit lessons: “We didn’t validate input size on that path.”
• Translate each lesson into at least one specific action item.

Every action item should be:

• Concrete: "Add input size validation to endpoint /upload" not "be more careful about inputs".
• Assigned: One clear owner, not "the team".
• Time-bound: With a due date or milestone.
• Traceable: Linked from the FRACAS record and referenced on the artifact label.

You can even add a small status indicator to each cabinet item:

• Red dot: Corrective actions open.
• Yellow dot: Actions in progress.
• Green dot: All defined actions closed and verified.

This turns your cabinet into a visual Kanban of reliability work. It’s a reminder: admiring the story is not enough; we have to close the loop.

Designing Your Desk-Sized Museum

You don’t need a lot of space to make this work. A single shelf, a toolbox, or a small glass-front cabinet can be enough. Design it intentionally around two goals: storytelling and operational rigor.

Consider the following elements:

1. Physical Layout

• Sections by subsystem (e.g., Power, Networking, UI, Manufacturing).
• Or sections by failure mode (e.g., Overheating, Contamination, Software Regression, Configuration Drift).
• A dedicated “Hall of Near-Misses” for things that didn’t cause an incident—but almost did.

2. Artifact Cards

For each artifact, include a small card with:

• Title: "Melted connector from overcurrent in test rig"
• Event ID and date
• One-sentence impact summary
• QR code / link to full retrospective and FRACAS record
• Action status (red/yellow/green dot)

3. Story Surfaces

Reserve space for:

• Printed timelines or sequence diagrams from major incidents.
• Before/after snapshots of a design or process.
• Mini case studies: one-page summaries that can be read in under 3 minutes.

4. Interaction Rituals

Make the cabinet part of regular team life:

• Reliability Show & Tell: Once per sprint or month, pick one artifact and walk through its story and follow-up actions.
• Onboarding Tours: Every new hire gets a 15–20 minute tour of the cabinet with a senior engineer.
• Quarterly Reflections: Review all artifacts; retire any whose actions are complete and lessons are fully integrated into standards.

These rituals cement the idea that the cabinet is not decoration; it’s a living part of how you operate.

From Curiosity to Capability

A desk-sized museum of tiny failures might sound whimsical, but it can be a surprisingly serious tool.

When you:

• Treat every artifact as a reportable event,
• Use a structured retrospective template to capture what happened,
• Feed those events into a FRACAS or similar system,
• Ensure lessons are documented and visible, and
• Translate insights into concrete, assigned action items,

…your cabinet of curiosities becomes a reliability engine, not a novelty.

Over time, this small physical space starts to express big cultural truths: that you’re a team that doesn’t hide from failure, that you honor the details of what went wrong, and that you believe curiosity and rigor can coexist on the same shelf.

And every time someone picks up a tiny burnt part and asks, “What happened here?”, you have an answer that leads not just to a story, but to a system that is now a little bit stronger than before.