Forem: Jonathan Wong

From Machine Learning to Production: A Practical Walkthrough Using My Vancouver Traffic Accident Risk Predictor

Jonathan Wong — Mon, 11 May 2026 22:21:41 +0000

Artificial intelligence has many branches, but in real projects the most important question is simple: what tool solves the problem with the least complexity and the highest reliability.

This article walks through that question using my GitHub project, Vancouver Traffic Accident Risk Predictor, as a real example. Along the way, it explains when to use machine learning (ML) instead of large language models, how an ML pipeline works, what MLOps means, and how a model becomes a production ready service.

The Modern Habit of Using LLMs for Everything

There is a new pattern in the industry. Whenever a team faces a data problem, someone eventually says, “Why not just use an LLM for this?”

It sounds modern. It sounds powerful. It feels like a universal solution.

But this instinct hides a deeper issue.

LLMs are not designed for structured data prediction.

They can reason across messy text, generate explanations, and handle unstructured inputs. They are excellent at language. But when the task is numerical, statistical, or based on clean tabular data, an LLM behaves like a very smart person guessing instead of a model trained precisely for the job.

This is where the Vancouver project becomes a perfect example.

The goal is to predict accident risk based on weather and traffic conditions.

This is not a language problem.

This is a structured prediction problem.

This is exactly where classical ML shines.

Why Business Users Often Think LLMs Can Solve Everything

This misconception is extremely common, and it is not the fault of business users.

It comes from the experience of interacting with LLMs, not from their underlying capabilities.

LLMs feel magical

A business user types a question.

Claude answers instantly.

It sounds smart.

It sounds confident.

It sounds like it understands the business context.

From their perspective, this feels like general intelligence.

So the natural conclusion becomes:

“If it can talk about anything, it can probably do anything.”

Industry messaging reinforces the illusion

Marketing language often says things like:

“Analyze your data with AI”
“AI that understands your business”
“AI that learns from your documents”

Business users interpret this literally.

They imagine the LLM training on their data.

In reality, the LLM is only summarizing or sampling it.

LLMs hide complexity

A classical ML pipeline exposes its steps:

Data cleaning
Feature engineering
Model training
Evaluation
Deployment

LLMs hide all of this behind a single prompt.

So business users assume the complexity is gone.

But the complexity is still there — just invisible.

The professional explanation

The most effective way to explain this to business stakeholders is simple:

“Claude is excellent at understanding and generating language.

But price prediction, risk scoring, and forecasting are mathematical problems, not language problems.”

This keeps the conversation respectful, clear, and aligned with business outcomes.

The Reality Check: Is “LLM Everything” Acceptable in Terms of Results and Costs

The short answer is no.

But the reasons matter.

The results problem

LLMs can approximate patterns in structured data, but they cannot match the precision of a model trained directly on the dataset.

Classical ML consistently delivers:

Higher accuracy
Better calibration
More stable predictions
Clearer evaluation metrics

LLMs, by contrast, introduce variability and guesswork.

The cost problem

Even small LLMs are expensive compared to classical ML.

They require more compute, more memory, and often GPU acceleration.

A simple logistic regression or random forest runs on a tiny CPU with millisecond latency and almost zero cost.

An LLM introduces unnecessary overhead.

The engineering problem

LLMs are harder to test, harder to monitor, and harder to guarantee deterministic behavior.

For structured prediction, this is unnecessary complexity.

So is “LLM everything” acceptable?

Only if you do not care about accuracy, cost, latency, interpretability, or operational simplicity.

Real projects always care about these things.

Comparison of ML vs LLM for Structured Prediction

Dimension	Classical Machine Learning	Large Language Models
Accuracy on structured data	High accuracy with stable, well calibrated predictions	Lower accuracy, pattern guessing rather than statistical learning
Latency	Milliseconds on CPU	Tens to hundreds of milliseconds, often requires GPU
Cost per prediction	Extremely low	Significantly higher, especially at scale
Scalability	Scales cheaply on commodity hardware	Scaling requires more compute and higher operational cost
Interpretability	Clear metrics, feature importance, reproducible behavior	Hard to interpret, non deterministic, difficult to validate
Operational complexity	Simple to test, monitor, and deploy	Harder to test, monitor, and guarantee consistent outputs
Best suited for	Risk scoring, forecasting, classification, anomaly detection	Text reasoning, summarization, multi modal understanding
Overall fit for structured prediction	Excellent	Acceptable only with compromises in cost and accuracy

Real World Comparison

Scikit Learn ML vs Claude 4.7 LLM for a 10 GB Price Prediction Dataset

In real enterprise environments, teams often ask whether an LLM can replace a classical ML model for large scale prediction tasks.

So let us take a concrete scenario:

A 10 GB Excel dataset for price prediction.

Which tool performs better?

A well defined scikit learn pipeline wins every time.

Claude 4.7 is slower, less accurate, and dramatically more expensive.

Why ML Wins

When the task is structured prediction on a large dataset, classical ML does not just win — it wins decisively. And the reasons become even clearer when you look at the actual tools used in real projects.

ML can train on the full dataset

A scikit learn pipeline can load and process the entire 10 GB dataset using the Python data stack that enterprises rely on every day:

pandas for ingestion and cleaning
- pandas.read_csv to load large files in chunks
- DataFrame.merge to join datasets
- DataFrame.fillna to handle missing values
numpy for vectorized numerical operations
scikit learn for modeling
- RandomForestRegressor
- GradientBoostingRegressor
- train_test_split
- Pipeline
- StandardScaler

These libraries are built for structured data at scale.

They learn real statistical relationships instead of guessing patterns.

ML produces stable, reproducible predictions

With scikit learn, you can:

Set random_state for deterministic behavior
Evaluate models with cross_val_score
Inspect feature importance
Tune hyperparameters with GridSearchCV or RandomizedSearchCV

This gives you a model that behaves the same way every time.

ML runs cheaply and efficiently

A trained scikit learn model:

Runs on CPU
Responds in milliseconds
Costs almost nothing per prediction
Scales horizontally with minimal infrastructure

This is why ML is used in production systems where cost and latency matter.

ML integrates cleanly into production

With Python’s ecosystem, you can deploy the model using:

FastAPI for serving predictions
Docker for packaging the environment

This gives you a clean, maintainable architecture that fits naturally into modern DevOps and MLOps workflows.

Why Claude 4.7 Loses

Claude 4.7 is powerful, but it is not built for this category of problem.

It cannot train on 10 GB of structured data

Claude can only sample or summarize chunks of the dataset.

It cannot compute gradients, optimize a loss function, or learn the full distribution.

It guesses patterns instead of learning them

LLMs are language models, not regression engines.

They infer trends from text, not from numerical relationships.

It is slower and more expensive

Higher latency
Higher compute cost
Requires chunking and repeated calls
Cannot be cached effectively

It introduces non deterministic behavior

Even with the same prompt, outputs can vary.

This is unacceptable for financial, operational, or regulatory workloads.

When Claude 4.7 Is Still Useful

LLMs are excellent assistants for:

Exploratory analysis
Explaining trends
Suggesting features
Cleaning messy text columns
Generating documentation

But not for the core predictive model.

For large structured datasets and numerical prediction tasks:

Use ML for the model.

Use LLMs for support.

This is the architecture that delivers accuracy, cost efficiency, and operational stability.

Machine Learning as Part of AI

Machine learning is one of the foundational pillars of AI. It learns patterns from structured data and uses those patterns to make predictions.

When ML is the right tool

Use ML when the problem involves:

Numerical prediction
Classification on structured data
Statistical relationships
Low latency inference
Clear evaluation metrics
Reproducible behavior

When LLMs are the right tool

Use LLMs when the problem involves:

Understanding or generating text
Summarizing documents
Reasoning across unstructured information
Conversational interfaces
Multi modal inputs

A simple rule of thumb:

If the question is “Given these numbers, what is the probability of X?” , use ML.
If the question is “Given this text, what does it mean?” , use an LLM.

What an ML Pipeline Really Is

