Chapter 1.8 Capstone Project

Why This Chapter Matters

A capstone is not a test of whether you can follow instructions. It is a test of whether you can apply a complete architecture to a new client scenario making design decisions without explicit guidance, justifying your choices, and producing a system that would function in a real deployment. The Thornfield Legal Group scenario introduces constraints that the Part I practice workflows did not have: a different business domain, a different intake channel, different routing requirements, and a client with specific operational expectations. The engineering patterns are the same. The application is your own.

The system you build here is also the first entry in a professional portfolio: an AI advisory workflow deployed against a real business brief, with documented design decisions and a structured validation record. That is not an academic exercise. It is the form clients evaluate when scoping an engagement, the artifact employers examine when assessing capability, and the deliverable you reference when estimating the next project. The architectural rigor of Part I the advisory pattern, the reliability model, the audit trail exists so that what you produce here is defensible.

Real-World Scenario

Thornfield Legal Group is a mid-size law firm that receives 30 to 50 new matter inquiries per week. Currently, a receptionist reads every inquiry, attempts to classify the legal matter type, and routes it to the appropriate practice group. The process takes one to three business days, during which urgent inquiries wait in the same queue as low-priority ones. The firm’s managing partner wants a system that classifies incoming inquiries by matter type, assesses urgency, and routes high-priority matters within two hours without replacing the human review step for matters above a defined complexity threshold.

Learning Objectives

After completing this capstone, you will be able to:

  • Apply the complete Part I architecture to a legal services intake domain, adapting the advisory pattern, prompt engineering, and reliability model to a previously unseen client context.
  • Design a matter-type classification system with AI-assisted urgency scoring that routes high-priority inquiries within a defined SLA without replacing mandatory human review for complex matters.
  • Build and document four ADR-style design decisions justifying your architectural choices for the Thornfield system.
  • Evaluate your system against the capstone rubric, identifying the specific workflow nodes and configuration choices that satisfy each assessment criterion.
  • Demonstrate professional readiness for Part II by producing a system that a client team could operate, a brief that explains every design decision, and a handoff document for ongoing maintenance.

Builds On

  • Chapters 1.0 through 1.7 (complete Part I architecture)

Prepares For

  • Part II CRM & Revenue Systems Engineering

1.8.1 Before You Begin

This capstone tests independent architectural and implementation skill. You receive a client brief, design the advisory workflow from that brief alone, document your decisions, and validate your work with a structured test suite. There are no guided steps, no reference walkthroughs, and no checkpoints you are building as a practitioner would. The professional engagement simulation discovery calls, client approval gates, and a formal handover package is the scope of the Part II Capstone. This capstone prepares you for that experience by establishing independent implementation confidence first.

Prerequisites. Complete Chapters 1.0–1.7 before beginning. Chapter 1.5 is required before attempting Category 5 of the evaluation rubric. If Chapter 1.5 is not yet available, complete Categories 1–4 and 6 first and return to Category 5 when Chapter 1.5 is published Category 5 will be held open and scored separately.

Time. Plan for 10–18 hours depending on your domain familiarity and the number of prompt calibration iterations your design requires.

Prompt calibration testing your system prompt against six different scenario types, adjusting evaluation dimensions and scale anchors, and re-validating Parse Response extraction after each schema revision commonly takes longer than the initial workflow build. Budget a separate uninterrupted session for it.

1.8.2 The Engagement

Thornfield Legal Group is a twelve-attorney firm specializing in commercial litigation, employment law, business formation, and real estate transactions. The firm receives 80–120 new matter inquiries per week through a public intake form. Every inquiry currently reaches a partner inbox unfiltered.

Partners spend approximately four hours per week triaging inquiries that are outside the firm’s practice areas, insufficiently described to route, or urgently time-sensitive but treated as standard queue. Thornfield has retained you to build an AI-assisted intake advisory system that classifies and routes each inquiry to one of four designated handling paths before any partner review occurs.

The routing system you will build.

Path Trigger condition Notification target Response expectation
immediate_review Time-sensitive matter with strong suitability indicators #partner-review 60 minutes
standard_queue Standard matter, clear scope, no urgency flags #intake-queue 4 business hours
complexity_hold Scope unclear or matter involves unusual complexity #intake-ops Follow-up call scheduled
out_of_scope Matter type outside Thornfield’s practice areas #intake-ops Manual decline handling

