Chapter 3.8 Production AI Systems and Synthesis

Learning Objectives

After completing this chapter, you will be able to:

Describe the complete Part III five-layer architecture (Data Pipeline, Multi-Agent Assessment, Event-Driven Triggers, Observability, Governance) and explain how each layer depends on the others.
Apply the complexity threshold table to evaluate whether a given client scenario warrants multi-agent architecture, event-driven triggers, or the full Part III stack versus a simpler Part II implementation.
Articulate three architectural trade-offs made in the Part III design (ADR-6A, ADR-6B, ADR-6C) in Mini-ADR format, with rationale that a non-engineering stakeholder can evaluate.
Produce a capstone readiness self-assessment using the 20-item checklist, identifying any capability gaps that require review before beginning the Meridian capstone.
Explain what it means to maintain the Part III architecture over time: what the most likely sources of drift are, how the observability and testing layers detect them, and what the correct operational response is for each.

3.8.1 The Complete Part III Architecture

The Five-Layer Architecture

The Part III architecture has five interconnected layers. Each layer was introduced in a specific chapter; none of them stands alone.

Layer 1 Event Trigger Layer (Chapter 3.4)

Incoming submissions trigger Workflow A through HubSpot webhook events. The polling safety net (daily schedule trigger) catches any events not delivered via webhook. Events carry the full HubSpot property change payload including the objectId (contact ID) and propertyValue.

Layer 2 AI Pipeline Layer (Chapters 3.1–6.3)

Five stages: Ingest → Normalize → Enrich → Assess → Route + Store. The Assess stage implements the two-agent sequential pattern (Agent A: Engagement Type Classifier; Agent B: Advisory Assessor). Each stage has a defined schema contract at its input and output boundary. The Enrich stage adds multi-context peer data (Chapter 3.1) and firmographic signals (Chapter 3.2).

Layer 3 Observability Layer (Chapter 3.5)

The five p6_ properties written in Route + Store at the end of every execution are the instrumentation layer. The weekly observability workflow aggregates them into five health metrics and posts a Slack health report. Alert conditions trigger escalation outside the weekly cycle.

Layer 4 Governance Layer (Chapter 3.6)

The four extended governance fields (override_expires_at, override_reason_code, override_authorized_by, override_policy_version) combined with manual_override_active define the contact’s governance state at execution time. Workflow B’s Check Expiry node enforces expiry on every execution. Governance Notes maintain the time-series audit trail.

Layer 5 Testing Layer (Chapter 3.7)

The 10-fixture baseline set with contract validation and behavioral testing. The regression suite workflow runs before any prompt version deployment. The human review loop samples real executions weekly. Together these layers provide assurance that architecture changes do not silently degrade advisory quality.

Layer	Chapter	Key artifact	Operational cadence
Event Trigger	6.4	Webhook + polling hybrid	Per-submission
AI Pipeline	6.1–6.3	Five-stage pipeline, two-agent Assess	Per-submission
Observability	6.5	`p6_` properties + weekly workflow	Weekly
Governance	6.6	Four governance fields + Check Expiry	Per-submission
Testing	6.7	10-fixture set + regression workflow	Per prompt version change

3.8.2 When NOT to Add Complexity

Complexity Thresholds

Each Part III capability is justified only above a specific volume, team size, or compliance requirement. Below those thresholds, Part II is the correct answer.

Each Part III capability has a threshold below which it adds engineering cost without commensurate benefit. The table below defines those thresholds for the VAP domain. The Meridian domain may have different thresholds the capstone addresses this.

Capability	Add it when	Do not add it if
Multi-context retrieval	≥ 20 assessed contacts exist to retrieve as peers	Contact volume is too low for meaningful peer distributions
Data pipelines	You have ≥ 2 data sources OR an enrichment stage	You have one data source and no enrichment requirement
Multi-agent	The task has ≥ 2 distinct bounded subtasks with independent output contracts	The task is a single bounded assessment with no separable classification step
Event-driven triggers	Latency matters AND event delivery is reliable enough to trust	Latency of hours is acceptable AND your event source has unreliable delivery
Weekly observability	≥ 50 AI executions per month	Fewer than 50 executions per month (no statistical signal)
Rich governance	Override volume ≥ 5 per month OR team ≥ 4 people OR compliance accountability required	Override volume < 5 per month AND team < 3 AND no compliance requirements
Fixture-based testing	You have a defined output contract with ≥ 3 enumerated paths	You have no defined output contract (test what, exactly?)