An ML pipeline is the journey from raw data to a working model.

It is not a single script. It is a repeatable, structured process.

A complete ML pipeline includes:

Data ingestion
Data cleaning and preparation
Exploratory data analysis
Feature engineering
Model training and evaluation
Model packaging
Deployment and monitoring

This pipeline ensures that the work is reproducible, traceable, and ready for automation.

What MLOps Means

MLOps is the operational discipline that keeps machine learning systems healthy in production.

It brings together DevOps, data engineering, and model lifecycle management.

MLOps focuses on:

Versioning of data, code, and models
Automated training and retraining
Continuous integration and delivery
Monitoring model drift and performance
Scalable deployment patterns

If ML is the engine, MLOps is the system that keeps the engine running safely at scale.

Example: The Vancouver Traffic Accident Risk Predictor

This project analyzes weather and traffic accident data in Vancouver and builds a predictive model to estimate accident risk under different conditions.

It follows a complete ML pipeline from exploration to deployment.

Introduction to Weather and Traffic Accident Analysis in Vancouver

The project begins with a simple question:

How does weather influence accident risk in the city?

Data Sources and Analytical Tools

The project uses:

Traffic accident records: Traffic accident data is sourced from the City of Vancouver’s Strategic Plan Dashboard for reliability and accuracy. The dashboard provides detailed and regularly updated records essential for comprehensive traffic analysis.
Historical weather data: Weatherstats.ca aggregates data from Environment and Climate Change Canada for accurate meteorological information. The data encompasses a wide range of weather variables ensuring thorough climate analysis.

Tools include Python, Pandas, Matplotlib, Boken, Scikit Learn, FastAPI, and Docker.

Data Cleaning and Preparation

This stage merges datasets, handles missing values, and prepares the final analytical table.

Exploratory Data Analysis

EDA reveals patterns such as:

Higher accident frequency during snow
Seasonal variations
Time of day risk levels

Visualizing Key Trends

Charts help identify correlations and guide feature selection.

Predictive Modeling

The dataset is split into training and testing sets.

Models such as random forest are trained to predict accident risk.

Evaluation metrics confirm generalization.

Accuracy Metric: Accuracy measures the overall correctness of the predictive model by comparing true results to total predictions.

Precision Metric: Precision indicates how many of the positive predictions made by the model are actually correct.

Recall Metric: Recall assesses the model’s ability to identify all relevant positive cases in the dataset.

To increase the accuracy of Our ML module, we can tune the hyperparameters:

Insights and Conclusions

The analysis shows how weather patterns influence accident probability and demonstrates the value of structured ML for public safety insights.

5. Productionalization and Deployment

A model becomes valuable only when it can be used by real applications.

FastAPI Model Server

The trained model is wrapped in a FastAPI application that exposes a prediction endpoint.

An in memory prediction cache provides low latency responses.

Dockerized Environment

The entire environment is packaged in Docker, ensuring:

Consistent runtime
Easy local testing
Seamless deployment to any container platform

This closes the loop from exploration to production.

Why This Matters to Your Business

Every organization today is under pressure to adopt AI, but the real advantage comes from choosing the right tool for the right problem.

This article highlights a simple but often overlooked truth:

Not every AI problem needs an LLM. Many business problems are solved faster, cheaper, and more reliably with classical ML.

For business leaders, this means:

Lower operational cost
Faster time to value
More predictable performance
Easier compliance and governance
Clearer ROI

The Vancouver project is not just a technical exercise. It is a demonstration of how disciplined ML engineering can deliver practical, measurable outcomes without unnecessary complexity.

Conclusion

Machine learning is not a relic from the pre LLM era.

It is a precise, efficient, and reliable discipline that solves structured prediction problems better than anything else.

The Vancouver Traffic Accident Risk Predictor demonstrates how ML pipelines, MLOps practices, and lightweight deployment patterns come together in a real project.

If your team is exploring AI adoption, modernizing analytics, or evaluating where ML and LLMs fit into your roadmap, I am always open to meaningful conversations.

Whether you are building your first predictive model or scaling AI across the organization, the right architecture and the right tool choice make all the difference. Feel free to connect.

About the Author

Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.

Connect with me on LinkedIn

The post From Machine Learning to Production: A Practical Walkthrough Using My Vancouver Traffic Accident Risk Predictor appeared first on Behind the Build.

When AI Agents Transact: How Interaction Surface Mobility Redefines the Future of Payments

Jonathan Wong — Sat, 09 May 2026 03:46:22 +0000

The story of digital payments has always been a story about movement.
Not just the movement of money, but the movement of the place where intention begins, where authentication happens, and where the transaction is finally executed.

Amazon’s introduction of Amazon Bedrock AgentCore Payments marks the beginning of a new chapter in that story. It is a chapter where AI agents no longer wait for users to initiate payments. Instead, they transact autonomously, safely, and with full governance. And to understand why this matters, we need to look at how the interaction surface has been moving for more than two decades.

A New Foundation for Agent Payments

AgentCore Payments is a fully managed payment layer that allows AI agents to pay for APIs, data, MCP servers, and even other agents. It integrates Coinbase and Stripe to support microtransactions, stablecoin payments, identity bound wallets, spending guardrails, and full observability.

In the past, building this kind of payment capability required months of engineering work. Wallet management. Compliance. Guardrails. Billing logic. Error handling. AgentCore Payments removes all of that complexity. Payments become part of the agent execution loop, not a separate system bolted on the side.

This shift becomes clear when we look at how an agent handles a simple request such as analyzing Amazon stock.

How It Works

Once the agent realizes it needs paid data, the rest of the process is handled entirely by AgentCore Payments. The system provides a complete payment foundation inside the agent execution loop. It connects wallets, executes microtransactions, enforces spending rules, and records every event for governance and audit.

AgentCore Payments includes five core capabilities that work together as a single runtime layer.

Payment orchestration
The platform manages wallet connections, establishes secure sessions with providers such as Coinbase and Stripe, and executes payments on behalf of the agent.

Payment guardrails
Every transaction is checked against authorization rules and spending limits. This prevents runaway costs and ensures the agent stays within the boundaries defined by the user or the organization.

Unified identity for agents
Each agent operates under a consistent identity that ties together permissions, wallet access, and spending policies.

Observability across all payment events
Every payment attempt, success, failure, and retry is logged. This gives teams full visibility into how agents are spending and why.

Native integration with agent execution loops
Payments are not an external system. They are part of the agent’s reasoning and tool calling cycle. This allows agents to autonomously discover, evaluate, and pay for resources as part of completing a task.

Source: Agents that transact: Introducing Amazon Bedrock AgentCore payments, built with Coinbase and Stripe | Artificial Intelligence

Example: Analyze Amazon Stock Enquiry

A user asks the agent to analyze Amazon stock.
The agent determines that real time financial data is required, and that the data source is paid.
It reaches out to the provider.
At that moment, AgentCore Payments takes over.

It authenticates the wallet.
It executes the microtransaction.
It checks spending guardrails.
It logs the entire event for observability.

Once the payment clears, the agent receives the data.
It completes the analysis and returns the result to the user.

This example demonstrates the core value of AgentCore Payments.
Agents can autonomously transact inside a single execution loop without any custom payment logic.

Interaction Surface Mobility

A Short Explanation

To understand why this shift is so significant, we need a new lens.
Historically, people talked about device mobility. Desktop to laptop to mobile to wearables. But the real story is not about devices. It is about the interaction surface. The place where intention originates, where authentication happens, and where payments are triggered.

Interaction Surface Mobility describes how this surface keeps moving closer to the user’s life.
From the desk.
To the pocket.
To the environment.
And now into the cloud, where AI agents act on our behalf.

This mobility shapes how payments work, how businesses design services, and how value flows across digital ecosystems.

The Four Eras of Interaction Surface Mobility

Before we explore the eras, it helps to understand the underlying structure.
Payment flows follow a consistent pattern:

Interaction surface → service starting point → intention → authentication → channel