Out-of-scope matters receive no automated reply to the submitter decline communication is handled manually by the intake team.

Intake form fields. Contact name, contact email, matter type (dropdown: commercial litigation, employment dispute, business formation, real estate transaction, estate planning, other), matter description (free text, minimum 50 words), urgency indicator (standard / time-sensitive), prior engagement with Thornfield (yes/no), preferred contact method.

Technical environment. n8n (cloud or self-hosted), OpenAI API (GPT-4o), Slack.

1.8.3 The Advisory Output Contract

Advisory Output Contract all ten fields are required on every execution path.

Your system prompt, Parse Response node, and audit log must all target a shared output contract. The contract ensures that every component of the workflow reads from the same field names with the same types. Evaluation of your work checks compliance with this contract in addition to conformance with the Thornfield brief.

Any output that omits a required field, uses an incorrect type, or assigns a value outside the defined enum fails Category 3 criterion 3.3 regardless of other scores.

Required fields.

Field Type Key constraint
suitability_pass boolean false triggers rule fallback no AI call made
out_of_scope boolean When true, advisory_path must be "out_of_scope"
ai_confidence float 0.00–1.00; extracted from AI response, not calculated
confidence_band enum "high" | "medium" | "low"
evaluation_source enum "ai" | "rule_fallback"
matter_score integer 0–20; post-cap value from Advisory Score node
advisory_path enum "immediate_review" | "standard_queue" | "complexity_hold" | "out_of_scope"
requires_manual_review boolean true when confidence below medium threshold or signals conflict
ai_rationale string 1–3 sentences in system prompt voice
prompt_version string Increment on any system prompt change (e.g., "v1.0", "v1.1")

Field Definitions Reference

suitability_pass Set to true when the inquiry clears all pre-AI suitability rules (matter description length, matter type validity, required fields present). false bypasses the AI call entirely and routes the workflow to the rule fallback path. Document your suitability rules in Deliverable 1.

out_of_scope Set to true when the matter type maps to a practice area Thornfield does not handle. Estate planning, immigration, criminal defense, family law, and intellectual property are outside Thornfield’s scope by default; your domain specification may adjust this list. When out_of_scope is true, advisory_path must be "out_of_scope". Document whether out-of-scope detection occurs at the suitability layer (before the AI call) or as an AI output classification (after the AI call) in Deliverable 6.

ai_confidence The model’s self-reported confidence in its assessment, extracted directly from the AI response. This field must not be calculated or inferred by your Parse Response node it must be captured from the structured AI output as the model reports it. Range: 0.00 to 1.00.

confidence_band Derived from ai_confidence using your calibrated threshold values. Document the exact threshold numbers in your Domain Specification Document. These thresholds directly control when requires_manual_review is set to true and when the rule fallback activates.

evaluation_source "ai" when the workflow reached the AI scoring path and produced an advisory output. "rule_fallback" when suitability failure or low AI confidence caused the workflow to bypass AI scoring. This field is required in the audit log to distinguish the two execution paths in operational monitoring.

matter_score The final advisory score, range 0–20, after applying your AI contribution cap (Math.min(cap, ai_raw_score × multiplier)). The Advisory Score node for the AI path produces this value. The Advisory Score node for the rule fallback path produces a deterministic score derived from suitability signals only. Document your cap value in Deliverable 1.

advisory_path The routing decision produced by the Advisory Output Switch node. Exactly one of four allowed values. No other routing values are permitted.

requires_manual_review Set to true when ai_confidence falls below your medium threshold, or when the AI confidence level and rule-based suitability signals materially conflict. When true, the Slack notification for the assigned routing path must include a flag text requesting human verification before the path action is taken.

ai_rationale One to three sentences from the AI explaining its assessment, written in the voice of the system prompt. This field is surfaced in the #partner-review Slack notification so partners can read the AI’s reasoning at a glance.

prompt_version A version string you define and increment on any system prompt change. Must be present in the JSON template in your system prompt and captured unchanged in the Parse Response output. The audit log uses this field to correlate advisory outputs with the prompt version that produced them.

1.8.4 Your Deliverables

Seven deliverables. Submit all seven.

Seven deliverables constitute the completed capstone. Submit all seven.

1.8.4.1 Deliverable 1: Domain Specification Document

