Multiple instances execute concurrently; the count is determined at runtime before any instance starts, and all must complete before the process proceeds. The instance count is unknown at design time but is fixed before execution begins.
An AI due diligence system receives a deal submission. The submission includes a founder list — one, two, or five founders, depending on the team. Before any background-check agent runs, the system reads the founder list and determines N. One background-check agent is then spawned per founder. All N agents run in parallel. All must complete before the IC Recommendation step activates.
The key insight: the count is unknowable at design time (each deal has a different team size) but is fully determined before the first agent starts (the founder list is read once, upfront). This enables true parallelism with a deterministic join — unlike 30.37, no new instances can be created mid-execution. The sync gate is safe because N is fixed before any instance begins.
| Metric | Signal |
|---|---|
| Count accuracy rate | Fraction of cases where N matches the true founder count — monitors the most critical step |
| Per-instance P95 latency | 95th percentile background check duration — the slowest instance determines total wall-clock time |
| Parallel speedup ratio | Sequential time / parallel time — quantifies parallelism benefit; degradation signals resource contention |
| IC brief completeness | Fraction of IC briefs with full founder coverage — detects silent instance failures that passed through the join |
| Node | What it does | What it receives | What it produces |
|---|---|---|---|
| Count Founders | Reads deal submission, extracts founder list, determines N. Passes N to the multiple-instance task as the execution count. | Deal submission package | Founder list with N entries; MI count = N |
| Founder Background Check | Runs background research on a single founder: LinkedIn history, prior companies, public records, reference signals, regulatory flags. One agent per founder, all running in parallel. | Single founder profile + research scope | Structured founder profile: exits, credentials, red flags |
| Sync All Checks | AND join: waits for all N background checks to complete. Collects N reports into a unified founder dossier. | N founder profiles | Complete team dossier |
| IC Recommendation | Evaluates the full team dossier against fund investment criteria. Produces a structured IC brief with recommendation and confidence score. | Team dossier + fund thesis | IC brief: recommendation, confidence, key questions |
| Origin of Value | Where it appears | How it is captured |
|---|---|---|
| Future Cashflow | IC Recommendation quality | Parallel background checks cut DD cycle time from hours to minutes. Faster founder diligence increases deal throughput without sacrificing coverage. |
| Governance | Count Founders + Sync All Checks | The count step ensures every founder is covered. The AND join ensures none are skipped. Missing a founder background check is architecturally prevented. |
| Risk Exposure | Count Founders (step 1) | An incorrect N — a founder not listed, a duplicate counted twice — corrupts the entire parallel execution. The count step is the highest-risk single point of failure. |
| Conditional Action | Background Check instances | Each check consumes external API calls (LinkedIn, Crunchbase, public records). Cost scales linearly with N. Large founding teams increase per-case cost proportionally. |
Design principle: count step is the critical path. The parallelism benefit is only realized if Count Founders runs correctly. Instrument this step with schema validation and logging — it is the single point where N is determined, and errors here are unrecoverable downstream.
The Count Founders step misparses the submission and produces N=2 for a three-founder team. The third founder is never checked. The AND join fires after two completions, and the IC brief is produced with a missing founder dossier. The process cannot detect this — it completed "successfully." Fix: validate N against the raw submission before spawning; emit a count-verification event that a monitoring step can audit.
A founder's LinkedIn profile is flagged as private, and the background-check agent enters an infinite retry loop. The AND join never receives this instance's output. The entire process stalls. Fix: apply a per-instance timeout; on timeout, submit a partial report flagged "incomplete" and allow the IC Recommendation step to handle missing data explicitly.
A 12-founder team triggers 12 simultaneous background-check agents, each consuming API rate-limited resources. Rate limit errors cascade and most agents fail. Fix: introduce a concurrency cap (e.g., max 5 simultaneous checks) with a queue; or pre-check API availability before spawning all instances.
| Variant | Modification | When to use |
|---|---|---|
| Capped Parallelism | Instances run in batches of size K rather than all at once | External APIs have rate limits; unbounded parallelism causes systematic failures on large teams |
| Prioritized Instance Order | Count step ranks founders by priority; higher-priority checks run first | Lead founders matter more; early results from key individuals are more valuable than a complete but delayed set |
| Partial-Accept Join | IC Recommendation proceeds with N-1 reports if one instance fails after timeout | Missing one founder check is recoverable; blocking the entire IC brief for one failure is not acceptable |
| Pattern | Relationship |
|---|---|
| 60.62 MI Design-Time | Simpler variant where N is a design constant rather than a runtime variable |
| 60.64 MI No Runtime | Dynamic variant where new instances can be created mid-execution |
| 60.61 MI No Sync | Relaxes the AND join — use when partial results are acceptable |
| 10.11 Pipeline | The Sync All Checks node can feed into a pipeline for further sequential processing |