Pilot Program Guide

[!WARNING] This guide is only valid for Controlled Pilot users and printing offices participating by invitation. General public services (Public Self-Service) are not yet active. Supplier-verification mutations and attaching files to an existing RFQ are disabled by default until their security, idempotency and audit evidence is complete. Re-listing an expired RFQ uses a package-owned command with a required idempotency key and exact revision precondition. The RFQ, immutable revision, audit record and outbox event commit together; stale or pre-migration RFQs fail closed. They are available only when explicitly enabled server-side for the controlled pilot. Opening a dispute is disabled for both the API and the application action in Controlled P0. A different UI entry point does not bypass this boundary; support records the risk through the manual operations channel. Internal resolution, escalation, and timeline writes use the current dispute aggregate inside one server transaction; a stale screen cannot authorize a closed dispute. Escalation and timeline retries are exact and do not repeat the mutation or its notification; changed command data is rejected. The domain policy accepts escalation only for canonical active dispute states; terminal, unknown, and already-escalated states fail closed.

Welcome to the NowToPrint Printing Pilot Program! This program is an exclusive controlled phase conducted with a select group of buyers and print shops. All print product categories — books, magazines, catalogs, brochures, packaging, labels, large format and more — are open for quote requests from day one. The system is designed to process your printing orders in the most secure way possible.

---

1. Minimum Information and Missing Technical Details

Creating and publishing an RFQ to print shops requires Name + Email, what is being printed (or a canonical product), a meaningful product type, and a positive quantity explicitly provided by the buyer. If any of these three critical job facts is missing, the system does not publish the request; it asks for the missing information in the same conversation. Because no RFQ exists yet, no tracking code or token is issued at this stage.

• other, an empty product type, an artificial quantity of 1, or quantity supplied only by a system assumption does not satisfy the critical-information gate.
• Missing non-critical details such as size, paper, finishing/binding, city, deadline, or file do not prevent an otherwise complete RFQ from being saved and published.
• These gaps can create a Manual Review signal and disable risky automation without making the RFQ private by default.
• A real Tracking Code and private Tracking Token are issued only after the RFQ is actually created.

---

2. What Does "Your Request is Under Review" Mean?

When you submit your request, if there are missing or incorrect technical parameters, the system forwards it to our steward queue.

• Who is a Steward? A NowToPrint technical operator who checks and corrects request parameters so print shops can provide accurate quotes.
• Communication Step: Our steward team may contact you via email or phone to complete missing or incorrect details. Review can block production release, ERP handoff readiness, future Auto-Bid policy readiness, or final quote certainty, but it does not mean the RFQ waits for admin approval before first publication. Automatic external production and Auto-Bid dispatch remain disabled during the controlled pilot.

---

3. Receiving and Accepting Bids

If admin visibility is not paused and scope review allows it, the request is visible to eligible pilot print shops.

• Print shops submit their best pricing quotes for your project.
• You will be notified of quotes via email, and they will be listed on your tracking portal.
• The comparison screen loads quote rows only after canonical buyer-organization or supervised platform-operations access is granted. A matching raw user id alone does not grant access.
• You can choose the quote that suits you best by clicking "Select This Quote".
• If the same actor retries the same acceptance request because the connection drops, the system returns the first committed order; it does not create or charge a second order. Reusing the request key for changed details is rejected. A different account using the same text key does not share the first account's command or order identity.
• If you opened the request as a guest, the private tracking link is preserved when you sign in or create an account with the same email. A different email cannot claim the request in self-service. If the account is still pending onboarding, order creation waits until onboarding is complete and then returns you to the same private tracking link.

---

4. Payment Readiness and Wire Transfer Process

Once your order is created, the system directs you to the payment readiness screen.

[!IMPORTANT] During the pilot phase, automatic credit card charging is disabled. The platform collects the payment and pays the print shop after delivery, minus commission. The default public pilot payment options are limited to Wire Transfer / EFT and approved open account terms. Provider credentials alone cannot enable card checkout; a separate server-side launch gate must also be explicitly enabled. document_payment, check, deferred_terms and direct_deal are not public checkout options; they are used only in operator-approved corporate contract or import scenarios. The production gate does not open until payment or supplier terms approval is complete. If an order record has an unknown version, unreadable state, or inconsistent payment amount, it is quarantined for operator repair; production does not proceed from guessed defaults.

---

5. Why Doesn't Production Start Immediately? (Production Hold)

Once your payment is verified, a production_ready_after_payment signal is written to your order. However, printing presses do not start automatically.

• Why is there a Hold? During the Controlled Pilot, file quality, plate compatibility, and material stock availability are verified one last time manually by our steward team.
• Manual Permission: Following these checks, the steward approves the order, and the production instruction is manually sent to the print shop. This safeguard reduces error and delay risk. Automatic external production integrations will remain locked (on hold) throughout the pilot.

How pilot data cutover is protected

Before a launch cutover, Marketplace operations use a registry-based dry run and verify a current backup. Transaction data cannot be reset without separate data-owner and product-owner approval, and shared print-shop, notification and webhook records are outside Marketplace bulk-delete authority. A cutover is not accepted until the full registry is recounted and revision, receipt and financial orphan checks report zero. These controls do not mean a public launch is approved; the protected backup and restore drill remain launch evidence.