Sovereign Commerce
The 90-Day E-Commerce
Independence Audit

The audit is designed to be executed, not read. It assumes an operating e-commerce business of any size — a hundred SKUs or twenty thousand — and it produces, over ninety days, a documented account of where that business actually stands: what it controls, what it rents, and what fails when a dependency is removed.

The four phases run in sequence. Each contains working material — procedures, worked examples from production systems, and fill-in worksheets — and each closes with a scored diagnostic.

In this web edition the diagnostics are interactive: selections are stored on your device and the scorecard computes continuously. In the print edition the same tables are completed in pen. The two editions are identical in content; the web edition of every WestNet manual remains free to read in full.

Companion software: the systems this manual audits for exist as production code — the WestNet Commerce Engine. The audit does not require it, and the manual is complete without it. Licensing terms appear once, on the final page.

The ninety days start whenever you are ready. But three moves, made in your first seventy-two hours with this manual, remove most of the fear before the audit even begins:

1. Hours 0–2: take your catalog back. Run every platform's export — products, prices, quantities, order history, images if offered — and save the files somewhere the platform cannot touch. This single act passes Diagnostic 1.03 and ends the worst-case scenario: whatever happens to any account after today, the catalog is yours. Most readers report this as the moment the anxiety drops.
2. Day 1–2: secure the ground. Confirm the domain is registered to you (not to an agency, a platform, or a former developer), with auto-renew on a payment method that will not silently expire. If there is no domain, register one tonight — it costs less than lunch and it is the one asset in commerce nobody can suspend.
3. Day 2–3: power on the machine. A spare desktop in the office or a modest virtual server — the standard web-server / scripting / database stack from §2.1, default install. It does not need to be pretty and nothing customer-facing depends on it yet. It needs to exist, so that every exercise in Phases 2 through 4 has somewhere real to land.

Everything in the four phases descends from these ten statements. Each is stated once here and then enforced by specific diagnostic items later in the manual. Each one exists because its violation, at some point in twenty years of operation, produced a documented failure.

1. Every platform you do not run makes you a tenant. Tenancy is an acceptable arrangement for a sales channel and a fatal one for a foundation.
2. There is exactly one master record. One database decides what exists, what it costs, and how many remain. Every other copy is a projection.
3. Marketplaces are satellites. They receive data from the master. They do not write back to it, with the single exception of orders through an audited importer.
4. Every human retype is a defect. A person re-entering data that already exists digitally is functioning as a slow, error-prone interface between systems that should be connected.
5. Propagation latency is measurable, and it is money. The interval between a decision and that decision being live on every channel is quantifiable margin loss.
6. Write, then read back, then believe. No automated write is confirmed until an independent read verifies it — ideally from the public side, as a customer would see it.
7. Locks precede loops. Any scheduled job will eventually run longer than its interval. Without a non-blocking lock, its invocations will stack until they exhaust the machine.
8. Control outranks capacity. Modest hardware you fully control is a stronger foundation than rented infrastructure that can be repriced or revoked.
9. Channels die; catalogs do not. Plan on the assumption that any satellite account can be closed tomorrow. The measure of readiness is the time required to rebuild it from the master record.
10. Automation is complete when the operation passes the 3 a.m. test: orders flow, inventory synchronizes, listings renew, and failures report themselves, with no one awake.

Begin with one written exercise: assume your largest sales channel suspends your account tomorrow at 09:00, without warning and without a stated reason. Document, in the table below, what stops and for how long. This is not a hypothetical scenario; it is a standard event in platform commerce, executed by risk algorithms at scale, and the 2020 crisis multiplied its frequency.

Note that selling on two platforms is not diversification if both use the same payment processor, the same manually-duplicated catalog, and the same class of risk model. Diversification is measured at the level of failure domains, not logos.

Propagation latency is the elapsed time between an operational decision — a price change, a stock-out, a new SKU — and that decision being live on every channel. It is the single most honest measurement of infrastructure quality, because it cannot be estimated flatteringly: it is taken with a clock.

