Model what the press can make. Refuse what it cannot. Output print-ready.

How the fail-closed pipeline works

A print job moves through the pipeline in a fixed order. Each step is a gate; the job cannot advance until the current gate passes. The pipeline is fail-closed: any failure stops the job at the gate that caught it and returns a plain-language reason. There is no silent degradation.

1. Printer assignment. A publication is assigned to a printer or supplier. The assignment triggers a profile resolution: resolveCapabilityProfile looks up the vendor’s CapabilityProfile. If the vendor has no profile on record, resolveCapabilityProfile returns the EMPTY profile — hasData=false, every capability set empty, every publication type unsupported. The pipeline then runs against that empty profile, which denies everything. A printer with no declared capabilities offers nothing.
2. Capability gate before offering. Before a cover option, a finishing treatment, a paper stock, or any other physical attribute is presented to the adviser as available, capabilityFor checks the profile. An undeclared attribute returns supported=false with a reason the UI surfaces as a disabled tile with a whyUnavailable label. The adviser sees only what the assigned printer can actually produce. There is no option presented that the printer cannot run.
3. Publication-type gate before submit. assertProducible checks the publication type first. A book whose type — newspaper, literary magazine, yearbook, class storybook, event program — is not in the profile’s supportedPublicationTypes list is denied immediately with a 422 and a plain reason. A printer that does not produce newspapers cannot receive a newspaper. A printer with no capability data cannot receive any job.
4. Full producibility gate before manifest build. assertProducible then iterates every requested physical attribute and checks each against the profile. The first unsupported dimension or out-of-limit value throws ProducibilityDeniedError with a machine code, a human-facing reason, and a FERPA-clean detail bag of physical-spec tokens only. The job does not proceed to manifest build until every attribute clears.
5. Preflight against the profile. The manifest and manifest-validation layer preflight the complete job against the same profile used at the gate. Preflight confirms that the assembled artifact — page count, trim, bleed, color system, font embedding, TAC cap, PDF dialect — matches what the profile expects. A job that fails preflight does not proceed.
6. Print-ready render through the single facade. The render facade (check:render-facade invariant, one facade over @homeroom/pdf) re-runs the render gate server-side before it renders. The gate checks the scene a second time against the concrete render facts — the same profile, the same constraints — so there is no divergence between what preflight passed and what the renderer produces. The facade returns a render job reference; the worker produces the print-ready artifact and lands it as a Photo record.
7. Plant send (early access). The plant-send path takes the print-ready artifact and the manifest and submits them to the production plant. This step is wired and switched off. When it is enabled, the plant receives only jobs that have cleared every prior gate. A plant is never handed a file it cannot run — the gate is upstream of the send, not a note attached to the submission.

Refusal is the feature

The most important behavior this pipeline has is what it does not do. It does not submit a job to a plant that cannot run it. It does not offer a finishing option a printer has never declared. It does not present an interior stock as available when the profile is silent on it. It does not pass a newspaper to a vendor whose declared publication types are yearbooks only. It does not accept a tip-in quantity above the declared maximum. And when a vendor has no capability data at all, it offers nothing — it does not fall back to a generic template of what a “typical” printer can do.

This matters because the alternative — offering options optimistically and catching errors at the plant — produces real production problems. A job that reaches a plant with a finishing treatment the plant cannot run requires manual intervention: a call, a correction, a resubmission, a delay. A job that reaches a plant with the wrong stock requires a reprint. A job that reaches a plant with a publication type it does not handle requires re-routing after the fact. These are not edge cases; they are what happens when the system does not enforce capability at the point of offer.

The fail-closed gate runs at offer time, before the adviser makes a selection. By the time a job is assembled, every attribute in it has already been checked against the assigned printer. The manifest builder, the preflight step, and the render facade check again — authoritatively, server-side, at the gate before submission. A plant that receives a file through this pipeline receives a file it can run, because a file that cannot be run does not leave the pipeline.

The why-unavailable reason system is the UI-facing side of the same principle. When a tile is disabled because the assigned printer does not support a finishing option, the UI shows a plain-language reason from the profile: “The assigned printer does not offer the finish [value]. It is not on this printer’s list of options.” The adviser understands why, can assign a different printer, or can contact us to confirm the printer’s actual capabilities. The system is transparent about what it knows and what it does not.

How this differs from photolab.software and mailing.software

These three products share a platform but are distinct operations. Confusing them leads to looking for production-press capability modeling in the wrong place.

printlab.software is the production-side press and print stack: capability profiles per vendor, fail-closed producibility gating, preflight, and print-ready render. It is the layer a printed publication passes through on its way to a plant. It answers the question: can the assigned printer actually produce this job, and if so, is the output print-ready?

photolab.software is the photographic and package-lab side: order intake for school portrait packages, the PSPA/pony-sort routing logic that assigns a lab order to a vendor, and the lab-routing module (@homeroom/lab-routing) that manages the vendor dispatch. Its concern is the fulfillment side of a school portrait order — which lab receives which order, how the packages are sorted, how the tracking flows back. It is not the press production layer; it is the portrait-fulfillment and vendor-routing layer.

mailing.software is the postal/print-and-mail operations home: the layer that manages the outbound mail operations for a printed piece after it leaves the press. Its concern is addressing, presort, USPS compatibility, and the mailing side of a print-and-mail job. It is not the capability-modeling or preflight layer; it is the mailing-operations layer.

A yearbook that is designed in the production editor, preflighted through printlab.software, sent to a plant, and then mailed to a school touches all three layers at different points. The design and preflight live here. The portrait-package order that feeds the yearbook portraits lives at photolab.software. The outbound mailing of the finished book lives at mailing.software. They are separate operations on the same platform, not overlapping products.