This formula becomes the backbone for understanding how payments evolve as the interaction surface becomes more mobile and more embedded in daily life.

But what is actually changing in this new era?
The primary shift is the movement of the interaction surface itself.
As the interaction surface moves, everything downstream changes with it.
The service starting point moves.
The intention model changes.
The authentication model changes.
The payment channel changes.
The interaction surface is the driver.
The rest of the flow is the consequence.

With this causal structure in mind, the four eras become clear.

Table: The Evolution of Interaction Surface Mobility

Era	Interaction surface	Service starting point	Intention	Auth	Channel
Desktop Web	Desktop	Website	User initiated	Manual login	Web payment page
Mobile App	Mobile phone	App	User initiated	Biometric	Mobile wallet
Cloud AI Services	Cloud agents	Cloud workflows	AI interpreted	Pre authorized agent identity	Agent to agent payment service
Ambient AI	Ambient compute	Autonomous AI workflows	AI reasoning	Identity bound spending guardrails	Autonomous payment protocols

Era 1: The Desktop Web

In the beginning, the interaction surface was fixed.
People sat at a desk, opened a browser, and intentionally navigated to a payment page. Every action was explicit. Every step was manual. Payments were a destination, not a flow.

This era shaped the first generation of online commerce. But it was limited by the immobility of the interaction surface. The user had to go to the computer. The computer never followed the user.

Era 2: The Mobile App

Then the interaction surface moved into the pocket.
The phone became the center of digital life.
Apps replaced websites.
Biometrics replaced passwords.
Wallets replaced card forms.

Payments became faster, more personal, and more contextual.
This era created ride hailing, food delivery, and mobile commerce.
It also marked the beginning of lifestyle mobility.
People no longer went to the payment interface.
The payment interface went with them.

Era 3: Cloud Based AI Services

The next shift was subtle but profound.
The interaction surface moved off the device entirely and into the cloud.
AI agents began performing tasks on behalf of users.
They interpreted intention.
They initiated workflows.
They accessed paid resources.

But payments were still a problem.
Agents could not pay for anything without custom engineering.
Wallets were not agent native.
Guardrails were not standardized.
Governance was fragmented.

AgentCore Payments solves this.
It gives agents a native way to transact, with identity, guardrails, and observability built in.
This is the first real payment system designed for autonomous agents.

Era 4: Ambient AI

This is the era we are entering now.
The interaction surface becomes the environment itself.
Homes, cars, offices, glasses, wearables, sensors, and cloud agents all become part of a continuous ambient layer.

Intention is no longer expressed.
It is reasoned.
Sometimes even anticipated through context.

Authentication becomes a set of identity bound spending rules.
Channels become autonomous payment protocols.
Transactions become micro events inside larger workflows.

In this world, payments are not actions.
They are side effects of intelligent systems doing their work.

Why This Matters for Business

Interaction Surface Mobility is not just a technical evolution.
It is a business transformation.

Payments become invisible.
Intention becomes fluid.
Authentication becomes ambient.
Channels become agent native.
Business models shift from subscriptions to usage based to agent based.

Agents will buy data.
Agents will buy compute.
Agents will buy services.
Agents will buy from other agents.

The companies that understand this shift will design products for a world where the user is no longer the primary actor in the payment flow.
The agent is.

Closing Thought

The movement of the interaction surface has always reshaped the payment landscape.
From the desk.
To the pocket.
To the environment.
And now into the cloud, where agents transact on our behalf.

AgentCore Payments is not just a new feature.
It is the infrastructure for the next era of commerce.
An era defined by Interaction Surface Mobility, where payments become autonomous, contextual, and woven into the fabric of intelligent systems.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn

The post When AI Agents Transact: How Interaction Surface Mobility Redefines the Future of Payments appeared first on Behind the Build.

A Pre‑AI Lesson for the AI Era: Scrum in a Cross‑Regional Cloud Migration Delivered in Ten Weeks

Jonathan Wong — Wed, 06 May 2026 23:23:33 +0000

A few years ago, I stepped into one of the most challenging and transformative projects of my career as a Cloud Architect. I was responsible for leading a cross‑regional team of more than twenty developers across Hong Kong and China. With Scrum, Atlassian JIRA, and Confluence as our backbone, we rebuilt an AWS‑based JEE Spring microservices platform using Kafka and PostgreSQL and migrated it fully to Azure. The original engineering estimate was six months. We delivered it in ten weeks.

This is the story of how alignment, structure, and communication reshaped the entire organisation.

Background

Situation
The project began with a strong team but a fragmented operating model. Everyone worked hard, but the lack of shared structure created delays and misunderstandings.

Points
• Cross‑regional team of more than twenty developers across Hong Kong and China
• Many engineers were domain experts with strong CI and CD foundations
• Multiple teams involved including product, engineering, sales, and customer success
• Hardworking culture but no unified workflow
• Required to migrate a cloud product to Azure due to client request
• Engineering estimated six months, which the business could not accept

Result
The team had the talent and capability, but without alignment, the project was heading toward an unacceptable timeline.

My Role in the Transformation

As the Cloud Architect leading this initiative, I became the bridge between product, engineering, sales, and customer success. My role was not only technical but also organisational. I facilitated communication, explained Scrum practices in simple and practical ways, and guided the teams to adopt a structured, transparent workflow. By aligning expectations, enforcing clarity, and coaching the teams through Agile execution, I helped transform the project from fragmented chaos into a predictable, collaborative delivery model.

Problems and the Real Original Situation

Situation
The delays were not caused by technical difficulty. They were caused by fragmented communication, inconsistent requirement handling, and a workflow that depended heavily on verbal instructions and individual memory. The actual “before” situation was far more chaotic than a simple misalignment.

Points
• Product team sometimes gave requirements verbally through phone calls, WhatsApp or WeChat
• Product features were told directly to individual engineers or salespeople
• Different parts of the same requirement were distributed through different channels such as email, phone, and chat
• Customer success often contacted individual engineers or product members suddenly
• No one had a complete picture of the requirement
• Engineering teams lacked visibility into each other’s status and technical availability
• Developers were frequently switched between tasks, losing focus
• Management had no visibility into progress or bottlenecks
• CS handled customer issues without knowing what was released
• Feedback rarely reached product or engineering in a structured way

Result
The organisation operated on tribal knowledge. Misunderstandings were common, rework was frequent, and timelines were unpredictable. The six‑month estimate reflected organisational misalignment, not technical complexity.

How I Solved It Using JIRA, Confluence, and Scrum

Inside the Engineering Teams

Situation
The engineering team needed structure, clarity, and a predictable rhythm.

Points
• All development work documented on the tracker
• Engineers only worked on items listed in the tracker
• Requirements treated as negotiable conversations
• PM updated the tracker after every discussion
• Engineers picked the first available item
• Story status updated continuously
• One engineer worked on one item at a time
• Requirements broken into technical tasks
• Development discussions moved into JIRA
• Work delivered into testing story by story
• Tasks created for POC, technical debt, and research
• Tasks broken down with dependencies and blockers
• One task assigned to one engineer

Result
Engineering gained clarity, focus, and a stable delivery rhythm that accelerated progress.

Inside the Product Team

Situation
The product team needed a consistent way to express requirements so engineering could execute without ambiguity.

Points
• Features and bugs written with proper structure
• Requirements documented from the user perspective
• Simple English, point form, short sentences
• Stories tested and verified quickly
• Backlog groomed regularly and prioritized top to bottom

Result
The product team became a source of clarity instead of confusion, reducing rework and saving time.

Knowledge and Task Management

Product, Knowledge, and Requirement Management

Situation
Information lived in too many places. Teams needed a single source of truth.

Points
• Confluence used as a centralized panel
• Structure followed Space to Pages to Contents
• Pages included product requirements, technical documents, and notes
• Product requirement pages included goals, milestones, and voting
• Technical documents included architecture, installation, and account details
• Notes captured meetings, research, and decisions
• Confluence pages linked directly to JIRA issues

Result
Knowledge became shared, searchable, and consistent across all teams.