Execute each event below once, in production, and time it to live-everywhere. Human steps count in full; if a step waits until "someone gets to it," the waiting is part of the measurement.

Trace the full life of your product data, from supplier to sold, and record every point where a person re-enters information that already exists in digital form somewhere in the operation. Each instance carries three costs: the wage paid for the entry, the latency it adds, and an error rate that compounds with volume. A price retyped in four systems is not verified four times; it is exposed to four opportunities for a misplaced decimal to reach a public listing.

Multiply the weekly total by fifty-two and record the annual figure. This census is revisited in Phase 4, where each row is either automated, absorbed into the master record, or accepted in writing with a stated reason.

Ask the operation one question: which system decides how many units of a given SKU exist? A sound operation answers in one sentence. An answer that requires qualification — the store says one number, the marketplace another, and a spreadsheet is what staff actually trust — means there is no master record; there are several databases in unmanaged disagreement, and the disagreement is discovered by whichever customer orders the unit that was already sold.

Every oversell in this industry has the same root cause: two systems each believed they owned the quantity, and both sold the last unit. Complete the table for your three fastest-moving SKUs:

The final Phase 1 measurement is the one most sellers have never computed end-to-end: of every hundred dollars a customer pays, how many do you keep? Marketplace selling stacks costs that are individually tolerable and collectively decisive — the referral commission, fulfillment and storage where used, and the advertising that visibility increasingly requires as marketplaces convert search placement into auctioned inventory. Selling on owned infrastructure carries one material per-order cost: payment processing.

The systems that carried a national-scale medical supply operation through 2020 ran on consumer-grade hardware of considerable age. This is stated not as a recommendation for old equipment but as evidence about what actually matters: control, not capacity. Sovereignty does not require a data center. It requires that the storefront, the database, and the files run somewhere that cannot be repriced, suspended, or discontinued by a third party's product decision. A used tower in an office qualifies. An inexpensive virtual server that can be re-imaged and relocated in an afternoon qualifies. A commerce SaaS whose export function defines the limit of what you can take with you does not.

• Own the domain. Registrar account in the business's name, with renewal that cannot lapse silently.
• Own the stack. A web server, a relational database, and a filesystem that can be archived tonight and restored elsewhere tomorrow. The conventional LAMP arrangement remains the reference standard here precisely because it is unremarkable: every failure it can have is documented somewhere.
• Own the backups. A nightly database dump and file synchronization, shipped automatically to a second machine in a second location. A backup that has not been restore-tested is an assumption; the restore is drilled quarterly and timed.
• Engineer within the hardware's limits. Memory, disk age, and concurrency ceilings are design inputs. Phase 4 documents what happens when they are treated as someone else's problem.

Everything in the operation projects outward from one table. The following is the minimum viable master record, refined across thousands of production SKUs; adapt names to your storefront software, but keep every constraint.

Three of these decisions carry most of the weight:

• Integer money. Prices are stored in cents, without exception. Floating-point currency arithmetic eventually prints its rounding error on a public listing.
• A database-maintained modification timestamp. Every synchronization job in Phase 3 reduces to one indexed query — rows changed since the job's last run — regardless of what wrote the row. Incremental sync becomes a property of the schema rather than a feature of any one program.
• A row-locking storage engine. One slow write to one product must not block reads of the whole table. The incident that fixed this rule in place is documented in Phase 4.

Storefront software — an osCommerce-lineage cart, WooCommerce, a purpose-built catalog — either uses these tables directly or is a downstream projection of them. What is not permitted after Day 45 is any channel, spreadsheet, or employee's memory holding a quantity the master does not know about.

An administrative dashboard — including your own storefront's — is one client of the database, and for bulk work it is the wrong one. Forty new SKUs entered through an admin panel is an afternoon of page loads; the same forty SKUs as a single SQL transaction is seconds. Operating directly on the master record is a standard capability of a sovereign operation. It is performed under a fixed discipline:

