Lou,

Since 1995, AMI has been the backbone of shutter shops like ours. It brought ordering, programming, the cart system, assembly, accounting, shipping, and much more together into one system, and Vintage has built its business on it. We have always seen Vintage as an experimental laboratory for assembling shutters, and we have always been inspired by AMI's ability to bring ideas into reality.

In that spirit, I've been building on AMI's foundation in two areas: the people on the floor and the machines they run. This letter is my idea of where that could go, and what I think could be the next step forward for AMI shops. Everything in it builds on AMI. None of it replaces anything AMI does.

The people

Before Vintage, I worked in an RV axle shop, in automotive gear assembly, and in medical implant machining. In every one, the rub was the same: management sets a goal, and the operators either hit it or they don't. And in every one, management saw labor as underused and built systems to measure it and improve it.

I believe the shutter shop has the same problem ten times over. The work is far more labor-intensive, and because each step is so decoupled from the next, it is hard to see what is slowing things down at any given moment, and the operators aren't held to anything. Managing the people in a shop like that is a plate of spaghetti in the dark. Work moves from station to station, and when the line slows down, nobody can see where or why.

That is what VDS set out to fix. It has since grown into an operating system for managing the floor.

It turns the lights on by putting a gauge on every operator. When every station scans its work, it is easy to see who or what is slowing down the line. The kiosk turns each job into a game: the standard is on the screen, everyone can see it, and everyone holds it all day. The operators on VDS at Vintage like the screens. Knowing how they are doing, and knowing that all of their work counts, has proved to be powerful.

At its core, VDS is a database that takes in data effortlessly and displays it in clear, creative ways. Fully integrated, it works like an Internet of Things for the plant, tracking operator output and flow, orders, machine diagnostics, inventory, and material usage in one place. That alone makes it a powerful tool. I believe systems like this are how labor-intensive manufacturing stays profitable in the United States. They take the emotion out of decisions and give ownership hard numbers to calculate their way to profitability.

On top of that sits one more layer: a local AI model running on the VDS server's own graphics card. There are no subscriptions, and the shop's data never leaves the building to reach it. It learns the shop, then begins to take over repetitive tasks and answer questions about the operation that used to take hours of digging.

Running at Vintage today

VDS is not fully rolled out at Vintage yet. Four operator kiosks are online, and the core technology is built and proving itself every day. The rest of the floor is ready to go when the shop is.

  • Every second accounted for. Operators at VDS stations are accountable for every second of the day. Each one's individual report goes in their paycheck envelope, showing whether they are doing well or poorly over time.
  • It just works. Adoption lives or dies on friction. The kiosks are single-board Linux computers with active cooling, sealed in plastic enclosures. They turn themselves on and off with the shifts, need no username or password, and have none of the failure points of a Windows box. They have run at 100% uptime for almost a year, and every diagnostic can be done over SSH from the office or remotely. For a 25–50 operator shop with no IT department, that matters more than any feature.
  • Any screen is a VDS screen. Any device with a browser on the VDS network can be a scan kiosk, a manager's tablet, a scoreboard, an office display, a customer service portal, or the plant manager's suite.
  • SOPs from the floor. The floor manager builds SOPs at the station on a tablet, with photos. Only a handful are written so far, but each one becomes training material.
  • Ask VDS. The local AI answers questions from every tablet and portal. As open-source models improve, VDS upgrades to them with a download.

Where it goes next

  1. Any production day replayed with real numbers to see what went right or wrong.
  2. Take AMI paperless. Each kiosk shows the operator exactly what they need, and the plant manager gets the view he has always wanted.
  3. An assistant that learns how the plant manager responds to events, suggests an action on every message, and once it has earned trust, takes the small daily tasks off his plate.
  4. Reports that flag stations held by a single operator and suggest cross-training.
  5. Maintenance assigned to a manager or operator, prompted until it's done, with its own SOP and material list.
  6. Order sequencing that learns to schedule for the most output, the most money, or the fastest ship times. The AMI cart system already keeps the Bus Bus Car Bus problem in check on the floor. With AMI's order data and live floor data working together, sequencing could take that further and sort it out before orders ever reach the floor.
  7. A dealer calls the shop and gets told where their order is, without anyone stopping to look it up.
  8. Over a hundred more buildable feature ideas are in the VDS animation, under the VDS card below this letter.

The machines

Today a shop has two choices: a hobby-grade machine that barely does the job, or an industrial machine at a large price. Either way it arrives mothballed. It has to be wired and commissioned, then custom fixturing and tooling has to be built, often with your team's help to get it working with AMI. That takes serious time, money, skill, and risk.