Design Practice

The Part II platform was correct for Part II requirements. It became inadequate as requirements grew. The Part III capabilities are not universally better than Part II they are better for a specific volume, complexity, and compliance profile. A small-scale advisory operation with ten new contacts per month and a two-person team should not build the full Part III architecture. It should build Part II well.

3.8.3 Architecture Tradeoffs

Architecture Tradeoffs

Every architectural decision in Part III has a cost. The three primary tradeoffs are summarized below and detailed in the ADRs that follow.

Tradeoff	Benefit	Cost	Threshold
Multi-agent (sequential)	Validation gate between agents classification errors catchable before assessment	Two LLM calls per execution; doubled API cost and latency	VAP and Meridian volume: acceptable
Event-driven triggers	Advisory latency reduced from hours to seconds	Requires idempotency, DLQ, and polling safety net	Use when latency matters AND event delivery is reliable
Rich governance (four fields)	Full compliance auditability who, why, when, under which policy	Requires team discipline to populate all fields on every override	Use when compliance accountability is required

Tradeoff 1 Multi-agent adds debuggability at the cost of latency and complexity.

The sequential two-agent pattern produces a validation gate between agents Agent A’s output can be caught and routed before it propagates to Agent B. The cost is two LLM calls per execution instead of one, roughly doubling API cost and execution latency.

At VAP scale (hundreds of contacts per quarter), the doubling is acceptable. At Meridian scale (200–300 per quarter with time-sensitive deal routing), the latency of two sequential calls must be evaluated against the value of the intermediate validation gate.

Tradeoff 2 Event-driven reduces latency at the cost of reliability complexity.

A polling-only architecture is simple and reliable: the scheduler fires, the workflow runs, all contacts are processed. An event-driven architecture reduces latency from hours to seconds but requires idempotency checks, a DLQ for failed events, and the polling safety net to catch dropped events. The hybrid from Chapter 3.4 is the correct middle ground but it is not simpler than polling-only.

Tradeoff 3 Rich governance increases auditability at the cost of data maintenance.

The four extended governance fields and the governance Note time series are valuable for compliance review and policy version management. They also require consistent discipline from every team member who sets an override.

Incorrect or missing fields degrade the governance record without triggering a system error. The governance record is only as good as the team’s adherence to the field protocol.

3.8.4 Build versus Buy

Build versus Buy

Buy the infrastructure; build the intelligence.

Part III uses a mix of purchased capabilities and built implementations. The decision for each component:

Component	Decision	Rationale
AI inference	Buy (API)	Foundation model capability is not a differentiator; building a model is not the engineering task
Workflow orchestration	Buy (n8n)	Orchestration is commodity; building a scheduler and HTTP client from scratch adds no value
CRM and contact data	Buy (HubSpot)	The data store and CRM logic are not the product; the advisory logic running on top of it is
Observability analytics	Build (n8n workflow)	No vendor provides AI-specific property-level observability for HubSpot custom properties at this scale
Governance record	Build (HubSpot properties + workflow logic)	The four governance fields are domain-specific; no vendor provides this for the VAP/Meridian advisory context
Fixture evaluation	Build (n8n workflow)	Domain-specific fixtures cannot be purchased; the evaluation logic is straightforward to build
Alert delivery	Buy (Slack webhook)	Delivery is commodity; the alert content is what matters

The pattern: buy the infrastructure, build the intelligence. The intelligence the governance calibration, the fixture set, the output contracts, the observability thresholds is domain-specific and cannot be purchased. The infrastructure it runs on is commodity.

3.8.5 System Evolution

System Evolution Axes

The Part III architecture is a foundation, not a destination. Three evolution axes that the architecture supports:

Axis 1 Volume scaling

As submission volume grows from hundreds per quarter to thousands, the weekly observability cadence moves to daily, then near-real-time. The fixture set grows from 10 to 50–100. The human review loop shifts from manual sampling to AI-assisted flagging. The architecture supports this evolution without redesign only cadence and fixture count change.

Axis 2 Team scaling

As the team grows beyond 3–4 people, the approval chain transitions from recorded-in-a-field to technically enforced. A two-person approval workflow (requestor + approver) can be built as an n8n workflow that posts to Slack, waits for an approval click, and only then sets manual_override_active = true with the approver’s identity in override_authorized_by. The governance fields from Chapter 3.6 provide the data model; the enforcement mechanism is additive.