Issue Types and Their Purpose

Situation
Teams needed a common language to describe work, track progress, and estimate timelines.

Points
• Bug for previously working functions that broke
• Note for behaviours that became new requirements
• Story for the smallest unit of user value
• Task for feasibility studies, POC, and technical debt
• Epic for large initiatives
• Subtask for breaking down work
• Enabled velocity tracking and release estimation
• Tracked internal and external dependencies
• Smart Commits connected code changes to tasks
• JIRA release notes notified sales and CS automatically

Result
The organisation gained predictable delivery, accurate planning, and better cross‑team alignment.

Team Meetings to Improve Communication

Situation
Tools alone were not enough. Teams needed real‑time alignment and shared understanding.

Points
• Daily morning standups with engineering
• Weekly Monday meeting with all team heads
• Customer success joined standups when client feedback needed clarification

Result
Communication became continuous, reducing misunderstandings and last‑minute surprises.

Example: From Product Design through Engineering to CS and Back

Situation
To show the impact of the transformation, here is a real example of how a feature moved through the organisation before and after the new workflow.

Before

Situation
The original workflow was chaotic, fragmented, and heavily dependent on verbal communication.

Points
• Product team sometimes gave requirements verbally through phone calls or WhatsApp
• Product features were told directly to individual engineers or salespeople
• Different parts of the same requirement were distributed through different channels
• Customer success often contacted individual engineers suddenly
• No one had a complete picture of the requirement
• Engineering built based on partial or outdated information
• Sales promised features based on verbal conversations
• CS handled customer issues without knowing what was released
• Feedback rarely reached product or engineering

Result
The organisation operated on tribal knowledge. Misunderstandings were common, rework was frequent, and timelines were unpredictable.

After

Product Design

• Product team created a clear Confluence page with goal, user story, acceptance criteria, and diagrams
• Page linked directly to a JIRA story and tasks
• All teams saw the same requirement at the same time

Engineering Development

• Engineers broke the story into tasks and subtasks
• Dependencies and blockers were defined
• Work delivered story by story into testing
• PM verified each story immediately

Release to CS

• JIRA release function automatically pushed release notes to Microsoft Teams
• CS team received a clear list of new features, fixes, and version numbers
• Sales also received the same release notes

CS Feedback Loop

• CS tested the new feature with real customers
• Feedback added as comments on the Confluence page
• Product team reviewed and updated requirements
• Engineering received new tasks or improvements linked to the original story

Result
The entire lifecycle became a closed loop. Every team saw the same truth, reacted quickly, and aligned their actions.

Before and After Comparison

Situation
The transformation changed the culture, speed, and clarity of the entire organisation. Presenting the contrast as a table makes the improvement immediately clear.

Phase	Before	After	Result
Product Design	Requirements delivered verbally through phone or WhatsApp	Requirements documented clearly in Confluence	Clear documentation replaced verbal memory
Product Design	Different parts of the same requirement sent through different channels	Single source of truth for all requirements	One place for all information
Product Design	Product features communicated directly to individual engineers or sales	Structured JIRA stories and tasks shared with all teams	Everyone received the same message
Knowledge Management	No documentation and no shared visibility	Centralized product and technical knowledge	Teams aligned on the same information
Engineering Execution	Frequent rework and misaligned expectations	Predictable engineering workflow with clear dependencies	Work became stable and predictable
Release Management	No release notes for CS or sales	Automated release notes through JIRA to Microsoft Teams	All teams stayed informed on every release
Customer Success	CS feedback delivered suddenly to individuals	CS feedback captured in Confluence and linked to JIRA	Feedback became structured and trackable
Delivery Timeline	Six month timeline estimate	Ten week delivery	Alignment accelerated delivery dramatically

Result
The organisation shifted from reactive chaos to proactive alignment, with every team operating from the same truth.

What This Solved and the Result

Situation
Once structure, communication, and knowledge alignment were in place, the entire organisation began to move faster.

Points
• Centralized visibility improved planning and saved time
• Clear product goals reduced misunderstanding
• Early validation reduced downstream rework
• Engineering timelines became predictable
• Product page and task linkage aligned business and engineering
• JIRA auto‑release notes empowered sales and CS
• Engineering teams understood each other’s status and availability
• Defined blockers prevented last‑minute surprises
• Centralized documentation reduced search time and improved support

Result
The six‑month estimate collapsed into ten weeks because every team finally moved in the same direction.

Conclusion

Product success is built on teamwork across all functions. Improving the product development timeline required alignment from product design to feature validation, business requirement transformation, testing, release, customer success, post delivery support, and customer feedback. When every team shares the same truth, the entire organisation accelerates.

This experience, even though it happened a few years ago, remains fully relevant in today’s AI driven business era. It is a clear example of how Scrum and Agile principles solve real operational problems. The story shows that delays rarely come from tools or technical expertise. They come from the absence of a disciplined operational methodology. When teams follow a repeatable Agile process supported by a single source of truth, technology becomes an accelerator rather than a bottleneck.

What’s Next

This article presents the high level view of how Scrum and operational alignment improved a cross regional cloud migration timeline. In the next article, I will walk through the detailed implementation across each phase, and explain the specific problems the team encountered, how those challenges were solved, and how the Scrum workflow kept the project moving with clarity from design to delivery.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn

The post A Pre‑AI Lesson for the AI Era: Scrum in a Cross‑Regional Cloud Migration Delivered in Ten Weeks appeared first on Behind the Build.

Cloud Summit 2026

Jonathan Wong — Mon, 04 May 2026 19:56:54 +0000

I spent the day at Cloud Summit and it turned into one of the busiest days I have had in the Vancouver tech scene. The event pulled together a wide mix of local engineers and builders, and most of the sessions leaned heavily into AI. The conversation has clearly shifted from abstract excitement to real architectural patterns and operational challenges.

One of the most interesting sessions was the deep dive into the Kubernetes AI Gateway work. The working group is shaping a consistent way to handle AI‑specific traffic at the gateway layer, including protocol awareness, egress controls, payload inspection, routing and guardrails. It is still early and mostly proposals and prototypes, but the direction is promising for teams trying to standardize how they expose and secure inference workloads.

Another standout was the talk on cloud billing complexity, The Cloud Bill Nobody Could Explain. The speaker walked through a real incident investigation where even experienced teams struggled to explain unexpected cost behaviour. The supporting tools were practical, from VPC flow log analyzers that map traffic to namespaces, to exporters that surface per‑namespace cloud cost metrics, to utilities for finding orphaned disks across providers. It was a reminder that cost transparency is still one of the hardest engineering problems in cloud.

The free snacks and pizza made the long day easier, and if you also joined the AWS Workshop on Introduction to Claude Code on AWS and stayed for the after party, you probably felt the same mix of learning, networking and exhaustion.

Vancouver’s cloud and AI community is moving fast, and days like this make it clear how much is happening across the ecosystem.

The post Cloud Summit 2026 appeared first on Behind the Build.

Autodata and the New Data Pipeline: Why Meta’s Agentic Data Scientist Matters More Than the Model

Jonathan Wong — Sun, 03 May 2026 01:52:55 +0000

The industry has spent years debating model size, architectures, and inference tricks. But Meta’s latest research makes something very clear: AI success is still determined by four elements: prompt, grounding, training, and fine tuning, and three of them are fundamentally data problems.

Which means the real bottleneck isn’t compute. It’s data quality, data structure, and data digestion.

Meta’s new Autodata framework reframes this bottleneck entirely. Instead of treating data as a static asset that humans must continuously curate, Autodata turns the model itself into an autonomous data scientist , capable of generating, analyzing, and iterating on its own training data.

Figure: Autodata pipeline. The framework employs an autonomous agent that emulates the role of a data scientist, iteratively generating data, conducting qualitative inspection and quantitative performance evaluation, synthesizing insights, and updating the data-generation recipe. The agent itself can be trained to be better at the data scientist task using the same criteria used in the inner loop. This cyclical process aims to progressively enhance data quality; the diagram depicts the general workflow underlying possible instantiations. RAM @ Meta AI | A framework to study AI models in Reasoning, Alignment, and use of Memory (RAM)