I'm proposing machines built for exactly the task, with every feature the job needs and nothing extra, and AMI and VDS integrated from day one:

  • Built around the process. Each process is evaluated first, then the fixturing and tooling are proposed, and the machine takes shape around them. The linear motion design repeats across machines: linear guides with roller bearing blocks, and helical gear racks on gear reducers driven by closed-loop servo motors, connected to one of several control options. That combination has held tight tolerances on the machines I have built. Raw material, steel frames, bent metal parts, laser cutting, welding, large machining, and powder coating go to local Fort Wayne shops that specialize in that work and that I have relationships with. I am very confident this combination will produce extremely reliable custom machines quickly, with predictable cost and lead times.
  • Closed-loop calibration. The screen prompts the procedure and the machine cuts a calibration part. The operator takes it to the calibration center, the error is measured and sent back to the machine, and the machine adjusts itself. VDS logs every error, predicts drift, and schedules calibration so parts stay in spec.
  • Maintenance the machine can prove. VDS watches motor torque against a tolerance and prompts the lubrication procedure when it climbs. Lower torque afterward confirms the job was done right.
  • Tooling handled. Each machine comes with go/no-go gauges for the parts it makes. VDS tracks the work through the station and prompts a tool change before it causes a problem. The operator taps the tool on the screen, takes a new one from the tool crib, and assembles the holder. The calibration center measures its length and sends it to the machine. The plant manager sees live tool inventory at all times.
  • Trained from the screen. Training videos on the control screen and prebuilt operation and maintenance SOPs in VDS make the transition fast and bring the ROI sooner.

The result is a plug-and-play machine that handles the whole automated process and lowers the skill it takes to run and maintain it. The machine render library is under the Abstrax Wired Machines card below this letter.

Why now

With Vintage in contract negotiations with Hunter Douglas, I'm seeking the opportunity to bring what we've built to other AMI shops. I hold a signed acknowledgment from Jim that I own VDS and the machine designs. The two cards below lay out two ways we could do it together.

Jon KnapkeAuto Fence LLC · Fort Wayne, Indiana(260) 433-4038 · jon@autofence.net

Background. I grew up in the plant and returned to it after training as a machinist — a two-year Machine Tool Technology certificate from Ivy Tech, then LH Medical, machining titanium and stainless implants on STAR Swiss lathes after working a five-machine HAAS 5-axis cell. At Vintage I design the machines in Fusion 360, program the controls, write the software and commission the result on our own floor. Each machine on these pages says plainly whether it is built or a concept.

Auto Fence LLC is my company. It makes the automated rip fence sold at autofence.net, and it would be the licensee and the builder in either proposal.

Two Proposals

Each card opens a page with the full picture — what's built, what's a concept, and what I'd propose. Click through in any order.

1 · License

VDS as the AMI bolt-on

Abstrax sells VDS to its shops as the bolt-on. Auto Fence LLC builds the software, assembles the hardware, installs every system on site running parallel to AMI — touching nothing of AMI's but a read-only login to the database — carries customer service, and shares the revenue with Abstrax.

  • Every panel scanned at each VDS station; pace and score per operator, live
  • Tablets, TVs, a plant manager portal, and a local AI that answers from the plant's own data
  • Four operator kiosks live on a 50-person floor today; the rest of the floor is ready to roll out
Open VDS

2 · Hardware division

Purpose-built machines, sold by Abstrax

Abstrax launches a hardware division: complete solutions for the shutter fabrication process — sold or leased — integrated with AMI and VDS out of the box, plus custom builds as they present. Auto Fence LLC designs, builds, programs, installs and commissions them.

  • An eight-machine library — Louver Cutting Machine, Miter Saw Station, Auto Fence Abstrax Edition, Poly Bending Machine, Stile Machining Center, 3-Axis Calibration Station, Rail End Router, Tool Crib
  • Every one sets itself up from the AMI order — one barcode, nothing typed
  • Two running at Vintage, one in market as a product, one prototyped, four designed — each tile says which
Open Abstrax Wired Machines

Reference · AMI from the inside

AMI from the inside — a study of the database

A study of the AMI database as installed at Vintage Shutters, built entirely from read-only observation: where it lives, its 193 tables by family, how an order cascades to a single panel, the money rules, the shipment register, the stored geometry, and the questions only Abstrax can answer. Every statement is labeled measured, inferred or open.

Open the AMI reference

One more thing I'd like to share · Template Studio

The irregular shapes AMI doesn't take yet — laid out and programmed

This is a version of Template Studio I have cleaned up and given the AMI skin. I don't know if it is of any interest to you, but it automates the manual Mastercam procedure I did for years. Give it the DXF of the shape Hunter Douglas provides us, and it lays everything out and posts the layouts and the code for the Fanuc.

Template Studio — an arched two-panel shutter laid out with its frame, stiles, rails and louver holes Open Template Studio at studio.autofence.net

What I work in

Fusion 360 · machine design Mastercam · toolpaths & post-processors Blender · product renders & animation Fanuc G-code Teknic ClearCore / ClearPath servos Nextion HMI EZAutomation EZ9 HMI Modbus TCP Raspberry Pi kiosks Python · Flask SQLite SQL Server · read-only AMI integration JavaScript Three.js · React · Vite Ollama · local LLMs, retrieval with citations Gaussian splats · Scaniverse, SuperSplat Netlify · GitHub STAR Swiss lathes HAAS 5-axis Wood shutter manufacturing
Two proposals  /  VDSAbstrax Wired Machines →

Proposal 1 · License VDS to Abstrax as the AMI bolt-on

VDS — the low-friction production monitoring system that makes data your superpower.