1. Snapshot first. Before any bulk write, dump the affected tables to a dated file. An error against eight thousand rows is a ninety-second rollback if the snapshot exists, and an incident if it does not.
2. Rehearse with SELECT. Run the exact WHERE clause as a SELECT and inspect the row count and a sample. An expected 120 rows returning 8,000 is the error caught at the rehearsal stage, where it costs nothing.
3. Transactions for multi-table changes. Products, descriptions, and category mappings change together or not at all.
4. Read back before believing (Axiom 6). After the commit, an independent query — count, checksum, spot-check — confirms the result, followed by a check of the rendered public page, since the database and the storefront are separated by every cache layer in between.
5. Record the operation. One line in an operations journal: date, change, reason, row count, snapshot filename.

Between the master record and the outside world sits a format that every system in commerce can produce and consume — accounting packages, marketplace bulk uploaders, courier tools, and a text editor in an emergency. That format is the delimited flat file, and a sovereign operation treats it with the same discipline as the database. The working pattern: one file per purpose, generated from the master, never edited downstream.

• Generated files have exactly one writer. The moment a generated feed is hand-edited, the operation has two masters again. The correction is made in the master and the feed regenerated.
• Event streams are append-only. Orders, signups, allocations: new lines only. Append-only files survive interrupted writes, compare cleanly between backups, and constitute an audit trail at no additional cost.
• Ownership is part of the contract. A file the web application appends to must remain writable by the web application's user. Maintenance performed under other accounts must not alter this. Field Report 1 occurred on precisely such a file.
• Source timestamps are preserved on everything fetched. Supplier files and images mirrored from elsewhere keep their origin modification times; cache logic and future debugging both depend on timestamps that mean something.

Past a few hundred SKUs, product imagery is not managed by hand. It is treated as derived data under three rules:

1. Deterministic naming. The image for product 4117 is p4117.jpg, in one flat directory. Given a product ID, any script, template, or channel exporter constructs the image path without consulting a database or a person. This single convention eliminates an entire category of lookup software.
2. Automated acquisition with a repair loop. New SKUs receive their primary image by script — from a supplier feed, a manufacturer asset, or a staged photo drop — normalized to standard dimensions and written to the canonical name. A daily job walks the catalog for missing or unreadable images and repairs them, so that missing imagery is a metric, not a recurring chore.
3. The catalog stores keys, not paths. The master record holds image_key; recompression, resizing, or relocating storage later touches no database rows.

Identifiers outlive everything else in the operation. A SKU that has been printed on a label, quoted in correspondence, or sold on a channel is never reassigned to a different product. Barcode identifiers additionally carry arithmetic: the final digit of a UPC is a checksum over the preceding eleven, and marketplace ingestion, scanners, and feed validators verify it.