This is not “synthetic data 2.0.”

This is a shift in how data pipelines operate.

1. Why Data Quality Still Determines AI Success

Prompting and grounding matter, but they sit on top of the real foundation:

the training data that shapes the model’s baseline
the fine‑tuning data that aligns it
the evaluation data that determines whether it’s improving

Three of the four levers that determine AI performance are data‑centric.

And historically, all three required human data scientists — expensive, slow, and difficult to scale.

2. The Traditional Data Scientist Bottleneck

Data scientists have always played the critical role of:

curating high‑quality examples
grounding tasks in real documents
designing evaluation rubrics
iterating based on model failures

This work is high‑cost because it requires human judgment , domain knowledge, and careful harness engineering. Even synthetic data pipelines still depended on humans to design prompts, filters, and quality checks.

3. Meta’s Autodata: A Model That Trains Itself With Data It Creates

Autodata changes the loop.

Instead of single‑pass synthetic generation, the model now:

Data Creation. The agent grounds on the provided documents and uses its existing skills and compute to create training or evaluation data. It can repeat this step after each analysis cycle to incorporate new learnings and improve the data.
Data Analysis. The agent reviews the data it created to understand correctness, quality, difficulty, and diversity. These learnings feed directly back into the next creation cycle until the data reaches the required standard.
Data Scientist Loop. The agent cycles between creation and analysis until it is satisfied with the final dataset. Guardrails can be applied to prevent reward hacking, and later generations of agents can build on earlier learnings.
Meta Optimization. The agent itself can be improved through autoresearch or meta‑harness optimization so it becomes better at performing the data scientist role over time.

Meta’s implementation uses a multi agent setup with a Challenger, a Weak Solver, a Strong Solver, and a Verifier to ensure the generated data is neither trivial nor impossible. The result is higher quality training data than classical Self Instruct or CoT Self Instruct methods.

This is the first time we’ve seen a closed‑loop, feedback‑driven data creation system that mirrors how human data scientists work.

Figure: Example agent trajectory on a CS research paper, showing the final accepted round (round 6) after 5 failed attempts. The Main Agent reflects on prior failures and prompts the Challenger Agent to generate a new question. The example is evaluated by Weak (4B) and Strong (397B) solvers, scored by a Verifier/Judge across 12 rubric criteria. Round 6 achieves a 45% gap (weak 48% vs. strong 93%) and is accepted. Learnings from rounds 1–5 feed back into the Main Agent’s refinement strategy. RAM @ Meta AI | A framework to study AI models in Reasoning, Alignment, and use of Memory (RAM)

4. Reducing the Cost of Human‑Grounded Data

The cost of training data has always come from:

human annotation
human‑designed prompts
human‑designed evaluation rubrics
human‑driven iteration

Autodata reduces all four.

Meta’s meta‑optimization layer even shows that the agent can improve its own instructions , discovering better harness logic without human intervention.

Figure: Meta-optimization of the data scientist agent. An outer optimization loop evaluates the agent’s harness on training papers, analyzes failure trajectories to identify systematic weaknesses (e.g., context leakage), implements harness modifications via a code-editing agent, and re-evaluates on held-out validation papers. Changes are accepted only if they improve the weak-strong separation rate. This process improved validation pass rate from 12.8% to 42.4% over 126 accepted iterations out of 233 total. RAM @ Meta AI | A framework to study AI models in Reasoning, Alignment, and use of Memory (RAM)

This is the part that matters:

The model is not just generating data, it is improving the rules for generating data.

5. AI as the Data Scientist

Meta’s results show that an AI data scientist can:

enforce paper‑specific insights
prevent context leakage
design structured rubrics
tune difficulty levels
widen capability gaps between weak and strong solvers

All without manual harness engineering.

This is the beginning of agentic data operations , where the model becomes an active participant in its own training pipeline.

6. A Shift in the Data Operations Pipeline

Autodata changes the relationship between:

data creation
data evaluation
model training
model alignment

Instead of a linear pipeline, we now have a self‑improving loop where the model continuously refines the data that refines the model.

This transforms data operations from a human‑driven workflow into a compute‑driven optimization problem.

7. Rethinking the Four Elements of AI Success

If prompt, grounding, training, and fine‑tuning determine AI success, and three of them are data‑centric, then Autodata forces us to rethink how these elements interact.

We now have:

new external grounding (the model grounds itself on documents)
new internal grounding (the model evaluates its own reasoning)
new training loops (data improves as compute increases)
new fine‑tuning strategies (agent‑generated datasets outperform human‑designed ones)

The implication is simple:

Data pipelines are becoming agentic systems, not manual processes.

Where This Leads

Autodata is not just a research milestone.

It signals a future where:

models generate their own training curriculum
data scientists supervise strategy, not samples
data quality scales with compute, not headcount
grounding becomes dynamic, not static
fine‑tuning becomes continuous, not episodic

The next wave of AI performance will come from agentic data pipelines , not larger models.

And Meta just opened the door.

Source: Meta Autodata research https://facebookresearch.github.io/RAM/blogs/autodata/

The post Autodata and the New Data Pipeline: Why Meta’s Agentic Data Scientist Matters More Than the Model appeared first on Behind the Build.

IEC BC x ISACA Vancouver Cybersecurity Networking Event

Jonathan Wong — Thu, 30 Apr 2026 23:04:57 +0000

At the IEC BC x ISACA Vancouver Cybersecurity Networking Event this week, newcomers, experienced professionals, and employers had the chance to connect meaningfully. Thank you to Immigrant Employment Council of BC, ISACA Vancouver Chapter and Vancouver Community College (VCC) for making this possible.

The speaker shared a clear breakdown of certification pathways in cybersecurity.

Foundational certifications include ISC2 Certified in Cybersecurity (CC).

Intermediate tracks include CISA, CCSP, and AWS Security.

Senior level designations include CISSP and CISM, which reflect broader responsibility across governance, architecture, and organizational risk.

The speaker also highlighted the challenges overseas trained professionals face in the Vancouver job market. Many arrive with strong technical backgrounds, yet still need to navigate local hiring expectations, credential recognition, and the persistent “Canadian experience” requirement. Hearing this acknowledged openly was valuable for many attendees.

Another insight from the talk focused on how companies are adopting AI inside their organizational structure. The risk is not only technical. For SMEs with fewer than 50 employees, restructuring teams too quickly around AI can create instability and unclear ownership.

One final note for anyone exploring cybersecurity.

The free ISC2 Certified in Cybersecurity (CC) enrollment ends on May 20, 2026.

If you are considering a first step into the field, this is a good opportunity before the window closes.

The post IEC BC x ISACA Vancouver Cybersecurity Networking Event appeared first on Behind the Build.

My Journey to the Google Cloud Get Certified: From Fundamentals to Generative AI

Jonathan Wong — Thu, 30 Apr 2026 22:19:03 +0000

Deciding to get Google Cloud certified is one thing; finding a structured path to get there is another. I recently hit a major milestone in my journey: completing Stage 2 of the Google Cloud Get Certified program.

By earning five specific skill badges, I’ve officially unlocked my free exam voucher. These weren’t just theoretical modules—they were intense, hands-on labs that forced me to build, secure, and automate real-world cloud environments. Here is how I structured my learning path to cross the finish line:

Build a Secure Google Cloud Network

I started with the foundation. This badge focused on the defensive side of cloud architecture. I configured VPC firewalls, set up private access, and ensured that the network followed the “least privilege” principle to protect data from the ground up.

Set Up an App Dev Environment on Google Cloud

Once the network was secure, I moved to the application layer. This badge covered the essential tools for a developer’s workflow, including setting up development clusters and managing the full lifecycle of an app within the Google Cloud ecosystem.

Implement Load Balancing on Compute Engine

