8. Project: production-readiness audit

Overview

By the end of this project you'll have produced the deliverable that justifies the entire module: a production-readiness audit of Terra Market's catalog. It's not an exercise that gets filed away. It's a document with three pieces —a classified inventory, a per-workflow gap table, and a report with the three workflows that need fixing first and why— that becomes, literally, the work plan for the seven modules that follow. When you finish it, you'll know where to start operating Terra Market for real, and you'll be able to defend that decision to anyone who asks "why that one and not the other?"

This matters because everything you learned in the module —recognizing production, classifying by criticality, calibrating the checklist, organizing the catalog, drawing the responsibility— was knowledge until now. A project turns it into a product. And this product in particular is the one an employer recognizes instantly: the difference between "I know n8n" and "I can walk into a messy operation, understand it, and say with grounds what needs fixing first" is exactly what separates someone who executes tasks from someone who's trusted with a system. The audit is that second thing made visible.

Connection with the module: this project brings the six previous lessons together into a sequence. The classification is lesson 3; the calibrated checklist is lesson 4; the inventory and tags are lesson 6; the responsibility map is lesson 7; and the judgment that runs through all of it —what production is, what an owner is, what a promise is— comes from lessons 1 and 2. There's nothing new to learn here: there's something to do with everything learned. And its output looks ahead: the final report orders modules 2 through 8, because it tells them which workflows and in what order to apply each technique.

What an audit is and why it's delivered, not just thought

Before doing it, it's worth being clear about what a readiness audit is, because the word "audit" scares more than it should.

What it is. A production-readiness audit is, simply, looking at each workflow in a catalog and honestly answering two questions: how important is it? and what is it missing to be as protected as its importance demands?. The result is a map of debts: not "it's fine" or "it's broken," but "this workflow is critical and it's missing these four things; this one is convenient and it's fine as it is." It's a diagnosis, not a repair.

Why it's delivered and not just thought. Because an audit that lives in your head isn't an audit, it's an intuition. The entire value is that it be a document: something that can be read, discussed with the team, shown to whoever decides the budget, inherited by whoever replaces you, and —most important— used as an ordered to-do list. The same idea the whole module pursued: getting the knowledge out of your head and putting it where it survives and can be acted on.

The analogy. It's exactly what an inspector does before a building opens. They repair nothing: they walk through, check, and deliver a report that says "these emergency exits are fine, this extinguisher is expired, this staircase needs a railing before opening to the public, and this storeroom can wait." The report isn't the repair work; it's what makes the repair happen in the right order and keeps anyone from forgetting the expired extinguisher. You are the inspector of your own catalog, and this project is your report.

A note of reassurance before starting, because audits intimidate: finding many debts isn't a bad result, it's the result. An inherited catalog without a previous audit always has debts —that's why it hadn't been audited. A report with twelve workflows missing something doesn't say you worked badly; it says someone finally looked. The shame would be not looking.

The procedure: five steps

The audit is done in five steps, and each one produces a piece of the deliverable. Remember the module's rule: you do this on your instance; the guide runs nothing. The steps describe what to look at and what to write, not commands to run.

Step 1 — Build the base inventory

Start with the list, which you already built in lessons 1 and 6. One row per workflow, with what it does in one line and which systems it touches. If you don't have it written yet, this is the moment: you can't audit what isn't listed.

What to expect. In a real inherited instance, this step alone already produces findings before classifying anything: workflows nobody recognizes, forgotten test copies, names that say nothing. Note them; they're part of the audit. For Terra Market we start from the catalog of eighteen you already know.

Step 2 — Classify with the matrix

For each workflow, the two questions from lesson 3, without opening the workflow: if it fails and nobody recovers it, what is lost? (criticality) and if it goes wrong, who fixes it and how? (reversibility). Write each one's cell.

This is Terra Market's matrix, which you already built in lesson 3 and now formalize as part of the deliverable:

CLASSIFICATION — Terra Market — 18 workflows

  Workflow                 Criticality   Reversibility
  ──────────────────────────────────────────────────────
  order-sync               Critical      Irreversible
  invoice-issue            Critical      Irreversible
  refund-process           Critical      Irreversible
  seller-payout            Critical      Irreversible
  error-handler            Critical      Correctable     (infrastructure)
  dead-letter-watch        Critical      Correctable     (infrastructure)
  shipment-notify          Important     Correctable
  seller-commission-calc   Important     Correctable
  support-ticket-triage    Important     Correctable     (uses AI)
  seller-onboarding        Important     Correctable
  daily-ops-report         Important     Correctable
  inventory-update         Important     Self-correcting (escalates if sustained)
  catalog-sync             Important     Self-correcting
  price-sync               Important     Self-correcting
  review-sentiment-tag     Convenient    Correctable     (uses AI)
  abandoned-cart-reminder  Convenient    Correctable
  review-request           Convenient    Correctable
  weekly-sales-digest      Convenient    Correctable