This document records your architectural decisions before you build. Answer the seven questions below in writing. For the three decisions you consider most architecturally significant, add one paragraph beneath the answer documenting what you decided, what you considered as an alternative, and why you chose as you did.

  1. What are your four routing paths, and what conditions distinguish one from another?
  2. What suitability rules does your workflow apply before making any AI call?
  3. At what layer does your workflow detect an out-of-scope inquiry the suitability gate (before the AI call) or the AI output (after the AI call)? Why?
  4. What evaluation dimensions does your system prompt use to assess matter quality and urgency?
  5. What are your confidence_band thresholds (the numeric cutoffs between high, medium, and low), and what reasoning did you use to set them?
  6. What is your AI contribution cap, and what would the scoring model produce if the cap were removed?
  7. What fields does your audit log write, in what order, and to what destination?

1.8.4.2 Deliverable 2: System Prompt Package

Your system prompt targeting the advisory output contract in §1.8.3. The JSON template embedded in your system prompt must include all ten required fields with correct types and enum values explicitly shown. Include the prompt_version string in the template.

1.8.4.3 Deliverable 3: n8n Workflow Export

Complete .json export of the Thornfield intake workflow. Required nodes: Webhook, Suitability Gate, Build Prompt, HTTP Request (OpenAI), Parse Response, Advisory Score (AI path), Advisory Score (Rule Fallback), Advisory Output Switch (four branches), Audit Log, and four Slack notification nodes (one per advisory path). On Error connections are required on the HTTP Request node and the Parse Response node. Additional nodes are permitted.

1.8.4.4 Deliverable 4: Test Case Documentation

Six test scenarios demonstrating coverage across all workflow paths. Required coverage: all four advisory paths covered across the six scenarios, at least one scenario where ai_confidence falls below your medium threshold (triggering requires_manual_review = true), and at least one out-of-scope inquiry.

For each scenario, document:

Column Content
Scenario description Matter type, free-text excerpt, urgency flag value, prior engagement status
Expected output All ten required fields with your predicted values, completed before running the workflow
Actual output All ten required fields captured from workflow execution
Pass/Fail Per field
Variance analysis For any mismatch: identify whether the source was the AI response, the Parse Response extraction, or the Advisory Score formula

1.8.4.5 Deliverable 5: Workflow README

A one-page document for Thornfield’s intake coordinator not an engineer. Cover: what the workflow does in plain terms, what action to take when a notification arrives in #partner-review, what action to take when a notification arrives in #intake-ops, and who to contact if the workflow stops producing notifications.

1.8.4.6 Deliverable 6: Architecture Decision Record

Write one ADR documenting the most architecturally significant decision you made during this build. An ADR is a short, structured document that makes your design reasoning visible to anyone who maintains or extends this system. Choose one of the three options below.

Option A out_of_scope detection placement. Did you detect out-of-scope inquiries at the suitability gate (deterministic, before any AI call, based on the matter type dropdown) or as an AI classification in the advisory output (probabilistic, after the AI call, allowing the AI to assess ambiguous matter types)? Document the trade-off: reliability and token cost versus nuance and recall.

Option B Confidence threshold calibration. Why are your high and medium thresholds set at the specific values you chose? What does Thornfield’s operational risk profile imply about where those thresholds should sit is a false positive (routing a complex matter to standard_queue instead of complexity_hold) more costly than a false negative? Document the reasoning and the consequence of setting each threshold ten percentage points higher or lower.

Option C AI contribution cap. Why is your cap value set where it is? What does the scoring model produce if the cap is removed? What does a lower cap constrain in terms of AI influence over routing decisions and what does that constraint protect against?

ADR Format Template

Use the following structure for your ADR. Length: 200–350 words.

Title: A short, descriptive title for the decision (e.g., “Out-of-Scope Detection at Suitability Layer”)

Status: Decided

Context: What situation required this decision? What constraints or trade-offs were present? What was the consequence of getting the decision wrong?

Decision: What did you choose? State it directly.

Alternatives Considered: What else was evaluated, and why was each alternative not chosen? Name the alternative and give the reason for rejection.

Consequences: What does this decision enable? What does it constrain or foreclose? What would a future engineer need to know before changing it?

Review Condition: Under what changed circumstances should this decision be revisited? Name a specific trigger condition.

1.8.4.7 Deliverable 7: Problem-Solution Narrative

A 200–300 word portfolio narrative in client language. Audience: a prospective client reading your work samples, not an engineer. Structure:

Problem (60–90 words). What operational challenge did Thornfield face? What was the cost of that challenge? Use specific numbers from the brief.