With the environment ready, I had to ensure it could handle traffic. I practiced configuring various Google Cloud load balancers (HTTP(S) and TCP/UDP) to distribute traffic across Compute Engine instances, ensuring high availability and performance.

Build Infrastructure with Terraform on Google Cloud

After mastering the manual setups, I moved to Infrastructure as Code (IaC). This badge acted as the bridge, taking the networking and compute skills I’d learned and teaching me how to provision them automatically using Terraform configuration files for repeatable, version-controlled deployments.

Create Your First Gemini Enterprise Application

Finally, I explored the future of the cloud: Generative AI. This badge involved integrating Google’s Gemini large language models into enterprise-level applications, showing how AI can be layered on top of a robust infrastructure.

The Road Ahead

These labs provided the practical “muscle memory” needed for the real world. Now that the voucher is unlocked, the final step toward official certification can be taken!

Are you working on GCP networking or security right now? I’d love to compare notes or hear about your approach!

The post My Journey to the Google Cloud Voucher: From Fundamentals to Generative AI appeared first on Behind the Build.

Sakura Migration

Jonathan Wong — Sun, 26 Apr 2026 05:03:15 +0000

Not long ago I visited UBC, where the Sakura blossoms were in full bloom again.

It reminded me of the first time I saw them decades ago in Japan, when I was working inside a 200‑person IT department. That was the on‑prem era. Everything lived in racks and server rooms. Everything felt stable, predictable, and physical. I thought my career would stay that way.

But life moves. Sometimes quietly. Sometimes without a plan.

Later I met Notey, and that was the beginning of my startup journey. I moved from enterprise structure to startup speed. From on‑prem systems to the cloud. From a single role to wearing multiple hats. That was my first migration, not geographical but mental. A shift in how I saw technology, teams, and myself.

I moved to Boxful next. Built an MVP that helped secure funding. Shifted from development to product. From proprietary stacks to open source. From execution to ownership. Another migration. Another environment. Another version of myself.

After that chapter, I joined venture builders, Flatiron, helping capital create new startups. Moving from building one company to helping many. From operator to enabler. From solving problems to designing systems that solve problems. Another migration.

Eventually, the Startup Visa program brought me to Vancouver. From East Asia to North America. From familiar ground to a new ecosystem. From the world I grew up into the world I chose. A migration across continents, but also across identity.

Walking past the students on UBC’s campus takes me back to when I was an undergraduate, excited about my first Yahoo email. At the time, I believed I would be happy coding every day. But the world kept shifting. We moved from desktop to cloud, then to mobile, and now to AI, where skills can be downloaded and coding itself is being redefined. Another migration. Another environment. Another identity.

Looking back, none of these migrations were planned. They happened one step at a time. Each one pulled me into a new environment and forced me to grow in ways I never anticipated.

There were migrations in scale. Migrations in technology. Migrations in geography. Migrations in identity.

Those who pause beneath the Sakura on UBC’s Memorial Road often say the trees were brought from Japan and replanted here. They blossom every year in a way you cannot find anywhere else. They did not choose the journey, yet they grew. And they became something unique because of the journey, not in spite of it.

Are you someone shaped by migrations.

What has been your latest migration.

The post Sakura Migration appeared first on Behind the Build.

The Modernization Journey: How to Take a Legacy System From Zero Trust to AI Ready Without Rewrites or Downtime and Big Costs

Jonathan Wong — Fri, 24 Apr 2026 22:58:21 +0000

Modernization is often misunderstood. Many organizations believe it requires rewriting their legacy systems, replacing entire architectures, or enduring long periods of downtime. In reality, modernization is a sequence. It begins with security, continues with infrastructure uplift, and ends with AI powered capabilities that operate safely around the legacy core.

This journey illustrates how we helped a client transform a fragile legacy PHP system into a secure, compliant, AI ready platform without rewriting the application and without interrupting production. The journey is documented across a series of articles that cover the business perspective, the technical deep dives, and the AI implementation. This final piece brings the entire story together.

Project Background: Why Modernization Became Mandatory

The client wanted to elevate their product and expand into new regulated markets. To do that, they needed to meet compliance standards such as SOC 2 and PCI DSS. These frameworks require strict identity controls, auditability, and a security posture that legacy systems rarely provide. Compliance was not a technical preference. It was a business requirement for entering new industries.

At the same time, the client wanted to introduce AI powered features into their product. They envisioned multilingual document understanding, intelligent automation, and natural language interfaces. But AI cannot be safely added to a system that lacks identity boundaries, secure data flows, or modern compute layers. Without the right foundation, AI becomes a risk multiplier.

This created a clear sequence. Secure the current system. Achieve compliance readiness. Modernize the environment. Prepare the architecture for AI. Then introduce AI features safely. This is why the project began with Zero Trust rather than AI.

The Business Case

The business perspective behind this transformation is detailed in the article:

How I Delivered Zero Trust Security for a Client’s Legacy PHP System Without Rewrites, Downtime, or Big Costs

The core challenge was simple. The legacy system was too critical to rewrite and too fragile to modify. It supported daily operations and revenue generating workflows. A rewrite would introduce risk, cost, and uncertainty. A multi-year migration could easily fail. Even a successful rewrite could disrupt the business.

The constraints were clear:

No application revamp
No downtime
Free or low‑cost solutions only
Compliance‑aligned security improvements
Immediate business value

The smarter approach was to modernize around the legacy system. Strengthen the environment. Improve the security posture. Introduce modern cloud capabilities. Build new features outside the legacy core. This approach delivered value quickly and reduced risk. It also created a path where AI could be added safely and incrementally.

The Zero Trust Foundation

The Zero Trust foundation became the anchor of the entire transformation. It provided the identity first model required for SOC 2 and PCI DSS. It removed public exposure. It enforced access boundaries. It created a secure perimeter around the legacy system without modifying the application code.

The technical implementation is documented in two deep dive articles:

The foundation included VPC only networking, IAM based access to RDS, S3, and CloudWatch, passwordless authentication, and a hardened runtime. Every component was isolated. Every request was authenticated. Every action was logged. The system became secure by design.

This foundation made compliance achievable and created the conditions required for safe modernization.

The Modernization Path

Once the security perimeter was in place, we modernized the environment around the legacy system:

The application code remained untouched. Instead, we uplifted the infrastructure into modern cloud primitives.
Introduced observability, identity enforcement, and automation.
Replaced brittle components with managed services.
Created a modernization perimeter that isolated risk and allowed new capabilities to be added without affecting production.

This approach delivered immediate improvements. The system became more stable. Operations became more predictable. Compliance became measurable. And the environment became ready for the next stage.

The AI Ready Architecture

AI readiness is not about adding a model. It is about preparing the system to support AI safely. That requires an architecture that is event driven, API first, identity enforced, and capable of handling structured and unstructured data.

However there was a major constraint: the client’s primary business entity is registered in an unsupported region for these advanced AI models. The only viable path was to leverage their overseas entity to create a new AWS account in a supported region and integrate it with their existing environment.

The constraints were non‑negotiable:

multilingual inference
multi‑modal document processing
cross‑account AWS integration
cross‑region invocation
access to advanced LLMs such as Claude
strong security controls for sensitive customer data

We introduced two‑sided trust‑granting model and network isolation to secure APIs and data pipelines that could feed Bedrock or other models. We ensured that every AI workflow operated within the Zero Trust perimeter. The result was an architecture that could support AI features without exposing the legacy system to new risks.

Lambda and Bedrock Integration

The AI execution layer is documented in the article:

How I Delivered a Cross Account Cross Region Multilingual Multi Modal AWS Bedrock Solution in a Zero Trust Environment

Lambda act as a region proxy. Bedrock provided secure enterprise grade AI capabilities. Together, they enabled new features without touching the legacy code.

We implemented multilingual understanding, multimodal document analysis, workflow automation, and intelligent assistants. The legacy system remained stable. The AI layer delivered new value. The business moved forward without risk.

The detailed implementation of the AI pipeline is documented:

Building a Multilingual Multi Modal Document Analysis Pipeline with AWS Lambda and Claude Sonnet 4.6