Step 3 — Run the calibrated checklist

Now the part that turns the classification into a map of debts. On each workflow you run the ten items from lesson 4, with the demand its cell warrants, and you note which mandatories it meets and which it doesn't. You don't need the detail of the ten for all eighteen —that would be overwhelming and not very useful; it's enough to mark, per workflow, how many and which mandatories it's missing.

To keep from drowning in detail, the audit is summed up in a single metric per workflow: the gap, which is how many of its mandatory items are unmet. A critical×irreversible has ten mandatories, so its gap can be big; a convenient has two or three mandatories, so its gap is small by definition. That's exactly what you want: the calibration makes the gap come already weighted by importance.

What to expect. On a freshly inherited instance, where almost nothing is configured, the criticals will show big gaps —they're missing almost all their many mandatories— and the convenients small gaps —they have few mandatories and with luck they meet them. That's not a defect of the method: it's the method working. A critical's big gap is an alarm; a convenient's small gap is reassurance.

Step 4 — Add owner, promise, and responsibility

Complete each row with what n8n doesn't store and that comes from lessons 2 and 7: the owner (a person, almost never you), the measurable promise (even if today it can't be verified), and a responsibility note if the workflow depends on a fragile external system. This is where the audit stops being technical and becomes organizational: the empty "owner" column is, almost always, the biggest finding and the cheapest to fix.

Step 5 — Order and choose the first three

With all of the above, order the catalog by priority and choose the three that need fixing first. This is the heart of the deliverable, and it deserves its own section, because how you choose the three is what demonstrates you understood the module.

How the first three are chosen

Here's the decision an employer would want to see you make. It's not "the three most critical" plainly —that would be collapsing the axes, the mistake lesson 3 fights. It's a decision with an explicit criterion, and the criterion combines three things:

