BOIS · CASE STUDY
From a 300-Item Checklist to a Dynamic Graph: How BOIS Helped Get Auto Parts Stores into Production Faster
The hardest thing about a large checklist is not the number of items by itself. It is having to hold the whole document in your head again for every new project: what applies to this store, what can be done now, what is waiting for access, and what is blocking the launch.
A checklist should not just remind. It should manage.
We already had a detailed onboarding checklist for automotive online stores. Nine pages. Sixteen sections. 281 separate items, covering everything from access and catalog imports to payments, shipping, test orders, and post-launch stabilization.
Formally, everything we needed was written down. In practice, the document still had to be worked through manually almost from beginning to end. For every new store, the operator had to decide all over again which items applied, which depended on the customer’s decisions, which were already available, and which were pointless to start yet.
The checklist could remind us to test a payment or an import. But it could not answer the central operational question: what should we do now?
The problem was not a shortage of checklist items. It was the absence of executable causality between them.
A document like this quietly turns the operator into their own task-management system. The person is not only doing the work. They are constantly servicing the checklist: rereading, filtering, matching, remembering what depends on what, and worrying that one small item will disappear among hundreds.
The original onboarding checklist
The complete anonymized list: nine pages, 281 items.
1. SCOPE AND REQUIREMENTS CONFIRMED
- Automotive integrations confirmed
- Catalog source confirmed
- Sources of pricing and stock confirmed
- Final brands list received
- Brand approvals confirmed on provider side
- Product categories confirmed
- Categories and brands excluded from import confirmed
- MMY or YMM requirement confirmed
- VIN Lookup requirement confirmed
- Pricing and markup rules confirmed
- Inventory tracking settings checked (for all thousands of products? Some products' inventory tracking may differ)
- Out-of-stock products display setting checked
- Backorder settings checked, if applicable
- Automotive stock source handling checked
- Stock and price import settings checked
- Product variations display mode confirmed, if applicable
- Shipping requirements confirmed
- Tax requirements confirmed
- Payment methods confirmed
- Custom requirements documented
- Planned launch date confirmed
Milestone: all required information is received and catalog setup can begin.
2. ACCESS AND ACCOUNTS
- All credentials received through Secure Credentials Form
- Access to all applicable automotive integrations checked
- Integration accounts active
- Brand approvals actually granted
- API Credentials tested successfully, additional FTP import configured if needed
- Payment credentials tested successfully
- Shipping carrier credentials tested successfully
- Tax service credentials tested successfully
- No employee personal or temporary credentials are used
- All missing access requested from customer
3. CATALOG ARCHITECTURE
- Primary category source selected
- Categories imported or created
- Unnecessary categories disabled
- Categories match selected brands and catalog scope
- No empty technical categories
- No obvious duplicate categories
- Category hierarchy checked
- Category names checked
- Storefront category navigation checked
- Product-to-category mapping rules confirmed
- Demo categories and products removed or disabled
- ‘Imported Categories structure’ mapping to the store categories structure checked (category mapping).
- "Shop by Brand" block is hidden if only one brand is sold
Milestone: catalog structure is approved before the full product import.
4. AUTOMOTIVE INTEGRATION CONFIGURATION
- Connection successful
- Available brands retrieved
- Import brands selected
- Required categories enabled
- Warehouses selected
- Pricing rules configured
- MAP / MSRP rules checked
- Stock rules configured
- Product visibility rules configured
- Images import configured
- Descriptions import configured
- Fitment import configured
- Supplier shipping rates configured, if applicable
- Order export / fulfillment configured, if applicable
- Cron and import schedule configured
- Latest import completed successfully
- Import errors reviewed
- Repeated import does not create duplicates
- Repeated import does not restore excluded products
5. MULTIPLE-SOURCE CONFLICT RULES
- Priority source defined for product title
- Priority source defined for description
- Priority source defined for images
- Priority source defined for categories
- Priority source defined for fitment
- Priority source defined for price
- Priority source defined for stock
- One import does not overwrite correct data from another
- Import schedules do not conflict
- Sufficient intervals configured between related imports
- Product available from multiple suppliers checked
- Same SKU / MPN from multiple sources checked
6. CATALOG IMPORT COMPLETED
- All approved brands imported
- All approved categories imported
- Imported product count compared with expected count
- Unexplained product count differences resolved
- Missing brands checked separately
- Import errors investigated and resolved or documented
- No mass duplicate products
- No mass products without price
- No mass products without category
- No mass products without brand
- No mass products without images
- No invalid zero or negative prices
- Stock statuses match provider data
- Disabled / out-of-stock logic works
- Verified that only authorized brands are present in the automotive integration catalogs
- MAP pricing works
- Options and variants imported correctly
- Fitment imported
- Repeated scheduled import completed successfully
Milestone: the entire agreed catalog is imported and a repeated import does not damage it.
7. CATALOG QA SAMPLING
Required sample:
- At least 5 products from every main supplier
- At least 3 products from every key brand
- Product with multiple images
- Product with options or variants
- Product with MMY fitment
- Product without fitment
- Out-of-stock product
- MAP product
- Discounted product
- Oversized or freight product
- Product available from multiple suppliers
- Product in a deeply nested category
For each sampled product, verify:
- Title
- SKU / MPN
- Brand
- Price
- MAP / MSRP
- Stock
- Images
- Description
- Category
- Fitment
- Shipping attributes
- Add to cart
8. MMY / FITMENT QA
Applicable only to products imported with fitment data. AutoSync products imported as Regular products are excluded.
- Vehicle database imported
- Make selector works
- Model selector works
- Year selector works
- Submodel / engine works, if used
- Matching vehicle displays compatible products
- Non-matching vehicle does not display incompatible product
- Fitment displayed on the product page for products imported with fitment data
- Selected vehicle persists between pages
- Clear / change vehicle works
- MMY works on desktop
- MMY works on mobile
- At least 5 different vehicles checked
- Universal products checked
- Products with multiple fitments checked
9. STORE CONFIGURATION
- Store profile completed
- Company name, address and phone are correct
- Localization configured
- Currency configured
- Weight and dimension units configured
- Zones configured
- Taxes configured
- Email notifications configured
- Customer emails delivered
- Administrator order notifications delivered
- Correct store email address configured
- Legal pages published
- Shipping policy published
- Return policy published
- Privacy policy published
- Terms published
10. PAYMENTS
- Payment gateway connected in production mode
- Test mode disabled before launch
- Successful payment tested
- Failed payment tested
- Order created in X-Cart
- Transaction saved correctly
- Order status changes correctly
- Capture tested
- Void tested, if supported
- Refund tested
- Customer payment / order email received
- Administrator notification received
- Unused test payment methods disabled
- Unused offline payment methods disabled
- In case customer uses Turn14, make a test order to ensure that Turn14 receives orders.
11. SHIPPING
- Shipping origin configured
- Carrier accounts connected
- Calculated rates returned successfully
- Flat rates configured, if used
- Supplier shipping rates work, if used
- Free shipping rules checked
- Weight and dimensions passed correctly
- Residential / commercial rules checked, if applicable
- Oversized products checked
- Freight products checked
- Multiple products from one supplier checked
- Mixed cart from different suppliers checked
- Shipping method names are customer-friendly
- Test and unavailable shipping methods disabled
12. STOREFRONT, BRANDING & SEO QA
- Logo installed
- Favicon installed
- Corporate colors applied
- Banner installed or absence approved
- Company information added
- Website load speed checked
- Homepage has a clear, informative H1 tag describing the business
- Key landing pages have H1 tags, and duplicate H2 tags are removed
- Descriptive meta titles and descriptions set for key pages (Admin > SEO tabs)
- Clean, canonical URLs configured (no GET parameters in indexing)
- robots.txt and sitemap.xml are optimized to avoid unnecessary crawls
- Image alt-text is used effectively
- Promotional text is confined to logical locations, avoiding repetition on every page
- Rich snippets module installed and configured (if applicable)
- Category pages display 20-24 products to optimize load speed
- Category images are properly sized (e.g. 400x400 instead of 110x110) for better visibility
- Homepage checked
- Header checked
- Footer checked
- Main menu checked
- Category pages checked
- Product pages checked
- Search works
- Filters work
- Brand pages work
- Cart works
- Checkout works
- Mobile layout checked
- Demo content removed
- No broken images
- No broken links
- No placeholder text
- No visible technical errors
- Contact Us page checked
13. END-TO-END ORDER QA
Required scenarios:
- Standard order
- Guest checkout
- Registered customer checkout
- Order with MMY-selected product
- Order from one supplier
- Mixed cart from multiple suppliers
- Out-of-state order
- Order with tax
- Order with coupon
- Free shipping order
- Oversized / freight order
- Failed payment
- Refund / void
For each relevant scenario verify:
- Product price correct
- Tax correct
- Shipping correct
- Payment successful
- Order created
- Emails received
- Stock updated
- Order visible to administrator
- Supplier export / processing works
- Tracking workflow is defined
14. CUSTOMER ACCEPTANCE
- Customer received storefront review link
- Customer reviewed brands
- Customer reviewed categories
- Customer reviewed pricing
- Customer reviewed MMY
- Customer reviewed shipping
- Customer reviewed checkout
- Customer feedback list received
- All launch-blocking feedback resolved
- Non-blocking feedback moved to separate tasks
- Written launch approval received
Recommended confirmation:
Customer confirmed that the agreed catalog, storefront, payment, shipping and automotive functionality are ready for launch, with no known launch-blocking issues.
15. LAUNCH GATE
The store must NOT be launched while any applicable condition below remains true:
- Approved brands are not fully imported
- Unexplained import errors remain
- Scheduled imports have not been verified
- Repeated import damages catalog data
- Mass pricing errors exist
- Mass stock errors exist
- MMY works incorrectly
- Payment has not passed end-to-end testing
- Shipping has not passed end-to-end testing
- Taxes are not configured or responsibility is not confirmed by customer
- Mixed cart from multiple suppliers has not been tested
- Email notifications do not work
- Critical storefront errors remain
- Customer launch approval is missing
- Backup / rollback plan is missing
- DNS / domain switch time is not agreed
16. POST-LAUNCH STABILIZATION
- First production import completed successfully
- Scheduled imports checked at least twice
- First real orders reviewed
- Payment errors reviewed
- Shipping errors reviewed
- Email delivery checked
- Stock updates checked
- Order export checked
- No unresolved critical onboarding tickets
- All launch-related issues resolved
- Customer confirmed there are no launch blockers
- Store transferred to regular Support flow
- No critical errors in logs except for known and currently resolved
- Needed workers are up and running
- Feeds are properly generated
- sitemap.xml is present and generated
- CloudSearch index works
- Store is indexed in Google (search console)
- GA4 is connected and do not have conflicts with GTM.
Final milestone: the store is operating consistently, scheduled imports complete successfully, real orders are processed, and no onboarding blockers remain.
The source is shown in full so the original bureaucratic surface does not collapse into the abstraction of “several hundred tasks.”
What BOIS changed
BOIS did not suggest writing another, better checklist. Instead, the flat list was treated as a system of causally connected actions that could be executed and tested.
Compound items were split into atomic tasks. Tasks received stable IDs, direct dependencies, applicability conditions, and states. Repeating components—supplier integrations, payment gateways, carriers, tax services, and E2E scenarios—became dynamic branches that appear only when a specific project needs them.
In the current configuration, the source document became a graph of 313 tasks. The important change is not that the number grew. It is that those tasks no longer need to live in a person’s head all at once.
The observable contribution of BOIS
The high effectiveness of BOIS did not show up as more generated text. It showed up as a change in the type of object:
static checklist → normalized task graph → configurable runtime.
BOIS operations visible in the artifacts:
- Atomization. Combined items were separated—for example, pricing/stock, category/brand exclusions, and pricing/markup.
- Explicit causality. Tasks received direct
Dependencies;Parent IDremained only for theINACTIVEcascade. - Separation of inapplicability from incompleteness.
INACTIVEdoes not block dependent tasks and does not produce a capability. - Templating of repeatable organs. Integrations, payments, carriers, tax services, and E2E received instantiable branches.
- Positive completion criteria. Negative launch blockers were converted into testable admission conditions.
- Human authority. Where meaning or applicability required confirmation, the decision remained with the operator.
- Testability. Unique IDs, valid references, absence of cycles, state preservation, and correct transitions became testable invariants.
- Visible debts. Unmeasured live performance and untested replication were not declared complete.
Task and dependency graph
313 tasks, dynamic branches, and a fragment of an actual causal chain.
The toggle in the lower fragment shows a causal transition: after 02-MEYER-01 is completed, the dependent task 02-MEYER-02 automatically moves from WAITING to READY.
Where human attention returned
The table now distinguishes five fundamentally different situations:
This looks like a small interface change, but it contains the project’s main value. The operator no longer has to calculate the state of several hundred items by hand every time. The system carries the procedural memory: it tracks causality, avoids proposing actions too early, and does not mix inapplicable tasks with unfinished ones.
Human attention is freed for work that cannot honestly be reduced to a checkbox: understanding an unusual case, reaching agreement with a customer or supplier, checking whether a result makes sense, and making the launch decision.
The checklist as a working system
A short recording of the resulting interactive table.
Instead of rereading nine pages, the operator works with the current project state directly in the table.
What BOIS did not do
The boundary matters here. This article does not claim that BOIS created the system on its own. It shows a specific contribution within the limited domain where BOIS was applied: the structural transformation of a large human procedure.
| Participant | Actual contribution |
|---|---|
| Operator | Provided the domain model, determined the meaning of checklist items, corrected inaccurate dependencies and interface decisions, tested the live table, and accepted changes. |
| BOIS | Provided the language of structural transformation: boundaries, atomicity, state roles, dependencies, applicability, control transitions, debts, and testability. |
| Codex | Performed the decomposition; wrote and repaired the Apps Script, tests, documentation, and GitHub changes; and diagnosed the ten-second redraw. |
| Google Sheets / Apps Script | Provided the working interface, state storage, and runtime execution. |
| GitHub | Provided versioning, diffs, the source of truth, and reproducible code delivery. |
| Real onboarding projects | Have not yet produced enough external data to confirm the system’s field effect at scale. |
Evidence debt
One boundary remains open: the article does not use a convincing form to substitute for missing field data.
| Evidence | Status | Limitation |
|---|---|---|
| Acceleration across a series of real launches | Not confirmed | Until comparative data exists for several projects, the article cannot claim a numerical reduction in calendar time. |