This article explains how the multilingual and multimodal capabilities were orchestrated using Lambda, Bedrock, and secure data flows inside the Zero Trust perimeter.

Outcomes and Lessons Learned

The transformation delivered measurable results.

The client achieved a compliance ready security posture
The system became more stable and more observable
The legacy system remained untouched
No rewrite, no downtime, no big costs
The business expanded into new regulated markets
The product gained new AI capabilities
The entire journey followed a repeatable sequence that can be applied to any legacy environment.

The core lesson is simple. Modernization is not a single project. It is a sequence.

Secure first
Modernize the environment
Prepare the architecture
Add AI safely

This approach reduces risk, accelerates delivery, and creates long term value.

Modernization is not a rewrite. It is a journey. And when executed in the right order, it turns a legacy system into an AI ready platform without disruption.

The post The Modernization Journey: How to Take a Legacy System From Zero Trust to AI Ready Without Rewrites or Downtime and Big Costs appeared first on Behind the Build.

Building a Multilingual, Multi‑Modal Document Analysis Pipeline with AWS Lambda and Claude Sonnet 4.6

Jonathan Wong — Wed, 22 Apr 2026 20:16:46 +0000

In my last article How I Delivered a Cross‑Account, Cross‑Region, Multilingual, Multi‑Modal AWS Bedrock Solution in a Zero Trust Environment, I walked through the architecture that makes secure, multilingual, multi‑modal AI processing possible across AWS accounts and regions. That foundation solved the infrastructure challenge, but it left one critical question unanswered: how does the system actually understand real documents?

This article picks up exactly where the last one ended. Now that the pipeline is built, it’s time to open the black box and examine the Lambda Python function that turns raw files into structured, multilingual insights. This is where OCR, model selection, prompt engineering, and Claude Sonnet 4.6 all come together to form the intelligence layer of the entire solution.

Selecting the Right LLM Model

The core requirement was clear: the model must handle multilingual content (English + Chinese) and multi‑modal inputs including text files, PDFs, and images. Several AWS‑native and third‑party models were evaluated.

Evaluation Results

AWS Textract + Titan performs OCR well for English, but Titan consistently ignored Chinese content, making it unsuitable for bilingual documents.
Amazon Nova attempted to interpret Chinese text but produced random guesses with a very low success rate.
Qwen3 handled Chinese better, with an acceptable success rate for mixed‑language documents.
Claude Sonnet 4.6 delivered 5× higher accuracy than Qwen3 while also offering lower total cost. It consistently extracted structured fields correctly across English‑only, Chinese‑only, and mixed‑language documents.

Final Decision
Claude Sonnet 4.6 was selected due to its superior multilingual reasoning, stable multi‑modal performance, and cost efficiency.

Activating Claude Sonnet 4.6 in AWS Bedrock
Before the Lambda function can invoke Claude, the model must be activated in the AWS account.

Step 1: Submit the Use Case
Submit the required use case form in the Bedrock console. Approval typically takes 15–30 minutes.

Step 2: Test in the Model Playground
Run a first inference in the Claude Sonnet 4.6 playground to confirm access.

Step 3: Resolve Marketplace Permission Errors
Some accounts encounter the following error during the first invocation:

“Model access is denied due to IAM user or service role not authorized to perform the required AWS Marketplace actions (aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe)...”

To resolve this, attach the following IAM policy to the IAM user or role:

{
  "Effect": "Allow",
  "Action": [
    "aws-marketplace:Subscribe",
    "aws-marketplace:ViewSubscriptions"
  ],
  "Resource": "*"
}

After applying the policy, retry the model activation. Once the subscription completes, the Lambda function can invoke Claude normally.

Lambda Function Architecture
The Lambda function is the operational heart of the pipeline. It performs ingestion, OCR, reasoning, and structured extraction.

Handler
The handler contains the main execution logic:

Receive request payload from the EC2 caller
Download the uploaded file from the S3 bucket
Perform OCR text extraction
Invoke Claude Sonnet 4.6 for reasoning and field extraction
Clean and normalize the output
Return the structured JSON result back to the EC2 instance

Claude handles PDFs and images differently during OCR and target‑field extraction, so the Lambda logic must normalize and clean the model’s output to ensure consistent, structured results:

# s3_doc_in_bytes , the s3 document as bytes format  
# content_type , the content type matched by s3 document extension  

# covert the bytes to Claude supported base64 type  
doc_base64 = base64.standard_b64encode(s3_doc_in_bytes).decode("utf-8")

# Build the content block based on document type
if content_type == "application/pdf":
    doc_config = {
    "type": "document",
    "source": {
        "type": "base64",
        "media_type": content_type,
        "data": doc_base64,
    },
    }
else:
    doc_config = {
    "type": "image",
    "source": {
        "type": "base64",
        "media_type": content_type,
        "data": doc_base64,
    },
    }

request_body = {
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 4096,
    "temperature": 0,  # no creative answer  
    "system": OCR_PROMPT,
    "messages": [
    {
        "role": "user",
        "content": [
            doc_config,
            {"type": "text", "text": TARGET_FIELD_PROMPT},
        ],
    },
    ],
}

response = bedrock_client.invoke_model(
    modelId=BEDROCK_MODEL_ID,
    contentType="application/json",
    accept="application/json",
    body=json.dumps(request_body),
)

response_body = json.loads(response["body"].read())
assistant_text = response_body["content"][0]["text"]