Axis 3 Model replacement

When the AI provider releases a new model or changes pricing, the fixture set from Chapter 3.7 enables migration testing. Run all fixtures against the new model, compare the distribution, and deploy the new model if the regression suite passes. The p6_prompt_version property does not change on model replacement (the prompt is unchanged); the observability workflow detects the distribution shift as model drift and the team decides whether the new model’s behavior is acceptable.

Engineering Rationale

The three evolution axes volume, team, model are the same axes the Meridian Venture Partners capstone addresses. Meridian has higher volume (200–300/quarter), a larger team (managing directors + compliance), and a model replacement cadence driven by LLM pricing competition. The capstone is not a new architecture; it is the Part III architecture calibrated for Meridian’s position on all three axes.

Architecture Decision Records Part III Summary

Three ADRs formalize the primary architectural decisions of Part III. These correspond to Capstone ADRs A, B, and C, which expand the Mini-ADR format to the full seven-field format required for Meridian’s LP reporting obligations.

ADR-6A Why Multi-Agent?

Mini-ADR 6A | Context: Part II used a single AI call for the full advisory assessment. The assessment requires two distinct tasks: determining the engagement type of the inquiry, and producing an advisory recommendation based on that type. Both tasks were bundled into the single Part II call.

Decision: Sequential two-agent pattern. Agent A (Engagement Type Classifier) runs first and produces a validated classification with confidence. Agent B (Advisory Assessor) receives the classified type and produces the advisory recommendation.

Rationale: Bundling classification and assessment into one call means a classification error cannot be detected before it propagates into the assessment. If the AI misclassifies partnership as exploratory, the assessment proceeds on incorrect premises and the error is not detectable from the advisory output alone.

The sequential pattern adds a validation gate between agents: Agent A’s classification is checked at ≥ 0.65 confidence before Agent B executes. This makes classification errors catchable and correctable, at the cost of one additional LLM call per execution. At VAP and Meridian volume, this cost is operationally acceptable.

ADR-6B Why Event-Driven?

Mini-ADR 6B | Context: Part II Workflow B used a polling trigger a scheduled workflow firing every few hours to check for contacts requiring lifecycle transitions. Polling works but introduces latency proportional to the polling interval. A contact that completes intake at 09:01 may not be assessed until the next poll at 12:00.

Decision: Hybrid architecture event-driven primary (HubSpot webhook on lifecycle stage property change) with a daily polling safety net.

Rationale: Event-driven reduces advisory latency from hours to seconds, which matters when contacts expect prompt follow-up after submitting an inquiry. Pure event-driven requires confidence in delivery guarantees that HubSpot webhooks do not unconditionally provide they can fail silently under rate limits or connectivity issues.

The hybrid retains polling as a safety net that processes any contacts that the event path missed, without adding a full DLQ implementation for a domain where missed events are recoverable within 24 hours. For Meridian, where deal routing decisions can be time-sensitive, the event-driven primary path is the correct choice; the polling safety net provides the reliability margin.

ADR-6C Agent Boundaries

Mini-ADR 6C | Context: The multi-agent architecture from Chapter 3.3 requires a decision about what belongs inside each agent and what belongs in the pipeline between them. There is a design pressure to add capabilities to Agent B (the Advisory Assessor) for example, having Agent B also compute an urgency score or draft an initial response email. Each addition makes Agent B more capable and the architecture harder to test, replace, and monitor.

Decision: Agent A scope limited to engagement type classification only. Agent B scope limited to advisory recommendation only. No agent performs a task outside its declared output contract. Pipeline capabilities (enrichment, routing, audit writing) remain in the pipeline, not inside agents.

Rationale: An agent that does multiple things cannot be independently tested for any single thing. If Agent B classifies, assesses, and drafts emails, a fixture that expects an advisory path cannot distinguish whether a wrong output came from classification logic, assessment logic, or email drafting logic.

Narrow scope makes each agent independently testable against its output contract. It also makes each agent independently replaceable Agent B can be swapped for a different model or a rule-based assessor without affecting Agent A. The principle is: an agent should do exactly one thing that can be specified in an output contract. Everything else belongs in the pipeline.

Reference Diagrams

Figure 3.8.1 AI Systems Architecture Map

