Seven Orders for the File Factory
A customer asks for a job to be done.
AI delivers a file that does it.
Here is what seven of those orders could look like.
From the idea to the order
Make the product specific enough to buy.
“AI can make spreadsheets” describes a capability. “Give me a workbook that tells me how many cases to reorder” describes a product.
In The File Factory, I argued that files can be extraordinary finished goods because they carry calculations, instructions, designs, and reusable methods into the customer’s existing workflow. The next step is to turn that idea into recognizable orders.
Below are seven worked examples. The businesses, quantities, filenames, and previews are illustrative specifications, not reported customer deliveries. They show what would need to be supplied, what an AI production system would make, and how the finished artifact would earn its value.
For these examples, “on its own” means completing file production after the inputs and acceptance criteria are agreed. The factory has access to the relevant software and can inspect its output. Missing information still needs an answer; a machine cannot infer a customer’s real requirements from nothing.
The replenishment order / .xlsx
Tell me what to reorder.
The sample brief
“We order in full cases. Build a workbook that uses demand, lead time, stock, and incoming orders to recommend the next purchase.”
The customer suppliesItem identifiers, average daily unit demand, current inventory, confirmed incoming units, supplier lead times, case sizes, and an approved safety-stock rule.
The delivered files
- reorder_planner.xlsxEditable inputs, visible formulas, and a purchase-quantity column.
- reorder_instructions.pdfHow to refresh the inputs and interpret the result.
Take one item. It sells eight units per day. The supplier takes fourteen days to deliver. The owner wants seven additional days of demand in reserve. There are ninety units on hand and twenty-four confirmed units on order. Each case contains twenty-four.
The workbook calculates a target of 168 units: eight multiplied by twenty-one days. Subtract the 114 units already held or incoming, and the shortfall is 54. Because the supplier sells full cases, the recommendation is three cases: 72 units.
AI can construct the workbook, apply the same rule across the catalog, recalculate it, and compare selected rows with independent arithmetic. AI-generated Excel workbooks with formulas are a documented capability; the valuable customization is this owner’s replenishment method.
The file becomes a repeatable operating tool. The customer updates stock and demand; the method remains. This simplified rule assumes steady demand and reliable incoming stock, which is why those assumptions should remain visible.
A worked preview of the workbook logic
- Target inventory8 × (14 + 7) = 168 units
- Available + confirmed incoming90 + 24 = 114 units
- Unrounded shortfall168 − 114 = 54 units
- Full-case order3 × 24 = 72 units
The catalog order / .csv
Make these records import correctly.
The sample brief
“Three suppliers use three different layouts. Give me one catalog file that matches our inventory system, and show me every record you cannot resolve.”
The customer suppliesThe three source exports, the destination template, approved field mappings, valid units, and explicit rules for recognizing duplicate products.
The delivered files
- catalog_import.csvOnly the records that meet the destination contract.
- exceptions.csvUnresolved records and the reason for each exception.
- source_mapping.csvThe route from original rows to the delivered records.
Suppose there are 2,400 source rows. Under the customer’s matching rules, 180 are redundant duplicates. Another sixty distinct rows lack a required identifier or contain an unresolved unit. The finished import contains 2,160 accepted records.
The accompanying reconciliation accounts for all 2,400 rows. Nothing disappears into a vague statement that the data has been “cleaned.” Every excluded row remains traceable, and every uncertain record waits for a decision instead of receiving an invented identifier.
AI’s production work is to write and run the transformations, validate the export, and repair format failures. The destination determines the specification. For example, Shopify documents required CSV formatting and recommends testing a subset in a development store for large imports. An arbitrary CSV is not automatically a compatible import.
The value is an unblocked migration or catalog launch. The customer receives the file that can enter the next system, plus evidence explaining what happened to the source data.
Source rows received.
Redundant duplicates removed under approved rules.
Distinct unresolved rows preserved as exceptions.
Accepted rows in the import file.
The weekly reporting order / .py
Stop rebuilding this report every Friday.
The sample brief
“Every Friday I combine fourteen supplier exports. Deliver a program that creates our standard workbook and flags missing or malformed inputs.”
The customer suppliesRepresentative exports, the required supplier list, an approved report layout, field definitions, and a reference report whose totals are already known.
The delivered files
- supplier_report.pyThe reporting program.
- requirements.txt + config.example.jsonThe dependencies and documented settings.
- tests/ + README.mdReference cases and operating instructions.
The program loads the fourteen files, normalizes their columns, applies the agreed aggregation rules, and writes weekly_supplier_report.xlsx. It also produces a run log recording which inputs were used.
The crucial requirement is what happens when supplier number eleven is missing. The program should stop or label the report incomplete according to the owner’s rule. It should not quietly produce a thirteen-supplier total that looks finished.
AI can write the program, run it against the sample exports, compare the generated workbook with the trusted reference, and exercise the missing-file case. The delivery should include a successful run from a fresh environment, with setup instructions that match that environment.
This file has recurring value. The owner commissions the automation once, then uses it for subsequent reports. If input formats change, the file needs maintenance; the original service should make that boundary clear.
Example invocation: python supplier_report.py --input ./exports --output ./reports --as-of 2026-10-13
The cabinet-shop order / .step / .dxf / .nc
Prepare forty-eight shelf panels.
The sample brief
“We need forty-eight identical shelf panels, each 600 by 300 millimeters, from 18-millimeter stock. Prepare the files for our approved router workflow.”
The customer suppliesThe part drawing and tolerances, stock-sheet sizes, edge and grain rules, workholding geometry, machine configuration, tool library, approved machining parameters, and the matching post processor.
The delivered files
- shelf_600x300.stepThe part model.
- sheet_layout.dxfThe nesting layout with units and orientation explicit.
- router_job.nc + setup_sheet.pdfThe machine-specific program and its setup documentation.
Within a known part family and an established toolchain, AI can coordinate model creation, nesting, CAM operations, export, and documentation. The result is the digital manufacturing package the shop needs before production can start.
The NC file is particularly valuable because its contents become machine instructions. Autodesk describes post processing as conversion of manufacturing operations into machine-consumable NC code using a suitable post configuration. That toolchain belongs in the service; plausible-looking G-code alone is not enough.
Completion means that the exported files match the specified dimensions and quantity, and the machining has been simulated against the supplied setup. The shop still owns first-run release and physical validation of stock and workholding. AI can finish the files without thereby proving the physical setup safe.
The business opportunity is repeatable preparation for a constrained class of parts. A new dimension or quantity becomes a new order in the same production method.
The brand-production order / .svg / .pdf
Deliver all 180 label variants.
The sample brief
“We have thirty products, three label sizes, and two approved language versions. Deliver the complete production set with consistent naming and no missing variants.”
The customer suppliesApproved product copy and translations, licensed fonts and brand assets, label dimensions, printer specifications, and verified identifiers or barcodes where required.
The delivered files
- labels_source/The editable vector artwork for every variant.
- labels_print/The PDF exports using the printer’s required settings.
- variant_manifest.csv + proofs.pdfThe completeness checklist and review proofs.
Thirty products multiplied by three sizes and two languages creates 180 required variants. The factory constructs the layouts from the approved content, exports them, and compares the delivered set with the expected product-size-language combinations.
A useful filename might be product_014_small_en.pdf. Its identity is also recorded in the manifest, so a printer can distinguish it from product_014_large_en.pdf without opening and guessing.
AI can render all variants and look for clipped text, missing assets, and incorrect dimensions. The printer’s contract supplies the production checks. Adobe’s guidance calls for suitable fonts, bleed, color, linked resources, and preflight. Those requirements make “finished” more concrete than an attractive preview.
The value is a coordinated launch. The customer needs every correct variant, not one impressive label. New product records can become additional orders through the same controlled process.
The field-report order / .pdf / .html
Turn 600 photos into twelve usable reports.
The sample brief
“Our team photographed twelve sites. Make one clearly organized report per site, preserve the approved captions, and give us an index we can open locally.”
The customer suppliesThe 600 images, a reliable photo-to-site mapping, approved captions, capture metadata, the report template, and rules for ordering and image size.
The delivered files
- site_01_report.pdf … site_12_report.pdfOne report per site, with fifty images each in this example.
- report_index.htmlA local index linking to the twelve reports.
- photo_manifest.csvThe mapping from each source image to its report and page.
The factory groups the images, places each beside the corresponding caption, inserts site identifiers and metadata, and creates the twelve PDFs. It then builds a self-contained HTML index with relative links, so the delivery folder can move intact to another computer.
The acceptance check is tangible: 600 received images must map to 600 report placements, distributed as fifty images in each of twelve reports. The system verifies that all local links work and renders the pages to inspect layout and readability.
This service packages the customer’s evidence. The example does not ask AI to invent inspection findings or decide what a photograph proves. Approved observations remain the source of the report’s factual claims.
The files carry value because they make an otherwise unwieldy collection usable in a meeting, handover, or project record. On the next reporting cycle, the customer supplies a new batch and receives another completed set.
600 source images → 12 site reports × 50 images
Every image has a destination. Every report has an entry in the index.
The release-confidence order / .py / .json / .zip
Give us tests that catch the broken booking rules.
The sample brief
“Our appointments last thirty minutes. We close from noon to one. A resource cannot have overlapping bookings. Build a test package that verifies these rules.”
The customer suppliesThe application interface, business timezone, booking contract, opening hours, trusted examples, and an isolated test environment.
The delivered files
- test_booking_rules.pyExecutable tests against the specified interface.
- fixtures.json + expected_results.jsonThe scenarios and independently specified outcomes.
- test_results.html + README.mdThe recorded run and instructions for repeating it.
One fixture already contains a booking from 9:00 to 9:30 for resource A. A new 9:15 booking for that resource should be rejected. A 12:30 booking should be rejected because it falls inside the closure. An otherwise available 13:00 booking should be accepted.
AI can generate the test files, run them against the application, and verify that a deliberately broken version fails the relevant tests. This last step matters: a suite that always reports success is a decorative file, not a useful product.
The expected outcomes come from the agreed contract. Letting AI infer the rules from the implementation and then test against those same inferred rules would make an existing mistake harder to see.
This package is valuable because it can travel with every subsequent release. The customer receives repeatable evidence about a defined set of behaviors, with its coverage documented. The suite supports a release decision; it does not establish that every part of the application is correct.
The business behind the file
A clear order is the beginning of a factory.
Each example can become a focused service: replenishment workbooks for one trade, catalog imports for one platform, reporting programs for one recurring workflow, router packages for one part family, production artwork for one kind of brand, field reports for one kind of project, or tests for one class of business rule.
The customer is buying a completed job. The file is how that job is delivered. It may save repeated labor, unlock a migration, start manufacturing, coordinate a launch, or preserve a method that can be used again.
I would begin with the orders whose outputs are easiest to check against trusted examples: the workbook, the catalog, and the reporting program. Complete one narrow order, measure whether the customer can use it without repair, and improve the production method before expanding the menu.
The durable advantage is knowing which inputs matter, how to make the artifact, and what proves it works. When those are explicit, AI has a realistic path to producing the finished file on its own.
These are proposed services and worked numerical examples. Documentation links support the underlying tools and formats; they do not establish measured savings or universal autonomous reliability. The named file packages describe commissioned deliverables, rather than completed artifacts supplied with this article.