AMI owns the order. VDS owns what actually happens to it on the floor — every panel, every station, every minute — and puts the numbers where the people doing the work look. It reads AMI read-only and never writes a byte back.

Watch: VDS — a day in the shop, and what comes nextOne shift on our floor, every station, then the roadmap. 33 minutes — the first seven are the day.
VDS Performance tab — one operator's live Output Index and cumulative square feet
Performance — one operator, liveScreenshot · Sep 9, 2026 · click to enlarge
VDS panel analytics — panels scanned, tilt, finish, panel type, sill, OI by operator
Panel analytics — what the scans add up toScreenshot · Sep 9, 2026 · click to enlarge
1PC runs the whole plant
0software installed on any client — kiosk, tablet or phone needs only a browser
0internet required on the floor; the models run in the building
100%kiosk uptime for almost a year

The deal, plainly

Abstrax sells VDS to its shops as the AMI bolt-on, bills it and owns the customer. Auto Fence LLC builds the software, assembles the hardware — the plant PC, the kiosks, the scanners, the tablets — installs it on site running parallel to AMI, and carries customer service. The only thing it touches of AMI's is a read-only login to the database. Abstrax and Auto Fence LLC share the recurring revenue. The pilot: two shops, then every shop that wants it.

What it does

The floor

A Raspberry Pi kiosk at every station reads the barcode AMI printed. One scan clocks an operator in; the next says this panel arrived here. From the scans: live pace and score per operator, flags and instructions at the moment of the scan, a manager summon, maintenance prompts.

The office

Floor-manager tablets, break-room and office displays, the daily P&L email, and a plant manager portal — goals, shifts, lines and jobs, people, reports, knowledge, maintenance, customers, tablets, backups, the ship map, shipping.

Ask VDS

Plain-English questions answered by a local language model on one PC in the plant. Every answer cites its source; anything it cannot verify, it refuses. Nothing leaves the building.

Beside AMI

Reads AMI's database read-only through one guarded connection — 193 tables mapped, the production-number join verified 150 of 150, the revenue path reconciled three ways to the penny. Never writes. Installs nothing on any AMI machine.

Operator performance you can seeOutput Index per operator — square feet scanned against the goal prorated minute by minute, green ahead, red behind — on the kiosk, the tablet and the wall.
Training at the stationSOPs with a bilingual glossary so one word has one translation, the Process Definer for tribal knowledge in the operator's own words, and Ask VDS answering from them with citations.
Maintenance that lives with the workPrompts on the kiosk where the machine is; the schedule and the history in the portal where the owner is.

See it — click a tile. Built means on the floor today; roadmap means designed, not built.

Two proposals  /  Abstrax Wired MachinesVDS →

Proposal 2 · An Abstrax hardware division

Abstrax Wired Machines. They set themselves up from the AMI order.

Complete solutions for the shutter fabrication process — sold or leased — integrated with AMI and VDS out of the box, plus custom builds as they present. Every setting an operator dials in today is a number AMI already knows; these machines read the number instead.

1
ScanThe panel barcode resolves to the exact panel in AMI. A scan that doesn't resolve cleanly is flagged, never guessed.
2
ConfirmThe machine shows what it derived — the same numbers the paperwork shows — and asks for one press.
3
RunAngle, stop, fence, positions or program come from the order. Nobody types.
4
RecordVDS logs the arrival; cycle counts feed the maintenance schedule; tooling counts against square feet.

The deal, plainly

Abstrax launches a hardware division and puts its name on the machines. Auto Fence LLC designs them in Fusion 360, has the parts fabricated by specialist shops, assembles and wires them, programs the controls on Teknic ClearCore and ClearPath servos, connects them to AMI through the same read-only path VDS uses, and installs, commissions and trains on the shop's floor — with the changeover SOP, the maintenance schedule and a hand-off package so someone other than me can keep each machine running. Sold or leased through Abstrax; custom builds as they present.

Integration out of the boxThe recipe comes from AMI's configured product — the same tables VDS already maps — so the shop's configuration and the machine can never disagree.
Operator performance you can seeEvery machine becomes a station VDS can see: the scan that sets it up is the scan that records the panel's arrival.
Training and maintenance built inEach machine arrives with its SOP in the plant's languages, its maintenance schedule with the parts list, and its hand-off document — not a phone number.

The library — eight machines, click a tile. Built means running at Vintage; prototype means built there and learned from; product means sold today by Auto Fence LLC; concept means designed, not built.

Proof on the floor at Vintage — what is already running, and where the library's patterns come from

How a machine gets built

1
Scope on the floorMeasure the real flow first. The bending machine that worked and didn't pay is why this step exists.
2
DesignFull assemblies in Fusion 360, around the shop's product, floor, air, power and the operator's reach.
3
ProgramMastercam for parts and programs; ClearCore and ClearPath for motion; interfaces people can read at arm's length.
4
Fabricate and assembleLaser, waterjet, machining and welding bought from shops that do one thing well; assembly and wiring mine.
5
IntegrateConnected to AMI and VDS before it is connected to production; settings checked against real orders.
6
Install, commission, trainOn the shop's floor, with its operators — SOP, maintenance schedule, hand-off package.
Two proposals  /  AMI from the inside← Back