Figure 40.1 is the Reference Architecture Map for Part III use it for consultation across all seven chapters, not single-reading comprehension. It shows the complete five-layer architecture with chapter annotations; every component has a direct equivalent in the Meridian capstone build.

%%{init:{"theme":"base","themeVariables":{"primaryColor":"#eef2ff","primaryTextColor":"#1e1b4b","primaryBorderColor":"#6366f1","lineColor":"#6366f1","clusterBkg":"#f8f9ff","clusterBorder":"#6366f1","titleColor":"#1e1b4b","edgeLabelBackground":"#f6f4ef","fontFamily":"system-ui,sans-serif","fontSize":"13px"}}}%%

flowchart TD
    subgraph L5["Layer 5 Testing (Ch 3.7)"]
        T1["10-Fixture Baseline (contract + behavioral)"]:::process
        T2["Regression Workflow (per prompt version)"]:::process
        T3["Human Review Loop (weekly sample)"]:::fallback
    end

    subgraph L1["Layer 1 Event Trigger (Ch 3.4)"]
        E1["HubSpot Webhook (primary per submission)"]:::trigger
        E2["Daily Polling Safety Net (catches dropped events)"]:::process
    end

    subgraph L2["Layer 2 AI Pipeline (Ch 3.1–3.3)"]
        P1["Ingest → Normalize (Ch 3.4 / Ch 3.2)"]:::process
        P2["Enrich (Ch 3.1: peer context Ch 3.2: firmographic)"]:::process
        P3["ASSESS (Ch 3.3) Agent A: Classify type Validation gate ≥ 0.65 Agent B: Advisory assess"]:::process
        P4["Route + Store writes p6_ properties"]:::process
        P1 --> P2 --> P3 --> P4
    end

    subgraph L3["Layer 3 Observability (Ch 3.5)"]
        O1["p6_ Properties (5 health metrics)"]:::process
        O2["Weekly Workflow → Slack #vap-ops"]:::success
        O3["Alert Conditions Critical / Warning / Info"]:::process
        O1 --> O2 --> O3
    end

    subgraph L4["Layer 4 Governance (Ch 3.6)"]
        G1["Workflow B: Check Expiry manual_override_active check"]:::process
        G2["4 Governance Fields + Note time-series"]:::process
        G3["Policy Versioning + Approval chain recording"]:::process
    end

    subgraph CC["Cross-Cutting"]
        CC1["Multi-Context AI (Ch 3.1)"]:::process
        CC2["Multi-Agent Architecture (Ch 3.3)"]:::process
        CC3["Capstone Synthesis (Ch 3.8)"]:::process
    end

    L1 --> L2
    L2 --> L3
    P4 --> O1
    L5 -.->|validates| L2
    L4 -.->|governs| L2
    classDef trigger  fill:#dcfce7,stroke:#16a34a,color:#14532d,font-weight:600
    classDef process  fill:#eef2ff,stroke:#6366f1,color:#1e1b4b
    classDef decision fill:#fef9c3,stroke:#ca8a04,color:#78350f,font-weight:600
    classDef success  fill:#d1fae5,stroke:#059669,color:#064e3b,font-weight:700
    classDef fallback fill:#fee2e2,stroke:#dc2626,color:#7f1d1d

Figure 40.1: Complete Part III Architecture. Complete Part III architecture: five integrated layers (Event Trigger, AI Pipeline, Observability, Governance, Testing), each corresponding to a dedicated chapter.

Figure 3.8.2 Production Maturity Model

Phase 5 baseline: Single-call advisory, polling trigger, boolean governance, reactive diagnosis only, no peer context, no pipeline structure.

Rung	Capability added	Problem solved
Ch. 6.1	Multi-context retrieval (peer context + firmographic)	Every contact assessed in isolation
Ch. 6.2	AI data pipeline (five stages; schema contracts)	No structure between data and AI call
Ch. 6.3	Multi-agent (sequential; validation gate between agents)	Classification errors propagate silently
Ch. 6.4	Event-driven triggers + DLQ + polling safety net	Hours of polling latency; event loss
Ch. 6.5	Observability (five health metrics + weekly report)	System health invisible between failures
Ch. 6.6	Rich governance (four fields + lifecycle + policy version)	Boolean cannot support compliance audit
Ch. 6.7	Fixture-based testing + regression suites	Prompt changes break silently

Future evolution (beyond Phase 6):