1. How serious and how irreversible it is (the cell in the matrix: how close you get to the red corner).
2. How exposed it is right now (its gap: how many mandatories it's missing today).
3. How hidden its risk is (whether its danger is obvious and already watched, or whether it's a blind spot nobody looks at).

Let's look at Terra Market's ranking and choose with that criterion, defending each choice and each exclusion.

The maximum-priority group is the four in the red corner: order-sync, invoice-issue, refund-process, and seller-payout. All four are critical×irreversible, and on an unprotected instance all four have a big gap. As a group, they're the ceiling of priority. The question is which three, of the whole catalog, get fixed first, and to answer it you have to look beyond the cell.

The three chosen: order-sync, seller-payout, and inventory-update. And here's the why of each one, which is what you have to be able to defend:

1. order-sync — the undisputed number one. Critical×irreversible, 1,200 executions a day, the highest volume among the criticals, and exposed doubly: it receives webhooks from storefront that sometimes duplicate, and it writes to an erp that's slow at peak. Its gap is big and its blast radius is the highest in the catalog —customer, warehouse, support, trust. There's no debate: if you could only fix one, it would be this one. It's also the workflow on which the guide builds its main example in modules 2, 3, and 4.

2. seller-payout — the critical that's scariest for being rare. Critical×irreversible that moves money outward —a transfer made isn't undone— and double-edged: not paying leaves a seller without their money, paying twice takes out extra money that doesn't come back. But the reason it makes the first three isn't only that: it's that it runs at month close, so it fails rarely, and you already know from lesson 4 that what almost never fails almost never gets exercised, so its error handling —if it exists— could have been broken for months without anyone knowing. A critical×irreversible that's also never tested because of its own frequency is the most dangerous combination there is. It also represents its cell neighbors —invoice-issue, refund-process— which are fixed with the same work.

3. inventory-update — the blind spot. And here's the choice that demonstrates you understood the module. inventory-update is only important, not critical, and self-correcting, the most benign reversibility. By cell, it shouldn't be among the first three. It gets in through the third consideration: its risk is hidden. Its criticality isn't a fixed point —it escalates to critical when the failure is sustained— and today nothing detects the sustained failure. Nobody watches the pattern. That means Terra Market could be selling with stale inventory for hours without any alarm going off, ending in orders that can't be fulfilled. It's a critical risk disguised as important, and the disguised risks are the ones that do damage, because nobody watches them. Also, fixing it well builds the "watch the streak, not the execution" pattern that serves its neighbors catalog-sync and price-sync.

The exclusions, which also have to be defensible:

• invoice-issue and refund-process land just below the cut, and not because they're less important —they're pure red corner— but because seller-payout represents them: all three are critical×irreversible that move money and are fixed with the same work, so attacking seller-payout first leaves the path drawn for them. In a real plan they'd go immediately after, in the second batch.
• shipment-notify is tempting for its volume (2,500/day) and because its duplication already generates tickets today. But it's important×correctable: its damage is a recoverable annoyance, not an irreversible loss. Its risk is visible and bounded, not hidden. It goes soon, but after the three irreversible ones.
• error-handler and dead-letter-watch are infrastructure criticals, and there's a strong argument to move them up: if they fail, you're left blind to the others. The reason they're not in the first three is one of sequence: they become indispensable once you already have error handling to report, which is what you build by fixing order-sync. They're fixed in parallel with module 2, not before.

What to expect. Notice the shape of the reasoning, because it's the real deliverable —more than the list of three. None of the three choices was justified with just "it's critical." order-sync got in through cell + exposure; seller-payout, through cell + risk-from-rarity; inventory-update, through hidden risk despite a low cell. And no exclusion was "it doesn't matter": all will get fixed, in a grounded order. An employer who reads this doesn't see a list; they see a criterion. And the criterion is what gets hired.

The deliverable: the audit report

All of the above comes together in a document. Here's how Terra Market's final report looks —the one that would be your deliverable:

PRODUCTION-READINESS AUDIT — Terra Market
Date: <today>   ·   Audited by: <your name>   ·   18 workflows in production

── EXECUTIVE SUMMARY ──────────────────────────────────────────────
The 18 published workflows were audited (~4,000 exec./day). All operate
without ever having gone through a readiness review. Findings:
 • 4 critical×irreversible workflows without verifiable error handling.
 • No workflow has an assigned business owner (all fall on the operator).
 • No measurable promise is written or can be verified today.
 • 1 hidden critical risk: inventory-update doesn't watch sustained failure.
 • At least 1 opaquely-named workflow to investigate/archive.

── THE THREE TO FIX FIRST ─────────────────────────────────────────
1. order-sync      critical×irreversible · highest volume and radius · big gap
   → Start with error handling (module 2): set aside and reprocess.
2. seller-payout   critical×irreversible · moves money · rare failure = untested
   → Verify and TEST its error handling before the next month close.
3. inventory-update important×self-correcting · hidden sustained-failure risk
   → Detect the failure streak (module 4), not protect each run.

── PLAN BY MODULE (the work that follows) ─────────────────────────
Module 2  Error handling         → order-sync first; then the red corner.
Module 3  Debugging/replay       → on order-sync when it fails.
Module 4  Observability          → measurable promises + streak alert (inventory).
Module 5  Credentials            → least privilege on the erp key (9 use it).
Module 6  Performance            → order-sync at the 21:00 peak.
Module 7  AI cost                → cap on support-ticket-triage and review-sentiment.
Module 8  Runbooks and on-call   → runbook by symptom for the three above.

── FULL CLASSIFIED INVENTORY ──────────────────────────────────────
(the 18-row table: workflow · what it does · criticality · reversibility ·
 systems · owner · promise · gap · notes)

Notice the three parts and what each one does. The executive summary is for whoever won't read the eighteen rows —whoever decides the budget, whoever hired you— and has to understand the state in thirty seconds. The three to fix first is the decision, with its compressed why. And the plan by module is what turns the audit into the map of the rest of the guide: each module to come already knows which workflow and with what objective it's going to work on. The full table is at the end, as backup, for whoever wants the detail.

Why this report is the guide's work plan. Look at it again: the "plan by module" section is, literally, the syllabus of modules 2 through 8 landed on Terra Market. Module 2 isn't going to ask "on which workflow do I build the error handling?": the audit already answered it, order-sync first. Module 4 isn't going to ask "which alert is the most urgent?": the audit already pointed to inventory-update's streak. That's the ultimate usefulness of auditing before operating: the rest of the work stops being improvised and moves to executing a plan. Without the audit, each module would begin by deciding where to apply itself, which is precisely the decision that gets made worst in the heat of the moment.

Common mistakes

Auditing to repair on the spot (practical, and about sequence). What happens: when going through a workflow and seeing it's missing something, the temptation is to fix it right there before continuing. Two hours later you have one improved workflow and seventeen unlooked-at, and you lost the whole-catalog view that was the point of auditing. Why it happens: repairing feels productive; inventorying feels bureaucratic, just like with the credential inventory. How to catch it: if you opened a workflow's editor to change it during the audit, this is it. How to fix it: the audit is diagnosis, not repair —the inspector doesn't repair the extinguisher, they note it. Finish looking at the eighteen before touching one. The repair comes after, in order, guided by the report. A whole catalog looked at badly for the sake of repairing one well is a bad deal.

Choosing the three only by the criticality tag (conceptual). What happens: the catalog gets ordered by "critical > important > convenient" and the first three criticals on the list get chosen, without looking at exposure or hidden risk. The result leaves out inventory-update —which is only "important" but hides a critical risk— and doesn't distinguish among the four in the red corner. Why it happens: the criticality tag is the most visible and ordering by it is the easiest. How to catch it: if your justification for the three chosen is "they're the three most critical" and nothing more, this is it. How to fix it: the criterion has three parts, not one: cell, current exposure, and how hidden the risk is. The case that proves it is inventory-update: it gets into the first three despite not being critical, because its risk is disguised and nobody watches it. Auditing well is seeing the risks the tag hides.

Delivering the table without the report (practical). What happens: the eighteen-row table gets made with all its classification and that gets delivered as the audit. Whoever receives it —who maybe doesn't know the detail— sees eighteen rows and doesn't know what to do with them: not the general state, not where to start. Why it happens: the table is the hard work and it feels like the deliverable; the report seems like "just a summary." How to catch it: if your deliverable doesn't have a thirty-second executive summary or a "start with these three" decision, this is it. How to fix it: the table is the backup, not the product. The product is the report that interprets it: what you found, what it means, and where to start. An audit without a recommendation is a pile of data; with a recommendation, it's a decision. The second is what gets hired.

Exercises

Exercise 1 — Defend an uncomfortable choice. A coworker reviews your report and objects: "How do you put inventory-update among the first three and leave out invoice-issue, which is critical and irreversible? You're prioritizing something important over something critical." Answer them with an argument that uses the three parts of the selection criterion.

See solution

A possible answer:

"You're right that invoice-issue is more serious by cell —critical×irreversible versus important×self-correcting— and that's why it's in the second batch, not excluded. But choosing the first three isn't just ordering by cell; it's three things. The first, the cell, does favor invoice-issue. The second, current exposure: both have a big gap. The third is the one that decides, and it's how hidden the risk is. invoice-issue's risk is obvious —everyone knows issuing invoices matters, and if it fails it's noticed fast because someone's waiting for their invoice. inventory-update's is disguised: it seems harmless because it's self-correcting, but it escalates to critical when the failure is sustained, and today nothing watches the sustained failure. We could be selling with stale stock for hours and not find out until the orders we can't fulfill arrive. A critical risk nobody watches is more urgent to uncover than a serious one everyone watches. That's why inventory-update goes first: not because it's more important than invoice-issue, but because its danger is hidden and invoice-issue's isn't. And as soon as I finish with inventory-update, invoice-issue is next, with the same work as seller-payout."

Why it works: the answer doesn't deny the objection —invoice-issue is more serious by cell— but introduces the dimension the objection ignores: the visibility of the risk. And it doesn't exclude invoice-issue, it sequences it. Prioritizing isn't saying what matters and what doesn't; it's saying in what order, and why that order.

Exercise 2 — Write your catalog's executive summary. Take your real catalog (or Terra Market's) and write just the executive summary of its audit: five or six bullets that tell someone who doesn't know the detail what the general state of readiness is. Remember it should read in thirty seconds and that whoever reads it decides priorities or budget.

See solution

There's no correct summary, but there are signs it's well written. A good executive summary:

• Starts with the scale, not the detail. "X workflows audited, ~Y executions/day" situates the reader before telling them about problems.
• Reports findings, doesn't describe workflows. "4 criticals without verifiable error handling" is a finding; "order-sync validates orders and creates them in the erp" is a description that doesn't help the decider.
• Names the hidden risk explicitly. If your catalog has an inventory-update —a critical risk disguised as minor— that bullet is the most valuable, because it's the one nobody else was going to see.
• Includes the organizational finding. "No workflow has a business owner" or "the whole operation falls on one person" is as important as the technical ones, and speaks louder to whoever decides budget, because it's a continuity risk.
• Neither exaggerates nor minimizes. Neither "everything is broken" (false and alarmist) nor "generally fine, with details" (false and reassuring). The correct tone is the inspector's: facts, ordered by severity.

The proof that it came out right: give it to someone who doesn't know your workflows and ask them, thirty seconds later, "where would you start?". If they can answer, the summary does its job.

Why it works: the executive summary is the part of the report most people will read and the one least practiced to write. Training yourself to compress a whole catalog into six actionable bullets is an operator skill as much as configuring a retry —maybe more, because it's the one that gets the time and budget to do everything else.

Exercise 3 — Do the full audit (the project). This is the module's project. On Terra Market —or on your instance if you have one— produce the complete three-piece deliverable: (a) the classified inventory of the eighteen, with criticality, reversibility, systems, owner, and promise; (b) the gap of each one (how many mandatories it's missing by its cell); and (c) the report with executive summary, the three to fix first with their three-part why, and the plan by module. Store it where the team sees it, with a date and your name.