Reference · a study of the AMI database

AMI from the inside.

Abstract. This paper describes the AMI database as installed at Vintage Shutters, reconstructed entirely from read-only observation of its tables between 11 August and 10 September 2026. It covers where the system lives, how its 193 tables are organized, how an order cascades down to a single physical panel, how money, shipments and production state are recorded, and how completely the stored geometry describes a shutter. Every statement is labeled by how it is known. Where the data supports a conclusion that only the system's authors can confirm, it is marked as an inference or left as an open question.

Method and disclosure. Everything here was learned by reading the AMI database at Vintage Shutters — Vintage's own orders, invoices and shipments, in the table layout Abstrax designed — through the account Michael approved for read-only use. Nothing came from Abstrax's application or its code: AMI's program files are compiled and were never opened. Anthropic's Claude was used as a research aid — AI agents helped write and run the read-only queries, reconcile the results and draft this paper — so the schema and slices of Vintage's data were processed by that tool during the work. One diagnostic created an empty table in the database; it was disclosed to Michael on 8 September with a request to drop it, and it produced the rule this study follows: a permission is never tested by attempting a write. I would rather you hear this from me than find it here, and I am glad to walk Michael through exactly what was done.
How to read this paper. Every figure was measured against the live database on the date given beside it; row counts grow daily, so anything countable should be re-verified rather than built on. Each statement carries one of three labels: Measured read from the database and recorded with the query · Inferred consistent with the data but not confirmed by Abstrax · Open a question only the owners of the schema can answer.

This paper deliberately contains no revenue figures, dealer names, prices, addresses or network details.

193tables in AMI_DB, 100 populated, mapped by family; the twenty that matter documented column by column
150 / 150production numbers taken from shop-floor barcodes found in BD_Order — none unmatched
27,004shipments in AMI's own register, each with a destination postal code
0.017″how closely a shutter drawn from AMI's geometry tables reproduces AMI's own print

1Summary of findings

The system

A Microsoft SQL Server 2016 instance holding AMI_DB, kept in merge replication with Abstrax. The local copy is a complete replica.

The schema

193 tables, 100 populated, in six families. The database declares no foreign keys; every relationship is an application convention, inferred from composite keys and confirmed against real orders.

The spine

