Module 8: Capstone The Andes Cargo Genai Extractor
6. The boundary with AI Engineering, closed
Description
M1.4 fixed, in the first module's lesson 4 — deliberately early, not at the close — the exact boundary between what this guide builds and what AI Engineering already teaches: this guide operates, AI Engineering builds. Thirty-five lessons later, it's time to confirm that boundary held, without a single exception, through this guide's very last line of code. This lesson introduces no new criterion — it walks through, module by module, every point where the temptation to cross the boundary could have appeared, and confirms, with evidence from the exact lesson where it happened, that none did.
Connection to the module
Where this module's lesson 5 closed the "what stayed unexecuted" ledger, this lesson closes the complementary ledger: "what this guide deliberately decided not to teach at all." These are two different questions — one about execution scope, the other about content scope — and both need their own closing before this capstone ends.
Analogy: the operations manual, closed without a single leaked recipe
M1.4 already established the central analogy: this guide is the restaurant's operations manual, AI Engineering is the recipe book. A well-written operations manual, by the time it reaches its last page, doesn't have, in any earlier chapter, a recipe that leaked in by accident — no sauce-reduction technique, no spice ratio, nothing that belonged in the recipe book. This lesson is the final review of that promise: it walks through the complete manual, chapter by chapter, and confirms no recipe leaked into this guide's thirty-six lessons — the extract-shipment-manifest-fields prompt, in M8.4, turned out exactly as minimal as M1.4 promised it would be, not one line more elaborate.
M1.4's table, confirmed with the exact lesson where it held
| This guide DID build | Confirmed in | AI Engineering — never crossed | Confirmed in |
|---|---|---|---|
extract-shipment-manifest-fields's infrastructure | All of M3, bedrock.tf + BedrockManifestExtractorRole | The prompt that does the extraction itself | M8.4 — a three-line PROMPT_TEMPLATE, no few-shot, no reasoning chain |
| The managed guardrail, as code | M4.2-M4.3, six mechanisms, five policies | Advanced prompt engineering, application-level injection resistance | M1.4, Exercise 1 — explicitly named as a boundary, never developed |
| A custom guardrail, defense in depth | M4.5-M4.6, pre_invoke_checks.py/post_invoke_checks.py | RAG, embeddings, semantic retrieval | Never mentioned as a build item in any lesson of this guide |
| Least-privilege IAM over a specific model | M3.4, M5.3 | Agents, function calling, multi-step orchestration | Never mentioned as a build item in any lesson of this guide |
| The per-token cost model | All of M2, GENAI-COST-PROFILE.md | Semantic evaluation of a response's quality | M7.5-M7.6 — the harness compares shape, never meaning, with the line drawn in code (run_smoke_test() never reads expectedFields) |
| The extended security gate and cost gate | M5.8, M6.8 — the same jobs, none new | Application-level hallucination-reduction techniques | Never mentioned as a build item in any lesson of this guide |
| SLI/SLO for an AI workload | M7.2-M7.4, escalation rate, latency, guardrail block rate | Fine-tuning, training, or adjusting a model of your own | Never mentioned as a build item in any lesson of this guide |
| The smoke test harness, comparison structure | M7.6, manifest_extraction_smoke_test.py | The semantic quality metric that harness would compare in real production | M7.5 — named, with STRATEGY.md's exact quote, never built |
Eight rows, the same eight from M1.4 — none added or removed along the way. The right column, now with its own confirmation, is what this capstone can write that M1.4 couldn't yet: in the first module's lesson 4, that column was a promise; here, it's a verified fact, lesson by lesson.
The moment closest to the boundary: M8.4's PROMPT_TEMPLATE
It's worth taking a close look at this guide's only point where a real prompt, with real text, appeared — M8.4:
PROMPT_TEMPLATE = (
"Extract shipment fields from the manifest text below. Return a JSON "
"object with exactly these keys: shipmentId, originCountry, "
"destinationCountry, carrier, weightKg. If a field is not present in "
"the text, omit the key rather than guessing.\n\nManifest text:\n{text}"
)Four lines. No few-shot examples, no step-by-step reasoning chain, no elaborate system message with extra tone or formatting rules, no ambiguity-handling instruction beyond "omit the field instead of guessing" — a single sentence, not a strategy. M1.4 already anticipated this precisely: "extract-shipment-manifest-fields's prompt is going to be short, direct, and — on purpose — not a piece of polished prompt engineering." This is, exactly, that promise fulfilled — not a coincidence that M8.4 needed little text, but the active discipline of never adding more than the lesson's point actually required.
Compare it to what a production prompt, designed by someone actually solving AI Engineering's problem, would likely include: examples of ambiguous manifests with their correct extraction (few-shot), explicit instructions on handling mixed weight units (kg versus lb), a step-by-step reasoning instruction before producing the final JSON, disambiguation rules for carrier names with spelling variations. None of those pieces appear in PROMPT_TEMPLATE — not because this guide didn't know they exist, but because building them would be exactly the recipe the operations manual was never supposed to write.
What this guide DID have to name, without building it
Closing the boundary doesn't mean this guide entirely avoided any mention of AI Engineering territory — it means that, every time it mentioned it, it named it and moved on, without developing it. It's worth listing the exact points where that happened, because they're the most concrete proof of the discipline:
| AI Engineering concept | Where it was named | What this guide said, exactly |
|---|---|---|
| Application-level prompt injection | M1.4, Exercise 1 | "Structuring the prompt itself to resist them is the half that belongs to AI Engineering" |
| Semantic quality evaluation | M7.5 | "It's not the same as evaluating an LLM's quality" — named as the exact line M7.6 doesn't cross |
| Model families and capabilities | M1.6 | Listed (Nova, Claude, Llama, Mistral) as a catalog, never compared on reasoning quality |
| Fine-tuning | M1.4's table | Named in the right column, with no dedicated lesson in the rest of the guide |
Four mentions, four times where the guide stopped exactly at the name, without taking a further step — the same discipline M1.4, in its own closing section, described as "naming it, and moving on."
Common mistakes
Retroactively hunting for "the lesson where this guide did cross the boundary a little," assuming that across 36 lessons it must have happened at least once (statistical distrust). What happens: someone, familiar with how hard it is to hold this kind of discipline across a whole guide, actively looks for an exception. How to spot it: if your reading of this lesson is "surely something slipped through somewhere." How to fix it: this lesson's table, with its lesson-by-lesson confirmation column, is exactly the verifiable evidence for that doubt — each row points to a specific place where you can check, not a confidence claim with no evidence. If you find a lesson in this guide that does develop a prompt engineering, RAG, or semantic evaluation technique beyond naming it, that would be a real inconsistency worth flagging — but this lesson's table, and the M1.4 that originated it, hold that there isn't one.
Confusing "the prompt is short" with "the prompt was easy to write well" (underestimating the work of maintaining the discipline, not the work of writing the prompt itself). What happens: someone reads the four-line PROMPT_TEMPLATE and concludes this part of the guide "had no real work." How to spot it: if your assessment of this lesson is "writing four lines of prompt isn't a big deal." How to fix it: this guide's real work, at every point where the prompt could have grown, wasn't writing those four lines — it was resisting the temptation to add a fifth, a sixth, a seventh, every time an ambiguous manifest's example (like 4479 in M8.4, missing a weight) invited "improving" the instruction with one more rule. M1.4 already said it precisely: "the correct answer isn't to explain it better — it's to name it, and move on," and that discipline, sustained across sixty-four lessons, is the real work, not the final text's length.
Treating this lesson as a plain repeat of M1.4, with no added value (missing the difference between promise and confirmation). What happens: someone, recognizing M1.4's table nearly intact, concludes this lesson adds nothing new. How to spot it: if your summary of this lesson is "it's the same as M1.4, again." How to fix it: the exact difference is in the "Confirmed in" column — M1.4 promised a boundary before a single line of this guide's code existed; this lesson confirms it with the specific lesson where each promise was fulfilled, something M1.4, written first, couldn't do yet. Promising a discipline and confirming it held are two different acts, and the second one is, precisely, a capstone's job.
Exercises
Exercise 1 — Without looking at this lesson's table, recite from memory M1.4's eight rows (left column) with the exact module where each was built. Check your answer against this lesson's table.
See solution
Infrastructure (M3), managed guardrail (M4.2-M4.3), custom guardrail (M4.5-M4.6), least-privilege IAM (M3.4/M5.3), cost model (M2), extended gates (M5.8/M6.8), SLI/SLO (M7.2-M7.4), smoke test harness (M7.6). If you named all eight with their correct module, you have this guide's complete architecture clear, not just its boundary.
Exercise 2 — A classmate argues: "M8.4 did cross the boundary a little, because PROMPT_TEMPLATE explicitly tells the model to omit fields instead of guessing — that's already a prompt engineering technique." Evaluate this argument with precision.
See solution
The argument has a grain of truth worth recognizing precisely, not dismissing outright: any instruction inside a prompt, technically, is a prompt-engineering decision in some broad sense. But the distinction M1.4 draws isn't "zero instructions," it's "without the additional depth AI Engineering develops thoroughly" — a single ambiguity-handling sentence ("omit instead of guessing") is far from few-shot, reasoning chains, or strategies handling multiple, chained edge cases, which is the kind of depth M1.4 explicitly delegates. The correct line isn't "zero prompt engineering whatsoever" — impossible, any prompt involves some decision — it's "no lesson in this guide develops prompt engineering as its own object of study," and that claim does hold, even with that specific sentence present.
Exercise 3 — Predict what would happen to this guide if, in a future version, someone added a ninth lesson to M4 explaining how to improve PROMPT_TEMPLATE with few-shot. Exactly which principle of this lesson would break?
See solution
It would precisely break this lesson's table's "The prompt that does the extraction itself" row — that new lesson would move content from the right column (AI Engineering territory) into the left column (what this guide builds), exactly the risk M1.4 named in its own "What happens if this boundary gets crossed without noticing" section: "this guide would end up teaching a weaker version of what AI Engineering already teaches thoroughly." The guide would keep working technically, but it would stop being the definitive source for its own half of the problem — operations — and become a diluted source for two different halves, neither complete.
Summary and next step
This lesson walked through the eight rows of the boundary M1.4 fixed first, confirming, with each module's exact lesson, that none was crossed across this guide's thirty-six lessons. You took a close look at the only real prompt this guide wrote — PROMPT_TEMPLATE, four lines, no advanced technique — and the four exact times an AI Engineering concept was named without being developed. Lesson 5's ledger closed what stayed unexecuted; this lesson closes what stayed, deliberately, untaught.
Before moving on you should be able to: recite the boundary's eight rows with their exact module of construction; explain why a four-line PROMPT_TEMPLATE is a sustained discipline, not a simple task; and defend, with an example of your own, why adding a prompt-engineering lesson to M4 would break this guide's whole identity.
Lesson 7 looks forward, not backward: what Andes Cargo would need if its volume of escalated manifests grew to the point of justifying infrastructure neither this guide nor kubernetes-and-eks-in-production-guide builds — named, precisely, without pretending a $0 path exists for it.
Resources
- This same course, Module 1, lesson 4 (
04-the-boundary-with-ai-engineering-said-out-loud.md) — the complete source of the eight-row table and the three exactSTRATEGY.mdquotes this lesson confirms. src/paths/aws-cloud-ecosystem/STRATEGY.md— the original source of this guide's position in the NIEVA ecosystem graph.- This same course, Module 8, lesson 4 (
04-end-to-end-walkthrough-the-ai-escalation-path-mixed-and-declared.md) — the origin ofPROMPT_TEMPLATE, examined in detail in this lesson. - This same course, Module 7, lessons 5 and 6 — the boundary applied specifically to quality evaluation, the second time this guide traces it in detail.