See solution

There's no single correct audit —it depends on your catalog and your judgments— but there are clear criteria that you did it well:

On the classified inventory (a). It should have the eighteen rows, each with its cell justifiable per axis. If you come out with almost everything critical, you reviewed with fear, not with judgment (reread lesson 3). If the "owner" column is almost all empty or with your name, that's not a mistake in your table: it's the finding, and it goes in the executive summary.

On the gaps (b). They should come weighted by cell: the criticals with big gaps (many missing mandatories), the convenients with small gaps (few mandatories). If a convenient came out with a big gap, you probably demanded too much of it —you didn't calibrate. If a critical came out with a zero gap on an untouched inherited instance, you probably demanded too little —look again.

On the report (c). It's the piece that separates a real audit from a table. It has to have the three parts: a thirty-second executive summary, the first three with a why that uses the three considerations (cell, exposure, hidden risk) and not just the criticality tag, and the plan by module that ties each following module to a workflow and an objective. And —the final proof— it has to be stored where the team sees it, with a date and a responsible person, because an audit on your laptop dies with you, just like the lesson 6 inventory.

How to know you finished: if you can hand this document to someone who's going to take charge of Terra Market tomorrow, and that person knows —without talking to you— what's there, how prepared it is, and where to start, then the audit fulfills its purpose. That is, moreover, the rehearsal of the whole guide's final deliverable: the module 8 operations kit, which begins precisely with this audit and ends when all of it is resolved.