Order → window (stamp) → zone → partition → panel. [Order#] is the internal key; [Production#] is the number on the shop paperwork. Both are distinct across all orders; the offset between them is not constant.

Barcode to panel

Production number, stamp and panel letter resolve to exactly one BD_Panels row: ABS(Stamp_ID) picks the window, an ordinal over the window gives the letter. 149 of 150 orders consistent; the one miss is a real edit in AMI.

Money

Integer cents throughout. Issued sales are Type = 2 AND State = 0; line totals reconcile to invoice headers to the penny over a closed twelve-month window.

Geometry

AMI stores no drawings, but it stores everything needed to draw one. Partitions, panels, rails, T-posts, stiles, tilt rods and frames close arithmetically with no fudge factor.

Shipping

BD_ev_Carrier is a complete shipment register with a machine-readable carton manifest. Ship-to addresses are on 99.7% of real invoices, at job-site grain.

State and change

C_Production_States carries the lifecycle from 100 Quoted to 1200 Fulfilled; BD_Events is current to the minute; AMI's own floor-scanning tables stopped receiving rows in October 2025.

2Where AMI lives Measured · Aug 2026

HostAbstrax's server, Abstrax-administered.
EngineMicrosoft SQL Server 2016 (product version 13.0.6500.1), a named instance.
DatabaseAMI_DB — 193 tables.
ReplicationAMI_DB participates in merge replication with Abstrax. The local database is a complete replica, so a local read is complete — and a local write would not stay local; it would propagate.
NetworkThe instance listens on the default port and SQL Browser does not answer, so connecting by instance name fails with error 26 from any client; connecting by host or port works.
The applicationAMI itself is a 32-bit application, and legacy 32-bit ODBC DSNs exist on the office machines. The 32-bit constraint belongs to the application, not to the database; a fresh 64-bit connection works.

The install share. AMI ships Ghostscript and a PostScript template set (headers, footers, line items, totals, two logos); the customer-specific templates are invoice and confirmation. AMI composes its paperwork from these at print time and pipes it through Ghostscript. A recursive search for PDF, PostScript and spool files found three files in total. There is no drawing archive. The configurator's construction and pricing rules (VIN.pmo, ac.dbi, models.dat) are compiled and unreadable; the configurator's logic is visible only through what it writes to the database.

The CNC share. 45,020 .nc files in machine folders (Onsrud and its archive, OSAI, Fanuc, specialty DXFs). Filenames decode as production number (5 digits) + stamp number (2 digits) + layout number (L1, L3 …) + machine letter — 3845909L1.nc is production 38459, stamp 09, layout 1, Onsrud — cross-checked against four live orders on the floor. These are G-code, not drawings, but the presence of a file for a production number and stamp is itself a record that the program was generated.

3Method: how the database was read

Direct 64-bit pyodbc, no DSN, Windows authentication, with an APP= name on every connection so every session is attributable in the server's own logs. Every query passed through a single function that accepts only one statement beginning with SELECT or WITH, rejects any interior semicolon and any write verb, sets READ UNCOMMITTED, executes, returns rows and closes. Dates were validated and production and order numbers cast to integers before they reached SQL.

Permissions, stated plainly 24 Aug, re-read 8 Sep. The login carries a broad grant — far more than a reader needs. Michael approved its use as read-only; the grant itself is not restricted, so read-only was a discipline of the method, not a property of the account. Permissions were read with fn_my_permissions(), a SELECT, and never tested by attempting a write.

Verification. Every relationship in this paper was confirmed against real orders before it was written down. Every revenue path was reproduced by at least two independent queries. Every probe report carries a read-only attestation: 57 statements in the twelve-month reconciliation, all SELECT or WITH.

4The schema, as measured 13 Aug 2026 · large tables re-read 8 Sep

FamilyTablesPopulatedRowsWhat it is
BD_86543,993,993The business data — orders, the configured shutter, geometry, invoices, events, the shipment register
MSmerge_ / sys*355373,995Merge-replication internals
MFG_10860,909AMI's own shop-floor scanning — no rows since October 2025 (§8)
C_1817507Code tables; small, stable, joinable. The decode column is Type, except C_Production_States, which uses Description
BOL_ · BM_ · BA_ · RME_ · ARM_269116Customer notes, benchmarking, sales-app configuration, report definitions, parameters — effectively unused at Vintage
SHP_ / Ship_600Shipping/staging module — entirely empty; not in use at Vintage

Inferred Empty tables are features switched off at this installation, not data waiting to load. Two are worth naming because their names promise something they do not hold: BD_CNC_Instructions (0 rows — CNC output goes to the file share) and BD_Shtr_Split (0 rows — shutter splitting is not recorded, which matters for the negative-stamp case in §5). The largest populated tables: BD_Inv_Line_Categories 562k, BD_Events 492k, BD_Window_Dimension 360k, BD_Window_Features 328k, BD_Frame_Info 265k, BD_Rails 191k, BD_Panels 114k, BD_Inv_Lines 83k, BD_Order 27.5k, BD_Invoices 27.5k, BD_ev_Carrier 27k — all growing by about one percent a month.

Two structural facts that shape everything

No referential integrity. sys.foreign_keys returns exactly one foreign key in the whole database, on a replication internal. No BD_, MFG_ or C_ table declares one. Every relationship in this paper is an application convention, inferred from composite primary keys and confirmed against real orders; the database itself does not enforce any of them.

The spine. Everything keys on [Order#], cascades on Unique_Win (a window or opening — what the shop calls a stamp), then Zone_Num → Part_Num → Panel_Num. Unique_Win is order-scoped but globally increasing. Column names containing # must be bracketed. Decode tables are keyed by (Mfg_ID, ID); Vintage's Mfg_ID is 10.

The order header — BD_Order

27,550 rows; primary key Order#; 101 columns. Order# is the internal key; Production# is the shop-floor number printed on paperwork and barcodes — five digits today, distinct across all rows, and the offset from Order# is not constant. Quote# is unique. Customer_Code joins the dealer master on a non-key column. The sidemark is the job or homeowner name printed on paperwork. Ten date columns, and unset dates are 1753-01-01, not NULL. Window_Count equals the BD_Shutter row count. Production_State decodes through C_Production_States. Remake_of reads as the order this one remakes — measured: 0 on every row, every year 2018–2026; never populated, so there is no parent-order link. Last_Stamp_ID is 0 on live orders and cannot be used to count stamps. Inferred A non-empty Lock_uid means someone has the order open in AMI. Three address blocks are snapshotted at write time (§7). There is no modified-at column; change is visible in BD_Events (§8).

The configured product

BD_Shutter — one row per window, keyed (Order#, Unique_Win). Stamp_ID is the stamp number on the barcode and can be negative or zero. Type is pure geometry (Rectangle, Arch, Bypass, French Door, Cafe — 85 values); Shutter_Style is where the tilt type lives (29 values, e.g. Enlightened Front Tilt); Coat is paint versus stain, not Finish; Color is a name from 229, never an RGB value; Louver_Size is inches and joins C_Louver_Sizes on Size, not ID; stile and rail depths are the millwork depths needed to draw a section; seven per-department spec-note pointers cover assembly, framing, hinging, finish, shipping, installation and milling.

BD_Window — Room, Wall, Window are the human location label (SUNROOM / 1 / 3). Shape decodes to ten values: Rectangle, Rake, Eyebrow, Arch, Pie (two hands), Circle, Oval, Cathedral, Inverse Rake. BD_Window_Dimension is name/value pairs from a vocabulary of fifteen names — wall position and depth on every window, width and height on almost every one, the arch names (Left Arch Start, Right Arch Start, Center Height) on about 4,500. BD_Window_Features is an open attribute bag of 54 names; MFG-dest is near-universal and is probably a routing hint Open. BD_Feat_Cut_Out carries French-door handle cutouts with side, size, position and escutcheon.

The geometry beneath a window

All keyed on order and window; units are inches. BD_Partitions are the shutter sub-rectangles (Part_Num 0–7). BD_Panels is one row per physical panel — the thing that carries a barcode — with Panel_Num restarting at 0 inside every partition; width, position within the partition (X_Pos already includes the joint overlap), stile widths and edge types, hinge group, mid-stile, tilt-rod position (0 means hidden tilt — 4,774 panels) and the fan geometry for sunbursts. BD_Rails is keyed to the partition, not the panel: every panel in a partition shares the rail set; Rail_Pos is measured from the bottom of the partition. Rail_Type has no lookup table Open, and its value does not determine position — type 22 sits at the top of a partition 49,977 times and mid-panel 16,685 times. BD_T_Posts are the mullions between partitions, Post_X being the post's center. BD_Frame_Info is one row per side of each window with the frame type (39 = None) and its projections. BD_Panel_Sect.Sect_Type has no lookup table either Open.

Invoices, lines and categories

BD_Invoices — 27,457 rows, dates 2018 to today, 66 columns. All money columns are integer cents. Type (2 = normal sale) and State (0 = issued) — State is the invoice status, not a geography; Ship2_State is the geography. SM_Addr is not an address despite the name — it is the sidemark. Target_Ship_Date was populated on every invoice in a twelve-month window. BD_Inv_Lines has no primary key; money is integer cents; Billing is square feet per unit and Quantity the unit count. BD_Inv_Line_Categories is an explicit category overlay (shutter, surcharge, discount, repair and six more), and the categories are overlays, not mutually exclusive — every repair-tagged line also carries shutter. BD_Customer is a fifteen-row dealer master with no address columns at all — addresses live on the order and the invoice.

5From shop-floor barcode to physical panel

The barcode on the shop paperwork carries the production number as six characters, '038486'; AMI stores it as the integer 38486. Measured 13 Aug 150 recent production numbers taken from shop-floor barcodes were looked up in BD_Order — 150 of 150 found. The correct join is an integer cast, never a string compare, and the production number must be resolved to Order# before any geometry, invoice or shipping table is read, because the paperwork carries one and the database keys on the other.

BD_Order.[Production#] = CAST(barcode_production_number AS int)      -- 38486
barcode_production_number = FORMAT(BD_Order.[Production#], '000000')  -- '038486'

The resolution path

Barcode                              AMI
production number '038486'   ──→  BD_Order.[Production#] = 38486  →  Order#
stamp             '03'       ──→  BD_Shutter WHERE ABS(Stamp_ID) = 3  →  Unique_Win
panel letter      'C'        ──→  BD_Panels, third row of that window,
                                  ordered by Zone_Num, Part_Num, Panel_Num

The panel letter is an ordinal, not Panel_Num. A window with three partitions of two panels has Panel_Num values 0,1 / 0,1 / 0,1 — but the shop letters them A–F. On the reference order, AMI's panels per window [6, 2, 4, 2, 4, 4] matched exactly the letters scanned on the floor per stamp. ROW_NUMBER() OVER (PARTITION BY [Order#], Unique_Win ORDER BY Zone_Num, Part_Num, Panel_Num) is correct; Panel_Num + 1 collides across partitions by construction. Large windows can exceed the ten letters the barcode allows.

Stamp_ID can be negative

Negative on 3,116 windows (4.5%), zero on 235 (0.3%), positive on 65,480. One live order carried Stamp_ID −7, −5, −4 while the barcodes on the floor read stamps 04, 05, 07 — the absolute values match exactly. Inferred The sign marks a window that was removed and re-added or otherwise reworked while the stamp number on the barcode stayed put. Over 150 orders, ABS(Stamp_ID) agreed with the floor on 149; taking the n-th window instead agreed on only 141, and would resolve to the wrong panel about 6% of the time.

AMI records current intent, not history

One order: stamps 1 to 4 had been built and scanned on the floor; AMI now holds only 3 and 4, fulfilled. Two windows were deleted from the order after their panels were made, and BD_Shtr_Split is empty, so AMI keeps no record of the change. Observed rate: 1 in 150 orders.

AMI describes what an order is now, not what it was. Any record of what was physically built has to be kept outside it.

6Money and invoices

SELECT COUNT(*) AS invoices,
       SUM(CAST(Grand_Total AS bigint)) AS cents,
       SUM(CAST(Billing_Sqft AS float)) AS billed_sqft
FROM BD_Invoices
WHERE Type = 2 AND State = 0
  AND Invoice_Date >= '<start>' AND Invoice_Date < '<end>'

Money is integer cents. Divide by 100; cast to bigint before summing, because sums overflow int at month scale. Type = 2 AND State = 0 selects normal issued sales, excluding credits, voids and quotes. Open — the most important assumption in this paper The filter produces sensible results and reconciles three independent ways, but nobody who owns the schema has confirmed it or explained the other values. It was verified by a direct query, by the same SQL run by hand in a separate session, and by adding one day's invoices by hand — which is what proves the cents-to-dollars conversion is not off by a factor of a hundred.

Line grain — two traps that produce a confident wrong answer 31 Aug

Extended_Price is extended; Billing is per unit. Quantity is already inside the price but not inside the square feet. Correct line area is Billing × Quantity; with it every invoice in a twelve-month window reconciled to its header exactly, without it the total is short by about 5.6% and every price per square foot comes out about 6% high — invisible in spot checks, visible only in the total. Amount is not the invoice money column; Extended_Price is. Only Extended_Price reproduces Grand_Total to the penny.

What the lines can and cannot classify

Remakes at the shop's own cost have an exact marker: a line whose description begins Remake Discount. In twelve months every such invoice was fully zeroed, and fifteen of them carried square feet with zero revenue. Billed repairs are a description match, not a flag; the repair category tags only about a third of them Open. There is no parent-order link and no fault code anywhere. A four-way split of lines reconciles to the headers on both axes with nothing dropped.

Calendar

The plant invoices Monday to Thursday: there are zero Friday invoices, so any per-day figure must divide by working days, not calendar days — a five-day assumption is wrong by about 40%. Invoiced is not produced. AMI bills what shipped; it does not record what was made on a given day.

7Shipping — the register and the addresses

BD_ev_Carrier is a complete shipment register counts 13 Aug, shape 8 Sep — 27,004 rows against 27,550 orders, filling for years: order, tracking or PRO number, carrier as free text, total weight, a handling-unit count, sidemark, a per-carton manifest as free text, ship date and five reference fields. The manifest grammar — w= 12 s= 114 X 5 X 5 boxes= 1, w= 439 s= 48 X 44 X 84 boxes= 9 — is groups of weight, dimensions and count, exactly the payload a carrier's API asks for. Every real manifest string parses, and each can be rebuilt from its parts character for character. The register also contains hand-keyed stub rows (carrier "1", weight 1, dimensions 1 × 1 × 1) that distort any average.

The FedEx numbers are twelve digits, which is parcel tracking, and several are single boxes of a few pounds, so the "LTL" label on those rows is Inferred a choice made at entry rather than the service bought Open. The five reference fields look like a large dealer's routing references Inferred. Boxes do not reliably follow stamps: the distinct stamp count predicted the piece count exactly 28% of the time and within one 75% of the time.

Where addresses live 26 Aug

The dealer master records nobody's location. Both the order and the invoice carry three address blocks snapshotted at write time: bill-to (the dealer's office), ship-to (the destination — filled on 99.7% of real invoices), and a sidemark block filled on about 1.5% of orders. Order and invoice ship-to agree on 27,043 of 27,047 pairs. Grain is the job site — about 4,900 distinct addresses across 3,200 postal codes in the US and Canada, a third of them appearing exactly once. Postal codes are unusually clean; country needs light normalization. Invoicing has been continuous, with ship-to on every invoice, since February 2019.

8Production state, the floor-scanning tables, and change

IDStateLive · 13 AugIDStateLive · 13 Aug
100Quoted1700In Finish5
200Ordered0800In Hinging40
300Confirmed0900In Packing15
400Released51000In Shipping0
425Pre-Specialty01100Hold0
450In Specialty101200Order Fulfilled26,951
475Specialty Complete11300Canceled441
500Pre-process0
600In Process81

158 orders were in flight that day. State 1000 had no live orders; whether it is ever set is Open. Orders never invoiced in a ten-month window were all Canceled — there is no pool of built-but-uninvoiced work in BD_Order.

The floor-scanning tables. MFG_Opening_Record holds AMI's own shop-floor scans — production number, opening, timestamp, square feet, station, user, panel — and its timestamps run from January 2020 to 16 October 2025 and stop, with no rows for any current order.

Change. BD_Order has no modified-at column. BD_Events — 492,328 rows, ev:state current to the minute, ev:cre8 marking creation — records when an order changes, alongside Production_State.

9Drawings — none stored, everything needed to draw one

13 Aug · three independent checks A scan of every column name in all 193 tables for file, path, drawing, document, image, PDF, print, CNC, program, spool, URL, folder or attachment found nothing in the business tables beyond two tiny opaque blobs and two empty columns. No drawing files exist on the install share. AMI composes documents at print time and stores none of them.

The geometry closes

On the sample order — six windows, 22 panels, 24 rails, 2 T-posts — the sum of panel widths against the partition width differs by exactly 0.1875 inches per panel-to-panel joint on all eight partitions: the rabbet overlap where panels meet, already encoded in X_Pos. Rail heights subtracted from the partition height leave the louver run exactly. Drawing each panel at X_Pos with Panel_Width, and each rail at Rail_Pos with Rail_Height, reproduces the real construction with no fudge factor.

ElementSource
Panel outlineBD_Panels.X_Pos, Z_Pos, Panel_Width + BD_Partitions.Part_Height
StilesLeft_Stile_w, Right_Stile_w → louver opening = width − L − R
RailsBD_Rails.Rail_Pos + Rail_Height, per partition
LouversBD_Shutter.Louver_Size over the louver run; count = ceil(run ÷ size) — verified against AMI's own print
Tilt rod, mid-stileTrod_Pos, Trod_Off; Substile_*
MullionsBD_T_Posts (center, height, face width, length, angle)
FrameBD_Frame_Info per side (type and projections)
Wall and window positionBD_Wall + BD_Window_Dimension (<-Left Wall, <-Floor)
Arches and fansBD_Window_Dimension arch names + BD_Panels.Fan_* + BD_T_Posts.Angle

What the tables leave out. Exactly three things needed for a faithful drawing are not in the database: the tilt-rod face width, the fill color (color is stored as a name, never an RGB value), and a 0.375-inch louver-into-rail seating that AMI's own print shows and BD_Rails does not. With that seating solved from one calibration window, a drawing built from the rows reproduces AMI's louver band to 0.017 inches and lands the top rail and louver pitch on clean shutter fractions — which a fitted fudge factor would not do. Rectangular windows were reproduced; arches, fans and angled tops were not yet tested.

10Open questions

These are meanings only the owners of the schema can settle. They were written up for Michael on 8 September.

  1. BD_Invoices.Type and State — confirm that 2 and 0 is a posted sale, and list the other values. Every revenue figure rests on this.
  2. BD_Panel_Sect.Sect_Type and BD_Rails.Rail_Type — the integer meanings; no lookup table exists.
  3. The BD_Window_Features vocabulary, MFG-dest first.
  4. The five reference fields on the shipment register — what each carries, and whether they derive from the order.
  5. Whether production state 1000 is ever set, and what Billing_State, End_Status and Exit_Type mean.
  6. Why the repair line category covers only a third of repair lines.

11Reading AMI correctly — sentinels and traps

  • Unset dates are 1753-01-01, not NULL.
  • Address and text columns are varchar NOT NULL: missing means empty string. A coverage check written against IS NULL reports 100% and is wrong.
  • Stamp_ID is negative on about 4.5% of windows and zero on 0.3% — use ABS().
  • Remake_of is always 0. Last_Stamp_ID is 0 on live orders. Rail_Style is always 1. Panel_Sect.Sub_Type is always empty.
  • SM_Addr on the invoice is the sidemark, not an address; the sidemark address block on the order is filled on about 1.5% of rows.
  • BD_ev_Carrier contains hand-keyed stub rows that poison any average.
  • Money is integer cents; sums overflow int at month scale — cast to bigint. Extended_Price for line money; Billing × Quantity for line area.
  • Panel_Num restarts per partition; the panel letter is an ordinal over the window.
  • BD_Invoices.State is a status; Ship2_State is a place. A role is never inferred from a column name.
  • Order# and Production# differ, and the offset between them is not constant. Join by integer cast.
  • The database enforces no relationships; every join must be validated by the reader.

Reference queries

-- Resolve a shop-floor production number to the order key
SELECT TOP 1 [Order#] FROM BD_Order WHERE [Production#] = 38486;

-- Windows (stamps) on the order, with the location label and the decoded style
SELECT s.Unique_Win, ABS(s.Stamp_ID) AS stamp, w.Room, w.Wall, w.Window,
       (SELECT TOP 1 t.Type FROM C_Shutter_Styles t WHERE t.ID = s.Shutter_Style) AS style,
       (SELECT TOP 1 t.Type FROM C_Coat_Types t WHERE t.ID = s.Coat) AS coat,
       s.Louver_Size, s.Sqft
FROM BD_Shutter s JOIN BD_Window w ON w.[Order#] = s.[Order#] AND w.Unique_Win = s.Unique_Win
WHERE s.[Order#] = @order ORDER BY s.Unique_Win;

-- The panel letter, correctly
SELECT [Order#], Unique_Win, Zone_Num, Part_Num, Panel_Num, Panel_Width, X_Pos,
       ROW_NUMBER() OVER (PARTITION BY [Order#], Unique_Win
                          ORDER BY Zone_Num, Part_Num, Panel_Num) AS letter_ordinal
FROM BD_Panels WHERE [Order#] = @order;

-- Line grain, the two traps applied
SELECT l.[Inv#], l.Idx, l.Description,
       CAST(l.Extended_Price AS bigint) AS cents,
       CAST(l.Billing AS float) * l.Quantity AS sqft
FROM BD_Inv_Lines l JOIN BD_Invoices i ON i.[Inv#] = l.[Inv#]
WHERE i.Type = 2 AND i.State = 0 AND i.Invoice_Date >= @start AND i.Invoice_Date < @end;

-- The shipment register for an order
SELECT Event_ID, [Ship#], Carrier, Weight, Units, Dims, Ship_Date
FROM BD_ev_Carrier WHERE [Order#] = @order ORDER BY Event_ID DESC;

-- What the login can do — a SELECT, never a trial write
SELECT permission_name FROM fn_my_permissions(NULL, 'DATABASE') ORDER BY permission_name;

Compiled 10 September 2026 from probe reports and notes written between 11 August and 8 September 2026. The fuller internal record, with the probe reports it cites, is available to Abstrax under an NDA.

← Back to the two proposals

VDS — a day in the shop, and what comes next · 33:27 · the first seven minutes are the dayOpen in a new tab  ·  Download (18 MB)