Solution (90–120 words). What did you build? What does it do? Write as if explaining to a managing partner who has never heard of n8n or the OpenAI API. No technical acronyms.

Outcome (40–60 words). What can Thornfield now do that it could not do before? Frame the answer in time recovered, routing consistency, or partner workload not system architecture.

Thornfield Legal Group is a simulation scenario designed for portfolio use. Write as if Thornfield authorized you to include this engagement in your professional portfolio.

1.8.5 Evaluation

Passing threshold: 75 of 100 points, with three category sub-thresholds.

Your capstone is evaluated across six categories. The passing threshold is 75 of 100 points.

Category 1 Suitability and Domain Specification: 17 points

Criterion Points
1.1 Four routing paths are defined, mutually exclusive, and consistently referenced across Deliverables 1–3 4
1.2 Suitability rules are specific, testable, and apply before any AI call 4
1.3 Out-of-scope detection is placed at a defined architectural layer with documented justification 4
1.4 Deliverable 1 includes a written justification paragraph for the three most consequential decisions 3
1.5 ADR (Deliverable 6) uses the required seven-field format; decision is one of the three defined options 2

Category 2 System Prompt Engineering: 20 points

Criterion Points
2.1 System prompt targets the canonical advisory output contract; JSON template includes all ten required fields with correct types and enum values 6
2.2 Evaluation dimensions correspond specifically to the Thornfield brief, not generic matter intake dimensions 5
2.3 Instructions produce consistent output structure across the six test scenarios 5
2.4 prompt_version string is present in the JSON template and in the audit log output 4

Category 3 AI Service Layer Reliability: 20 points

Criterion Points
3.1 HTTP Request node targets the correct model and endpoint with timeout and retry configuration 4
3.2 Parse Response node extracts all ten required fields with correct type coercions 5
3.3 All ten extracted fields are within their defined types and enum ranges across all six test scenarios 5
3.4 On Error connections are present on the HTTP Request node and the Parse Response node 3
3.5 Rule fallback path activates correctly when suitability fails or ai_confidence falls below the medium threshold 3

Category 4 Advisory Architecture: 20 points

Criterion Points
4.1 Advisory Score (AI path) correctly applies the AI contribution cap documented in Deliverable 1 5
4.2 confidence_band is derived from ai_confidence using the documented threshold values 4
4.3 Advisory Output Switch routes correctly to all four paths based on advisory_path 5
4.4 Each of the four Slack notifications contains the required fields; when requires_manual_review = true, the notification includes the manual review flag 6

Category 5 Governance and Audit: 15 points

Criterion Points
5.1 requires_manual_review is set to true under the correct conditions: ai_confidence below the medium threshold, or AI and rule-based signals materially in conflict 4
5.2 Audit log writes all ten required output contract fields plus timestamp, contact_email, and prompt_version 5
5.3 Audit log field names use snake_case with no spaces or ambiguous abbreviations, suitable for direct mapping to Part II HubSpot Contact property internal names 3
5.4 Rule fallback activations are distinguishable from AI-path activations in the audit log (evaluation_source correctly set to "rule_fallback") 3

Category 6 Test Coverage and Documentation: 8 points

Criterion Points
6.1 All six scenarios are documented with complete expected and actual output for all ten required fields 3
6.2 Required coverage is met: all four advisory paths represented, at least one requires_manual_review = true scenario, at least one out-of-scope scenario 2
6.3 Variance analysis is present for any field mismatch; source is correctly identified (AI response, Parse Response extraction, or Advisory Score formula) 2
6.4 Problem-Solution Narrative (Deliverable 7) uses client language throughout, references specific numbers from the brief, and stays within the 200–300 word limit 1
ImportantCritical Requirement

Part II Readiness Gates

To be cleared for Part II, you must meet the overall passing threshold and all three sub-thresholds below. A passing total score with any sub-threshold unmet requires remediation of the failing category before Part II enrollment.

Category Sub-threshold Why this gate exists
Category 3 AI Service Layer ≥ 15 / 20 Parse Response reliability is the foundation of Part II’s HubSpot property write architecture
Category 4 Advisory Architecture ≥ 15 / 20 The scoring formula and Switch routing extend directly into Part II Workflow A
Category 5 Governance and Audit ≥ 12 / 15 Audit log field names and requires_manual_review implementation are Part II property write prerequisites