A system becomes easier to depend on when its complexity stays within its boundaries.
By Ed Bednar
Lab: 001
Technology: Claude Code, Python
Prerequisites:
1. Getting Started: Preparing Your Development Environment for the Enterprise AI Architecture Labs
Estimated Time: 30-45 minutes
1.0 Introduction
In this lab, we will build an environment that simulates enterprise systems. We’ll create stable service boundaries that encapsulate system behavior behind defined Python interfaces.
By introducing service boundaries first, the orchestration, retrieval, and AI components built later will remain independent of the underlying implementations.
2.0 Architecture Blueprint
As introduced in the Architecture Blueprint series, enterprise systems are best understood as collections of assets and their dependencies.
Figure 1 illustrates the architecture of the simulated Order Fulfillment System and the enterprise assets that will be implemented in this lab.

3.0 Artifacts Created
You will run a prompt that generates the following Python modules:
- stubs/erp_system.py – Simulates an ERP system by creating purchase orders, calculating service levels, and generating invoices.
- stubs/warehouse_system.py – Simulates warehouse operations by creating shipping manifests, dispatching shipments, and recording material acceptance.
- stubs/contract_store.py – Provides a collection of procurement contracts that will serve as the knowledge base for Retrieval-Augmented Generation (RAG).
- stubs/po_generator.py – Generates purchase orders that drive the order fulfillment workflow.
- stubs/init.py – Exposes the modules as a Python package, allowing them to be imported through a common stubs namespace.
4.0 Generate the Enterprise Services
4.1 Claude Code Prompt
Copy the following prompt and paste it into Claude Code. It will then generate the project scaffolding.
I am building the foundation for an enterprise AI application that will be extended across multiple implementation labs. The project implements a modern version of an enterprise order fulfillment process inspired by classic business process orchestration (BPO/BSO) systems.
The purpose of this lab is to demonstrate the enterprise architecture principle of encapsulation. These modules represent stable service boundaries around enterprise systems. They intentionally hide implementation complexity behind simple interfaces because later labs will orchestrate these services rather than interact with their internal implementations.
The working directory is:
order-fulfillment-ai
Create the following project structure:
order-fulfillment-ai/
└── stubs/
├── __init__.py
├── contract_store.py
├── erp_system.py
├── po_generator.py
└── warehouse_system.py
Follow these conventions throughout the project:
• Use Python 3.11.
• Use only the Python standard library unless explicitly instructed otherwise.
• Include type hints on all public functions.
• Add concise module and function docstrings.
• Keep implementations intentionally simple and easy to understand.
• Do not introduce classes unless specifically requested.
• Do not introduce dependency injection, configuration frameworks, logging frameworks, or unnecessary abstractions.
• Keep each function focused on a single responsibility.
• Generate realistic enterprise data suitable for later AI reasoning.
• Use Python's random module for simulated behavior.
• Centralize random generation so deterministic testing can be introduced later by setting a random seed.
• Do not create any files beyond those explicitly requested.
--------------------------------------------------------------------
stubs/erp_system.py
--------------------------------------------------------------------
Simulate a SAP-like ERP back-end system.
Define a custom exception:
OrderCreationError
Implement the following public functions.
create_order(po: dict) -> dict
Accept a purchase order dictionary.
Return:
• order_id (string formatted like ORD-XXXXX)
• confirmed_quantity (integer)
• estimated_ship_date (ISO date string)
Simulate realistic enterprise failures by raising OrderCreationError on approximately 10% of calls.
Example failure reasons include:
• Vendor on credit hold
• Inventory unavailable
• Material allocation failure
• ERP timeout
• Invalid purchasing organization
get_service_level(order_id: str, requested_delivery_date: str) -> dict
Return:
• committed_date (ISO date string)
• confidence_score (float between 0.65 and 0.98)
• available_quantity (integer)
The committed delivery date should occasionally be 2–5 days later than requested.
Available quantity should occasionally be less than requested.
get_invoice(order_id: str) -> dict
Return:
• invoice_id
• line_items
• part_number
• description
• quantity
• unit_price
• extended_amount
• subtotal
• tax
• total
On approximately 20% of calls, introduce a realistic pricing variance between 3% and 7% above the expected unit price. These anomalies will be detected by AI in later labs.
--------------------------------------------------------------------
stubs/warehouse_system.py
--------------------------------------------------------------------
Implement the following public functions.
create_shipping_manifest(order_id: str, items: list) -> dict
Return:
• manifest_id (MFT-XXXXX)
• carrier (FedEx, UPS, or DHL)
• estimated_arrival (ISO date string)
• item_list
notify_dispatch(manifest_id: str) -> dict
Return:
• tracking_number (12-digit string)
• dispatch_timestamp (ISO datetime)
record_material_acceptance(
manifest_id: str,
accepted_items: list,
qa_notes: str
) -> dict
Return:
• acceptance_id
• recorded_at
• status ("recorded")
--------------------------------------------------------------------
stubs/contract_store.py
--------------------------------------------------------------------
Implement one public function.
get_contracts() -> list[str]
Generate five realistic enterprise procurement contracts.
Each contract should be approximately 500–1000 words and resemble an actual supplier agreement.
Each contract represents one product category:
• Steel Components
• Electronic Assemblies
• Plastic Moldings
• Fasteners
• Precision Machined Parts
Each contract should include clearly identifiable sections covering:
• Unit pricing schedules
• Delivery service level agreements
• Quality acceptance standards
• Material inspection procedures
• Late delivery penalties
• Invoice validation requirements
• Invoice dispute procedures
• Payment terms
• Escalation procedures
• Termination clauses
The contracts should read like real legal procurement documents rather than sample text.
--------------------------------------------------------------------
stubs/po_generator.py
--------------------------------------------------------------------
Implement two public functions.
generate_po() -> dict
Return a realistic purchase order containing:
• po_number (PO-XXXXX)
• vendor_id
• vendor_name
• line_items (2–4 items)
Each line item includes:
• part_number
• description
• quantity
• unit_price
• parts_category
Also include:
• requested_delivery_date (ISO date string)
• cost_center
Occasionally generate aggressive delivery requests only 3–5 days in the future.
Ensure purchase orders are internally consistent with the vendors, product categories, and contracts generated in contract_store.py.
generate_batch(n: int) -> list
Return a list containing n purchase orders.
--------------------------------------------------------------------
stubs/__init__.py
--------------------------------------------------------------------
Import all four modules so they are available as:
stubs.erp_system
stubs.warehouse_system
stubs.contract_store
stubs.po_generator
--------------------------------------------------------------------
Completion Requirements
--------------------------------------------------------------------
When finished:
• Verify that every module imports successfully.
• Ensure all generated code is syntactically correct.
• Ensure every public function includes a concise docstring.
• Provide a brief summary of each file that was created.
• Do not create additional files beyond those requested.
• Do not explain your implementation unless errors occur.5.0 Verify the Implementation
Now we will verify that the generated implementation behaves as expected.
5.1 Verify the Project Structure
Run the Verification Command
find stubs -type f | sortExample Output
A project structure similar to:
stubs/
__init__.py
contract_store.py
erp_system.py
po_generator.py
warehouse_system.py5.2 Verify Module Imports
Run the Verification Command
python3.11 - <<'EOF'
from stubs import (
contract_store,
erp_system,
po_generator,
warehouse_system,
)
print("Imports successful")
EOFExample Output
Imports successful5.3 Verify Purchase Order Generation
Generate a Sample Purchase Order
python3.11 - <<'EOF'
from pprint import pprint
from stubs.po_generator import generate_po
pprint(generate_po())
EOFExample Output
A purchase order similar to:
{'cost_center': 'CC-2100',
'line_items': [{'description': 'ABS Enclosure Shell',
'part_number': 'PN-4253',
'parts_category': 'Plastic Moldings',
'quantity': 184,
'unit_price': 14.01},
{'description': 'ABS Enclosure Shell',
'part_number': 'PN-7390',
'parts_category': 'Plastic Moldings',
'quantity': 42,
'unit_price': 44.97},
{'description': 'Polycarbonate Cover Panel',
'part_number': 'PN-8558',
'parts_category': 'Plastic Moldings',
'quantity': 356,
'unit_price': 47.01}],
'po_number': 'PO-40935',
'requested_delivery_date': '2026-07-28',
'vendor_id': 'VEND-1003',
'vendor_name': 'Polyform Industries Inc.'}Verify that:
- The purchase order contains a PO number.
- It contains 2–4 line items.
- Each line item includes a part number, quantity, price, and category.
- A requested delivery date is present.
5.4 Verify ERP Order Creation
Create an ERP Order
python3.11 - <<'EOF'
from stubs import erp_system, po_generator
po = po_generator.generate_po()
print(erp_system.create_order(po))
EOFExample Output
An order confirmation similar to:
{
'order_id': 'ORD-48172',
'confirmed_quantity': 14,
'estimated_ship_date': '2026-07-05'
}5.5 Verify Simulated ERP Failures
Simulate ERP Failures
for i in $(seq 1 20); do
python3.11 - <<'EOF'
from stubs import erp_system, po_generator
po = po_generator.generate_po()
try:
print(erp_system.create_order(po)["order_id"])
except Exception as e:
print("ERROR:", e)
EOF
doneExample Output
You should observe approximately one or two simulated failures, such as:
ORD-82421
ORD-49694
ORD-61417
ORD-56933
ORD-64642
ORD-94860
ORD-95764
ORD-51939
ERROR: Material allocation failure
ORD-75615
ORD-71835
ORD-54683
ORD-43077
ORD-87169
ERROR: Material allocation failure
ORD-44349
ORD-41829
ORD-43903
ORD-82424
ORD-236745.6 Verify Service Level Generation
Generate Service Levels
python3.11 - <<'EOF'
from stubs import erp_system
print(
erp_system.get_service_level(
"ORD-12345",
"2026-07-01"
)
)
EOFExample Output
{'committed_date': '2026-07-01', 'confidence_score': 0.87, 'available_quantity': 52}Verify that:
- committed_date is present
- confidence_score is between 0.65 and 0.98
- available_quantity is returned
5.7 Verify Invoice Generation
Generate an Invoice
python3.11 - <<'EOF'
from pprint import pprint
from stubs import erp_system
pprint(
erp_system.get_invoice("ORD-12345")
)
EOFExample Output
{'invoice_id': 'INV-384519',
'line_items': [{'description': 'Hex Bolt, Zinc Plated',
'extended_amount': 22340.86,
'part_number': 'PN-3459',
'quantity': 142,
'unit_price': 157.33},
{'description': 'Circuit Board Module',
'extended_amount': 9534.96,
'part_number': 'PN-5744',
'quantity': 114,
'unit_price': 83.64},
{'description': 'Hex Bolt, Zinc Plated',
'extended_amount': 1325.82,
'part_number': 'PN-4417',
'quantity': 19,
'unit_price': 69.78},
{'description': 'Circuit Board Module',
'extended_amount': 31428.0,
'part_number': 'PN-5994',
'quantity': 180,
'unit_price': 174.6}],
'subtotal': 64629.64,
'tax': 4847.22,
'total': 69476.86}Verify that:
- invoice_id exists
- line_items are present
- subtotal, tax, and total are calculated
5.8 Verify Warehouse Operations
Execute Warehouse Operations
python3.11 - <<'EOF'
from pprint import pprint
from stubs import warehouse_system
manifest = warehouse_system.create_shipping_manifest(
"ORD-12345",
[{"part_number": "ABC", "quantity": 10}]
)
pprint(manifest)
dispatch = warehouse_system.notify_dispatch(
manifest["manifest_id"]
)
pprint(dispatch)
EOFExample Output
{'carrier': 'FedEx',
'estimated_arrival': '2026-07-05',
'item_list': [{'part_number': 'ABC', 'quantity': 10}],
'manifest_id': 'MFT-98740'}
{'dispatch_timestamp': '2026-06-30T17:17:21.782635',
'tracking_number': '498525603858'}Verify that:
- A manifest ID is generated.
- A carrier is assigned.
- A tracking number is returned.
5.9 Verify Contract Generation
Generate Contract Documents
python3.11 - <<'EOF'
from stubs.contract_store import get_contracts
contracts = get_contracts()
print(len(contracts))
print(len(contracts[0].split()))
EOFExample Output
5
835Verify that:
- Five contracts are returned.
- Each contract contains several hundred words.
6.0 Lab Summary
6.1 What You Built
At the conclusion of this lab you have implemented four independent enterprise service boundaries:
- ERP System
- Warehouse System
- Contract Repository
- Purchase Order Generator
6.2 Architectural Takeaway
Each of these modules encapsulates the behavior of an enterprise system behind a stable interface. The implementation details remain hidden from the consumers of those services, allowing the surrounding application to evolve independently of the systems it integrates.
This separation between interface and implementation is one of the enduring architectural principles that connects enterprise AI to enterprise architecture and systems integration.
In the next lab, Lab 002: Context as Infrastructure with Qdrant, RAG, and Hugging Face, we’ll build a Retrieval-Augmented Generation (RAG) pipeline that consumes these services to semantically retrieve enterprise content.
The Computer Is Going to Do Something – Join an ongoing, practical examination of technology strategy, enterprise architecture, systems engineering, and technology operations.

Leave a Reply