# remove any markdown code fences from Claude answer, if present
cleaned = assistant_text.strip()
if cleaned.startswith("

```"):
    cleaned = cleaned.split("\n", 1)[1]
if cleaned.endswith("```

"):
    cleaned = cleaned.rsplit("

```

", 1)[0]
cleaned = cleaned.strip()

# other logic

Prompts
Two categories of prompts guide the LLM’s behavior.

OCR Prompt Defines the system role, extraction rules, and reasoning instructions. It explains how the LLM should interpret different document scenarios.
Target Field Prompt Defines how to handle different file types (PDF, image, text). Provides a list of target fields with descriptions and common pattern multilingual examples, like: | total_deposit | Total deposit collected in HKD (numeric) — include ALL deposits: deposit (按金), electricity deposit (電費按金), renovation deposit, etc. Use the grand total from the receipt/table if available. |. Specifies strict output format rules such as:
- no markdown
- no explanation
- return only a JSON object

These prompts ensure deterministic, repeatable extraction across diverse document types.

Deploying the Lambda Function
Deployment is straightforward but requires attention to packaging:

Zip only the Python files, not the parent folder.
The zip file must contain the .py files at the root level.
Use the Upload ZIP button in the Lambda console.

Configuring the Handler
In the Lambda configuration tab, set the handler to match your file and function name. For example:

document_handler.handler

Where:

document_handler.py is the file
handler is the function inside that file

Closing Thoughts

This architecture demonstrates how to build a multilingual, multi‑modal document analysis pipeline using AWS Lambda and Claude Sonnet 4.6. The key is not just choosing the right model, but designing the prompts, IAM permissions, and Lambda workflow so the system behaves predictably under real production workloads.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn

The post Building a Multilingual, Multi‑Modal Document Analysis Pipeline with AWS Lambda and Claude Sonnet 4.6 appeared first on Behind the Build.

Inside TECHSPO Vancouver 2026 at Paradox Vancouver — Innovation, Community, and Real Conversations

Jonathan Wong — Tue, 21 Apr 2026 01:00:30 +0000

This year’s TECHSPO Vancouver 2026, hosted at the Paradox Vancouver, brought together innovators, founders, engineers, and creators across the tech spectrum, with the venue’s modern, design‑driven environment providing the perfect backdrop for two days of meaningful conversations and emerging‑tech exploration.

TECHSPO showcased a diverse range of companies across iCRM , MarTech , AI , SaaS , and even mental‑health technology , creating an experience built for hands‑on demos, high‑value networking, and discovering the next wave of digital innovation.

The hotel’s atmosphere, shaped by modern architecture, clean lines, and a calm yet energetic vibe, created a perfect setting for focused conversations and networking.

Meaningful Connections Throughout the Event

Reconnected with my friend Maksym , a hardware professional I first met at the Vancouver Careerin Coffee Meetup. He’s one of the rare engineers who can move seamlessly from low‑level parts and protocol discussions to market intelligence. His insights always sharpen my thinking.
Met Layth , a cybersecurity professional with real‑world threat experience. Our conversation covered:
- A real supply‑chain attack case
- How fake network infrastructures deceive internal teams
- The rising importance of AI model protection.
Connected with startup founders , including Anil , who is building an AI‑agent service. It’s energizing to see founders experimenting with automation, agentic workflows, and new business models.
Met new workforce talent , like Betty , an Intermediate Software Engineer open to work and passionate about accessibility‑first design. Her enthusiasm for inclusive product development was refreshing and aligned with where modern product expectations are heading.

Vancouver’s tech ecosystem is clearly accelerating, with momentum spanning AI agents, cybersecurity, and mental‑health technology, and what stood out most throughout TECHSPO was the depth of talent across the community, from experienced founders to early‑career engineers, all building with purpose and pushing the region’s innovation forward.

If you attended TECHSPO Vancouver as well, I’d love to hear what conversations or trends stood out to you.

The post Inside TECHSPO Vancouver 2026 at Paradox Vancouver — Innovation, Community, and Real Conversations appeared first on Behind the Build.

How I Delivered a Cross‑Account, Cross‑Region, Multilingual, Multi‑Modal AWS Bedrock Solution in a Zero Trust Environment

Jonathan Wong — Mon, 20 Apr 2026 05:47:25 +0000

After I modernized my client’s platform security, the next strategic move was clear: elevate their product with generative AI. They wanted an LLM‑powered component capable of analyzing customer‑submitted documents during application intake and performing price forecasting. The goal was to dramatically improve user experience by streamlining the workflow, offering proactive suggestions, and providing real‑time assistance.

To deliver this, the AI analyst feature needed multilingual support , multi‑modal document understanding (images, PDFs, text files, and more), and advanced reasoning , which pointed directly to models like Claude. But there was a major constraint: the client’s primary business entity is registered in an unsupported region for these advanced AI models. The only viable path was to leverage their overseas entity to create a new AWS account in a supported region and integrate it with their existing environment.

The constraints were non‑negotiable:

multilingual inference
multi‑modal document processing
cross‑account AWS integration
cross‑region invocation
access to advanced LLMs such as Claude
strong security controls for sensitive customer data

It reads like an AWS Solution Architect Professional exam scenario? It wasn’t a hypothetical. This was a real‑world architecture challenge with real compliance, security, and business constraints.

To achieve the goal, I designed a two‑sided trust‑granting model between the two AWS environments. AWS Account A (AC‑a) operates in Region A, and AWS Account B (AC‑b) operates in Region B.

Why Lambda in AC‑b Is Mandatory

Claude enforces region restrictions based on the source IP. This means:

all traffic to Claude must originate from Region B , and
any request coming directly from Region A will be blocked , regardless of AWS account ownership.

Because of this, the Lambda function in AC‑b becomes a non‑negotiable region proxy. It is the only component allowed to make outbound requests to Claude, ensuring that Anthropic sees a valid Region‑B AWS IP.

In other words: AC‑a (data + app) → AC‑b (Lambda proxy + Claude) is the only viable architecture that satisfies both the business requirements and the regional restrictions.

Resources and IAM Roles

In AC‑a, an EC2 instance acts as the caller of the AI service hosted in AC‑b. The EC2 instance assumes the IAM role ec2‑production , which must be explicitly granted permission to invoke the Lambda function in AC‑b.

{
    "Effect": "Allow",
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:region-b:ac-b-id:function:lambda-name"
}

At the same time, the Lambda function in AC‑b must enforce the reverse trust boundary: it should only accept invocations originating from AC‑a’s ec2‑production role. It uses resource-based policy:

Statement ID : AllowCrossAccountPHPInvoke
Principal : arn:aws:iam::ac-a-id:user/ec2-production  
Effect : Allow
Action : lambda:InvokeFunction

At the Lambda IAM role level, it must be explicitly granted permission to access Amazon Bedrock and invoke Claude. This role becomes the trusted execution identity for all outbound LLM requests from AC‑b, ensuring that only the Lambda function running in the supported region is authorized to call the model:

{
    "Sid": "AllowBedrockInvoke",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
    "arn:aws:bedrock:*:ac-b-id:inference-profile/your-claude-model",
    "arn:aws:bedrock:*::foundation-model/your-claude-model"
    ]
}

Set the region to “*” in the IAM policy, since Bedrock may internally route the invocation across multiple supported regions. This ensures the Lambda role can invoke the service regardless of the specific regional endpoint used.

This ensures mutual, least‑privilege trust across accounts and regions.

Cross‑Account Data Access

Because the system exchanges customer‑sensitive data across multiple AWS accounts and regions , the communication path must meet strict security guarantees. The design enforces three core requirements:

No traffic may traverse the public internet
Data can only originate from controlled, authenticated AWS resources
Data can only be delivered to controlled, authenticated AWS resources

The PrivateLink endpoint is protected by a dedicated security group that permits inbound HTTPS traffic only from the ec2-production instance. This ensures that no other resource, inside or outside the VPC, can reach the endpoint at the network layer.

In addition, the PrivateLink service is bound to a resource policy that explicitly authorizes only the ec2-production IAM role to invoke the controlled Lambda function. Even if another resource could reach the endpoint, the policy prevents it from calling the Lambda:

{
    "Sid": "RestrictToLambda",
    "Principal": {
    "AWS": "arn:aws:iam::ac-a-id:user/ec2-production"
    },
    "Action": "lambda:InvokeFunction",
    "Effect": "Allow",
    "Resource": "arn:aws:lambda:aws-region-b:ac-b-id:function:lambda-name"
}

Together, the security group and the endpoint policy enforce strict, dual‑layer Zero Trust: network access is restricted to a single controlled source, and service‑level access is restricted to a single controlled identity.

The Lambda function is responsible for analyzing the customer’s document as part of the AI prediction workflow. However, due to regulatory requirements, all customer data must remain stored in AC‑a’s private S3 bucket. However, AC‑b still needs controlled access to this data for analysis. Therefore, the S3 bucket policy in AC‑a must selectively grant AC‑b permission to read only the required objects, while maintaining strict Zero Trust boundaries. This is the authoritative gatekeeper :

{
    "Sid": "AllowACBReadSpecificObjects",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::ac-b-id:role/lambda-role"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket/path/to/allowed/*"
}

This ensures AC‑b cannot read anything outside the approved prefix.

In the AC-b, the lambda iam role attaches a policy to ensure that only attempt to access the specific S3 objects it is supposed to. This is the identity‑side limiter :

{
    "Sid": "AllowReadOnlySpecificObjects",
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket/path/to/allowed/*"
}

This is the same dual‑layer pattern AWS recommends for cross‑account S3 access with Zero Trust.

After the Claude model is activated and the required use‑case approvals are completed, the EC2 instance in AC‑a can securely invoke the AWS Bedrock service.

Bringing It All Together

This project was not only about adding generative AI to an existing platform, but also delivering advanced LLM capabilities under strict regional, security, and compliance constraints. By designing a cross‑account, cross‑region architecture with a mandatory Lambda proxy, enforcing mutual least‑privilege trust, and routing all sensitive data through PrivateLink, the solution enables multilingual, multi‑modal AI analysis without ever exposing customer information to the public internet.

The result is a fully compliant, Zero‑Trust, enterprise‑grade AI integration that unlocks Claude’s capabilities for a business operating in an otherwise unsupported region—transforming their application workflow while preserving the highest security standards.

The post How I Delivered a Cross‑Account, Cross‑Region, Multilingual, Multi‑Modal AWS Bedrock Solution in a Zero Trust Environment appeared first on Behind the Build.