%%{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"]
T1["10 Fixtures F001–F010+"]:::process
T2["Regression Workflow"]:::process
T3["Human Spot-Check (MD)"]:::process
end
subgraph L1["Layer 1 Event Trigger"]
E1["HubSpot Deal Webhook (dealstage = New Submission)"]:::trigger
E2["Daily 03:00 Polling (safety net)"]:::process
E3["DLQ + Replay"]:::fallback
end
subgraph L2["Layer 2 AI Pipeline (Workflow A)"]
P1["Ingest"]:::process --> P2["Normalize"]:::process --> P3["Enrich (peer + thesis + market)"]:::process
P3 --> P4["Assess (Eval + Match + Thesis + Risk)"]:::process
P4 --> P5["Score + Output"]:::success
end
subgraph L3["Layer 3 Observability"]
O1["6 deal_ audit properties"]:::process
O2["Daily Health Report"]:::process
O3["Drift + Calibration Monitor"]:::trigger
end
subgraph L4["Layer 4 Governance"]
G1["3-Tier Gate (Category / Risk / Stage)"]:::process
G2["6 governance properties"]:::process
G3["Override + Audit Trail"]:::process
end
L1 --> L2
L2 --> L4
L4 --> L3
L5 -. "validates" .-> 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
Chapter 3 Capstone Project
Meridian Venture Partners Multi-Agent Intelligence Platform
Why This Chapter Matters
The Part III capstone certifies that an engineer can design and build a complete multi-agent AI intelligence platform from data pipeline through observability, governance, and testing adapted to a previously unseen client scenario. Meridian Venture Partners processes 200 to 300 deal submissions per quarter with a four-person investment team.
The capstone does not reteach Part III capabilities. It certifies that engineers can apply them together, make defensible architectural decisions under realistic constraints, and document those decisions in the ADR format that client teams can maintain.
Real-World Scenario
Meridian’s managing partner has committed to the firm’s limited partners that deal screening decisions will be consistently documented and explainable by Q3. The current process where partners screen deals ad hoc based on personal judgment cannot meet that commitment at the firm’s current submission volume. The capstone builds the platform that makes consistent, documented, explainable deal screening possible at scale: a multi-agent assessment pipeline, a governance layer with full override auditability, an observability stack, and a regression test suite.
Learning Objectives
After completing this capstone, you will be able to:
- Design the complete Meridian Multi-Agent Intelligence Platform architecture, from the five-stage deal pipeline through multi-agent assessment, event-driven triggers, observability, and governance.
- Produce four full 7-field ADRs (Status, Context, Decision, Rationale, Consequences, Alternatives Considered, Review Trigger) that document the platform’s four major architectural decisions.
- Build and configure the deliverables specified in the capstone brief (D0–D8), demonstrating integration of every Part III capability in a coherent, client-deployable platform.
- Evaluate your own implementation against the 110-point capstone rubric, identifying specific deliverables, ADR quality criteria, and integration requirements that determine your score.
- Demonstrate Part III mastery by producing a platform that can be handed to Meridian’s operations team with documented procedures, observable health metrics, and a regression test suite for ongoing AI quality assurance.
Builds On
- Chapters 6.0 through 6.8 (complete Part III curriculum)
- Part II Capstone Vantage Advisory Partners CRM Intelligence Platform
Prepares For
- Phase 7 (next phase of the curriculum)
Domain Brief
Domain Brief: Meridian Venture Partners
Meridian Venture Partners is an early-stage venture capital firm managing a $300M fund. The firm receives 200–300 deal submissions per quarter from founders seeking seed and Series A investment. Submissions arrive through a HubSpot Deal form and are tracked as Deal objects (not Contact objects) each Deal is associated with a Contact (the founding team representative) via the HubSpot Associations API.
Meridian’s current process is fully manual: a junior associate reviews each submission, assigns a preliminary stage-fit score, and routes the deal to a Managing Director for review or to a decline queue. The process takes 3–5 business days per submission, creating a backlog that grows each quarter. Several time-sensitive deals have been declined by default due to processing delay.
Platform goal: An AI-assisted deal evaluation pipeline that processes each new submission within hours of receipt, produces a structured advisory recommendation, and routes the deal to the appropriate review track with full observability, LP-reporting-grade governance, and a regression-tested prompt version.
Domain-specific constraints that differ from the VAP build:
| Constraint | VAP (Chapters 6.1–6.8) | Meridian (this capstone) |
|---|---|---|
| Object type | Contact | Deal (associated to Contact) |
| Property prefix | vap_ / p6_ |
deal_ |
| Submission volume | Hundreds per quarter | 200–300 per quarter (~3–5 per day) |
| Observability cadence | Weekly | Daily |
| Governance tier | Single-level (any team member) | Three-tier (Associate / MD / MD + Compliance) |
| Override expiry calibration | Relationship-cycle (30–90 days) | Deal-cycle (7–90 days; some manual-clear only) |
| ADR format | Mini-ADR (one paragraph) | Full 7-field format (LP reporting requirement) |
Technology stack: HubSpot (Deal CRM), n8n (workflow orchestration), OpenAI API (AI inference), Slack (alerts and reporting).
Readiness Gates
Readiness Gates
Complete both gates before submitting any deliverable.
Gate 1 Technical Readiness
The fixture evaluation workflow from Deliverable 7 must return CLEAR for your chosen prompt version. No CONTRACT_VIOLATION. No REGRESSION. Post the evaluation report to #meridian-ai-ops and retain the screenshot as Gate 1 evidence.
Gate 2 Documentation Readiness
All four ADRs (Deliverable 0) must be in the full 7-field format. The governance Notes pattern (Deliverable 6) must be demonstrated with at least one complete override lifecycle set, then either auto-expired or manually cleared with a HubSpot Note written at each transition. Retain the HubSpot Contact/Deal activity timeline screenshots as Gate 2 evidence.
CautionProduction Risk
Do not attempt Deliverables 1–9 until both gates are defined (even if not yet executed). The ADR decisions in Gate 2 constrain design choices across all subsequent deliverables. Write the ADRs first.
Deliverable 0 ADR Package
Full 7-Field ADR Format
The ADR package is the primary intellectual artifact of the capstone it demonstrates the ability to justify architectural decisions in the specific language of the domain.
Produce four Architecture Decision Records in the full 7-field format. This format expands the Mini-ADR practiced in Chapters 6.3, 6.4, and 6.6 to satisfy Meridian’s LP reporting obligations, which require documented rationale for all AI system design decisions affecting deal routing.
7-field ADR format:
| Field | Content |
|---|---|
| Status | Proposed → Accepted → Deprecated / Superseded |
| Context | The situation, constraint, or problem requiring a decision |
| Decision | What was decided one clear sentence |
| Rationale | Why this decision over alternatives specific to the Meridian domain |
| Consequences | What this decision means going forward: benefits, costs, new obligations created |
| Alternatives considered | What else was evaluated; why it was rejected |
| Review trigger | The condition under which this ADR should be revisited |
Write all four ADRs in this format. The domain context in each ADR must reference Meridian’s specific constraints (deal volume, deal-cycle timing, LP reporting), not generic Part III content.
ADR-A Pattern Selection: Multi-Agent Architecture
Status: Accepted
Context: Meridian’s deal evaluation requires two distinct cognitive tasks: (1) classifying the deal by sector and stage to determine which evaluation framework applies, and (2) assessing the deal’s merit within that framework. In the VAP build (Mini-ADR 6A), these tasks were separated into Agent A and Agent B.
At Meridian, a third dimension is required comparative assessment against recent peer deals making the correct pattern choice more consequential. A single-call approach, a two-agent sequential approach, and a three-coordination-pattern approach (sequential + parallel + conditional) are all viable.
Decision: Three-coordination-pattern multi-agent architecture: sequential classification → parallel merit + comparative assessment → conditional domain-expertise gate.
Rationale: Sequential classification (Agent 1) must complete before merit assessment (Agent 2) because the evaluation framework depends on the sector classification a biotech deal is assessed against different criteria than a SaaS deal.
Merit assessment (Agent 2) and comparative assessment (Agent 3) are independent of each other and can run in parallel, reducing total pipeline latency. The domain-expertise gate (Agent 4: Regulatory Risk Assessor) is required only for biotech and deep-tech submissions conditional execution avoids two additional LLM calls on every deal. The combination of all three patterns produces the most efficient path to a validated advisory recommendation.
Consequences: Four LLM calls on biotech/deep-tech deals (sequential + parallel pair + conditional), two LLM calls plus parallel pair on all other deals. API cost approximately 3× the VAP sequential pattern.
Parallel execution requires n8n to support concurrent branch execution (confirmed). Each agent must have an output contract and a validation gate. Four agents means four contracts to maintain and four fixture sets to test.
Alternatives considered: (1) Single-call: rejected because classification errors propagate silently into assessment; no validation gate. (2) Two-agent sequential (VAP pattern): rejected because comparative assessment cannot run in parallel with merit assessment, increasing latency beyond acceptable range for MD responsiveness requirements. (3) Parallel-only for all four agents: rejected because Agent 2 (merit assessment) requires Agent 1’s classification output dependency prevents pure parallel execution.
Review trigger: If deal volume grows to >50/day and parallel LLM call latency becomes a bottleneck (>30s per deal), revisit whether merit and comparative assessment can be merged into a single enriched call without losing the independent validation benefit.
ADR-B Trigger Architecture: Event-Driven vs. Polling
Status: Accepted
Context: Meridian’s current 3–5 day processing cycle is partly caused by polling latency deals sit in HubSpot until the next manual review cycle. A webhook-first event-driven architecture reduces this to minutes, but HubSpot Deal webhooks have delivery reliability constraints. A pure polling architecture is reliable but slow.
The VAP Mini-ADR 6B established the hybrid pattern. This ADR confirms the same pattern is correct for Meridian and calibrates the polling safety net interval for deal volume.
Decision: Webhook-primary event-driven architecture with daily polling safety net. Trigger event: deal.propertyChange where propertyName = dealstage AND propertyValue = "New Submission".
Rationale: At 3–5 deals per day, the processing latency of a polling-only system depends entirely on the polling interval. An 8-hour polling interval means some deals wait up to 8 hours before first assessment unacceptable when a founder’s inquiry may be time-sensitive. Event-driven reduces this to minutes.
The daily polling safety net sweeps all deals where dealstage = "New Submission" AND deal_last_execution_timestamp is not set, catching any events dropped by the webhook delivery system. At 3–5 deals per day, the daily sweep processes at most 5 missed deals acceptable as a safety-net cost.
Consequences: The idempotency check (verify deal_last_execution_timestamp not already set before processing) is mandatory and must run before any Agent 1 call. Failed events require a DLQ record with the full deal payload and delivery metadata. The polling safety net must be scheduled outside business hours (03:00) to avoid competing with real-time webhook events during peak submission hours.
Alternatives considered: (1) Polling-only (4-hour interval): rejected because maximum 4-hour latency is still too high for time-sensitive deal routing. (2) Pure event-driven with no safety net: rejected because HubSpot webhook delivery is not guaranteed under high load; missed events with no safety net produce permanent processing gaps that are not detectable from the workflow layer. (3) Real-time polling (every 5 minutes): rejected because API rate limits become a constraint at this polling frequency for the full HubSpot Deals search endpoint.
Review trigger: If HubSpot releases guaranteed webhook delivery with at-least-once semantics, revisit whether the polling safety net adds complexity without benefit.
ADR-C Agent Scope: Boundaries and Responsibilities
Status: Accepted
Context: The four-agent architecture in ADR-A requires precise scope boundaries for each agent. There is design pressure to expand Agent 2 (Merit Assessor) to include comparative assessment, eliminating Agent 3. There is also pressure to expand Agent 4 (Regulatory Risk Assessor) to include full biotech merit assessment, consolidating the biotech path. Each consolidation reduces API calls but merges independently testable scopes into a single unauditable unit.
Decision: Each agent’s scope is bounded by a single, fully specified output contract. No agent performs more than one distinct assessment task. Pipeline synthesis (combining agent outputs into the final deal_advisory_path) occurs in a Code node, not inside any agent.
Rationale: Agent 2 assessing merit and Agent 3 assessing comparables in a single call means a bad comparative context cannot be isolated as the cause of a wrong recommendation the call conflates two failure modes.
Separate agents with separate output contracts allow each to be tested independently (Deliverable 7 includes per-agent fixtures), replaced independently (a different comparative-assessment model can be substituted for Agent 3 without touching Agent 2), and monitored independently (observability tracks deal_agent_call_count and can detect Agent 3 failures separately from Agent 2 failures).
Synthesis in a Code node is deterministic and testable with standard unit tests it does not belong inside a probabilistic AI call.
Consequences: Four output contracts to maintain. Each agent’s output must be validated before the next stage consumes it.
The parallel branch (Agents 2 and 3) requires n8n to merge two outputs before the conditional branch evaluates this merge is a Code node that must be specified in Deliverable 2. Any agent contract change requires a fixture re-run across all downstream agents.
Alternatives considered: (1) Merge Agent 2 + Agent 3 into single “Assessment” call: rejected per rationale above. (2) Agent 4 handles full biotech merit instead of only regulatory risk: rejected because biotech merit assessment and regulatory risk assessment are both large, specialized tasks combining them produces unpredictably long responses that exceed output contract constraints. (3) Remove Agent 4 entirely and inject regulatory guidance into Agent 2’s system prompt: rejected because regulatory guidance injected as context is not auditable as a distinct assessment step; LP reporting requires evidence that regulatory risk was evaluated independently.
Review trigger: If the fixture suite (Deliverable 7) shows Agent 3 (comparative assessment) produces no material change in deal_advisory_path distribution versus a baseline without comparative context (as measured by the observability workflow in Deliverable 5), revisit whether Agent 3 adds cost without benefit.
ADR-D Governance Calibration: Override Policy for Meridian
Status: Accepted
Context: The VAP governance model (Chapter 3.6) calibrated override expiry durations and reason codes to relationship-cycle time (30–90 days). Meridian’s governance operates on deal-cycle time (diligence cycles of 30–90 days; regulatory reviews with no predictable end date) and must satisfy LP reporting obligations that require dual-approval for LP-sensitive deals.
Mini-ADR 6.6-D established the reason code candidates. This ADR formalizes the full governance model.
Decision: Three-tier governance model with five reason codes, deal-cycle-calibrated expiry durations, and a deal_governance_tier property that determines the required approval chain.
Rationale: Meridian manages LP relationships with specific visibility requirements into deal routing decisions. A deal originated from an LP referral (LP_RELATIONSHIP reason code) requires a Managing Director to authorize any override an Associate-level authorization is not sufficient for LP reporting. A deal under regulatory review (REGULATORY_REVIEW) requires both MD and Compliance Officer authorization.
The deal_governance_tier property encodes this requirement in the Deal record, enabling the observability workflow to flag any deals where deal_override_authorized_by does not match the tier requirement.
Expiry durations are calibrated to deal lifecycle: DEAL_IN_DILIGENCE at 60 days (standard Meridian diligence cycle), DATA_QUALITY at 7 days (sufficient for data correction), LP_RELATIONSHIP at 90 days (LP relationships require extended hold), COMPLIANCE_HOLD and REGULATORY_REVIEW at manual-clear only (no predictable end date).
Consequences: The Check Expiry node (Workflow B equivalent) must also validate deal_governance_tier against deal_override_authorized_by on every execution a new validation step not present in the VAP build. The governance audit Note must record the tier at the time the override was set.
Policy version follows MERIDIAN-POLICY-{YYYY}-{QN}. LP reporting exports require a query filtered on deal_override_policy_version to identify all deals under a specific policy version.
Alternatives considered: (1) Single-tier governance (any team member can authorize any override): rejected because LP reporting requires evidence that LP-sensitive overrides were authorized at MD level; single-tier provides no audit trail for this distinction. (2) Five-tier governance (one tier per reason code): rejected because the tier determines the approval chain, not the reason two reason codes (LP_RELATIONSHIP and COMPLIANCE_HOLD) can both be LP-sensitive regardless of the business reason. Three tiers (standard / lp_sensitive / regulatory) cover the full authorization matrix. (3) Technical enforcement of dual-approval at override set time: deferred to Phase 7 (ADR-D identifies this in consequences); current capstone records tier in the property; enforcement is audit-based, not technical.
Review trigger: If the quarterly governance audit identifies any cases where deal_override_authorized_by does not match the required tier for deal_governance_tier, this ADR must be revised to include technical enforcement of the approval chain before the next quarter’s submissions begin.
Collapsed reference: Deliverable 0 builds on Mini-ADRs from Chapters 6.3, 6.4, and 6.6. Full 7-field format required here per Meridian LP reporting obligations. The four ADRs above replace those Mini-ADRs for the Meridian domain.
Deliverable 1 Multi-Context Architecture
Three-Source Context Assembly
Design and implement the three-source context assembly for Meridian’s deal assessment pipeline.
Context sources:
| Source | Content | Retrieval method | Normalization target |
|---|---|---|---|
| Peer deals | Last 10 assessed deals in the same sector and stage | HubSpot Deals Search API filtered on deal_sector + deal_stage_completed |
peer_deal_context schema |
| Fund thesis | Meridian’s current sector focus and stage preferences | Static document injected as a prompt block | fund_thesis_context schema |
| Market signals | Recent funding announcements in the same sector (mock API) | Mock HTTP Request returning JSON | market_signal_context schema |
peer_deal_context schema (output of Normalize Context node):
{
"peer_count": 10,
"sector": "SaaS",
"stage": "Series A",
"advisory_path_distribution": {
"expedited_review": 3,
"standard_review": 5,
"decline": 2
},
"mean_confidence": 0.74,
"check_size_range": { "min": 500000, "max": 3000000 }
}fund_thesis_context schema:
{
"current_fund": "Fund III",
"preferred_sectors": ["SaaS", "FinTech", "HealthTech"],
"preferred_stages": ["Seed", "Series A"],
"check_size_target": { "min": 500000, "max": 5000000 },
"thesis_version": "2025-Q3"
}market_signal_context schema:
{
"sector": "SaaS",
"recent_funding_count": 12,
"recent_funding_total_usd": 180000000,
"notable_competitor_funded": true,
"signal_period_days": 90
}Implement all three context sources in the Enrich stage of the pipeline (Deliverable 2). Document any case where a context source returns empty results and how the Build Prompt node handles the absence.
Collapsed reference: Chapter 3.1 (
peer_contextsingle-source retrieval), Chapter 3.2 (Enrich stage design), Chapter 3.3 (multi-source context injection into agent prompts).
Deliverable 2 Pipeline Specification
Specify and implement the full five-stage pipeline for Meridian’s deal evaluation workflow.
Stage specifications:
Stage 1 Ingest Webhook trigger: deal.propertyChange event. Extract objectId (Deal ID). Fetch full Deal record from HubSpot Deals API, requesting all properties needed by downstream stages. Write deal_last_execution_timestamp = now() immediately (idempotency marker).
Stage 2 Normalize Validate all required Deal fields. Canonical deal schema at Normalize output:
deal_name, founding_team_contact_id, sector, stage_requested,
check_size_usd, pitch_summary, submission_date, deal_sourceAny missing required field routes to the error path and writes deal_last_execution_source = "normalize_error". An On Error branch catches Node errors and writes the same error property before terminating.
Stage 3 Enrich Three parallel sub-stages (can be implemented as three sequential HTTP Request nodes or as parallel branches): 1. Retrieve peer deals (HubSpot Deals Search API) 2. Retrieve fund thesis (static Code node or external document store) 3. Retrieve market signals (mock HTTP Request) Normalize each source output to its target schema. Merge all three into a single enriched_context object passed to Assess.
Stage 4 Assess Multi-agent coordination per ADR-A and Deliverable 3.
Stage 5 Route + Store Write all deal_ audit properties to the HubSpot Deal record. Route: - expedited_review → Slack alert to #meridian-deals-hot + create HubSpot Task for MD review within 24 hours - standard_review → add to weekly review queue (HubSpot List) - decline → send automated acknowledgment email template; archive deal
Specify the schema contract (property name, type, expected value range) for every boundary between stages. Any property that is not defined in the schema contract at a boundary should be treated as a pipeline error.
Collapsed reference: Chapter 3.2 (five-stage pipeline anatomy, schema contracts, stage-level error handling), Chapter 3.4 (idempotency marker pattern).
Deliverable 3 Multi-Agent System
Three-Coordination-Pattern Multi-Agent Architecture
All three coordination patterns sequential, parallel, and conditional must be present; a two-pattern implementation does not meet the deliverable requirement.
Implement all three coordination patterns within the Assess stage.
Agent definitions:
| Agent | Scope | Output contract fields | Validation gate |
|---|---|---|---|
| Agent 1 Sector Classifier | Classifies the deal sector and identifies the applicable evaluation framework | deal_sector_classified, sector_confidence, evaluation_framework, classification_valid |
sector_confidence ≥ 0.70 before Agent 2 executes |
| Agent 2 Merit Assessor | Evaluates deal merit within the classified sector using fund thesis context | deal_merit_score (0–10), merit_rationale, merit_confidence, merit_valid |
merit_confidence ≥ 0.65 |
| Agent 3 Comparative Assessor | Compares deal against peer deal context and market signals | deal_comparative_position (above_peers / at_peers / below_peers), comparative_rationale, comparative_confidence |
comparative_confidence ≥ 0.60 |
| Agent 4 Regulatory Risk Assessor | Assesses regulatory risk for biotech/deep-tech deals only | regulatory_risk_level (low / medium / high), regulatory_rationale, regulatory_confidence |
regulatory_confidence ≥ 0.70 |
Coordination pattern implementation:
Sequential:
Agent 1 (Sector Classifier)
→ Validation gate (sector_confidence ≥ 0.70)
→ [if pass] Parallel branch:
Parallel:
┌─────────────────────────┐ ┌──────────────────────────────┐
│ Agent 2 (Merit) │ │ Agent 3 (Comparative) │
└─────────────────────────┘ └──────────────────────────────┘
→ Merge outputs (Code node: merge_agent_outputs)
Conditional:
IF deal_sector_classified IN ["biotech", "deep_tech"]:
→ Agent 4 (Regulatory Risk Assessor)
ELSE:
→ skip (regulatory_risk_level = "not_applicable")
Synthesis (Code node):
Combine merit_score + comparative_position + regulatory_risk_level
→ compute deal_advisory_path + deal_ai_confidence
→ write deal_agent_call_count (2 for standard; 3 for biotech/deep_tech)Synthesis logic (implement in Code node):
// Advisory path synthesis deterministic logic, not AI
const { merit_score, comparative_position, regulatory_risk_level } = merged;
let advisory_path;
if (regulatory_risk_level === "high") {
advisory_path = "decline";
} else if (merit_score >= 7.5 && comparative_position === "above_peers") {
advisory_path = "expedited_review";
} else if (merit_score <= 3.5 || comparative_position === "below_peers") {
advisory_path = "decline";
} else {
advisory_path = "standard_review";
}Implement the rule fallback path: if any validation gate fails, set deal_last_execution_source = "rule_fallback" and route deal_advisory_path using the deterministic rule above applied to available non-AI data.
Collapsed reference: Chapter 3.3 (agent output contracts, sequential / parallel / conditional patterns, validation gates, rule fallback). All three patterns must be present; a two-pattern implementation does not meet the deliverable requirement.
Deliverable 4 Event-Driven Model
Implement the hybrid event-driven architecture per ADR-B.
Webhook configuration: HubSpot webhook subscription for deal.propertyChange on property dealstage. Filter in the n8n Webhook node: only process events where propertyValue = "New Submission".
Idempotency implementation: Before Agent 1 executes, check whether deal_last_execution_timestamp is already set on the Deal record. If set, log a duplicate event record and halt. If not set, write deal_last_execution_timestamp = now() and continue. The write must complete before any agent call.
DLQ record schema:
{
"event_id": "HubSpot eventId from payload",
"deal_id": "objectId",
"received_at": "ISO 8601",
"failure_reason": "string",
"delivery_attempt": "integer",
"full_payload": "complete HubSpot event JSON",
"status": "pending_retry | abandoned"
}Store DLQ records in a HubSpot Note on the Deal record (for auditability) and optionally in an n8n data store for replay orchestration.
Polling safety net: Schedule Trigger at 03:00 daily. HubSpot Deals Search: dealstage = "New Submission" AND deal_last_execution_timestamp not set. Limit: 50. Process each missed deal through the full pipeline.
Replay pattern: Failed DLQ events can be replayed by a manually triggered n8n workflow that reads DLQ records with status = "pending_retry", reconstructs the deal payload, and re-enters the pipeline at Stage 2 (Normalize). Set idempotency marker before replay to prevent double-processing.
Collapsed reference: Chapter 3.4 (event payload design, idempotency, DLQ, replay, hybrid architecture). The implementation here must use the HubSpot Deal webhook payload structure, not the Contact webhook structure from the VAP build.
Deliverable 5 Observability Package
Design and implement the daily observability workflow for Meridian.
Audit properties (write in Route + Store on every execution):
| Property | Type | Written value |
|---|---|---|
deal_last_execution_source |
Enum | ai | rule_fallback | normalize_error |
deal_ai_confidence |
Number | Synthesized confidence (0.00–1.00) |
deal_advisory_path |
Enum | expedited_review | standard_review | decline |
deal_agent_call_count |
Number | 2 (standard) or 3 (biotech/deep_tech) |
deal_prompt_version |
Text | Current prompt version string |
deal_last_execution_timestamp |
Datetime | Execution timestamp |
Five health metrics (adapted for Meridian deal volume):
- Confidence distribution: mean
deal_ai_confidenceacross all deals processed yesterday. Alert if mean < 0.68 (baseline from pilot fixture set). - Fallback rate: proportion where
deal_last_execution_source = "rule_fallback". Alert if > 15%. - Advisory path distribution: proportion per path value. Alert if
expedited_reviewexceeds 40% (indicates potential over-routing of deals for immediate MD attention). - Agent call count distribution: proportion with count = 2 vs. 3. Unexpected increases in count = 2 for biotech/deep_tech sectors indicate conditional branch failures.
- Sector classification accuracy: sampled metric once per week, an MD spot-checks 5
deal_sector_classifiedvalues against their own classification. Disagreements are recorded as asector_accuracy_eventHubSpot Note and reviewed in the weekly ADR-C review meeting.
Observability workflow: Schedule Trigger daily at 07:00. Query HubSpot Deals where deal_last_execution_timestamp >= yesterday 00:00:00. Compute all five metrics. Compare to baseline. Post to #meridian-ai-ops Slack channel. Email summary to Managing Directors for any 🚨 Critical alert.
Collapsed reference: Chapter 3.5 (three observability pillars, five health metrics, instrumentation flow, alerting design). Cadence is daily here vs. weekly in the VAP build justified by Meridian’s higher deal volume and MD response time requirements.
Deliverable 6 Governance State Model
Three-Tier Governance Model
Implement the three-tier governance model per ADR-D.
Governance property group: Meridian Deal Governance (HubSpot Deal property group).
| Property | Type | Values / format |
|---|---|---|
deal_override_active |
Boolean | true / false |
deal_override_expires_at |
Datetime | ISO 8601 |
deal_override_reason_code |
Enum | See table below |
deal_override_authorized_by |
Text | Authorizer email |
deal_override_policy_version |
Text | MERIDIAN-POLICY-{YYYY}-{QN} |
deal_governance_tier |
Enum | standard | lp_sensitive | regulatory |
Reason codes and calibrated expiry:
| Code | Expiry | Governance tier | Required authorizer |
|---|---|---|---|
DEAL_IN_DILIGENCE |
60 days | standard | Any Associate+ |
LP_RELATIONSHIP |
90 days | lp_sensitive | Managing Director |
DATA_QUALITY |
7 days | standard | Any Associate+ |
COMPLIANCE_HOLD |
Manual-clear only | lp_sensitive | Managing Director |
REGULATORY_REVIEW |
Manual-clear only | regulatory | MD + Compliance Officer |
Tier validation (Check Expiry + Tier node in Workflow B equivalent):
After the expiry check (Chapter 3.6 pattern), add a Tier Validation step: query deal_governance_tier and deal_override_authorized_by. If deal_governance_tier = "lp_sensitive" and deal_override_authorized_by is not an MD-level email, write a governance Note flagging the tier mismatch and add the deal to a #meridian-governance-review Slack alert. Do not block the override flag it for audit review.
Governance Note format:
MERIDIAN GOVERNANCE EVENT: {event_type}
Timestamp: {ISO 8601}
Deal ID: {deal_id}
Reason code: {deal_override_reason_code}
Authorized by: {deal_override_authorized_by}
Governance tier: {deal_governance_tier}
Expires at: {deal_override_expires_at | "MANUAL-CLEAR-ONLY"}
Policy version: {deal_override_policy_version}
Tier validation: PASS | FLAG
---
{Context note if tier mismatch flagged}Demonstrate the full override lifecycle (set → auto-expiry OR manual clear) on one test deal. Provide screenshots of both the HubSpot Deal property values and the governance Note on the Deal activity timeline.
Collapsed reference: Chapter 3.6 (four governance fields, override lifecycle, state machine, governance Notes, policy versioning). Deliverable 6 adds the
deal_governance_tierproperty and the Tier Validation step both are new relative to the VAP build.
Deliverable 7 Testing Package
Build the fixture evaluation workflow and run all fixtures before deploying any prompt version to production.
Minimum 10 fixtures. The table below defines the required fixtures; additional fixtures covering edge cases specific to your Meridian implementation are encouraged.
| ID | Scenario | Expected path | Confidence min | Pattern tested |
|---|---|---|---|---|
| F001 | Strong SaaS Series A, above-peer comparables, fund-thesis match | expedited_review |
0.78 | Sequential + Parallel |
| F002 | Hardware deal outside fund thesis stage preference | decline |
0.72 | Sequential + Conditional-skip |
| F003 | Borderline FinTech deal, at-peer comparables | standard_review |
0.65 | Sequential + Parallel |
| F004 | Biotech Series A, moderate merit, no regulatory red flags | standard_review |
0.65 | Sequential + Parallel + Conditional |
| F005 | Biotech with high regulatory risk (CRISPR application) | decline |
0.70 | Conditional + Synthesis logic |
| F006 | Valid deal, Agent 1 returns sector_confidence = 0.55 | rule_fallback |
N/A | Validation gate |
| F007 | Missing pitch_summary field |
rule_fallback |
N/A | Normalize gate |
| F008 | LP-referred deal should trigger deal_governance_tier = "lp_sensitive" on the Deal record |
standard_review |
0.65 | Governance tier |
| F009 | All 10 peer comparables declined, but current deal merit_score = 8.2 | expedited_review |
0.70 | Peer context anchoring |
| F010 | Deep tech deal, high merit, competitor recently funded (market signal) | expedited_review |
0.72 | Parallel + market signal context |
Evaluation workflow output: Post to #meridian-ai-ops: - Total fixtures: N - Passes / Regressions / Contract violations - Calibration summary (confidence band accuracy) - Deployment recommendation: ✅ CLEAR or 🚨 BLOCKED
Regression protocol: Before deploying any new prompt version, run all fixtures. Block deployment on any REGRESSION or CONTRACT_VIOLATION. For CONFIDENCE_SHIFT only, run a secondary human review of the shifted fixtures before deploying.
Collapsed reference: Chapter 3.7 (fixture design, output contracts, AI test pyramid, confidence calibration, regression workflow, human review loops). The 10-fixture set here replaces the VAP baseline set; do not reuse VAP fixtures for Meridian.
Reference Architecture
Figure 41.1 shows the complete Meridian five-layer architecture. All five layers from Chapter 3.8 are present; the Meridian-specific extensions (three-tier governance, three-coordination-pattern agents, three-source context) are annotated.
Evaluation Rubric
| Deliverable | Points | Criteria |
|---|---|---|
| D0 ADR Package | 20 | All 4 ADRs in 7-field format; context specific to Meridian; alternatives considered are substantive |
| D1 Multi-Context Architecture | 10 | Three context sources implemented; all three normalized to schema; empty-result handling documented |
| D2 Pipeline Specification | 10 | All five stages present; schema contract at each boundary; error path routes to deal_last_execution_source = "normalize_error" |
| D3 Multi-Agent System | 20 | All three coordination patterns present; four output contracts defined; synthesis in Code node (not AI); rule fallback implemented |
| D4 Event-Driven Model | 10 | Webhook configured; idempotency marker written before Agent 1; DLQ schema defined; polling safety net active |
| D5 Observability Package | 10 | Six audit properties written per execution; five metrics computed daily; email alert for MD on Critical |
| D6 Governance State Model | 10 | Six governance properties; three tiers; Tier Validation step; one complete lifecycle demonstrated with screenshots |
| D7 Testing Package | 10 | ≥10 fixtures; contract + behavioral validation; evaluation report posted to Slack; deployment recommendation present |
| D8 Portfolio Case Study | 5 | 600–800 words; professional tone; ADRs referenced by letter; one failure analysis; one retrospective design change |
| D9 Phase 7 Readiness | 5 | Three extensions identified; one ROI analysis; architectural implications for each |
| Gate 1 evidence | +5 bonus | Fixture evaluation report screenshot showing CLEAR status |
| Gate 2 evidence | +5 bonus | HubSpot Deal timeline screenshot showing complete governance Note lifecycle |
| Total | 110 + 10 bonus |
Minimum passing score: 80/110 (not including bonus). All ten deliverables must be submitted.
Deliverable 8 Portfolio Case Study
Write a 600–800 word case study documenting the Meridian Venture Partners AI Advisory Platform build. This document must be suitable for inclusion in a professional portfolio written for a hiring manager or prospective client who understands AI systems but does not know the Part III curriculum.
Required sections:
Problem: What was the business problem at Meridian? What was failing in the manual process? (2–3 sentences)
Architecture: What did you build? Reference ADR-A, ADR-B, ADR-C, and ADR-D by letter and describe each decision in one sentence. Include the architecture’s five-layer structure.
Key decision: Identify the single most consequential architectural decision you made during the build. Why was it consequential?
Failure analysis: Describe one failure you encountered during implementation a fixture that revealed a prompt regression, a governance Note that did not write correctly, a parallel agent branch that merged incorrectly. How did you diagnose it? How did you resolve it?
Retrospective: If you were rebuilding the Meridian platform from scratch with Part III knowledge from the start, what would you design differently? Why?
Outcome: What does the platform produce? What does Meridian’s team now have that they did not have before?
Do not include curriculum language, chapter references, or Part III terminology that would not be understood outside this course. Write as a practitioner, not as a student.
Deliverable 9 Phase 7 Readiness Analysis
Analyze the limitations of the Meridian platform you built and propose three Phase 7 extensions.
Current limitations: Identify three specific capabilities the Part III architecture cannot provide for Meridian. For each, describe the operational consequence what does Meridian fail to do, or do poorly, because of this limitation?
Three proposed Phase 7 extensions: For each: - Name the extension and describe what it adds - Explain which current limitation it resolves - Identify what new architectural components would be required - Estimate relative complexity: Low / Medium / High
ROI analysis: Of the three extensions, identify the one with the highest return on investment for Meridian. Justify your selection using Meridian’s business context (LP reporting obligations, deal volume, MD time cost).
Architectural implications: For your highest-ROI extension, describe in one paragraph what would change in the five-layer architecture from Chapter 3.8. Which layers would be modified? Which components would be added? Which ADRs would need revision?
Candidate Phase 7 extensions (do not limit yourself to these develop your own based on the Meridian build): - Retrieval-Augmented Generation (RAG) for fund thesis: replace the static thesis document with a vector-searchable fund thesis corpus - Real-time market signal integration: replace the mock market signal API with a live funding announcement data feed - Automated LP report generation: produce a quarterly narrative report from the observability data and governance audit trail - Technical dual-approval enforcement for regulatory tier overrides - Multi-fund support: extend the architecture to serve multiple Meridian fund vehicles with different thesis documents and governance policies
Discussion Questions
ADR-A justifies the conditional Agent 4 path for biotech and deep-tech deals based on regulatory risk. If Meridian expands to invest in crypto and Web3 deals, should Agent 4 be extended to cover regulatory risk for those sectors, or should a separate Agent 5 be created? Apply ADR-C’s rationale to justify your answer.
The Tier Validation step in Deliverable 6 flags deals where
deal_governance_tierdoes not matchdeal_override_authorized_bybut it does not block the override. Under what conditions would technical blocking (refusing to setdeal_override_active = trueuntil the correct authorizer acts) be better than flagging and audit review? What would need to be true about Meridian’s team workflow for blocking to be operationally viable?Deliverable 9 asks you to identify Phase 7 extensions. If Meridian’s LP reporting team requested that the AI system generate a one-paragraph narrative summary of why each deal was routed as it was suitable for inclusion in the quarterly LP letter what is the minimum architectural change required? Which ADR would need to be revised, and in what direction?
Chapter Summary
The Meridian Venture Partners Multi-Agent Intelligence Platform is the full realization of Part III. It applies every capability introduced in Chapters 6.0 through 6.8 to a new domain with higher volume, stricter compliance requirements, and more complex agent coordination than the VAP training platform.
The capstone is structured around four architecture decisions (ADR-A through ADR-D) that determine every subsequent design choice. The ADR package is the primary intellectual artifact of the capstone it demonstrates the ability to justify architectural decisions in the specific language of the domain, not in the abstract language of the curriculum.
Part III is complete when the Meridian platform passes both readiness gates, all ten deliverables are submitted, and the portfolio case study is written for a reader who has never heard of Part III. That final constraint is the test: if the case study requires curriculum knowledge to understand, the architecture has not been fully internalized.
Key Principle
The capstone is not a new architecture it is the Part III architecture calibrated for Meridian’s position on three axes: higher volume, larger team with compliance obligations, and more complex agent coordination. Every component has a direct counterpart in the Practical 6.1–6.7 builds.
End of Part III Capstone Meridian Venture Partners Multi-Agent Intelligence Platform
Part III AI Systems Engineering is complete.