Real-time observability (sub-second alerting)
Technical approval chain enforcement (two-person override approval)
Automated fixture generation from production data
Model-level A/B testing (fixture set as comparator)

Figure 3.8.3 Part III Synthesis Map

Figure 40.2 shows how each Part III chapter contributes to the complete architecture and which capstone ADR it prepares.

%%{init:{"theme":"base","themeVariables":{"primaryColor":"#eef2ff","primaryTextColor":"#1e1b4b","primaryBorderColor":"#6366f1","lineColor":"#6366f1","clusterBkg":"#f8f9ff","clusterBorder":"#6366f1","titleColor":"#1e1b4b","edgeLabelBackground":"#f6f4ef","fontFamily":"system-ui,sans-serif","fontSize":"13px"}}}%%

flowchart LR
    CH1["Ch 3.1 Multi-Context AI"]:::chapter --> CAP1["context_enrichment_layer"]:::process --> ADR1["ADR-001"]:::adr
    CH2["Ch 3.2 Data Pipelines"]:::chapter --> CAP2["ai_pipeline_stages"]:::process --> ADR2["ADR-002"]:::adr
    CH3["Ch 3.3 Multi-Agent Arch"]:::chapter --> CAP3["dual_agent_assess"]:::process --> ADR3["ADR-003"]:::adr
    CH4["Ch 3.4 Event-Driven"]:::chapter --> CAP4["webhook_trigger_layer"]:::process --> ADR4["ADR-004"]:::adr
    CH5["Ch 3.5 Observability"]:::chapter --> CAP5["p6_property_suite"]:::process --> ADR5["ADR-005"]:::adr
    CH6["Ch 3.6 Governance"]:::chapter --> CAP6["governance_gate"]:::process --> ADR6["ADR-006"]:::adr
    CH7["Ch 3.7 Testing"]:::chapter --> CAP7["fixture_validation_suite"]:::process --> ADR7["ADR-007"]:::adr
    classDef trigger  fill:#dcfce7,stroke:#16a34a,color:#14532d,font-weight:600
    classDef process  fill:#eef2ff,stroke:#6366f1,color:#1e1b4b
    classDef decision fill:#fef9c3,stroke:#ca8a04,color:#78350f,font-weight:600
    classDef success  fill:#d1fae5,stroke:#059669,color:#064e3b,font-weight:700
    classDef fallback fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef chapter  fill:#cce5ff,stroke:#004085,color:#003060,font-weight:600
    classDef adr      fill:#d4edda,stroke:#28a745,color:#1a5928,font-weight:600

Figure 40.2: Chapter-to-Capability Synthesis. Chapter-to-capability synthesis: each Part III chapter contributes one architecture component and one capstone ADR.

Chapter	Capability added	Architecture	Capstone ADR
6.0	Phase bridge; bootstrap observability properties	4 `p6_` properties; curriculum map	All ADRs (foundation)
6.1	Multi-context retrieval (peer context injection)	Retrieve + Normalize Context nodes	ADR-A (pattern selection)
6.2	AI data pipeline (schema contracts)	Five-stage pipeline with stage-level error handling	ADR-A (pattern selection)
6.3	Multi-agent (sequential pattern)	Agent A + Agent B in Assess stage	ADR-A + ADR-C (pattern + agent scope)
6.4	Event-driven triggers (DLQ; hybrid)	Webhook + polling hybrid; DLQ record	ADR-B (trigger arch)
6.5	Observability (five metrics; alerting)	Weekly health report workflow	ADR-C (agent scope + monitoring)
6.6	Rich governance (four fields; lifecycle)	Four governance fields + Check Expiry in Wf B	ADR-D (governance calibration)
6.7	AI testing (fixtures; regression)	Fixture set + regression workflow	ADR-A + ADR-B (validation evidence)

Practical Exercise 3.8 Capstone Readiness Checklist

Business Scenario

You have completed Practicals 6.1 through 6.7 and built all five layers of the Vantage Advisory Partners Part III architecture. The Meridian Venture Partners capstone is next a new domain with higher volume, stricter compliance requirements, and a larger team. Before beginning, you need to verify that each capability is actually in place, not just approximately implemented.

The Problem

Partially implemented capabilities create silent gaps. A governance record without Notes, an observability workflow that never ran, or a fixture set that was defined but never tested against the current prompt version each is a capstone prerequisite that cannot be assumed complete.