Products are state — they change and the master reflects the change. Orders are the opposite: orders are history, and history is never edited. The order log is append-only from the moment of capture (§2.4's rules apply in full), and it is retained effectively forever, because its value compounds with age in ways that are invisible on the day of the sale:

• Disputes are won with records. Chargebacks, marketplace claims, and courier loss investigations are decided months after shipment, by whoever produces the better paper. The operation that can produce the order row, the label data, the carrier acceptance scan, and a photograph of the sealed parcel wins by default against a claimant with a recollection.
• Shipments are photographed by procedure, not by suspicion. A camera at the packing bench, one frame per parcel as it is sealed and labeled, filed under the tracking or order number. The cost per parcel is seconds; the archive turns "we always package properly" from an assertion into evidence. Several photographs in this manual — including Figure ii-1 — exist only because of this procedure.
• Old orders are a demand dataset. Seasonality, repeat-purchase intervals, and the SKUs that resurrect every winter are all sitting in a decade of order history, queryable in one line against the master record. Operations that purge order history to "keep the database small" are deleting the only marketing research that is both free and true.
• Retention is cheap; reconstruction is impossible. A decade of order rows for a busy catalog fits in less disk than one day of product images. There is no storage argument for purging history — only an incompetence one.

Lawful-basis note: retain what your jurisdiction permits, secure it like the asset it is (the leads-and-logs class of files must never be publicly readable — audit web-server exposure of data files the same way §1.10 audits their ownership), and treat customer data as borrowed, not owned.

Readers who arrive at this manual as pure marketplace sellers — no storefront at all — build one in this phase, on the machine from §2.1, beside the master record. This is less work than platform marketing has taught you to believe, and the software choice matters less than four criteria that any candidate must meet:

1. It runs on your machine. Installed from files you keep, on the stack you control. Anything that only exists as someone's hosted service fails Phase 1 by definition, however good it looks.
2. It gives you the database. Direct access to its tables, so it can serve from — or be wired to — the master record of §2.2, and so §2.3's bulk discipline applies. A storefront whose data you can only touch through its own admin screens is a landlord with extra steps.
3. It is boring, documented, and old enough to trust. The reference implementation has run an osCommerce-lineage cart for decades; WooCommerce on your own box, or any mature open cart, meets the same test. Every failure a boring cart can have has already happened to someone who wrote up the fix. Novelty is a liability in the money path.
4. It can be left. Standard tables, exportable in full, restorable elsewhere. You are not marrying the software; you are renting its rendering layer for as long as it behaves.

The go-live checklist is deliberately short, because ugly and live beats perfect and hosted:

• Domain and TLS on your box — certificates are free and automated everywhere now.
• A payment processor account in the business's name — and, per Diagnostic 1.12, one that shares no kill-switch with your largest marketplace. Add a second processor when volume justifies it; two rails into your bank is cheap insurance the platforms cannot offer at any price.
• The legal pages — terms, privacy, returns — plain and honest; templates abound.
• One real end-to-end order: a real card, a real label off the Zebra or its equivalent, a real parcel with the §3.5 insert, refunded afterward if you like. The first order that flows storefront → master → label → tracking with no platform anywhere in the chain is the moment this manual stops being theory. Most readers place it themselves, and keep the packing slip.

Figure 2-1 · The WestNet UPC Registry — upc.westnet.caThe registry portal: code lookup, instant registration from $10, certificates and barcode assets per code. Twenty-eight years in operation; the identifier infrastructure behind this manual's own catalog number.

With a master record in place, every sales channel is reduced to what it structurally is: a projection of the catalog. Data flows outward from the master through exporters; orders and inquiries flow back through importers; nothing else crosses the boundary in either direction.

Two rules give the diagram force:

• Catalog data moves outbound only. Channel-side "catalog corrections," repricing suggestions, and quantity adjustments never write to the master automatically. Orders decrement quantity through the audited importer; nothing else does.
• Every satellite must be regenerable. The test is concrete: delete the presence on any one channel, then rebuild it entirely from the master record with scripts. If the rebuild requires human recollection of how the listings were configured, the channel holds information the master should hold.

Before paying marketplace fees, extract full value from the channel with none: structured catalog data plus one template yields hundreds of indexable, permanent landing pages on your own domain — each answering a specific buyer question, each terminating at your own checkout.

A worked example from production: a compatibility dataset — which consumable fits which machine, in this case printer cartridges — was rendered through a single template into 127 model-specific landing pages, with clean rewritten URLs, structured-data markup, an automatically regenerated sitemap, and reciprocal links between products and their pages. Each page matches the exact phrase a buyer types when a specific machine needs a specific consumable, and each lands the buyer on the operator's own domain rather than a marketplace results page listing competitors alongside. The pages have no per-month cost and do not expire.

1. Identify the repeating buyer question the catalog data can answer at scale: what fits X, what is compatible with Y, what replaces Z.
2. One template, one query, N pages. Clean URLs by rewrite rule; a search engine should never see a raw query string where a readable path is available.
3. The sitemap regenerates on a schedule from the same data.
4. Landing pages link to purchasable products; product pages link back to their landing pages.
5. These pages are generated projections, so Phase 2's feed rules apply in full: correct the data, regenerate the page. Page 83 of 127 is never edited by hand.

Classifieds — Kijiji in Canada, Craigslist in the United States — are structurally undervalued: free or near-free listings, local buyers with immediate intent, and no ranking algorithm auctioning your visibility to competitors. Their operational friction, which discourages casual sellers at roughly the dozenth manual listing, is precisely what makes them defensible for an operator with generation infrastructure. The engine that operates them at volume has five components:

• Persistent sessions. The posting system authenticates once and persists the session per identity, as a browser would — one clean identity per channel, maintained and refreshed on schedule, operated within the channel's rules.
• A state ledger per channel. A local record mapping each master SKU to its live ad identifier, posting date, and expiry. The ledger is what makes the engine idempotent — a second run posts nothing twice — and it is backed up with the database, because it is one.
• Renewal automation. Classifieds decay by design: ads expire and sink. A daily pass over the state ledger renews what is renewable, reposts what expired, and withdraws what the master has marked sold or paused. Sustained freshness at volume is the entire competitive position, and it is not achievable manually.
• Measured cadence. Volume is not burst. Postings are paced with delays and daily ceilings consistent with an active human seller. Every channel enforces a rate budget, published or not; the operator who exceeds it converts an asset into a banned account.
• Templates from the master. Title, body, price, and images render from master-record fields through per-channel templates. An ad is regenerated, never retyped.

Figure 3-2 · AbdouPost — calgaryfinder.com/AbdouPostThe multi-channel posting engine as a product: one listing in, four channels out, server-side. The architecture on this page — single source listing, per-channel publishers, no client machine — is the satellite doctrine of Figure 3-1 in commercial form.

Nothing in this manual argues against selling on Amazon or eBay; they are large rivers of buyers. The doctrine concerns architecture: they are retail outlets the operation stocks, not systems the operation lives in. The distinction is auditable:

• Listings are generated from the master through an exporter — bulk feed or API as the channel dictates, the master as the source regardless. Listing content that exists only inside a marketplace is catalog data the operation has surrendered.
• Channel quantity is an allocation, not a mirror. Each marketplace receives a budgeted slice of stock sized to its sales velocity. Allocation errors fail safe — a channel undersells — where mirror errors fail as oversells of the whole business.
• Rate limits are handled structurally. Marketplace interfaces throttle, process asynchronously, and fail partially as a matter of course. The exporter queues, retries with backoff, and — Axiom 6 — reconciles after every push: read back what the channel now believes, compare against what was sent, and treat the difference as a work queue.
• Orders enter through one importer that decrements the master and feeds the same fulfillment pipeline as every other channel. One pipeline, several faucets.
• Total channel cost is reviewed quarterly — referral, fulfillment, storage, and the advertising required for visibility — against a written threshold at which the satellite is downgraded or closed. The review is only possible because the architecture makes closure survivable.

The operating assumption, fixed in Phase 1, is that any satellite account can close tomorrow morning. Readiness for that event is a set of standing practices:

1. Nothing irreplaceable resides in a channel. Catalog: the master. Images: owned files under deterministic names. Customer contact: captured to the operation's own records at every lawful opportunity — invoices, package inserts, warranty registration, storefront accounts.
2. One identity per channel, operated within its rules. Account-evasion schemes create a treadmill that ends in the same place with higher losses; the durable alternative to fearing a ban is a business that a ban cannot kill.
3. Every parcel carries the operation's domain. A marketplace buyer costs a commission once; whether the repeat purchase also pays a commission depends on what the customer remembers. A printed insert is the cheapest customer acquisition in commerce.
4. The regeneration drill, executed on Day 70: select the smallest live channel and rebuild its full presence from the master record and scripts alone, in a test run, timed. The resulting figure — hours, if the phases were done properly — is the measured size of the risk that platform dependence holds over the operation.

Some marketplaces — social-network venues and app-only markets — offer no serviceable bulk interface and actively resist automation. This manual does not document techniques against those defenses; any such documentation would be obsolete within a season, and the channels' terms govern in any case. What remains permanently true is that the doctrine does not change: the master record feeds whatever presence is maintained there, the state ledger tracks what is live, the channel justifies its total cost quarterly or is closed, and the harder a garden makes departure, the smaller the share of the business it should be permitted to hold. A channel that cannot be scripted is a channel that must be staffed or licensed — that cost belongs in the quarterly review at its full value, and the staffing works from the same generated templates as everything else, so the manual-entry census stays clean. For operators who want the walled gardens served without building the capability, the managed route is AbdouPost (§3.3, Figure 3-2), which publishes to Facebook Marketplace alongside the open channels.

The order pipeline of §3.4 does not end at "order received." A sovereign operation carries the same discipline through the last physical meter — the label, the printer, and the tracking link the customer refreshes for a week. Each of the three is a dependency most sellers hand back to a carrier or a marketplace without noticing.

• Labels are generated by the pipeline, not by a person in a carrier's web portal. The order record already contains everything a label needs — addresses, weight, service level. In production at Abdou Express, fulfillment produces the shipping label directly from that record: no re-typed addresses (the census stays clean), no per-parcel logins, and batch runs produce a stack of labels in one pass. Which carrier interfaces you use, and on what terms, is between you and your carrier agreements — the architectural point is that label creation is a function of the order record, with the tracking number written back to that record automatically and verified by read-back, like every other write in this manual.
• The printer is an output device of the pipeline, not a dialog box. Thermal label printers — the warehouse-standard Zebra family — accept their own native command language directly over the network: the pipeline renders the label as printer commands and sends them straight to the device's socket on the LAN. No drivers, no PDF, no print dialog, no "fit to page" surprises. An order arrives; seconds later the label is hanging out of the Zebra. The printer becomes as scriptable, and as monitorable, as every other component: a heartbeat job can verify it is reachable exactly the way §4.3 verifies everything else.
• Tracking lives on your domain. When the notification email hands the customer a carrier's URL, the relationship walks off your property at the moment of highest attention. The sovereign pattern is a self-hosted tracking portal on your own subdomain, aggregating every carrier you ship with, so the customer's week of anxious refreshing happens under your brand — the same doctrine as the parcel insert of §3.5, applied to the digital touchpoint.

Figure 3-3 · WestNet Tracking — track.westnet.caThe self-hosted, multi-carrier tracking portal: one query box, seven carriers, ten shipments at once, served from the operation's own domain with its own archive — the customer's post-purchase attention kept on owned property.

One more property separates an owned storefront from every marketplace, and it is not technical: on your own property, nobody is auctioning your customer's attention against you. Open a major marketplace's product page and count what surrounds the buy button — sponsored competitors on the same page as your listing, recommendation carousels, cross-sell rows, program badges, upsell interstitials. That density is not poor design; it is the business model. The marketplace's customer is the advertiser, and your listing is the shelf its ads are sold against.

The cost of that noise lands on two people. The buyer pays in decision fatigue: every additional element on a page competes with the one decision that matters, and a distracted buyer defers, compares, and leaves. The operator pays twice — once in conversion, and once in maintenance, because every widget on a page is code to maintain, cache to invalidate, and a place for failure to hide. Clutter is expensive at both ends of the wire, and the marketplace collects on both.

The reference storefront's homepage carries roughly ninety-six links: a search box, a cart, account controls, category navigation, and products — priced, in stock, with an add-to-cart button. Nothing else. That restraint has held across two decades of the same catalog and two generations of theme, and it is a discipline, not an aesthetic:

• One purpose per page. The homepage sells; the product page sells; the checkout checks out. An element that does not advance the purchase or the navigation is removed.
• No rented widgets. Third-party chat bubbles, tracking pixels, and "engagement" embeds hand your customer's attention — and their data — to someone else's business model, and add someone else's outage to your page load.
• Restraint is performance. A page with little on it is fast on modest hardware. The uncluttered storefront and Phase 4's worker arithmetic are the same doctrine seen from two sides: fewer elements, fewer requests, more customers per gigabyte.
• Noise is a dependency. A storefront stuffed with plugins is a storefront that cannot be moved, cached, or reasoned about. Simplicity is what makes the 24-hour relocation of item 1.02 achievable.

Figure 3-4 · The reference storefront — AbdouExpress.com / Masks.HealthOne master record, projected without noise: Level 1 surgical masks (the 2020 line, still listed) beside operating-system licenses, commercial cleaner, and OEM Toyota parts, each new-arrival card carrying its barcode on its face. Search, cart, categories, products — and no third party bidding for the customer's attention.

Phase 4 opens with the incident that produced most of its rules. It is reconstructed here from logs, in full, because every element of it — the schedule, the lock, the storage engine, the memory ceiling — is an ordinary default that thousands of operations are running at this moment.

The generalized laws, applicable to every scheduled job the operation will ever run:

• Locks precede loops (Axiom 7). Every scheduled job eventually runs longer than its interval. The lock exists for that day, not for the ordinary ones.
• Every job carries a ceiling. A memory limit, a runtime limit, or both. A job that policy cannot terminate will eventually be terminated by the kernel, together with bystanders.
• Worker limits are arithmetic. Available memory, less everything else resident, divided by measured per-worker consumption: that quotient is the honest concurrency ceiling. A configured limit above it is not capacity; it is a scheduled out-of-memory event.

With locks and ceilings in place, each is verified the only way that produces knowledge: by attempting to defeat it.

1. The stacking drill. Artificially extend the synchronization job's runtime past its schedule interval and observe the next invocation exit immediately with a logged refusal. If two instances ever run concurrently, the drill has found the defect at drill cost rather than incident cost.
2. The interruption drill. Terminate the synchronization mid-run, without warning, and re-run it. A correct system heals on the second pass — no duplicate postings, no double decrements, state ledger intact. Idempotency is demonstrated here or it is absent.
3. The load rehearsal. Replay a multiple of the worst recorded hour against the storefront, observing memory alongside response time. A machine that completes the hour at 95% memory has reported its capacity for next month; the rehearsal is where that report is read.
4. The disk-exhaustion drill. Fill the log partition in a test window and observe every job's behavior. Systems are lost to full disks more often than to attackers, and disproportionately on weekends.

Automation is complete when the operation reports on itself to an absent operator (Axiom 10). The monitoring that satisfies this is inexpensive and specific:

• Heartbeats on every job. Each run records its timestamp, duration, rows affected, and result. A single watchdog reads all heartbeats and flags staleness. The critical property is that a job's death is detected by its silence — a job that can only report failure while alive reports nothing in the failure mode that matters.
• Public-side probes. Internal checks report the database healthy while the storefront serves errors to the world. The site is therefore probed the way a customer's browser fetches it — complete request, browser-equivalent presentation — because the operation's own defensive layers will otherwise filter the probe itself. In production this has produced both false alarms (a firewall rule rejecting abbreviated request types that real browsers never send) and masked outages; probing as a customer eliminates both.
• Error-log rates, not only error patterns. A hundred familiar lines a day is a baseline; a thousand familiar lines an hour is an event, regardless of their content. Rate deviation detects the failures that pattern-matching has already normalized.
• One daily digest. A single automated morning summary: orders per channel, heartbeat status, image repairs, the variance report of §4.4, and machine headroom. Thirty seconds of normal readings ends the operator's involvement; one abnormal line defines the day's first task. The digest replaces continuous dashboard attendance, which does not scale and does not rest.

Drift occurs in correct systems: a channel glitch, an importer interruption, a unit sold over the counter and unrecorded. The defense is a nightly variance report comparing three figures per SKU — the master's quantity, each channel's believed quantity, and physical count for a rotating weekly sample. Every variance receives a line: SKU, location, magnitude, resolution. Within a month of operation, zero-variance nights are the norm and the report's function is to make exceptions loud. An oversell reaching a customer is thereafter a rare event with a written postmortem, not an accepted cost.

Return to the manual-entry census of §1.3. Each row is now dispositioned one of three ways: automated (an exporter, importer, or template now performs it), absorbed (the master record made it unnecessary), or accepted — retained deliberately, in writing, with a reason and a revisit trigger. The census is closed when no human touch in the operation is unexamined. The goal is not zero touches; it is zero undocumented ones.

Everything in this phase exists for the fourth quarter, when volume multiplies and every latent defect is called at once. The hardened operation enters peak season under a written playbook, prepared in October, unchanged after mid-November:

1. The freeze window. No schema changes, no new channel integrations, no storefront redesigns, and no "quick improvements" from the first week of the peak until it ends. Every incident in the archive with a self-inflicted cause traces to a change made during load. Peak season runs on the system as rehearsed, or it does not run.
2. The rehearsal has a date. The load rehearsal of §4.2 runs against projected peak volume — last year's peak hour times this year's growth, times a safety factor — no later than six weeks out, leaving time to fix what it finds.
3. Allocations pre-scale. Channel stock allocations (§3.4) are re-budgeted for peak velocity in advance, with the reconciliation loop's cadence increased to match — drift that takes a week to matter in July takes a day in December.
4. Cutoffs are published, then beaten. Carrier deadlines for the season go on the storefront and in the channel listings with margin held in reserve. The reserve absorbs the storm, the courier backlog, and the box that comes back — and every parcel that beats the promise is a review.
5. The digest goes twice daily. The §4.3 morning digest gains an evening edition for the season. Same content, doubled cadence, still no dashboards to sit and watch.
6. Exceptions get a human rota. Automation handles the flow; the playbook names who handles the exceptions — the variance report line, the failed feed row, the customer whose parcel stalled — with hours and a handoff. Undefined responsibility at 10× volume is how exceptions become refunds.
7. January holds the postmortem. One page, written while it is fresh: what held, what strained, what the rehearsal missed. It is the first input to next October's playbook, and the annual proof that the operation learns on schedule.

Four diagnostics reduce to one figure: passes over applicable items, across all fifty-four. In this edition it computes from the selections above; in print, the tally is carried here by hand.

Your answers, worksheet notes, and calendar checkmarks are stored only in this browser — nothing is transmitted. Clear all saved work

Every system in this manual corresponds to a component running in production at Abdou Express and WestNet N.A. — most of them for many years, several of them public. The mapping below is provided so the reader can verify the manual's standing claim: nothing in it is theoretical. Internal mechanics are described at the level of architecture; the operating specifics of any carrier, channel, or defense are the operator's own business, yours and mine alike.

The storefront itself is shown at Figure 3-4 — masks beside operating systems beside OEM parts, one uncluttered grid. On the significance of the Masks.Health address: in 2020 it was the plainest possible demonstration of the whole doctrine — the most demanded product on earth, at the domain that names it, on infrastructure no platform could suspend.

Figure C-1 · The order flow, photographed by procedureFrom the same archive as Figure ii-1, spanning the operation's inbound and outbound sides: mask cartons addressed for medical distribution, batches of outbound mailers and Xpresspost parcels under the operation's own printed labels, cases staged for marketplace fulfillment, and an inbound liquidation pallet feeding the catalog. Addresses and label details obscured throughout. Every frame exists because §2.7 makes the camera part of the packing bench.

Abdou Traya is the founder of Abdou Express, a multi-channel retail operation that has run for three decades on self-hosted infrastructure, listing and synchronizing thousands of SKUs across an owned storefront, classifieds networks, and major marketplaces. By 2020 he had twenty-five years in e-commerce; that year he established Masks.Health under WestNet N.A., applying the accumulated infrastructure to the procurement and distribution of medical mask supply at scale through the global supply-chain failure. The systems described in this manual are the systems that operation ran on, together with the corrections earned from their documented failures. He operates from Calgary, Alberta.

Field operations, in public: AbdouExpress.com · Masks.Health · facebook.com/AbdouExpress · facebook.com/WestNet

Sovereign Commerce · WestNet Operator Series, Field Manual 01 · Catalog UPC-A 7 31985 46105 9
WestNet Publications · WestNet N.A. · Calgary, Alberta · westnet.ca/learning