Fixing AWS Architecture Diagrams: AI Document Processing (www.ilograph.com)

AWS’s Intelligent Document Processing sample solution was critiqued for an inaccurate architecture diagram that presents the system as a neat “assembly line” of services. The article compares the official diagram to the actual implementation and shows that unlabeled arrows, equal-sized/duplicated resource boxes, and even fabricated steps misrepresent control flow and responsibilities. That matters because experienced engineers might infer missing details correctly, but inexperienced developers can be seriously misled—especially when an official AWS diagram is treated as best-practice guidance. The author remedies this by converting the design into UML sequence diagrams focused on four Lambda-centered workflows and grounding changes in the repository source. Key technical corrections: Workflow 1 shows Textract pulling documents from the S3 source and the Lambda saving metadata to DynamoDB; Workflow 2 clarifies that Classification Lambda reads Textract results and metadata, writes raw results to Destination S3, and enqueues an SQS message (not S3) that triggers Analysis Lambda; Workflow 3 invokes a single Bedrock flow which reads from S3 while Analysis Lambda writes results to S3; Workflow 4 is simplified—Validate Lambda reads/writes Destination S3 (no A2I or extra cycles). The takeaway: use sequence diagrams and source-code truth to represent asynchronous back-and-forth control flows accurately, and be explicit about diagramming goals (marketing vs. engineering reference).