Why it works: the project invents nothing new; it executes the six previous lessons on a real case and produces a defensible document. And its real exam isn't that it be "complete," but that it be useful to someone who isn't you, which is the definition of operating well that runs through the whole guide.

Summary and next step

In this project you turned the module's judgment into a product. You learned that a readiness audit is a diagnosis, not a repair —the inspector who walks through the building and delivers a report, without fixing the extinguisher themselves— and that its entire value depends on it being delivered as a document, not on being thought. You followed the five steps —base inventory, classification with the matrix, calibrated checklist, owner and promise and responsibility, and the final ordering— each one producing a piece of the deliverable. You chose the three to fix first with a three-part criterion: order-sync for cell and maximum exposure, seller-payout for being a critical×irreversible that's almost never tested because of its rarity, and inventory-update for being a critical risk hidden behind an "important" tag that nobody watches today; and you knew how to defend the exclusions —invoice-issue and refund-process to the second batch, shipment-notify for being visible and correctable, the infrastructure in parallel with module 2. You assembled the report with its three parts —executive summary, the first three, plan by module— and saw why that report is, literally, the work plan for the seven modules that follow: each one already knows which workflow and with what objective it's going to work on.

With this you close module 1. You no longer just know how to build workflows: you know how to look at a whole production catalog, understand it, classify it, say what each one is missing and in what order to fix it, and do it in a way that another person can continue your work. That's the judgment that holds up everything else.

Module 2 takes the first line of your plan and executes it: robust error handling on order-sync. You're going to build the five layers of defense —the retry that heals itself, the error branch that sets aside the bad item, the deliberate failure, the global error workflow, and the notification with judgment— so that the 03:07 incident from lesson 1 ends in answer B, not A or C. The audit said where to start; module 2 begins.

Resources

• Run security audits — n8n Docs — n8n's built-in security audit, which automatically reports things like unused credentials and risks. A technical complement to this lesson's readiness audit, useful in step 1 for discovering what you didn't remember.
• Manage workflows — n8n Docs — the management index: tags, history, settings, and organization, the tools with which the inventory is built and classified.
• Tag workflows — n8n Docs — for tagging the catalog by criticality and system during the audit, as in lesson 6.
• Workflow settings — n8n Docs — the Error Workflow field and execution saving, which the checklist audits in the behavior-on-failure and trail items.
• Handle errors gracefully — n8n Docs — the base page for module 2, which is the first line of the work plan this audit produces.