Production Consideration

The readiness checklist is a point-in-time audit. A system that passes today can regress if a team member modifies a workflow node, changes a HubSpot property type, or rotates an API credential without updating the workflow. Before the capstone begins, establish a lightweight operational discipline: any change to a production workflow node should trigger a manual re-run of the fixture evaluation workflow to confirm no regressions were introduced.

For organizations with compliance obligations, the readiness checklist itself is a deliverable retain the completed checklist with the date it was signed off as evidence that the governance foundation was verified before the capstone build began.

Discussion Questions

ADR-6A justifies multi-agent by the debuggability benefit of the validation gate. For a domain where the engagement type can be inferred deterministically from a form field (the user selects “Partnership Inquiry” from a dropdown), is the multi-agent pattern still justified? What changes about the tradeoff when classification is deterministic?
The “When NOT to Add Complexity” table sets the observability threshold at ≥ 50 executions per month. Below that, there is “no statistical signal.” But statistical significance depends on the confidence level and the effect size you are trying to detect. For what kind of behavioral shift what size of effect would 20 executions per month be sufficient to detect with reasonable confidence? What would 50 fixtures buy you that 10 cannot?
ADR-6C defines agent boundaries by output contract: each agent does exactly one thing that can be specified in an output contract. The capstone requires Meridian to add an urgency score to each deal assessment. Should the urgency score be computed inside Agent B (advisory + urgency in one call), or should it be a third agent (Agent C: Urgency Scorer)? Justify using ADR-6C’s rationale.

Chapter Summary

The Part III architecture is five interconnected layers: event trigger, AI pipeline, observability, governance, and testing. No layer is optional in a production advisory system; each resolves a specific failure mode that the previous layer cannot address.

Key Principle

The Part III architecture is calibrated for a specific volume, team size, and compliance profile not universally superior to Part II. Apply each capability only when its complexity threshold is met. Below those thresholds, Part II is the right answer.

The architecture is not universally correct it is calibrated for a specific volume, team size, and compliance profile. The “When NOT to Add Complexity” table defines the thresholds. Below them, Part II is the right answer.

Three ADRs formalize the primary decisions: multi-agent is justified by validation-gate debuggability (ADR-6A); event-driven is justified by latency requirements with polling as a safety net (ADR-6B); agent boundaries are defined by output contracts, not capability bundles (ADR-6C). These ADRs expand to the full seven-field format in the capstone.

Transition to the Capstone

The Meridian Venture Partners capstone builds the same five-layer architecture for a new domain: 200–300 VC deal submissions per quarter, LP reporting obligations requiring compliance-grade governance, and a multi-team organization that requires technical approval chain enforcement rather than recorded-in-a-field authorization.

The capstone is not a new architecture. It is the Part III architecture with different calibration values, extended governance reason codes, a larger fixture set, and four capstone ADRs in the full seven-field format. Every component you built in Practicals 6.1 through 6.7 has a direct counterpart in the capstone. The readiness checklist in Practical 3.8 is the bridge.

Part III is complete. The capstone begins.

Key Takeaways

The Part III architecture has five layers: event trigger, AI pipeline, observability, governance, and testing. Each layer resolves a specific failure mode the others cannot.
Complexity has a threshold. Each Part III capability is only justified above a specific volume, team size, or compliance requirement. Below those thresholds, the simpler Part II architecture is correct.
The three primary tradeoffs: multi-agent adds debuggability at the cost of latency; event-driven adds latency reduction at the cost of reliability complexity; rich governance adds auditability at the cost of data maintenance discipline.
Build the intelligence, buy the infrastructure. Governance calibration, fixture sets, and observability thresholds are domain-specific and must be built. Orchestration, inference, CRM, and alert delivery are commodity and should be purchased.
Three ADRs formalize the architecture decisions: ADR-6A (why multi-agent: validation-gate debuggability), ADR-6B (why event-driven: latency reduction with polling safety net), ADR-6C (agent boundaries: one output contract per agent).
The architecture is designed to evolve on three axes: volume (cadence changes, fixture set grows), team (approval chains become technically enforced), model replacement (fixture set enables migration testing).
The Part III architecture is the capstone foundation. Meridian requires the same five layers with different calibration not a different architecture.

End of Chapter 3.8 Production AI Systems and Synthesis

End of Part III AI Systems Engineering (Chapters 3.0–6.8)